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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1571>
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>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1571>
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>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1571>
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>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1571>
Copy the code to deal with synchronization objects from the window
buffers to the GLAMOR/GBM code.
The idea is to deal with synchronizations for all pixmaps, even when
there is no window buffer involved.
This is still preparation work for the following commits, no functional
change intended at this point.
v2: Use a "xwl_window_buffer *" instead of a "void *data" (Michel)
v3: Bail early if there's no xwl_window_buffer (Michel)
v4: Rename xwl_window_submit_pixmap() to
xwl_glamor_gbm_wait_release_fence() (Michel)
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1571>
We want to decorrelate the explicit buffer synchronization from the
window buffers, and move that to the GLAMOR/GBM code instead.
To do that, we need to be able to invoke the xwl_window_buffer's
release_callback() routine from outside the window buffer code.
For that purpose, introduce xwl_window_buffer_release() which calls
xwl_window_buffer_release_callback() for us.
This is preparation work for the following changes, no functional change
intended at this point.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1571>
This fixes a hang on simpledrm where min_cursor_height and min_cursor_width is
never established, and drmmode_load_cursor_argb_check would infinitely when
the minimum values where 0 or less.
If the surface window already uses automatic redirection, we can upgrade
to manual redirection and save some blits with common use cases.
This fixes a minor performance regression from a65bb8480a ('Revert
"xwayland/glamor: Avoid implicit redirection with depth 32 parent
windows"') with mutter >= 44.
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1570>
If the manual redirection was done by xwl_present_maybe_redirect_window,
we are in control.
This allows xwl_present_maybe_redirect_window to work as intended again.
Previously, xwl_window_update_surface_window would ignore the window
redirected by xwl_present_maybe_redirect_window, which would result in
xwl_present_maybe_redirect_window undoing the redirection and bailing.
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1570>
This header isn't public and holds defines for code in os/ directory,
so no need to keep it in the global header dir - it's probably better
off in os/ directory - just like we already have with many others.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1389>
Instead of keeping lots of special hacks for Solaris, just rename the
field of struct i386_segment_regs, so we don't need special care anymore.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1548>
The header exists on all supported platform, maybe some might still need
to define _XOPEN_SOURCE to get pow() defined.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1548>
All supported platforms, except Linux, have have to call xf86InitVidMem()
from xf86scanpci(), so we can make the code much simpler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1548>
Since kdrive is only working on Unix'es, we don't need to care whether
that file might not exist on Windows, neither any need for doing so
exlusively on Solaris.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1548>
If a child window of the same size is unmapped, we should stop walking
the tree looking for the surface window to use.
Whatever lies beneath is not visible anyway.
This also fixes an issue with the Damage list becoming corrupted when
destroying a window, because the first thing that DeleteWindow() does
is to unmap the window and crush the window tree underneath it.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Fixes: 3a0fc268 - xwayland: Add xwl_window::surface_window
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1680
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1564>
Remove the previous change which ensured that the xwayland pkgconfig
file was installed into $libdir. This is a breaking change for build
systems searching for the xwayland pkg-config file. The sharedir
location fits xwayland better since the pkg-config file does not contain
linking information, it only contains the data on how to locate the
xwayland binary and which features are enabled.
Signed-off-by: Rouven Czerwinski <rouven@czerwinskis.de>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1543>
Before this change, the xwayland pkgconfig file will always contain an
includedir directive, even though xwayland is not a linkable shared
library:
prefix=/nix/store/3spcjqp5zcyg8arz6dnsj59fal5yk3jy-xwayland-23.2.6
includedir=${prefix}/include
exec_prefix=${prefix}
xwayland=/nix/store/3spcjqp5zcyg8arz6dnsj59fal5yk3jy-xwayland-23.2.6/bin/Xwayland
[…]
Cflags: -I${includedir}
According to a bug reporter this trips up cmake [1], which expects that
the include directory exists, which it does not since xwayland does not
install any header files.
Add the dataonly directive to pkgsconfig.generate() which will remove
the default "." subdir and ensures that includedir is not set inside the
pkgconfig file. Additionally enforce the install directory to
$libdir/pkgconfig, since it otherwise will be installed to
$datadir/pkgconfig, which precludes programs from finding the pkgconfig
because share/pkgconfig is usually not included in the search path.
The resulting pkgconfig does not contain an includedir:
prefix=/nix/store/p7xhdzl65hfhzf36vxykzp2i9cyy7y6c-xwayland-23.2.6
exec_prefix=${prefix}
xwayland=/nix/store/p7xhdzl65hfhzf36vxykzp2i9cyy7y6c-xwayland-23.2.6/bin/Xwayland
have_glamor=true
have_eglstream=true
have_initfd=true
have_listenfd=true
have_verbose=true
have_terminate_delay=true
have_no_touch_pointer_emulation=true
have_force_xrandr_emulation=true
have_geometry=true
have_fullscreen=true
have_host_grab=true
have_decorate=false
have_enable_ei_portal=true
have_byteswappedclients=true
Name: Xwayland
Description: X Server for Wayland
Version: 23.2.6
[1]: https://github.com/NixOS/nixpkgs/pull/309075#issuecomment-2108381428
Signed-off-by: Rouven Czerwinski <rouven@czerwinskis.de>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1543>
The core keyboard before this change always used a layout of "us" even if you
configured the build with another default layout.
Signed-off-by: Michael Dluhosch <michael.dluhosch@gmail.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1549>
The sun_apm.c support was written to a draft version of the interfaces that
were integrated under a different name (SRN - Suspend/Resume Notification)
in 2007 for OpenSolaris, and what eventually became Solaris 11.0. Adopt the
official names and use the system-provided header file for these now.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1540>
Left over from the builtin keyboard driver removed from the Xorg
server in 2006 (commit 3eeb62e8f5).
Requires xorg/driver/xf86-input-keyboard@40ef7d9e24987eb6708d822d0ea070
to build the current keyboard driver with this change.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1541>
This restores the handling of the XRandR emulation for Xwayland rootless
where it was before commit fa7b1c20.
Some compositors may trigger a protocol error if the viewport source is
larger than the actual window size, having that handled in the window
resize hook makes sure we do not regress.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1521>
On 32-bit, the shifts used to initialized the identity CTM overflow and
result in zero instead of the intended 1. This results in a broken
display (on at least i915) when using the modesetting xorg driver.
Fix the invalid CTM by using ULL suffix on the shifts.
Fixes:4e670f1281ad75c5673b6ac75645036d810da8d9
Signed-off-by: Trevor Davenport <trevor_davenport@selinc.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1526>
In xwl_set_shape(), xwl_window_set_input_region() should be called only
when the input shape of the toplevel window changes.
However, given that xwl_window_from_window() is going to walk the
ancestor tree until it finds an xwl_window, that lookup function cannot
be used. Instead, xwl_window_get() should be used. It's going to return
a valid xwl_window object iff the specified window has one associated
with it.
Fixes: a4ed100c0 - xwayland: Set wl_surface input region
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1672
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1516>
If multiple flips become ready for the same MSC, we would previously
execute them all sequentially, one per MSC for sync flips. This could
result in an unbounded flip queue and corresponding memory consumption.
With implicit sync, leave the mailbox handling to the compositor for
async flips though.
v2:
* Use present_vblank_rec::sync_flip.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1664
Fixes: e1f16fb1ac ("xwayland: don't scrap pending present requests")
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1511>
The functions xwl_glamor_dmabuf_import_sync_file and
xwl_glamor_dmabuf_export_sync_file are used to ensure proper
synchronization between clients using PresentPixmapSynced and
compositors that do not support the wp_linux_drm_syncobj_v1 protocol
when presenting by flipping. The acquire point's fence will be imported
as the DMA-BUF's implicit fence before handing it off to the compositor,
and then, after the DMA-BUF has been released, its new implicit fence
will be exported and become the release point's fence which the client
is expected to wait for before re-using the buffer.
Both functions currently set the flags arguments of their respective
ioctls to DMA_BUF_SYNC_READ. When importing a sync file, this means that
any subsequent implicitly synchronized reads from the buffer will not
wait for the fence, and when exporting a sync file it means that the
returned fence may be signaled before preceeding reads from the buffer
have completed.
While this is correct for xwl_glamor_dmabuf_export_sync_file since the
compositor will never write to the buffer, it is incorrect for
xwl_glamor_dmabuf_import_sync_file. To avoid corruption, we need any
reads from the buffer by the compositor to wait on the acquire point's
fence.
As a fix, instead of setting the DMA_BUF_SYNC_READ flag in
xwl_glamor_dmabuf_import_sync_file, we set the DMA_BUF_SYNC_WRITE flag.
This *does* provide the necessary guarantees.
Signed-off-by: Erik Kurzinger <ekurzinger@nvidia.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1509>
Some applications that use client side decorations usually set custom
input shape in order to prevent drop shadows stealing pointer events
from windows below. Currently, the only way to get it is to use some
XFixes APIs.
On the other hand, plenty of wayland compositors use solely the
wl_surface input region to decide what view can receive pointer input,
which results in some pointer input issues around client side drop
shadows because Xwayland doesn't set wl_surface.input_region.
See-also: https://bugs.kde.org/show_bug.cgi?id=448119
Signed-off-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1510>
On DRM lease connector withdrawn event, Xwayland would free the
corresponding xwl_output offered for lease.
However, the pointer is still referenced from the rrLease->outputs[],
meaning that trying to clean up the RANDR DRM leases as done with commit
ef181265 (xwayland: Clean up drm lease when terminating) would cause a
use after free and random crashes.
To avoid that issue, on the connector withdraw event, set the connector
withdrawn flag but do not to remove (i.e. free) the xwayland output if
its is offered for lease.
Then, once the lease is terminated, check for the xwl_outputs with a
withdrawn connector and remove them (once we have no use for them
anymore.
Note that we cannot do that cleanup from xwl_randr_terminate_lease() as
removing the xwl_output will free the RRcrtc resources, which checks for
leases in XRANDR, and calls RRTerminateLease(), which chains back to
xwl_randr_terminate_lease().
v2: Use a "withdrawn_connector" flag to mark outputs to remove (Xaver)
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Xaver Hugl <xaver.hugl@kde.org>
fixes: ef181265 - xwayland: Clean up drm lease when terminating
See-also: https://gitlab.freedesktop.org/xorg/xserver/-/issues/946
See-also: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1130
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1482>
In xwl_randr_request_lease(), the code checks first for leased device,
and then checks for existing output for lease.
The former assumes there are outputs for lease whereas the latter checks
for the output, connector and lease.
So if there is any existing rrLease->outputs[]->devPrivate unset, the
code would crash on a NULL pointer dereference on the first sanity check
before having a chance to reach the second check that would have caught
the problem.
Invert the sanity checks so that we would catch this first and return a
BadValue instead of possibly segfaulting.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Xaver Hugl <xaver.hugl@kde.org>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1482>
Use the connector name as basis for the Xwayland output name in XRANDR,
similar to what we do for regular outputs, instead of the generic
"XWAYLAND<n>" name which changes every time the output is leased.
Prefix the actual name with "lease-" to distinguish from duplicate names
from the regular outputs.
v2: avoid duplicate names (Simon)
v3: Move the check for duplicates to xwl_output_set_name() (Simon)
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1492>
Even though the name provided by either xdg-output or wl_output are
guaranteed to be unique, that might not be the case with output names
between different protocols, such as the one offered for DRM lease.
To avoid running into name conflicts, check that no other existing
output of the same name exists prior to changing the output name.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1492>
This include isn't used by any (known) driver nor included by any other
public header, so no need to keep it in the public module API.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1422>
This header is internal (not installed) and holds definitions for sources
in config/, thus it fells more clean moving it to config/, too.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1357>
With aa3f5023e3, pScreen->devPrivate now is
initialized only once, which uncovered a silent bug in xnestOpenScreen:
It's NULL'ing the pScreen->devPrivate pointer which already had been
initialized by previous miScreenDevPrivateInit() call.
Fixes: aa3f5023e3
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1495>
fix warning:
> In file included from ../hw/xfree86/int10/x86emu.c:11:
> ../hw/xfree86/x86emu/prim_ops.c:2478:9: warning: taking the absolute value of unsigned type 'x86emuu32' (aka 'unsigned int') has no effect [-Wabsolute-value]
> if (abs(div) > 0xff) {
> ^
> ../hw/xfree86/x86emu/prim_ops.c:2478:9: note: remove the call to 'abs' since unsigned values cannot be negative
> if (abs(div) > 0xff) {
> ^~~
> ../hw/xfree86/x86emu/prim_ops.c:2502:9: warning: taking the absolute value of unsigned type 'x86emuu32' (aka 'unsigned int') has no effect [-Wabsolute-value]
> if (abs(div) > 0xffff) {
> ^
> ../hw/xfree86/x86emu/prim_ops.c:2502:9: note: remove the call to 'abs' since unsigned values cannot be negative
> if (abs(div) > 0xffff) {
> ^~~
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1428>
Fix warnings on missing prototypes:
> ../hw/xfree86/os-support/bsd/bsd_VTsw.c:56:20: warning: a function declaration without a prototype is deprecated in all versions of C [-Wstrict-prototypes]
> xf86VTSwitchPending()
> ^
> void
> ../hw/xfree86/os-support/bsd/bsd_VTsw.c:67:17: warning: a function declaration without a prototype is deprecated in all versions of C [-Wstrict-prototypes]
> xf86VTSwitchAway()
> ^
> void
> ../hw/xfree86/os-support/bsd/bsd_VTsw.c:82:15: warning: a function declaration without a prototype is deprecated in all versions of C [-Wstrict-prototypes]
> xf86VTSwitchTo()
> ^
> void
> ../hw/xfree86/os-support/bsd/bsd_init.c:155:16: warning: a function declaration without a prototype is deprecated in all versions of C [-Wstrict-prototypes]
> xf86OpenConsole()
> ^
> void
> ../hw/xfree86/os-support/bsd/bsd_init.c:322:15: warning: a function declaration without a prototype is deprecated in all versions of C [-Wstrict-prototypes]
> xf86OpenPccons()
> ^
> void
> ../hw/xfree86/os-support/bsd/bsd_init.c:347:16: warning: a function declaration without a prototype is deprecated in all versions of C [-Wstrict-prototypes]
> xf86OpenSyscons()
> ^
> void
> ../hw/xfree86/os-support/bsd/bsd_init.c:453:13: warning: a function declaration without a prototype is deprecated in all versions of C [-Wstrict-prototypes]
> xf86OpenPcvt()
> ^
> void
> ../hw/xfree86/os-support/bsd/bsd_init.c:596:17: warning: a function declaration without a prototype is deprecated in all versions of C [-Wstrict-prototypes]
> xf86CloseConsole()
> ^
> void
> ../hw/xfree86/os-support/bsd/bsd_init.c:673:11: warning: a function declaration without a prototype is deprecated in all versions of C [-Wstrict-prototypes]
> xf86UseMsg()
> ^
> void
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1428>
This macro is only used inside xfree86's os-support layer, not by any
(known) drivers. Thus no need to have it exported in the public API.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1456>
It's cleaner to have public headers only holding public stuff and
xf86_os_support seems to be much more appropriate place for this.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1456>
This type is only used inside the os-support layer of xfree86, so it fits
better into xf86_os_support.h, whose purpose is being the primary entry
point into os-support layer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1456>
This function isn't exported at all, so it better fits into xf86_os_support.h,
whose purpose is being the primary entry point into os-support layer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1456>
Make sure everybody who needs stuff from <sys/mman.h> actually includes it,
and dropped the include from xf86_OSlib.h.
Check for all symbols defined by Open Group spec.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1412>
Instead of relying on very indirect includes, it's more more clean when
everybody explicitly includes what he really needs.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1417>
Found no evidence that this define is practically used anywhere, aymore.
Web research just showed up a single ancient .c file (looks like an
Wacom driver) from 1998. Xserver's git history doesn't tell when it
actually had been introduced.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1408>
This had been introduced almost two decades ago, by Dave Airlie (*1) along
with some major IO speed improvement, just in case some driver still needed
the old behaviour - in that case it would call xf86SetReallySlowBcopy(),
so xf86SlowBcopy() would fall back to the old approach emitting an extra
outb() on debug port, in order to slow things down more.
Now aeons have passed and there doesn't seem to be any actual user for this,
so it's time to drop that ancient relic.
*1) commit e717eb82dc
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1402>
The code pieces inside `ifdef DoSubModule` aren't used anymore since very
long time. There's no evidence of this symbol ever been set in the whole
git history, so it must be an really ancient relic, that nobody used for
decades.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1400>
Since we already had to rename some of them, in order to fix name clashes
on win32, it's now time to rename all the remaining ones.
The old ones are still present as define's to the new ones, just for
backwards compatibility.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1355>
Windows' native headers using some our RT_* define's names for other things.
Since the naming isn't very nice anyways, introducing some new ones
(X11_RESTYPE_NONE, X11_RESTYPE_FONT, X11_RESTYPE_CURSOR) and define the old
ones as an alias to them, in case some out-of-tree code still uses them.
With thins change, we don't need to be so extremely careful about include
ordering and have explicit #undef's in order to prevent name clashes on
Win32 targets.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1355>
This pointer allows a DDX to install it's own error print handler. It's really
only intended for DDXes, thus no need to have it exported to modules.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1369>
These functions shouldn't be called by drivers or extensions, thus
shouldn't be exported. Also moving it to separate header, so the
already huge ones aren't cluttered with even more things.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1334>
The header uses macros from Xfuncproto.h - right now it just works by pure
accident since consumers of this header indirectly include Xfuncproto.h
by totally different roads. This is a fragile programming style that deserved
to be cleand up.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1331>
Since we're not using C++ code, thus no trouble w/ name mangling, we don't
need explicit extern "C" { ... } sections in the code. (If we would, we
have to have it in many other places, too)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1331>
When getting an unhandled event from upstream Xserver, a warning
is printed, but it doesn't tell which one yet. Just printing it's
ID should be good enough for now - it's already a good help
for debugging.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1398>
For cleaner code, make sure every source needing something from Xdefs.h
does explicitly include it (not relying on indirect including)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1394>
Compiler warning:
[7/29] Compiling C object hw/xnest/Xnest.p/Display.c.o
In file included from ../include/misc.h:119,
from ../include/screenint.h:50,
from ../hw/xnest/Display.c:24:
../hw/xnest/Display.c: In function ‘xnestOpenDisplay’:
../include/os.h:81:32: warning: argument 2 range [2147483648, 4294967295] exceeds maximum object size 2147483647 [-Walloc-size-larger-than=]
81 | #define xallocarray(num, size) reallocarray(NULL, (num), (size))
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../hw/xnest/Display.c:124:29: note: in expansion of macro ‘xallocarray’
124 | xnestDefaultColormaps = xallocarray(xnestNumDefaultColormaps,
| ^~~~~~~~~~~
In file included from ../include/os.h:54:
/usr/include/stdlib.h:582:14: note: in a call to allocation function ‘reallocarray’ declared here
582 | extern void *reallocarray (void *__ptr, size_t __nmemb, size_t __size)
| ^~~~~~~~~~~~
Since we really don't need more than 2^16 colormaps, using uint16_t here
to silence this warning.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1392>
This doesn't seem to be needed anymore, probably a left over from migration
to libpciaccess. So it can be removed now.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1415>
The sun_vid.c driver seems to be the only actual consumer left, so it
can be dropped from public headers and moved to sun_vid.c instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1414>
SVR3/sysv support had been removed 13 years ago, but there still was
some fallout left. The symbol HAS_SVR3_MMAPDRV never had been set by
autoconf, let alone meson, so this piece of code is really dead.
Fixes: 6ce1908ba4
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1414>
In xwl_source_validate(), the actual box wasn't updated, so we would
possibly copy several times the same first box.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Fixes: aa05f38f3 - xwayland: Add SourceValidate hook
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1485>
xwl_dmabuf_feedback_tranche_target_device always allocates a new
drmDevice for xwl_feedback->tmp_tranche.drm_dev, so the pointers are
never equal here.
Fixes: 6f0b9deed6 ("xwayland: use drmDevice to compare DRM devices")
v2:
* Flip order of checks, so drmDevicesEqual is called only if the
supports_scanout flags match.
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1484>
Fixes leaks:
==13712== 144 bytes in 1 blocks are definitely lost in loss record 4,827 of 7,462
==13712== at 0x48459F3: calloc (vg_replace_malloc.c:1340)
==13712== by 0x49BE94D: drmDeviceAlloc (xf86drm.c:4072)
==13712== by 0x49BFAC9: drmProcessPciDevice (xf86drm.c:4104)
==13712== by 0x49BFAC9: process_device (xf86drm.c:4508)
==13712== by 0x49C35FB: drmGetDeviceFromDevId (xf86drm.c:4670)
==13712== by 0x1AD370: xwl_dmabuf_feedback_main_device (xwayland-dmabuf.c:477)
==13712== by 0x53C03FD: ffi_call_unix64 (unix64.S:104)
==13712== by 0x53BF70C: ffi_call_int (ffi64.c:673)
==13712== by 0x53BFEE2: ffi_call (ffi64.c:710)
==13712== by 0x49AC920: wl_closure_invoke (connection.c:1025)
==13712== by 0x49A8C08: dispatch_event.isra.0 (wayland-client.c:1631)
==13712== by 0x49AA5AB: dispatch_queue (wayland-client.c:1777)
==13712== by 0x49AA5AB: wl_display_dispatch_queue_pending (wayland-client.c:2019)
==13712== by 0x49AAB5E: wl_display_roundtrip_queue (wayland-client.c:1403)
==13712== 576 bytes in 4 blocks are definitely lost in loss record 6,289 of 7,462
==13712== at 0x48459F3: calloc (vg_replace_malloc.c:1340)
==13712== by 0x49BE94D: drmDeviceAlloc (xf86drm.c:4072)
==13712== by 0x49BFAC9: drmProcessPciDevice (xf86drm.c:4104)
==13712== by 0x49BFAC9: process_device (xf86drm.c:4508)
==13712== by 0x49C35FB: drmGetDeviceFromDevId (xf86drm.c:4670)
==13712== by 0x1AD583: xwl_dmabuf_feedback_main_device (xwayland-dmabuf.c:477)
==13712== by 0x1AD583: xwl_window_dmabuf_feedback_main_device (xwayland-dmabuf.c:691)
==13712== by 0x53C03FD: ffi_call_unix64 (unix64.S:104)
==13712== by 0x53BF70C: ffi_call_int (ffi64.c:673)
==13712== by 0x53BFEE2: ffi_call (ffi64.c:710)
==13712== by 0x49AC920: wl_closure_invoke (connection.c:1025)
==13712== by 0x49A8C08: dispatch_event.isra.0 (wayland-client.c:1631)
==13712== by 0x49AA5AB: dispatch_queue (wayland-client.c:1777)
==13712== by 0x49AA5AB: wl_display_dispatch_queue_pending (wayland-client.c:2019)
==13712== by 0x1A1842: xwl_read_events (xwayland-screen.c:566)
==13712== by 0x1A1842: xwl_read_events (xwayland-screen.c:553)
Fixes: 6f0b9deed6 ("xwayland: use drmDevice to compare DRM devices")
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1484>
It's needed when the surface window is a depth 24 descendant of a depth
32 toplevel window.
xwl_source_validate ensures the toplevel window pixmap has valid
contents when a client reads from it, or when the window hierarchy /
geometry changes. It's never called in the normal fullscreen application
case, so there's no GPU copy overhead with that.
v2:
* Don't try to redirect a depth 32 descendant of different-depth
ancestors, the alpha channel wouldn't be handled correctly.
(Olivier Fourdan)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1300>
A later commit will use it to ensure the toplevel window pixmap has
valid contents.
It's hooked up only while any xwl_window->surface_window_damage points
to a non-empty region. So far it's always NULL, so no functional change
intended.
v2:
* Fix trailing whitespace. (Olivier Fourdan)
v3:
* Use toplevel local variable more in xwl_window_update_surface_window.
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1300>
A later commit will use these to (un)redirect the surface window on
demand.
Not used yet, so no functional change intended.
v2:
* Use "surface_window_damage" instead of "surf_win_damage".
(Olivier Fourdan)
* Slightly simplify logic in xwl_unrealize_window.
v3:
* Add comment in xwl_present_maybe_unredirect_window explaining why we
use a timer. (Olivier Fourdan)
v4:
* Rename unredir_timer field to unredirect_timer.
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1300>
It may track a non-toplevel window which fully covers the area of the
window pixmap / Wayland surface. It is now used instead of
xwl_window::toplevel for updating the Wayland surface contents.
The surface_window can now hit the Present page flip path while it's
automatically redirected.
v2:
* Use "surface_window" instead of "surf_win". (Olivier Fourdan)
* Add comment describing surface_window, and describe what
surface_window/toplevel are useful for respectively. (Olivier Fourdan)
* Use surface_window in xwl_realize_window.
v3:
* Backtrack up to the closest opaque ancestor in
xwl_window_update_surface_window. (Olivier Fourdan)
v4:
* Clean up logic for determining the surface window in
xwl_window_update_surface_window, and document it better.
* Handle window_get_damage(xwl_window->surface_window) returning NULL
in xwl_window_update_surface_window.
* Call xwl_window_update_surface_window after xwl_window_buffers_init
in ensure_surface_for_window, since the former may call
xwl_window_buffers_dispose.
* Rename surf/win_pix to surface/window_pixmap in
xwl_window_update_surface_window.
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1300>
Preparation for next commit.
This might change behaviour for non-InputOutput top-level windows.
ensure_surface_for_window getting called and returning non-NULL for
those would seem like a pre-existing bug though.
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1300>
It's always the toplevel window, i.e. either the root window or a child
of it.
Preparation for later commits, no functional change.
v2: (Olivier Fourdan)
* Fix debug build.
* Add comment describing ::toplevel.
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1300>
When a present request is received, Xwayland will check if there is an
existing request targeting the same window and msc and scrap the older
request if so. Alas, this does not interact well the older fence-based
or newer syncobj-based synchronization features of the Present
extension.
Since execution of a request may be delayed for an unknown length of
time while waiting for a fence to be signaled, the target msc computed
upon receiving a request may not match the actual msc at which the
request is executed. Therefore, we cannot determine in advance whether a
more recently received request will make an older request redundant.
This change removes the code to scrap pending present requests.
We must also ensure requests are executed in the correct order even if
their fences are signaled out of order. To achieve this, whenever
execution of a request needs to wait for a fence, execution of any
later-received requests will be blocked until the earlier request is
ready. The blocked requests will be added to a list tracked in the
xwl_present_window struct. Once the earlier request's fence is signaled,
any blocked requests will be re-executed.
Signed-off-by: Erik Kurzinger <ekurzinger@nvidia.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/967>
This protocol allows for explicit synchronization of GPU operations by
Wayland clients and the compositor. Xwayland can make use of this to
ensure any rendering it initiates has completed before the target image
is accessed by the compositor, without having to rely on kernel-level
implicit synchronization.
Furthermore, for X11 clients that also support explicit synchronization
using the mechanisms exposed in the DRI3 and Present extensions, this
Wayland protocol allows us to simply forward the timeline, acquire, and
release points directly to the compositor, ideally avoiding any
premature stalls in the presentation pipeline.
Signed-off-by: Erik Kurzinger <ekurzinger@nvidia.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/967>
Together, DRI3 1.4 and Present 1.4 allow clients to explicitly
synchronize GPU rendering with presentation using DRM syncobjs. Here we
add the necessary support to Xwayland's glamor and Present
infrastructure to enable this functionality.
Signed-off-by: Erik Kurzinger <ekurzinger@nvidia.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/967>
If a presentation request is delayed while waiting for a fence, the
original target msc may no longer be correct. Instead, we should compute
a new target msc in xwl_present_re_execute.
Signed-off-by: Erik Kurzinger <ekurzinger@nvidia.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/967>
Without either implicit or explicit synchronization, the result of rendering is
pretty much undefined, and many glitches can appear. This still doesn't synchronize
buffer release, but it works around most glitches until explicit sync is supported.
Signed-off-by: Xaver Hugl <xaver.hugl@kde.org>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/967>
Implement fractional scale with Xwayland rootful by scaling the content
to the desired fractional scale using a viewport.
For now this applies to Xwayland rootful only.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-By: Kenny Levinsen <kl@kl.wtf>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1197>
Fractional scaling may not be available, or not suitable for the current
configuration (e.g. if running rootless).
Add a helper function to tell whether fractional scaling should be used.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-By: Kenny Levinsen <kl@kl.wtf>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1197>
To support the fractional scale protocol, we need a viewport.
Rename the existing function xwl_window_enable_viewport() to avoid
confusion with the viewport we use for fullscreen XRandR emulation in
rootless mode.
No functional change.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-By: Kenny Levinsen <kl@kl.wtf>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1197>
Recompute and update the global screen scale based on the different
outputs the root window is placed on.
For backward compatibility, this functionality is however disabled by
default and can be enabled using a new command line option "-hidpi".
That option has no effect if Xwayland is running rootless.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-By: Kenny Levinsen <kl@kl.wtf>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1197>
Recompute the window scale each time the window enters or leaves an
output.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-By: Kenny Levinsen <kl@kl.wtf>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1197>
Add a list of outputs a window is placed on, adding an output whenever
the surface enters the output and removing it once it leaves the output.
Note that not all Wayland compositors actually send a leave surface
event on output removal, so we need to make sure to remove the output
from the list for each window, otherwise we might end up pointing to
freed memory.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-By: Kenny Levinsen <kl@kl.wtf>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1197>
By using a sensible scale factor for input even when there is no
viewport enabled, no need to have xwl_window_has_viewport_enabled()
public anymore.
Small cleanup, no functional change.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-By: Kenny Levinsen <kl@kl.wtf>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1197>
The viewport's scale_x/y is currently applied to the motion event only.
Apply the same viewport_scale_x/y to all relevant input coordinates.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-By: Kenny Levinsen <kl@kl.wtf>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1197>
When the viewport is disabled, set the scale x/y back to 1.0 so that we
can apply the scale factor regardless of the viewport being enabled.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-By: Kenny Levinsen <kl@kl.wtf>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1197>
The scale_x/y factor applies when a viewport is in use, rename the
fields to reflect that and distinguish these from the other scale
factors such as the core protocol surface scale and the fractional
scaling.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-By: Kenny Levinsen <kl@kl.wtf>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1197>
Apply the scale factor to the root window and adjust the coordinates and
hotspot location for cursors.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-By: Kenny Levinsen <kl@kl.wtf>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1197>
For now, the global surface scale is always 1, no functional change.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-By: Kenny Levinsen <kl@kl.wtf>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1197>
Keep track of the output scales as advertised by the wl_output protocol.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-By: Kenny Levinsen <kl@kl.wtf>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1197>
Advertise the scaling factor applied to the Xwayland output using the
mechanism of CRTC transforms.
That allows for X11 clients to query the scale factor using XRandR.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-By: Kenny Levinsen <kl@kl.wtf>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1197>
Add a scale factor to the Xwayland output and take the scale into
account when computing the screen size.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-By: Kenny Levinsen <kl@kl.wtf>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1197>
The mode size can be different from the actual output size when a
transformation is at play.
Store the actual mode width/height as well in preparation for adding
support for transforms.
No functional change.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-By: Kenny Levinsen <kl@kl.wtf>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1197>
Use double precision floating point for the screen size to reduce the
rounding issues when using fractional scaling.
Introduce a couple of simple convenient functions that round the
floating point value into an integer and use it in place of directly
accessing the xwl_screen width/height for integer computation.
This is preparation work for the introduction of fractional scaling,
there should be no functional change at this point.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-By: Kenny Levinsen <kl@kl.wtf>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1197>
Commit 0d4a7ed6 put the definition of pcvt_version inside #ifdef __NetBSD__
but left one use of it outside of the ifdefs, resulting in a build failure
on FreeBSD 14.0 in the gitlab CI for xf86-input-keyboard.
../hw/xfree86/os-support/bsd/bsd_init.c:540:21:
error: use of undeclared identifier 'pcvt_version'
pcvt_version.rmajor, pcvt_version.rminor);
^
../hw/xfree86/os-support/bsd/bsd_init.c:540:42:
error: use of undeclared identifier 'pcvt_version'
pcvt_version.rmajor, pcvt_version.rminor);
^
Fixes: 0d4a7ed68 ("bsd_init.c: fix build on OpenBSD")
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1424>
We've got three #define's that are all set at once, on enable_debugging.
A comment in meson.build already asks for consolidating them into one,
so just do it now.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1409>
Historical legacy: the LED ID defines have/had different naming across various
platforms - for better portability of the keyboard driver, those have been
aliased to BSD's naming scheme. Meanwhile, lots of ancient platforms have
been died or moved to other drivers (eg. Linux went to either evdev or libinput
and not supported by the xf86-input-keyboard driver anymore).
The only remaining possible consumer is Solaris. But it has it's own dedicated
code (sun_kbd.c in xf86-input-keyboard), which already using the Solaris' naming.
Therefore, there's no actual consumer of them left, so we can drop them.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1418>
GLAMOR needs that, and the function returns TRUE unless GLAMOR is not
used.
Drop the function xwl_glamor_needs_buffer_flush() and call
glamor_block_handler() when glamor is used.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1386>
Now that we have only one backend, there is no need to initialize or
select between different backends.
Drop the corresponding functions.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1386>
Now that we have only one GBM backend, either it is available and
usable, or we cannot use GLAMOR.
Therefore we can drop the flag "is_available".
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1386>
And call xwl_glamor_gbm_init_egl() directly instead.
Yet, keep the function separate rather than merging it back into
xwl_glamor_init() for clarity of the code.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1386>
That will be used between the generic Xwayland GLAMOR functions and the
GBM implementation.
Move the definition of xwl_glamor_init_gbm() to that new header rather
than in the generic Xwayland GLAMOR header.
This is preparation work to eventually replace the xwl_egl_backend now
that we have only one backend left.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1386>
Now that the NVIDIA proprietary driver has grown support for GBM, the
EGLStream backend for NVIDIA GPUs is now superseded by the standard
GBM backend in Xwayland.
This code path is therefore not used and hardly ever tested.
Remove support for EGLStream in Xwayland.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1386>
Since no evidency of anybody actually using it (nor it ever been used within
recorded git history), it's time to drop this old relic from times before
the great flood.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1403>
The dmabuf support code is scattered across different source files,
making it hard to follow and bloating unrelated sources.
Move the dmabuf related source code to its own source files.
This is just a cleanup aimed at helping with code readability, no
functional change intended.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1111>
After executing a PresentPixmap request using the copy path, Xwayland
will clear the vblank's pixmap field and re-queue it for the next msc so
that on the next frame a PresentCompleteNotify event will be delivered
to the client by present_execute_post.
While this does work, since the pixmap field of the vblank will be NULL
when present_execute_post is called, the mode reported in the event will
always be PresentCompleteModeSkip, even if the request *was* actually
executed with a copy.
To fix this, we introduce a new "copy_executed" flag in the
xwl_present_event struct. If xwl_present_execute sees that this flag is
set, it will fall straight through to present_execute_post like it does
if the window or pixmap is NULL. So, after executing a request with
present_execute_copy, instead of clearing the pixmap field we will set
the copy_executed flag to true. This will cause present_execute_post to
report the correct completion mode to the client when the
PresentCompleteNotify event is delivered on the next frame.
Signed-off-by: Erik Kurzinger <ekurzinger@nvidia.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1254>
Since it's storing an locally defined (ddx-internal) data, it's better
not to abuse some globally defined key for this.
It just happened to work before, since CursorScreenKey is only used by DDX
(and there's only one DDX per executable) and they currently (!) have the
same size (pointer) - but that's a fragile programming style, so clean it up.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1342>
Since it's storing an locally defined (ddx-internal) struct, it's better
not to abuse some globally defined key for this.
It just happened to work before, since CursorScreenKey is only used by DDX
(and there's only one DDX per executable) and they currently (!) have the
same size (pointer) - but that's a fragile programming style, so clean it up.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1342>
It's naming is a bit unprecise: it actually is used for storing
xnestCursorFuncPtr inside a Screen. Thus rename it to
xnestScreenCursorFuncKeyRec to make it bit more clear.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1342>
This header isn't installed, so no external modules could use the
functions declared there. Thus we can unexport it all.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1358>
This function isn't used by any driver and doesn't seem to be useful for them,
thus move it out of the public module API, in order to tidy it up a bit.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1366>
We must not modify the contents of a client pixmap.
If there's an available window buffer, we re-use that for the window
pixmap. Otherwise we just allocate a new one.
This also avoids Present client hangs due to xwl_present_buffer_release
not getting called for the buffer release event.
v2:
* Use xwl_pixmap_get_buffer_release_cb instead of keeping track of the
flip pixmap in xwl_window.
* Dispose of xwl_window_buffer in xwl_window_swap_pixmap called from
damage_report.
v3:
* Use xwl_window->surface_pixmap in damage_report.
v4:
* Don't re-use client pixmaps as window buffers.
* Clear xwl_window_buffer->pixmap before calling
xwl_window_buffer_maybe_dispose in xwl_window_swap_pixmap, to prevent
it from clearing the buffer release callback.
v5:
* Keep using xwl_window_buffers_get_pixmap in xwl_window_attach_buffer.
* Always keep a reference to the old window pixmap in _swap_pixmap,
drop it in damage_report.
Fixes: 6779ec5bf6 ("xwayland: Use window pixmap as a window buffer")
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1633
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1644
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1314>
There will be another caller in a later commit.
v2:
* Bump xwl_window_buffer->refcnt in xwl_window_swap_pixmap, to prevent
xwl_window_set_pixmap from disposing of it.
v3:
* Go back to bumping xwl_window_buffer->refcnt in
xwl_window_buffers_get_pixmap. xwl_window_set_pixmap should no longer
dispose of it now that xwl_glamor_gbm_create_pixmap_for_window is
fixed, and xwl_window_swap_pixmap forgot to bump it if
xwl_window_buffer_get_available returned NULL.
v4:
* Unlink xwl_window_buffer from xwl_window->window_buffers_available
before calling xwl_window_set_pixmap in xwl_window_swap_pixmap, or
that might dispose of it.
v5:
* xwl_window_swap_pixmap does everything xwl_window_buffer_get_available
did before, except for just using the window pixmap if
!xwl_glamor_needs_n_buffering.
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1314>
Each function can get the damage region from the xwl_window instead.
Add xwl_window_get_damage_region helper for this.
v2:
* Use xwl_window_get_damage_region in xwl_window_attach_buffer as well
(Olivier Fourdan)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1314>
These aren't used by any drivers/modules, just DDX'es, so no need to export.
Note: tigervnc does use it, but it has it's own DDX, therefore directly
linked in, just like the in-tree DDX'es which doesn't need exporting.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1349>
This conditional practically only controls whether we have an pointer,
where DDX can plug in it's own VErrorF() handler (currently only xwin
doing that). The cost of having it even when DDX doesn't use it, is
really negligible: it's just one pointer and an extra non-null check
on it per VErrorF() call - a very cold path. Strangely, xwin has extra
Getting rid of this unnecessary complexity that really hasn't any
practical gain.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1329>
Enrico Weigelt, metux IT consult
Olivier Fourdan
Ian Douglas Scott
Alan Coopersmith
nerdopolis
Michel Dänzer
Chenx Dust
Rouven Czerwinski
Yusuf Khan
Michael Dluhosch
Joshua Ashton
Trevor Davenport
Vlad Zahorodnii
Erik Kurzinger
Simon Ser
Tom Yan
Jan Beich
Xaver Hugl
Peter Hutterer