using EGL (e.g., eglQueryString, epoxy_has_egl_extension)
before establishing this connection
enables the GBM/EGL implementation to potentially consume the
WAYLAND_SOCKET fd, which, if closed, will cause the compositor
to kill this xserver
(cherry picked from commit ff8ec59c97)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1702>
The install_demo meson_option was added in
libdecor/libdecor@7106f5e329
which is in the 0.1.1 tag, but not 0.1.0.
If we upgrade the version of meson used in the CI to 1.0.0, then it fails
to build libdecor 0.1.0 with: ERROR: Unknown options: "install_demo"
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
(cherry picked from commit 32adf434b7)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1702>
Clears warning from gcc 14.1:
../dix/resource.c: In function ‘HashResourceID’:
../dix/resource.c:691:44: warning: left shift of negative value
[-Wshift-negative-value]
691 | return (id ^ (id >> numBits)) & ~((~0) << numBits);
| ^~
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
(cherry picked from commit 26a7ab09ea)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1702>
No real harm, but clears warning from gcc 14.1:
../dix/property.c: In function ‘ProcListProperties’:
..//dix/property.c:605:27: warning: dereference of NULL ‘temppAtoms’
[CWE-476] [-Wanalyzer-null-dereference]
605 | *temppAtoms++ = pProp->propertyName;
| ~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
(cherry picked from commit 39f337fd49)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1702>
It shouldn't matter, since it would have a length of 0, but it
clears warnings from gcc 14.1:
../dix/property.c: In function ‘dixChangeWindowProperty’:
../dix/property.c:287:9: warning: use of possibly-NULL ‘data’ where
non-null expected [CWE-690] [-Wanalyzer-possible-null-argument]
287 | memcpy(data, value, totalSize);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../dix/property.c:324:13: warning: use of possibly-NULL ‘data’ where
non-null expected [CWE-690] [-Wanalyzer-possible-null-argument]
324 | memcpy(data, value, totalSize);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
(cherry picked from commit 10cafd0bbe)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1702>
Clears warning from gcc 14.1:
../dix/dixfonts.c: In function ‘SetFontPath’:
../dix/dixfonts.c:1697:28: warning: use of uninitialized value ‘bad’
[CWE-457] [-Wanalyzer-use-of-uninitialized-value]
1697 | client->errorValue = bad;
| ~~~~~~~~~~~~~~~~~~~^~~~~
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
(cherry picked from commit 1a86fba0d9)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1702>
Clears warning from gcc 14.1:
../dix/dixfonts.c:1352:15: warning: use of uninitialized value ‘*c.data’
[CWE-457] [-Wanalyzer-use-of-uninitialized-value]
1352 | free(c->data);
| ~^~~~~~
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
(cherry picked from commit d78836a3a6)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1702>
Commit 96bdc156 added a check for <sys/eventfd.h> to enable DRI3.
DragonFly and OpenBSD however rely on epoll-shim for <sys/eventfd.h>,
so that must be added as a dependency for the <sys/eventfd.h> check.
Fixes: commit 96bdc156 - xwayland: Do not enable DRI3 without eventfd
Suggested-by: Jan Beich <jbeich@freebsd.org>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit 8fe15a60c5)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1702>
DragonFly and OpenBSD rely on epoll-shim to provide eventfd.
Move the check for epoll dependency to the root meson.build script so
that we can use that for the <sys/evenfd.h> check as well.
This is preparation work for the following commits, no functional change
intended at this point.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit 673b56e61c)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1702>
If either the master pointer or keyboard was disabled, the respective
GetMaster() call returns NULL, causing a segfault later accessing the
deviceid.
Fix this by looking in the off_devices list for any master
device of the type we're looking for. Master devices lose the pairing
when disabled (on enabling a keyboard we simply pair with the first
available unpaired pointer).
And for readability, split the device we get from the protocol request
into a new "dev" variable instead of re-using ptr.
Fixes#1611
(cherry picked from commit e7c876ab0b)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1702>
The vidmode extension emulation in Xwayland reports the modeline based
on the current mode.
To do so, it searches for the mode using `xwl_output_find_mode(-1, -1)`
which is supposed to return the current mode, whatever that mode is.
With XRandR emulation, in rootless mode, the default value is the mode
at index 0. That assumption, however is not true when running rootful.
That means that the vidmode extension will always return the highest
mode available, which is 5120x2880, with Xwayland running rootful:
$ xwayland-run -geometry 1024x768 -- xvidtune -show
"5120x2880" 1276.50 5120 5560 6128 7136 2880 2883 2888 2982 -hsync +vsync
Luckily, when Xwayland is running rootful, we have the current mode size
conveniently stored in dedicated fields of the xwayland output struct,
so we can use that to search for the right mode being used and report
that through the vidmode extension:
$ xwayland-run -geometry 1024x768 -- xvidtune -show
"1024x768" 63.50 1024 1064 1176 1328 768 771 775 798 -hsync +vsync
That fixes legacy games using the vidmode extension and rendering at the
wrong size when running within Xwayland rootful.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit e2e5842444)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1702>
The code here assumed a `leave` event always occurs between two `enter`
events. On Sway (and presumably other compositors) this happens even if
the client has destroyed the `wl_surface`, but the client gets a null
`surface` here. (Which presumably on on the wire is the id of the
destroyed surface.)
This seems like a bad thing to rely on, and is easy to avoid. But if
this is correct to assume, the Wayland protocol should be explicit about
this.
(cherry picked from commit 386b54fbe9)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1635>
Now that we won't enable DRI3 if <sys/eventfd.h> is not available, there
is not point in trying to include that header without DRI3.
That allows to build Xwayland with GLAMOR enabled (without DRI3) on
platforms which do not support eventfd.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit 23c295ea8b)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1635>
DRI3 version 1.4 which supports explicit buffers synchronization relies
on the eventfd interface.
As result, building would fail with DRI3 enabled on platforms without
the eventfd interface.
Check for the availability of the sys/eventfd.h header and disable DRI3
support if missing.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit 96bdc156a1)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1635>
This rewrites the shader so that we use the same (more flexible) CSC as
we have for I420 and NV12. This also fixes the reverse of odd/even which
caused chroma shift.
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
(cherry picked from commit 39c8a6f367)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1635>
UYVY videos should be aligned by 2 to avoid breakups in the shader
Fixes: 832b392f7 - glamor: xv: enable UYVY acceleration
Suggested-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Konstantin <ria.freelander@gmail.com>
(cherry picked from commit eb26f32368)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1635>
Check actual BPP by render_format in upload_boxes, not by drawable BPP.
It is required when we used different BPP formats for storing and
rendering (for example, in the case of UYVY).
The problem of UYVY size lies inside method of glamor downloading boxes.
When we set GLAMOR_CREATE_FORMAT_CBCR, it actually uses 16-bit GL and
Pixman formats, but before this change in glamor_download_boxes, that
function deduces GL and Pixman formats from BPP, which is wrong in this
case (will be deduced to 32).
When GL and Pixman format BPP is identical to drawable BPP, this change
does nothing, but when it is different - it will prioritize Pixman
format, not the format deduced from BPP.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1730
Signed-off-by: Konstantin Pugin <ria.freelander@gmail.com>
(cherry picked from commit 75f56b7923)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1635>
Currently, we would start dequeuing events as soon as a device is
resumed, regardless of its capabilities.
If the capabilities are not available, we would just fallback to the
regular XTEST code path and not use input emulation.
As a result, it is very likely that we shall lose the first events until
the compositor resumes first a device with the requested capabilities.
To avoid that issue, start emulating only once we have the requested
capabilities, if they match the seat capabilities.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1732
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit 0525b9a5b9)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1635>
This is a small code refactoring to help with clarity, simply move the
code from the switch case for device resume to a dedicated function.
No functional change.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit 68ec297ee9)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1635>
If glamor_link_glsl_prog() fails, we may jump to the failed code path
which frees the variable vs_prog_string and fs_prog_string.
But those variables were already freed just before, so in that case we
end up freeing the memory twice.
Simply move the free at the end of the success code path so we are sure
to free the values only once, either in the successful of failed code
paths.
Fixes: 2906ee5e4 - glamor: Fix leak in glamor_build_program()
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit 34ea020344)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1635>
Currently, we would log only the event type, use the libei API to also
log the name in plain text, so we can quickly identify the events we're
missing out.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit 1a42fe40d0)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1635>
Since commit d370f1e58, Xwayland can optionally be started rootful and
fullscreen.
To do so, it will setup a viewport to scale the root window to match the
size of the output.
However, if the rootful Xwayland window receives an xdg-surface configure
event before the output definition is complete, as with e.g. the labwc
Wayland compositor, we might end up trying to setup a viewport with a
destination size of 0x0 which is a protocol violation, and that kills
Xwayland.
To avoid that issue, only setup the viewport if the output size is
meaningful.
Also, please note that once the output definition is complete, i.e. when
the "done" event is eventually received, we shall recompute the size for
fullscreen again, hence achieving the desired fullscreen state.
Fixes: d370f1e58 - xwayland: add fullscreen mode for rootful
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1717
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit 66f5e7e96a)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1635>
Clears -Wcalloc-transposed-args warnings from gcc 14.1, such as:
../dix/main.c:165:42: warning: ‘calloc’ sizes specified with ‘sizeof’ in the
earlier argument and not in the later argument [-Wcalloc-transposed-args]
165 | serverClient = calloc(sizeof(ClientRec), 1);
| ^~~~~~~~~
../dix/main.c:165:42: note: earlier argument should specify number of
elements, later size of each element
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
(cherry picked from commit 522f469fe9)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1635>
struct hostent->h_addr_list is of type char**, not const char**.
GCC considers this an error when in C99 mode or later.
Signed-off-by: Joaquim Monteiro <joaquim.monteiro@protonmail.com>
(cherry picked from commit 0ddcd87851)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1635>
Since commit 792758fa ("xwayland: Update lost focus on deactivation"),
in rootful mode, if we receive an "activated" state from xdg-shell
indicating that the surface is no longer active, we shall end up calling
xwl_seat_leave_ptr().
But xwl_seat_leave_ptr() does not actually check whether the seat has
pointer capabilities, and if not, get_pointer_device() will return NULL.
As a result, we would crash using a NULL pointer in GetMaster(). This
typically can happen when using Xwayland rootful on headless compositors
such as "cage" which do not advertise any capabilities for the seat.
To avoid the issue, simply check whether get_pointer_device() returns a
valid non-null device and bail out early otherwise.
Fixes: 792758fa - xwayland: Update lost focus on deactivation
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1700
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit 7203626173)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1592>
With explicit buffer synchronization in use, the window buffers use a
file descriptor for event notification to keep the buffer alive for
synchronization purpose.
When running rootful, the root window (which is visible) is destroyed
directly from the resource manager on server reset, and the window
buffer's eventfd will trigger after the window is destroyed, leading to
a use after free and a crash of the xserver.
To avoid the issue, check whether the window being destroyed is the root
window in rootless mode, and make sure to force the disposal of the
window buffers in that case.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1699
(cherry picked from commit a5e863963e)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1569>
For cases (to come) where we would want to force the disposal of the
window buffers, add a parameter to force the disposal by calling
dispose() directly instead of maybe_dispose().
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit fa04e15afc)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1569>
Right now, we would dispose the xwl_window and all the data associated
with it on unrealize.
But not all window destruction go through the unrealize code path, for
example when the root window (running rootful) is destroyed from the
resource manager on server reset, we do not get to the unrealize window
step, but straight to destroy window.
As a result, we are leaking the xwl_window and all the data associated
with it, for example:
| 65,536 bytes in 1 blocks are possibly lost in loss record 12,462 of 12,488
| at 0x484A0FC: calloc (vg_replace_malloc.c:1675)
| by 0x48B661C: UnknownInlinedFun (pixman-bits-image.c:1273)
| by 0x48B661C: _pixman_bits_image_init (pixman-bits-image.c:1296)
| by 0x48B6754: create_bits_image_internal (pixman-bits-image.c:1349)
| by 0x64180DE: UnknownInlinedFun (cairo-image-surface.c:380)
| by 0x64180DE: UnknownInlinedFun (cairo-image-surface.c:366)
| by 0x64180DE: cairo_image_surface_create (cairo-image-surface.c:432)
| by 0x6346B44: UnknownInlinedFun (libdecor-gtk.c:467)
| by 0x6346B44: libdecor_plugin_gtk_frame_new (libdecor-gtk.c:546)
| by 0x4B7F297: libdecor_decorate (libdecor.c:559)
| by 0x42C6F3: xwl_create_root_surface (xwayland-window.c:1266)
| by 0x42CD97: ensure_surface_for_window (xwayland-window.c:1466)
| by 0x42D0D1: xwl_realize_window (xwayland-window.c:1560)
| by 0x50858F: compRealizeWindow (compwindow.c:279)
| by 0x4FF2A2: MapWindow (window.c:2706)
| by 0x4F9E7F: InitRootWindow (window.c:697)
To avoid that issue, check whether there is still an xwl_window
associated with the X11 window on destroy, and if that's the case,
dispose the xwl_window.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit 0e1a98f52f)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1569>
The wp_linux_drm_syncobj_v1 protocol states that :
| If at surface commit time there is a pending buffer attached but no
| pending release timeline point set, the no_release_point protocol
| error is raised.
So we need to set a release timeline point in any case from the swap
pixmap routine, even for the early out code paths.
Failing to do so may cause a Wayland protocol error that is fatal to the
Wayland client, in this case Xwayland:
| wp_linux_drm_syncobj_surface_v1: error 4: No Acquire point provided
| (EE) failed to dispatch Wayland events: Protocol error
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1688
Fixes: 87bf2cafcc - xwayland: add support for wp_linux_drm_syncobj_v1
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit bc9bf56360)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1569>
Move the code which takes care of submitting pixmaps and the
synchronization points to its own function.
This will allow to reuse that code from different code path.
No functional change intended.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit 33330f0dc9)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1569>
The function xwl_window_swap_pixmap() can be called from two places,
either from xwl_window_attach_buffer() or from damage_report().
When called from xwl_window_attach_buffer(), the new buffer is attached
and the surface committed.
However, when called from damage_report(), a new buffer might not be
attached before the surface is committed.
That's fine with implicit synchronization, but if we use explicit
synchronization, committing a surface without a new buffer attached but
with a release timeline point set is a protocol error:
| If at surface commit time there is a pending release timeline point
| set but no pending buffer attached, a no_buffer error is raised.
To avoid such an issue, add a new parameter to xwl_window_swap_pixmap()
to hint whether it should set the synchronization points, and have the
synchronization points set only from xwl_window_attach_buffer().
v2: Rename param to handle_sync (Michel)
Suggested-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit aab01c7391)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1569>
Now that we have the buffer synchronization implemented in the
GLAMOR/GBM code, switch to use that code.
At this point, there is still not functional change intended, this is
still preparation work for a fix that is still to come.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit 256cef8b20)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1569>
