Not all Xserver versions define that symbol with a numeric value
(1 or 0), some just might not define it at all when disabled.
Using #if instead of #ifdef (as most sites do) will lead to compile break:
../../src/vmware.c:1102:25: error: expected value in expression
#if XSERVER_LIBPCIACCESS
^
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Found by clang 13.0.1:
./common_compat.h:1:9: warning: '_COMMON_COMPAT_H_' is used as a header
guard here, followed by #define of a different macro [-Wheader-guard]
#ifndef _COMMON_COMPAT_H_
^~~~~~~~~~~~~~~~~
./common_compat.h:2:9: note: '_COMMOM_COMPAT_H_' is defined here;
did you mean '_COMMON_COMPAT_H_'?
#define _COMMOM_COMPAT_H_
^~~~~~~~~~~~~~~~~
_COMMON_COMPAT_H_
Fixes: d8c2f85 ("vmware: Fix build warnings")
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/driver/xf86-video-vmware/-/merge_requests/14>
If the CRTC is supposed to be disabled we need to inform the kernel.
Fixes a bug where a secondary screen is left blank, but enabled, when
switching from two displays to one.
Signed-off-by: Ian Forbes <ian.forbes@broadcom.com>
A helper for the PutImage callback in adaptor 'XA G3D Textured Video' was not
taking into account the source data pitches for YV12 format, resulting in
garbled frames for misaligned frame widths. Issue reported by Doug Brown.
This patch is based off the patch proposed by Doug.
Repro of the original issue:
gst-launch-1.0 videotestsrc ! video/x-raw,format=YV12,width=449,height=240 ! xvimagesink
Reported-by: Doug Brown <doug@schmorgal.com>
Signed-off-by: Martin Krastev <krastevm@vmware.com>
Reviewed-by: Zack Rusin <zackr@vmware.com>
Fixes error identified by gcc-12.1.0 compiler
make
CC libvmwgfx_la-vmwgfx_tex_video.lo
vmwgfx_tex_video.c: In function 'stop_video':
vmwgfx_tex_video.c:240:20: error: the comparison will always evaluate as 'true' for the address of 'yuv' will never be NULL [-Werror=address]
240 | if (priv->yuv[i]) {
| ^~~~
Since the functions are pretty similar, Make them look more similar in terms
of memory allocation methods and variable names
Reported-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
The drm present readback command number of cliprects should not exceed
DRM_MODE_FB_DIRTY_MAX_CLIPS. If that number is exceeded, split
the command up.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Deepak Rawat <drawat@vmware.com> #v1
The drm present command number of cliprects should not exceed
DRM_MODE_FB_DIRTY_MAX_CLIPS. If that number is exceeded, split
the command up.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com> #v2
Reviewed-by: Deepak Rawat < drawat@vmware.com> #v1
The drm dirtyfb command would error if the number of cliprects were larger
than DRM_MODE_FB_DIRTY_MAX_CLIPS. If that number is exceeded, split the
command up.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com> #v2
Reviewed-by: Deepak Rawat <drawat@vmware.com> #v1
With a huge number of DMA clip rects we could exceed the device command
buffer command size limit. Fix this by sending multiple DMA commands
when we exceed the limit.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Deepak Rawat <drawat@vmware.com> #v1
Some of the CloseScreen callbacks were referencing XA objects so move the
destruction of the XA state tracker to the end of drv_close_screen to avoid
referencing freed resources.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Deepak Rawat <drawat@vmware.com>
Incorrect DestroyPixmap wrapping previously made the destruction of damage
objects typically happen in damageDestroyPixmap(), leaving a dangling
damage pointer in saa_destroy_pixmap() which was only cleared. However in
some cases that caused us to leak damage objects.
Rework saa initialization somewhat to make sure saa_destroy_pixmap happens
before damageDestroyPixmap and destroy the damage object in saa_destroy_pixmap.
Also add a damage object destruction notifier callback that clears the
saa pixmap damage pointer should the damage object destruction accidentally
happen elsewhere.
This makes sure we don't leak damage objects.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Deepak Rawat <drawat@vmware.com>
We were relying on a linux-specific way to do this. Now that the code is
used also on FreeBSD and there is functionality in libdrm to do this,
Use that functionality.
v2:
Remove unused variable warning in the !VMWGFX_LIBDRM_DEVICENAME case.
Co-authored-by: Johannes Lundberg <johalun0@gmail.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Deepak Rawat <drawat@vmware.com> #v1
We were not properly freeing the port privates.
In order to access those at CloseScreen time, don't free the adaptor pointers
at XV screen init, but hold on to them until CloseScreen.
Also properly free the new_adaptors pointer.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
They were defined as empty strings on all platforms except for the
long unsupported Cray systems which needed to use bitfields to define
any type smaller than 64-bits.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
The XA version was bumped from 2.3 to 2.4 to signal that there were no
significant correctness or performance regressions when running dri3
compared to dri2 on the vmware driver stack.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Deepak Rawat <drawat@vmware.com>
fbGetRotatedPixmap went away with 24bpp support, just treat it as NULL
and we'll do the right thing.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
In some enviroments, "index", "y1" and "y2" are defined globally causing
warnings about shadowed declarations. Fix this.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Some versions of the Gallium loader close our drm file descriptor if
xa_tracker_create() fails (typically 2D VMs.) While this is mostly fixed
everywhere, we implement a workaround to avoid tracking down the same bug
again and again on those setups where this is not fixed in mesa.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Deepak Rawat <drawat@vmware.com>
There are a number of compilation warnings caused by const char pointers
being either explicitly or implicitly cast to char pointers. There
are a number of ABI differences that have hindered this so far, but
make a new attempt using the common_compat.h defines.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Deepak Rawat <drawat@vmware.com>
Compilation on CentOS failed due to some code not being conditioned on
DRI3 headers being present.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Deepak Rawat <drawat@vmware.com>
Add server-side DRI3 support
Currently DRI3 introduces extra latency with gnome-shell for
the following reasons:
1) We enable GLX_EXT_buffer_age. Causes gnome-shell to post fullscreen damage.
2) We enable GLX_OML_sync_control. Cases additional slowdown.
Not exactly sure why.
Probably we want to implement workarounds in mesa so that we don't enable
these extensions for gnome-shell. That can be done with driconf, using some
trickery.
v2: Verify that sharing an ARGB surface as XRGB works before enabling
DRI3.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
This reverts commit d5550b7f83.
The commit was intended to support video drivers, but has the side effect
that GLX thinks our driver supports more than it does.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
