The situation already is handled gracefully (by the next line),
so no need to hard-crash the Xserver.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The module directory has changed to a per ABI folder in the xlibre-xserver.
Now the default value of `xorg-module-dir` will be detected from the `moduledir` variable in xorg-server.pc.
Signed-off-by: b-aaz <b-aazbsd.proton.me>
This pipeline builds the driver against the latest Xserver stable
release as well as current master.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Add the following forms for issue creation:
* Bug report
* Feature request
* Code change
* Documentation update
* Organizational task
* add issue type selection page on "New Issue" call
* mention Github Discussions and the mailing list where appropriate
Part-of: X11Libre/misc#156
Signed-off-by: callmetango <callmetango@users.noreply.github.com>
xnfstrdup is just an alias for XNFstrdup() that doesn't seem to serve
any practical purpose, so it can go away once all drivers stopped using it.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
xnfcalloc is just an alias for XNFcallocarray() that doesn't seem to serve
any practical purpose, so it can go away once all drivers stopped using it.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
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
