On NetBSD gives warning:
In file included from /usr/include/ctype.h:100,
from ../hw/xfree86/common/xf86pciBus.c:35:
../hw/xfree86/common/xf86pciBus.c: In function ‘xf86ParsePciBusString’:
../hw/xfree86/common/xf86pciBus.c:286:27: warning: array subscript has type ‘char’ [-Wchar-subscripts]
286 | if (!isdigit(d[i])) {
| ^
../hw/xfree86/common/xf86pciBus.c:293:23: warning: array subscript has type ‘char’ [-Wchar-subscripts]
293 | if (!isdigit(p[i])) {
| ^
../hw/xfree86/common/xf86pciBus.c:307:23: warning: array subscript has type ‘char’ [-Wchar-subscripts]
307 | if (!isdigit(p[i])) {
| ^
../hw/xfree86/common/xf86pciBus.c:320:23: warning: array subscript has type ‘char’ [-Wchar-subscripts]
320 | if (!isdigit(p[i])) {
| ^
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1455>
(cherry picked from commit 43a57fc6e9)
On NetBSD gives warning:
In file included from /usr/include/ctype.h:100,
from ../hw/xfree86/common/xf86Option.c:39:
../hw/xfree86/common/xf86Option.c: In function ‘xf86NormalizeName’:
../hw/xfree86/common/xf86Option.c:915:25: warning: array subscript has type ‘char’ [-Wchar-subscripts]
915 | if (isupper(*p))
| ^
../hw/xfree86/common/xf86Option.c:916:32: warning: array subscript has type ‘char’ [-Wchar-subscripts]
916 | *q++ = tolower(*p);
| ^
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1455>
(cherry picked from commit 1f861bbb9d)
On NetBSD gives warning:
In file included from /usr/include/ctype.h:100,
from ../hw/xfree86/common/xf86Bus.c:36:
../hw/xfree86/common/xf86Bus.c: In function ‘StringToBusType’:
../hw/xfree86/common/xf86Bus.c:270:22: warning: array subscript has type ‘char’ [-Wchar-subscripts]
270 | if (isdigit(busID[0])) {
| ^
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1455>
(cherry picked from commit 99017bf948)
Even if the manual redirect didn't result in the surface window we
wanted, it might be different again without the redirect.
I don't know of any specific scenario hitting this though, it's more of
a theoretical safeguard.
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1637>
(cherry picked from commit 23dde0860c)
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
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1646>
(cherry picked from commit ff8ec59c97)
$ echo "#foo\nfoo" > custom_config $ X -config custom_config
will trigger the double free because the contents of xf86_lex_val.str
have been realloc()ed aready when free is called in read.c:209.
This copies the lex token and adds all the necessary free() calls to
avoid leaking it
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1176>
(cherry picked from commit fbc034e847)
The functions declared here aren't used by any driver, so no need to keep
them in the public driver API. Since the whole file isn't included by anybody
outside the xserver tree itself, it doesn't need to be installed at all,
so making it internal and move it to Xi directory.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1325>
(cherry picked from commit 03eb593460)
This header includes libxfont2.h, but the dependency isn't stated anywhere,
causing some drivers to FTBS (when libxont2.h is in non-standard location).
Since this header doesn't seem to need including libxfont2.h at all, just
stop including it, instead of adding yet another dependency to server SDK.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1610>
(cherry picked from commit 646831cda2)
Most of the support for such OS'es was removed in 2010 for
xorg-server-1.10.0, but a few bits lingered on, and a few
comments were left out-of-date.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1667>
(cherry picked from commit f35951d83e)
Tidy it up a bit and split the actual request handler from the request
reading loop, making upcoming reworks easier to review (smaller diffs).
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1661>
(cherry picked from commit 0d3ae98661)
Make the code easier to read/understand by scoping variables to where
exactly they're needed. Also a preparation for subsequent reworks
(keep the diff smaller and thus easier to review)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1661>
(cherry picked from commit 3597323d48)
This header makes use of types and functions defined in gcstruct.h and
privates.h. It should include them, instead of demanding it's consumers
having done that before including this file.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1659>
(cherry picked from commit 4db1da86fc)
It's safer to zero-out the cursor-private memory on allocation,
instead of relying on being cleared initialized somewhere later.
Fixes: 3f3ff971ec - Replace X-allocation functions with their C89 counterparts
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1652>
(cherry picked from commit 8d5584558f)
We alread have several of these calls, that aren't interested in result value,
explicitly casting to void. Fixing this up for the remaining ones.
This is helpful for the human reader as well as quality analysis tools.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1648>
(cherry picked from commit f26f17c66a)
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>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1641>
(cherry picked from commit e2e5842444)
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.
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1527>
(cherry picked from commit 386b54fbe9)
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>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1523>
(cherry picked from commit 23c295ea8b)
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>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1631>
(cherry picked from commit 0525b9a5b9)
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>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1631>
(cherry picked from commit 68ec297ee9)
This has been nothing but an alias for two decades now (somewhere in R6.6),
so there doesn't seem to be any practical need for this indirection.
The macro still needs to remain, as long as (external) drivers still using it.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1529>
(cherry picked from commit dec57e5796)
This has been nothing but an alias for two decades now (somewhere in R6.6),
so there doesn't seem to be any practical need for this indirection.
The macro still needs to remain, as long as (external) drivers still using it.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1529>
(cherry picked from commit f446235b71)
This has been nothing but an alias for two decades now (somewhere in R6.6),
so there doesn't seem to be any practical need for this indirection.
The macro still needs to remain, as long as (external) drivers still using it.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1529>
(cherry picked from commit 9ec31d1a88)
This has been nothing but an alias for two decades now (somewhere in R6.6),
so there doesn't seem to be any practical need for this indirection.
The macro still needs to remain, as long as (external) drivers still using it.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1529>
(cherry picked from commit a1fd7e7ba5)
The xnfreallocarray was added along (and just as an alias to) XNFreallocarray
back a decade ago. It's just used in a few places and it's only saves us from
passing the first parameter (NULL), so the actual benefit isn't really huge.
No (known) driver is using it, so the macro can be dropped entirely.
Fixes: ae75d50395
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1529>
(cherry picked from commit 61233adbca)
The xnfallocarray was added along (and just as an alias to) XNFreallocarray
back a decade ago.
No (known) driver is using it, so the macro can be dropped entirely.
Fixes: ae75d50395
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1529>
(cherry picked from commit 6b3c916030)
This has been nothing but an alias for two decades now (somewhere in R6.6),
so there doesn't seem to be any practical need for this indirection.
The macro still needs to remain, as long as (external) drivers still using it.
Fixes: ded6147bfb
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1529>
(cherry picked from commit c55ddd072b)
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>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1620>
(cherry picked from commit 1a42fe40d0)
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>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1621>
(cherry picked from commit 66f5e7e96a)
Several places using _X_ATTRIBUTE_PRINTF macro from X11/Xfuncproto.h
but missing to include it, so it depends on other headers whether it's
included by mere accident, which quickly causes trouble if include order
changes. Cleaning that up by adding explicit include statements.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1580>
(cherry picked from commit b30edf326b)
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>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1606>
(cherry picked from commit 522f469fe9)
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>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1590>
(cherry picked from commit 7203626173)
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
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1589>
(cherry picked from commit a5e863963e)
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>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1589>
(cherry picked from commit fa04e15afc)
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>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1589>
(cherry picked from commit 0e1a98f52f)
