Kernel modesettings support also depends on dri2, see
./hw/xfree86/drivers/modesetting/meson.build
So update meson.build to reflect the changes made in configure.ac by
commit 9c81b8f5b5
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
The window buffer mechanism would free the pixmap and its corresponding
Wayland buffer as soon as window buffers are disposed.
Typically when the X11 window is unrealized, the current window buffer
is still used by the Wayland compositor and yet Xwayland will destroy
the buffer.
As a matter of fact, Xwayland should not destroy the Wayland buffer
before the wl_buffer.release event is received.
Add a reference counter to the window buffer similar to the to pixmap
reference counter to keep the buffer around until the release callback
is received.
Increase that reference counter on the buffer which will be attached to
the surface, and drop that reference when receiving the release callback
notification.
v2: Use a specific reference counter on the buffer rather than relying
on the pixmap refcnt (Michel Dänzer <mdaenzer@redhat.com>)
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Acked-by: Martin Peres <martin.peres@mupuf.org>
The cursor code would destroy the buffer as soon as the cursor is
unrealized on X11 side.
Yet, the Wayland compositor may still be using the buffer as long as a
released callback has not been received.
Increase the reference counter on the pixmap to hold a reference on the
pixmap when attaching it to the surface and use the new pixmap release
callback mechanism to release that reference when the buffer is
released.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Martin Peres <martin.peres@mupuf.org>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
The seat and tablet cursor functions are very similar, factorize the
commonalities to simplify the code and reduce the copy/paste.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Commit 6a5a4e6037 removed the option to
configure useSIGIO option. Indeed, the xfree86 SIGIO support was
reworked to use internal versions of OsBlockSIGIO and OsReleaseSIGIO.
As a result, useSIGIO is no longer needed and can dropped
Fixes: 6a5a4e60 - Remove SIGIO support for input [v5]
Closes: xorg/xserver#1107
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Prabhu Sundararaj <prabhu.sundararaj@nxp.com>
Signed-off-by: Mylène Josserand <mylene.josserand@free-electrons.com>
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
LogMessage logs only when the XLOG_VERBOSITY is >= 1, but by default
XLOG_VERBOSITY is 0, so for example warning about deprected -listen
parameter is never shown when running "Xwayland -listen 32 -help".
Signed-off-by: Mariusz Ceier <mceier+freedesktop@gmail.com>
Calling strlen on char[4] that does not need to contain '\0' is wrong and X
server may end up running into uninitialized memory.
In addition GCC 8 is clever enough that it knows that strlen on char[4] can
return 0, 1, 2, 3 or cause undefined behavior. With this knowledge it can
optimize away the min(..., 4). In reality it can cause the memcpy to be called
with bigger size than 4 and overflow the destination buffer.
Fixes: 83913de25d (xkb: Silence some compiler warnings)
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/288
Signed-off-by: Matt Turner <mattst88@gmail.com>
Avoid out of bounds memory accesses on too short request.
ZDI-CAN 11572 / CVE-2020-14360
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Matthieu Herrb <matthieu@herrb.eu>
ZDI-CAN 11389 / CVE-2020-25712
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Matthieu Herrb <matthieu@herrb.eu>
The region as passed in is in the source pixmap's coordinate space, so
intersecting it with the clipList (which is in screen space) resulted in
disappointment.
Fixes Firefox popups such as the hamburger menu when using the EGL
backend.
v2:
* Drop vblank->x/y_off from RegionTranslate call, since they're always
0 here (present_wnmd_check_flip rejects flips for x/y_off != 0).
Reported-by: Robert Mader <robert.mader@posteo.de>
Tested-by: Robert Mader <robert.mader@posteo.de>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Tested-by: Joakim Tjernlund <joakim.tjernlund@infinera.com> # v1
GCC warned about it:
../../../glx/indirect_dispatch_swap.c:85:1: warning: ‘bswap_CARD64’ defined but not used [-Wunused-function]
85 | bswap_CARD64(const void *src)
| ^~~~~~~~~~~~
By default, the macro DebugPresent() is a no-op but it can be enabled
at build time for debugging purpose.
However, doing so prevents the code to build because one debug statement
tries to make use of a non-existent variable:
present.c: In function ‘ms_present_queue_vblank’:
present.c:147:18: error: ‘vbl’ undeclared (first use in this function)
147 | vbl.request.sequence));
| ^~~
present.c:49:32: note: in definition of macro ‘DebugPresent’
49 | #define DebugPresent(x) ErrorF x
| ^
Fix the build with DebugPresent() by removing the vbl variable from the
debug message.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Querying the GLX_RENDER_TYPE of a GLX context via glXQueryContext will
currently return the render type of the context's FB config, which is
a bitmask of GLX_RGBA_BIT / GLX_COLOR_INDEX_BIT / ... values. However,
this query should really return the render type that was specified
when creating the context, which is one of GLX_RGBA_TYPE /
GLX_COLOR_INDEX_TYPE / .... To enable this, save the render type when
creating a new context (defaulting to GLX_RGBA_TYPE if unspecified),
and then include this value in the context attributes sent to clients.
With !155, the device bus ID received via udev is constructed
properly with the "usb:" prefix. But, it is not enough to
make the following line to work in Section "Device":
BusID "usb:0:1.2:1.0"
Introduce BUS_USB, so the prefix can be distinguished from BUS_PCI
and check the supplied BusID value against device->attribs->busid
in xf86PlatformDeviceCheckBusID().
Signed-off-by: Böszörményi Zoltán <zboszor@pr.hu>
The ID_PATH for a udl device looks like this:
$ udevadm info /dev/dri/card2 | grep -w ID_PATH
E: ID_PATH=pci-0000:00:14.0-usb-0:9.1:1.0
The parsing added in 0816e8fca6 ("linux: Make platform device probe
less fragile"), sets OdevAttributes::busid to "pci:0000:00:14.0", where
drmGetBusid() would have returned "3-9.1:1.0".
Identifying this as a "pci:*" device eventually causes the vendor/device
id check in probeSingleDevice() to fail, because a USB controller isn't
a supported device:
$ udevadm info --path=/devices/pci0000:00/0000:00:14.0 | grep -e VENDOR -e ID_PCI_CLASS
E: ID_PCI_CLASS_FROM_DATABASE=Serial bus controller
E: ID_VENDOR_FROM_DATABASE=Intel Corporation
Instead of parsing out "pci:0000:00:14.0" in this case, use
"usb:0:9.1:1.0" so the device probe will succeed.
Fixes: 0816e8fca6 ("linux: Make platform device probe less fragile")
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
XI2LASTEVENT identifies the bit number, not the mask size in bits. The
mask size in bits is XI2LASTEVENT + 1 and the mask size in bytes is
(XI2LASTEVENT + 8) / 8 or XI2MASKSIZE.
Provide an actual definition of noDriExtension where used, rather than a
tentative definition in a header, to fix compilation with -fno-common
(the default with gcc 10).
EGLStream implementation in Xwayland keeps a list of pending streams for
a window.
If the windows's pixmap is destroyed while there is a pending stream,
the pending stream will point to freed memory once the callback is
triggered.
Make sure to cancel the pending stream if there's one when the pixmap is
destroyed.
v2:
* Use xorg_list_for_each_entry() instead of the safe variant (Michel
Dänzer <mdaenzer@redhat.com>)
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Tested-by: Karol Szuster <karolsz9898@gmail.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Closes https://gitlab.freedesktop.org/xorg/xserver/-/issues/1096
Commit 77658741 - "xwayland: Add buffer release callback" added an API
to deal with Wayland buffer release callbacks.
The EGLstream implementation has its own wl_buffer callback, move that
to the buffer release API instead so we don't have to deal with Wayland
buffers directly and match the other Xwayland pixmap backend
implementations.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Tested-by: Erik Kurzinger <ekurzinger@nvidia.com>
Resolves warnings from Oracle Parfait static analyser:
Error: Misleading macro
Misleading macro [misleading-macro]:
misleading evaluation of ternary '?:' operator in expansion of macro V_ADDR_RB due to missing parentheses
at line 392 of hw/xfree86/int10/generic.c.
'|' operator has higher precedence than ternary '?:' operator inside macro body at line 431
low precedence ternary '?:' operator is hidden by expansion of macro V_ADDR_RB at line 431
Misleading macro [misleading-macro]:
misleading evaluation of ternary '?:' operator in expansion of macro V_ADDR_RB due to missing parentheses
at line 392 of hw/xfree86/int10/generic.c.
'<<' operator has higher precedence than ternary '?:' operator inside macro body at line 431
low precedence ternary '?:' operator is hidden by expansion of macro V_ADDR_RB at line 431
Misleading macro [misleading-macro]:
misleading evaluation of ternary '?:' operator in expansion of macro V_ADDR_RB due to missing parentheses
at line 392 of hw/xfree86/int10/generic.c.
'<<' operator has higher precedence than ternary '?:' operator inside macro body at line 442
low precedence ternary '?:' operator is hidden by expansion of macro V_ADDR_RB at line 442
Misleading macro [misleading-macro]:
misleading evaluation of ternary '?:' operator in expansion of macro V_ADDR_RB due to missing parentheses
at line 392 of hw/xfree86/int10/generic.c.
'<<' operator has higher precedence than ternary '?:' operator inside macro body at line 443
low precedence ternary '?:' operator is hidden by expansion of macro V_ADDR_RB at line 443
Misleading macro [misleading-macro]:
misleading evaluation of ternary '?:' operator in expansion of macro V_ADDR_RB due to missing parentheses
at line 392 of hw/xfree86/int10/generic.c.
'|' operator has higher precedence than ternary '?:' operator inside macro body at line 443
low precedence ternary '?:' operator is hidden by expansion of macro V_ADDR_RB at line 441
Misleading macro [misleading-macro]:
misleading evaluation of ternary '?:' operator in expansion of macro V_ADDR_RB due to missing parentheses
at line 392 of hw/xfree86/int10/generic.c.
'<<' operator has higher precedence than ternary '?:' operator inside macro body at line 443
low precedence ternary '?:' operator is hidden by expansion of macro V_ADDR_RB at line 443
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Resolves warning from Oracle Parfait static analyser:
Error: Uninitialised memory
Uninitialised memory variable [uninitialised-mem-var] (CWE 457):
Possible access to uninitialised memory referenced by variable 'mask'
at line 721 of xkb/XKBMisc.c in function 'XkbUpdateKeyTypeVirtualMods'.
Path in callee avoiding write at line 720
mask allocated at line 718
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Resolves warning from Oracle Parfait static analyser:
Error: Unchecked result
Unchecked result [unchecked-result-call-X]:
Unchecked return value from call to XOpenDisplay. Value display must be ch
ecked to ensure this function was successful.
at line 73 of hw/dmx/examples/xbell.c in function 'main'.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Resolves warning from Oracle Parfait static analyser:
Warning: Impossible or redundant condition
Impossible or redundant condition [impossible-redundant-condition]:
Condition 'dev != NULL' of branch is determined by previous branch
at line 270 of dix/devices.c in function 'AddInputDevice'.
Condition 'dev != NULL' from this branch implies following branch is always true at line 262
Fixes: commit 493ad83323
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
It runs XTS via piglit on (non-rootless) Xwayland on weston using the
headless backend.
Xwayland might use glamor if enabled in the build, but we're making sure
it uses software rendering.
v2:
* Use weston-info to wait for weston to be ready, instead of just a
fixed sleep. (Martin Peres)
v3:
* Build wayland 1.18 & weston 9.0 locally, since the packages in Debian
buster are too old for current Xwayland.
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
By its nature, testing incurs a risk of breaking something every time
we bump the image.
This requires building wayland-protocols locally, since the package in
buster is too old for current Xwayland.
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
They now ensure the image is up to date in forked projects, and we no
longer need to reconstruct the image name.
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
As Xwayland is usually spawned by the Wayland server/compositor, its
command line options are not always adjustable.
Yet, if EGLStream is not supported in a given Xwayland build, the option
will do nothing (yet we must still accept it otherwise Xwayland would
refuse to run if the Wayland compositor uses it).
If Xwayland was built without support for EGLStream, there is not point
in showing the option in the help message though.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Martin Peres <martin.peres@mupuf.org>
The command line options "-shm" is used to instruct Xwayland to prefer
shared-memory for passing buffers to the Wayland server, rather than
using glamor and DRI3.
The option was there from the beginning, yet not documented in the
"-help" message.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Martin Peres <martin.peres@mupuf.org>
With autoconf, hashtable support is built along with Xres support.
Yet, glvnd also use it, so when disabling Xres from configure, the
build will fail at link time because hashtable functions are not
available.
Untie the build of hashtable from Xres support, just like meson build
does.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1091
One general assumption in Xwayland is that the xwl_window remains the
same for all the child windows of the toplevel window.
When mapping a new X11 window, ensure_surface_for_window() checks for an
existing xwl_window by using xwl_window_get() which will just check for
the registered xwl_window for the window.
That means that a client mapping a child window of an existing window
with a xwl_window will get another different xwl_window.
If an X11 client issues a Present request on the parent window, hence
placed underneath its child window of the same size, the Wayland
compositor may not send the frame callback event for the parent's
Wayland surface which is reckoned to be not visible, obscured behind
the other Wayland surface for the child X11 window.
That bug affects some games running in wine which may get 1 fps because
the repaint occurs only on timeout with a long interval (as with, e.g.
https://bugs.winehq.org/show_bug.cgi?id=47066)
Fix ensure_surface_for_window() by using xwl_window_from_window() which
will walk the window tree, so that a child window won't get another
xwl_window than its parent.
https://gitlab.freedesktop.org/xorg/xserver/-/issues/1099
See-also: https://bugs.winehq.org/show_bug.cgi?id=47066
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
When running non-rootless, Xwayland requires that the Wayland compositor
supports the XDG-WM-Base protocol.
Check for XDG-WM-Base protocol support at startup and exit cleanly if
missing rather than segfaulting later in ensure_surface_for_window()
while trying to use xdg_wm_base_get_xdg_surface().
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
When making a pixmap exportable, glamor will currently create a temporary
exported pixmap backed by a GBM bo, with the devKind updated to the stride of
the bo. However, when the backing of the exported pixmap is swapped into the
original, the devKind of the original is not updated.
Some GBM bos may get implicitly padded, in which case the devKind of the pixmap
will not match the stride of the backing bo. For example, an 800x600 pixmap will
have a devKind of 3200, but the bo's stride will be 3328. This can cause
corruption with PRIME, when the sink uses the wrong stride to display the shared
pixmap.
This commit changes glamor_make_pixmap_exportable() to update the devKind of the
original pixmap after it swaps exported pixmap's backing into it, keeping
everything consistent.
Fixes issue #1018.
Signed-off-by: Alex Goins <agoins@nvidia.com>
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>