Couldn't find a trace where it actually had been used, so there doesn't
seem to be any reason while still keeping it around.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1512>
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>
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>
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>
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>
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>
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>
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>
Reduce #ifdef cluttering in os/utils.c a little bit my moving the (built-time-)
conditional printing of the help message into serverlock.c
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1320>
These functions work on server process level, and shouldn't be touched
by drivers at all, thus shouldn't be exported to them.
(couldn't find any driver/module using these symbols)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1320>
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>
If XkbComputeGetGeometryReplySize() returns an error, the XkbGeometryRec won't
be freed, since we're bailing out too early and not calling XkbSendGeometry().
Having XkbSendGeometry() responsible for freeing that struct is unnecessarily
complicated anyways, so move that to ProcXkbGetGeometry() and do it also when
XkbComputeGetGeometryReplySize() failed.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1622>
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>
Since we already had incident where a break in security extension went to
master unnoticed, it's better to enable it in CI build.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1617>
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>
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>
For now, new selection objects are only created in ProcSetSelectionOwner()
when dixLookupSelection() can't find the requested one (returns BadMatch).
When somebody's trying to listen on a not-yet existing selection, via
XFixesSelectSelectionInput() -- XFIXES:SelectSelectionInput message -- he's
also getting BadMatch. The spec isn't explicitly clear on the exact behaviour
in those specific situations: it doesn't tell anything about selection's
lifetimes (when are they actually *created* or *destroyed*), just about their
ownership.
But there are real-world clients not expecting an error here and crashing
with a BadMatch error.
Since the spec doesn't mandate any Selection lifetime, it's safe to assume,
they can be created as-needed (as other related code paths already do).
Doing so ensures such an error cannot happen anymore.
XACE consumers get properly notified by the new Selection object creation
(eg. SElinux is attaching it's private data to it). And all callers already
prepared to get a cleared Selection object, because that's always been a
perfectly normal situation - Selection objects never get removed again,
just cleared.
Fixes: 601fd0fd8 - xfixes/xace: fix pointer type mismatch on XFixesSelectSelectionInput()
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1574>
It was previously checking out the default branch into the $DRIVER
subdirectory, and the requested tag into the current subdirectory,
but then proceeding to build the $DRIVER subdirectory.
Fixes: 89b7f4501 ("CI: add a driver build stage to check for header breakage")
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1607>
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>
../hw/xfree86/os-support/bsd/bsd_init.c: In function ‘xf86CloseConsole’:
../hw/xfree86/os-support/xf86_os_support.h:22:6: error: ‘dispatchException’ undeclared (first use in this function)
22 | if (dispatchException & DE_TERMINATE) { \
| ^~~~~~~~~~~~~~~~~
../hw/xfree86/os-support/bsd/bsd_init.c:634:13: note: in expansion of macro ‘xf86FatalError’
634 | xf86FatalError("xf86CloseConsole: KDDISABIO failed (%s)",
| ^~~~~~~~~~~~~~
../hw/xfree86/os-support/xf86_os_support.h:22:6: note: each undeclared identifier is reported only once for each function it appears in
22 | if (dispatchException & DE_TERMINATE) { \
| ^~~~~~~~~~~~~~~~~
../hw/xfree86/os-support/bsd/bsd_init.c:634:13: note: in expansion of macro ‘xf86FatalError’
634 | xf86FatalError("xf86CloseConsole: KDDISABIO failed (%s)",
| ^~~~~~~~~~~~~~
../hw/xfree86/os-support/xf86_os_support.h:22:26: error: ‘DE_TERMINATE’ undeclared (first use in this function); did you mean ‘ACTION_TERMINATE’?
22 | if (dispatchException & DE_TERMINATE) { \
| ^~~~~~~~~~~~
../hw/xfree86/os-support/bsd/bsd_init.c:634:13: note: in expansion of macro ‘xf86FatalError’
634 | xf86FatalError("xf86CloseConsole: KDDISABIO failed (%s)",
| ^~~~~~~~~~~~~~
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1575>
We can directly use calloc() as all other places do.
If we wanna have an convenient macro for struct allocation, that would be the
job of a separate patch queue and should be done consequently, treewide.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1586>
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>
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>