Currently, Xwayland creates a pixmap backed by shared memory buffer as
soon as an X11 cursor is realized, which is destroyed when the cursor is
eventually unrealized.
If an X11 client is leaking cursors, Xwayland will be creating new
pixmaps continuously, which will eventually cause an error once the
limit is reached, and get Xwayland killed.
However, we do not need the shared memory buffer to stay around, we
already have the buffer retention mechanism which will take care of
keeping the buffer around until the Wayland compositor is done with it,
so we could just create and destroy the pixmap as needed when setting
the cursor.
That would not fix the leak in the X11 application, yet that would
mitigate the risk of Xwayland being killed by reaching the shared memory
limits, until the client itself reaches the limit of X11 resources.
v2: Don't increase the pixmap refcnt to destroy it just after (Michel)
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Suggested-by: Michel Dänzer <michel@daenzer.net>
See-also: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1773
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1754>
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>
The cursor in DIX is actually split in two parts, the cursor itself and
the cursor bits, each with their own devPrivates.
The cursor itself includes the cursor bits, meaning that the cursor bits
devPrivates in within structure of the cursor.
Both Xephyr and Xwayland were using the private key for the cursor bits
to store the data for the cursor, and when using XSELINUX which comes
with its own special devPrivates, the data stored in that cursor bits'
devPrivates would interfere with the XSELINUX devPrivates data and the
SELINUX security ID would point to some other unrelated data, causing a
crash in the XSELINUX code when trying to (re)use the security ID.
CVE-2024-0409
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
When using colored X11 cursors, the colors would appear wrong, yellow
would show white, green would show as cyan, and blue would show black
whereas red would show fine.
This is because the code expanding the cursor data accounts for green
for both green and blue channels. Funnily this bug has been there from
the beginning.
Fix the issue by correctly account for the color channels.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1303
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
The code to clear a cursor pending frame callback was duplicated in
multiple places in the code.
Introduce a new xwl_cursor_clear_frame_cb() function and remove the
duplicated code.
No functional change.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
It just make more sense to keep xwl_cursor_release() with the rest of
the cursor code.
No functional change.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
Two different functions in xwayland-cursor.c and xwayland-input.c use
the same name xwl_seat_update_cursor() which is confusing when reading
the code.
Rename xwl_seat_update_cursor() to xwl_seat_update_all_cursors() in
xwayland-cursor.c to help with readability of the code.
No functional change.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
If the buffer is NULL, do not even try to attach it, and risk a Wayland
protocol error which would be fatal to us.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Martin Peres <martin.peres@mupuf.org>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
https://gitlab.freedesktop.org/xorg/xserver/-/issues/1156
Xwayland won't emulate XWarpPointer requests if the cursor is visible,
this is to avoid having the cursor jumping on screen and preventing
random X11 clients from controlling the pointer in Wayland, while
allowing games which use that mechanism with a hidden cursor to work in
Xwayland.
There are, however, games which tend to do it in the wrong order, i.e.
show the cursor before moving the pointer, and because Xwayland will not
allow an X11 client to move the pointer while the cursor is visible, the
requests will fail.
Add a workaround for such X11 clients, when the cursor is being shown,
keep it invisible until the cursor is actually moved. This way, X11
clients which show their cursor just before moving it would still have a
chance to succeed.
v2: Add a timeout to show the cursor for well behaved clients.
v3: Some cleanup (Michel)
v4: Do not cancel cursor delay when updating the cursor to avoid
delaying cursor visibility indefinitely if the client keeps
settings different cursors (Michel)
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Tested-by: Jaap Buurman jaapbuurman@gmail.com
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/734
The cursor code would destroy the buffer as soon as the cursor is
unrealized on X11 side.
Yet, the Wayland compositor may still be using the buffer as long as a
released callback has not been received.
Increase the reference counter on the pixmap to hold a reference on the
pixmap when attaching it to the surface and use the new pixmap release
callback mechanism to release that reference when the buffer is
released.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Martin Peres <martin.peres@mupuf.org>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
The seat and tablet cursor functions are very similar, factorize the
commonalities to simplify the code and reduce the copy/paste.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Now that each source and header should be in order, we can safely cleaup
the last remaining bits from the main `xwayland.h` which is not needed
anymore and can be removed.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Move Xwayland screen related code to a separate source file and header.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Move the Xwayland cursor declarations to their own header file.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Move the Xwayland input declarations to their own header file.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Currently, `xwayland.h` contains all the declarations, which is a bit
awkward and hard to follow.
Move the SHM relevant declarations to their own header file.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
When a viewport is set, damage will only work properly when using
wl_surface_damage_buffer instead of wl_surface_damage.
When no viewport is set, there should be no difference between
surface and buffer damage.
This is a preparation patch for using viewport to add support for fake
mode-changes through xrandr for apps which want to change the resolution
when going fullscreen.
Changes by Hans de Goede <hdegoede@redhat.com>:
-Split the damage changes out into their own patch
-Add xwl_surface_damage helper
-Also use buffer_damage / the new helper for the present and cursor code
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
In non-rootless mode, not all pixmaps need a wl_buffer backing.
Suggested-by: Twaik Yont (@twaik) in #834
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Hiding the tablet tool cursor results in it being hidden forever after.
This is due to the stale frame callback that will neither be disposed
or replaced. This can be reproduced in krita (X11) as the pointer
cursor is hidden while over the canvas.
Clearing the frame callback ensures the correct behavior in future
xwl_tablet_tool_set_cursor() calls (i.e. a new cursor surface being
displayed, and a new frame callback created), and is 1:1
with xwl_seat_set_cursor() for pointers.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
From the bug: "What happens if bits->width is less than 8? :)"
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=103012
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Each xwl_tablet_tool gets a xwl_cursor, as on wayland each of those
will get an independent cursor that can be set through
zwp_tablet_tool.set_cursor.
However, all tools (and the pointer) share conceptually the same VCP
on Xwayland, so have cursor changes trigger a xwl_cursor update on
every tool (and the pointer, again). Maybe Xwayland could keep track
of the most recent device and only update that cursor to get better
visual results, but this is simpler, and it's going to be odd
anyway...
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Ping Cheng <ping.cheng@wacom.com>
This struct takes away the cursor info in xwl_seat, and has
an update function so we can share the frame handling code
across several xwl_cursors.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Ping Cheng <ping.cheng@wacom.com>
After an X cursor is unrealized, the seat's corresponding x_cursor is
cleared, but if a frame callback was pending at the time, it will
remain and thus prevent any further cursor update, leaving the window
with no cursor.
Make sure to destroy the frame callback, if any, when that occurs, so
that next time a cursor needs to be set, it won't be ignored for a frame
callback that will never be triggered.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1389327
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Rui Matos <tiagomatos@gmail.com>
Emulate pointer warps by locking the pointer and sending relative
motion events instead of absolute. X will keep track of the "fake"
pointer cursor position given the relative motion events, and the
client warping the cursor will warp the faked cursor position.
Various requirements need to be met for the pointer warp emulator to
enable:
The cursor must be invisible: since it would not be acceptable that a
fake cursor position would be different from the visual representation
of the cursor, emulation can only be done when there is no visual
representation done by the Wayland compositor. Thus, for the emulator
to enable, the cursor must be hidden, and would the cursor be displayed
while the emulator is active, the emulator would be destroyed.
The window that is warped within must be likely to have pointer focus.
For example, warping outside of the window region will be ignored.
The pointer warp emulator will disable itself once the fake cursor
position leaves the window region, or the cursor is made visible.
This makes various games depending on pointer warping (such as 3D
first-person shooters and stategy games using click-to-drag-map like
things) work.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
In Xwayland's xwl_unrealize_cursor(), the x_cursor is cleared up only
when a device value is provided to the UnrealizeCursor() routine, but
if the device is NULL as called from FreeCursor(), the corresponding
x_cursor for the xwl_seat is left untouched.
This might cause a segfault when trying to access the unrealized
cursor's devPrivates in xwl_seat_set_cursor().
A possible occurrence of this is the client changing the cursor, the
Xserver calling FreeCursor() which does UnrealizeCursor() and then
the Wayland server sending a pointer enter event, which invokes
xwl_seat_set_cursor() while the seat's x_cursor has just been
unrealized.
To avoid this, walk through all the xwl_seats and clear up all x_cursor
matching the cursor being unrealized.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The frame callback set up via wl_surface_frame() needs to be freed with
wl_callback_destroy() or we'll leak memory.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97065
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
On cursor unrealize, the associated pixmap is destroyed, make sure we
clear the pointer from the private resource and check for the value
being non-null when setting or destroying the cursor.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96246
This is (eventually) called during
InitializeSprite() → *pScreen->SetCursorPosition → miPointerSetCursorPosition
when a device is set to floating. We don't do anything special outselves, but
we need to pass on to the next layer to make sure the device is initialized
properly. Otherwise, pScreen stays NULL and eventually crashes the server when
we try to clean up behind us.
Test case: grab a device → floats it, ungrab again → crash
Reported-by: Jason Gerecke <killertofu@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
In some extreme cases with animated cursors at a high frame rate we
could end up filling the wl_display outgoing buffer and end up with
wl_display_flush() failing.
In any case, using the frame callback to throttle ourselves is the
right thing to do.
Signed-off-by: Rui Matos <tiagomatos@gmail.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Started out as an Xorg module to be used from Xorg drivers to let
Xorg run under a wayland server. The idea was to be able to reuse the
2D acceleration from the Xorg driver. Now with glamor being credible,
a better plan is to just make Xwayland its own DDX, similar to Xwin
and Xquartz. This is a much better fit, as much of the code in the
original approach had to hack around Xorg doing Xorg things like take
over the VT, probe input devices and read config files. Another big win
is that Xwayland dosn't need to be setuid root.
The Xwayland support for DRI3, Glamor and render nodes was done by
Axel Davy <axel.davy@ens.fr>, who also did a lot of work on the rebase
to the Xwayland DDX.
Contributions from:
Christopher James Halse Rogers <christopher.halse.rogers@canonical.com>
Corentin Chary <corentin.chary@gmail.com>
Daniel Stone <daniel@fooishbar.org>
Kristian Høgsberg <krh@bitplanet.net>
Robert Bragg <robert@linux.intel.com>
Scott Moreau <oreaus@gmail.com>
Tiago Vignatti <tiago.vignatti@intel.com>
Giovanni Campagna <gcampagn@redhat.com>
Jonas Ådahl <jadahl@gmail.com>
Ray Strode <rstrode@redhat.com>
Trevor McCort <tjmccort@gmail.com>
Rui Matos <tiagomatos@gmail.com>
Axel Davy <axel.davy@ens.fr>
Jasper St. Pierre <jstpierre@mecheye.net>
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Axel Davy <axel.davy@ens.fr>
Enrico Weigelt, metux IT consult
Olivier Fourdan
Robert Mader
Carlos Garnacho
Jonas Ådahl
Peter Hutterer
Rui Matos
Kristian Høgsberg