Commit 3c07a01c4 (xwayland: Use xdg-output name for XRandR) changed the
logic to use a fixed sized buffer allocated on the stack to pass to
RROutputCreate() which would then copy it.
Valgrind complains about this:
== Conditional jump or move depends on uninitialised value(s)
== at 0x49954B: MakeAtom (atom.c:87)
== by 0x5108B3: RRMonitorCrtcName (rrmonitor.c:33)
== by 0x510BBB: RRMonitorSetFromServer (rrmonitor.c:92)
== by 0x511882: RRMonitorMakeList (rrmonitor.c:373)
== by 0x512175: ProcRRGetMonitors (rrmonitor.c:634)
== by 0x508091: ProcRRDispatch (randr.c:748)
== by 0x4A860E: Dispatch (dispatch.c:546)
== by 0x4B692F: dix_main (main.c:271)
== by 0x431C90: main (stubmain.c:34)
== Uninitialised value was created by a stack allocation
== at 0x42122C: xwl_output_create (xwayland-output.c:816)
This is actually harmless, but also simple to avoid by just initializing
the content of the array with zeros, so let's just fix that.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Fixes: commit 3c07a01c4 - xwayland: Use xdg-output name for XRandR
If we allocated with implicit modifiers, then we shouldn't use the
modifier returned by gbm_bo when checking whether the modifier is
supported or not, since it won't be if the compositor only advertises
implicit modifiers, nor should we use the modifier when creating the
Wayland buffer object, as it wasn't explicitly advertised.
Fixes: c6f2598a4 ("xwayland: don't fall back to wl_drm with explicit modifier")
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
If we're using implicit modifiers, we'll pass NULL and zero modifiers.
Lets just use the legacy API directly instead.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
The linux_dmabuf_v1 protocol doesn't guarantee any DRM node type:
the compositor may send a primary node or a render node. Use
drmDevice so that device comparisons are node-type-insensitive.
Signed-off-by: Simon Ser <contact@emersion.fr>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1447
With wl_pointer.axis_v120 support, the wl_seat supported version has
been bumped to 8, but Xwayland is still using MAP_SHARED which is
prohibited, wl_seat version 7 and above enforces the use of MAP_PRIVATE
for keymaps.
Use MAP_PRIVATE for the keymaps mmap().
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1512
Fixes: 3a02f56b4 - hook up wl_pointer.axis_v120 events
It's incorrect to strip an explicit modifier. Daniels' docs [1]
states:
> when importing a buffer, the user may supply `DRM_FORMAT_MOD_INVALID` as the
> buffer modifier (or not supply a modifier) to indicate that the modifier is
> unknown for whatever reason; this is only acceptable when the buffer has
> not been allocated with an explicit modifier
[1]: https://lore.kernel.org/dri-devel/20210905122742.86029-1-daniels@collabora.com/
Signed-off-by: Simon Ser <contact@emersion.fr>
When the modifier is not supported by the compositor, and the
DMA-BUF contains multiple planes, xwl_pixmap->buffer is NULL.
Avoid crashing when calling wl_buffer_add_listener().
Signed-off-by: Simon Ser <contact@emersion.fr>
With the addition of linux_dmabuf v4, the code adds dev_t in various
places but did not include <sys/types.h>.
While that works on glibc, it may fail to build on other libc
implementations such as musl libc.
Make sure to explicitly include <sys/types.h> where we use dev_t.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1445
Fixes: bddfe190de - Implement linux_dmabuf_feedback event handlers
This allows developers to setup Xwayland as a subproject of a
Wayland compositor, and have it correctly pick up the features
advertised in the dependency variables.
Signed-off-by: Simon Ser <contact@emersion.fr>
Remove the xwayland.pc.in file:
- This avoids writing down each pkg-config variable twice: once in
the Meson files to set the configuration data, once in the .pc.in
file to print it.
- We'll be able to re-use the same variables for use as a
subproject.
Signed-off-by: Simon Ser <contact@emersion.fr>
If wl_output provides us with an output name, use that as well.
If we have both xdg_output.name and wl_output.name (from version >= 4),
prefer the latter.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>#
See-also: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/189
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
With the wl_output protocol, the actual bind to the interface is done in
xwl_output_create().
Pass the version number from the registry so we can bind to the minimum
version.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Currently, Xwayland assigns sequential output names for XRandR. When an
output is hotplugged, a new name is assigned sequentially (XWAYLAND0,
XWAYLAND1, etc.). This is a problem because if a monitor is unplugged
and plugged again, it will get a new name each time.
Luckily, xdg-output provides us with a name for the outputs.
Even though the protocol states that the name is not a reflection of the
underlying DRM connector name, it is to remain consistent across
sessions with the same hardware and software configuration.
So we could use the xdg-output name for the XRandR reported name for the
output.
Doing so is a bit tricky though, because the output name is set at
creation and is not supposed to change. The xdg-output event that
provides us with the name will come at a later time.
So we just allocate a default fixed size for the output name at creation
and just replace the default output name with the xdg-output name when
that is known.
Also, historically, some X11 clients were expecting output names in
Xwayland to be named XWAYLAND<x> and used that to check whether they
were running on Xwayland. Those clients should now use the Xwayland X11
extension which is designed specifically for that purpose.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1353
See-also: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/954
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Since commit 204f10c2, we notify XRandR clients that the randr
configuration has changes as soon as an new output is created.
Yet, this might be premature, considering that at that point, we are
still to receive the wl_output and xdg-output events that will most
likely change the setup.
So instead of calling RRTellChanged() from xwl_output_create(), wait
until we get to call apply_output_change(), which occurs after the done
events from both xdg-output and wl_output are received.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Some drivers (e.g. AMD GFX8-) don't support explicit format
modifiers. On these drivers, gbm_bo_create_with_modifiers()
will fail. This results in "Error getting buffer" in the logs
later on with all X11 windows staying invisible.
Fallback to the modifier-less API gbm_bo_create() in that case.
Signed-off-by: Simon Ser <contact@emersion.fr>
The window might be retained in the damage list after
`xwl_screen_post_damage` in certain conditions. This means we need to
check if the window is already in the list to avoid adding the same
window twice which will lead to list corruption resulting in server freeze
in `xwl_screen_post_damage`.
Signed-off-by: Minh Phan <phanquangminh217@gmail.com>
With Wayland 1.21 being our baseline, we do not need to compile
wl_pointer.axis_v120 conditionally.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
With libdecor, when the state changes (in the configure handler), we
need to commit the libdecor frame but also the wl_surface, otherwise
the surface is left in a uncommitted state until a wl_surface commit
eventually occurs later.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Fixes: c74c6add3e - xwayland: add optional support for libdecor
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
If the dmabuf protocol's feedback object gave us a new list of
modifiers, send PresentCompleteModeSuboptimalCopy to the client
to inform them that they need to call GetSupportedModifiers.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
This adds to xwl_glamor_is_modifier_supported, where if feedback
is in use we will check that the format/mod is allowed in any
device advertised by the compositor.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
[ Michel Dänzer:
* Move dev_formats declaration to where it's used in
xwl_feedback_is_modifier_supported
* Add curly braces around multi-line statement in
xwl_glamor_is_modifier_supported ]
If protocol version 4 of linux_dmabuf is in use, then the compositor
may not return anything with the modifiers event. We instead
will return the formats/mods reported for the main device.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
[ Michel Dänzer:
* Move main_dev declaration to where it's used in
xwl_glamor_get_formats
* Add empty line between variable declaration and comment ]
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
[ Michel Dänzer:
* Sort protocol #includes lexically.
* memcpy to &xwl_feedback->main_dev directly in
xwl_dmabuf_feedback_main_device. ]
This creates xwl_add_format_and_mod_to_list, which is a helper
that adds a format/mod combo to a xwl_format* list. This will
be used by both the modifier event handling and the tranche
format handling.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
There are systems where softpipe is the default renderer,
e.g. when llvmpipe is not is not available. Using glamor
on such systems is never a good idea.
This mirrors what commit 0a9415cf79
did for llvmpipe.
Closes: #1417
Signed-off-by: Ivan A. Melnikov <iv@altlinux.org>
For details on the protocol itself see the Wayland merge request:
https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/72
The v120 event has a value base of 120, so one wheel detent is 120, half a
wheel is 60, etc. This is the API Windows has been using since Vista but it
requires HW support from the device. Logitech mice and many Microsoft mice of
the last decade or so have support and it's enabled in the kernel since v5.0.
The new events replace wl_pointer.axis_discrete events, once you bind to
wl_pointer >= 8 you only get the v120 events. So backwards compatibility
is simple, we just multiply the discrete events if we get them and
treat everything as 120 event internally.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Leasable displays do not have any actual associated Wayland output and
are not available to regular X11 clients and left entirely to the
application who requests the lease.
As these are not actually managed by the Wayland compositor and left
entirely to the "lessee" application, the viewporter protocol required
for the XRandR emulation is not usable on such devices.
We should therefore not advertise the XRandR emulated modes for those
leasable displays.
This also solves a problem with implementations of glXGetMscRateOML()
which is used notably by Chromium/Electron. Applications using this
which will begin lagging/stuttering exponentially over
time, trying to look up a non-existent mode with 0x0 as returned by
XF86VidModeGetModeLine() with XRandR emulation for such devices.
See-also: https://github.com/labwc/labwc/issues/553
Signed-off-by: Joshua Ashton <joshua@froggi.es>
The X server swapping code is a huge attack surface, much of this code
is untested and prone to security issues. The use-case of byte-swapped
clients is very niche, so let's disable this by default and allow it
only when the respective config option or commandline flag is given.
For Xorg, this adds the ServerFlag "AllowByteSwappedClients" "on".
For all DDX, this adds the commandline options +byteswappedclients and
-byteswappedclients to enable or disable, respectively.
Fixes#1201https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1029
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This fixes an issue with GLFW-based games failing to set the resolution
when the user request to switch back to the native display mode.
Signed-off-by: Minh Phan <phanquangminh217@gmail.com>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Implements the xwayland_shell protocol which makes the surface
association happen via a shared serial, rather than sharing a wl_surface
resource ID across an X atom.
This solves a race that can happen if the wl_surface
associated with a WL_SURFACE_ID for a window was destroyed before the
update of the atom was processed by the compositor and another surface
(or other object) had taken its id due to recycling.
Closes: #1157
Signed-off-by: Joshua Ashton <joshua@froggi.es>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Updated the for-loop that iterates over the received EGLConfigs to
include the very first EGLConfig with index 0.
Signed-off-by: Doğukan Korkmaztürk <dkorkmazturk@nvidia.com>
Fixes: 8469241592 - xwayland: Add EGL-backed GLX provider
The virgl driver exposes the name of the host renderer which might be llvmpipe.
In this case we still need glamor to be initialized.
Only check if the renderer starts with llvmpipe (which is what llvmpipe exposes).
Signed-off-by: Corentin Noël <corentin.noel@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Commit 8a5f3ddb2 ("set tag on our surface") introduced the use of tags
to differentiate our own surfaces, and commit a1d14aa8c ("Clear the
"xwl-window" tag on unrealize") removed the tags before the surfaces are
actually destroyed.
Xwayland would then rely on these tags on the surface to decide whether
to ignore or to process the Wayland event in various places.
However, in doing so, it also checked for the tag on keyboard leave
events.
As a result, if the keyboard leave events is received after the X11
window is unrealized, keyboard_handle_leave() would not queue the
LeaveNotify events for the DIX to proceed, and the key repeat would
kick in and repeat the key event indefinitely.
To avoid the issue, process events regardless of the tag as before
in keyboard_handle_leave().
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Fixes: 8a5f3ddb2 - "xwayland: set tag on our surface"
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1395
Tested-by: Renan Guilherme Lebre Ramos <japareaggae@gmail.com>
Tested-by: Stefan Dirsch <sndirsch@suse.de>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Multiplanar GBM buffers can point to different objects from each plane.
Use the _for_plane API when possible to retrieve the correct prime FD
for each plane.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Simon Ser <contact@emersion.fr>
Tested-by: Guido Günther <agx@sigxcpu.org>
Check the fd for validity before giving a success return code.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Simon Ser <contact@emersion.fr>
Tested-by: Guido Günther <agx@sigxcpu.org>
Now that we keep the Wayland surface around for longer than the
xwl_window, we might get events for that surface after the X11 window
is unrealized.
Make sure we untag the Wayland surface when the Wayland surface is
delayed, to break the wl_surface/xwl_window relationship, so that events
for that surface are discarded by Xwayland.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Fixes: e37f18ee9 - xwayland: Delay wl_surface destruction
a77d95af61 intended to do this, but the
check for “is this rootless or rootful XWayland” was inverted.
Fixes: a77d95af61 ("xwayland: Prevent Xserver grabs with rootless")
Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
hw/xwayland/xwayland.c:306:10: fatal error: 'X11/extensions/xwaylandproto.h' file not found
#include <X11/extensions/xwaylandproto.h>
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Fixes: 2700bc6045 ("xwayland: add support for the XWAYLAND extension")
X11 and Wayland requests are unordered, causing a race in the X11 window
and wl_surface association.
To mitigate that race, delay the wl_surface destruction by 1 second,
so that the compositor has time to establish the association before the
wl_surface is destroyed: to see both the wl_surface created and the
WL_SURFACE_ID X11 property set.
This is only a mitigation though, a more robust solution requires a
future dedicated Wayland protocol.
v2: Clean up pending wl_surface destroy on exit as well.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1157
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Suggested-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Tested-by: Joshua Ashton <joshua@froggi.es>
Tested-by: Sterophonick <sterophonick@gmail.com>
See-also: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/163
Because of the design of most Wayland compositors, where the compositor
is both a Wayland server and an X11 window manager, any X11 client
issuing a server grab (i.e. XGrabServer()) can possibly hang the whole
desktop when Xwayland is running rootless.
This can happen with e.g. ImageMagick's import command with mutter.
1. "import" is launched and issues an XServerGrab(),
2. Xwayland restricts access to that "import" X11 client alone,
3. mutter continues to process events until it needs to sync with
Xwayland (there's variability in time before the hang occurs),
4. When mutter does an XSync() (explicitly or implicitly through some
other Xlib call), it will stop waiting for Xwayland to reply,
5. Xwayland waits for the XServerGrab() to be released by import,
6. "import" waits for a user input to release the XServerGrab(),
7. mutter is stuck waiting on Xwayland and does not process input
events...
To prevent this, re-route the GrabServer/UngrabServer requests and
pretend the grab works but actually does nothing at all for all clients
but the X11 window manager (which can still issue X11 server grabs, at
its own risks).
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Closes: https://bugzilla.redhat.com/1914021
Fixes accidentally taking the WL_POINTER_AXIS_HORIZONTAL_SCROLL case as
well after the WL_POINTER_AXIS_VERTICAL_SCROLL case, which resulted in
vertical wheel events triggering both vertical and horizontal scrolling.
Fixes: e37eeb7af2 ("xwayland: Aggregate scroll axis events to fix kinetic scrolling")
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1367
This extension exists to serve one purpose: reliably identifying
Xwayland. Previous attempts at doing so included querying root window
properties, output names or input device names. All these attempts are
somewhat unreliable. Instead, let's use an extension - where that
extension is present we have an Xwayland server.
Clients should never need to do anything but check whether the extension
exists through XQueryExtension or search through XListExtensions.
This extension provides a single QueryVersion request only, and
that is only to provide future compatibility if we ever need anything
other than "this extension exists" functionality.
https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/merge_requests/54
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Not that it actually matters since the typedef is int32_t anyway, but
this theoretically avoids an erroneous call to wl_fixed_to_double() on
that value.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Commit 7cdcdfea0 introduced a new command line option
"-force-xrandr-emulation", however it is missing from the
ddxProcessArgument().
As a result, trying to use that command option would result in a error:
(EE) Unrecognized option: -force-xrandr-emulation
Make sure "-force-xrandr-emulation" is accounted for in Xwayland's
ddxProcessArgument().
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Fixes: 7cdcdfea0 - xwayland: Add -force-xrandr-emulation switch
Pointer scroll events are collected in xwl_seat->pending_pointer_event
as they are received in the pointer_handle_axis and
pointer_handle_axis_discrete callbacks. They are dispatched together as a
single event when pointer_handle_frame is called which "Indicates the end of a
set of events that logically belong together" [1]. This patch also sends an
event with dx=0, dy=0 when pointer_handle_axis_stop is called, which is what
allows XWayland clients to recognise the end of a touchpad scroll.
[1] https://wayland.app/protocols/wayland#wl_pointer:event:frame
Signed-off-by: David Jacewicz <david.jacewicz27@protonmail.com>
Fixes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/926
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
When running rootful, the Xwayland window is not decorated (as all
Wayland surfaces), which makes it quite inconvenient to move on screen.
libdecor is "a client-side decorations library for Wayland clients"
which can be used precisely for adding decorations to Wayland surfaces.
Add optional support for libdecor in Xwayland to gain decorations when
running rootful and a new command line option "-decorate".
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1332
That allows to differentiate Xwayland's own surfaces from others.
This is preparation work for optional libdecor support.
v2: Check for surface not being NULL (Jonas Ådahl <jadahl@gmail.com>)
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
The app_id is used to identify applications (and group windows), some
desktops (such as GNOME Shell) use it in their top bar.
Set the XDG toplevel "app_id" to "org.freedesktop.Xwayland" and install
a desktop file for Xwayland rootful.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
So that when running rootful, the compositor can close the Xwayland
window using the xdg-toplevel protocol.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Set a meaningful title for the xdg_surface, it's nicer when running
rootful.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Currently, when running rootful, the toplevel root surface is created in
the same function as the rest of the Wayland surfaces.
Move it to its own function to improve readability - No function change.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Add a new command line option "-host-grab" to disable the keyboard
shortcuts and confine the pointer on the host so that Xwayland can
receive all keyboard events.
This is useful when running a complete desktop environment within
Xwayland rootful.
Use [CTRL]+[SHIFT] to release the keyboard and pointer.
This option is not compatible with rootless mode.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Xwayland tries to be smart and guess the intention of the X11 clients
sometimes, like issuing a pointer lock when a client hides the pointer
when confined.
While this is a good thing when running rootless, this is problematic
when running rootful as the pointer will be automatically locked unless
the "retro" mode is used (which doesn't hide the cursor, unlike the
default).
Make sure we don't trigger the automatic pointer lock when the cursor is
hidden when running rootful.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Add a new command line option "-fullscreen" to make the rootful Xwayland
window appear fullscreen.
This requires viewport support in the compositor and when used with
"-geometry" can emulate the full range of XRandR resolutions.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
When updating the overall screen size, Xwayland would first walk the
window tree then update both the xwl_screen and screen size.
As a result, if any ResizeWindow() handler tries to use the xwl_screen
size, it would get the old (wrong) size instead of the new one.
Make sure to update the xwl_screen size first, prior to traverse the
window tree.
This is preparation work for Xwayland fullscreen mode.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
When using xrandr emulation, the emulated mode is passed as a pointer to
the XRandR mode from the xwl_output associated with the X11 client.
In preparation for fullscreen mode, we want to be able to reuse that
code but use a separate emulated mode.
Simply change the internal API to pass a reference to the emulated mode.
This introduces no functional change.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
The xdg_toplevel object was used solely when creating the window
surface, and the value of the object discarded.
To be able to make the surface fullscreen using the xdg_toplevel
protocol, we need to have access that object, so keep it around along
with the xwl_window.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Keep track of the output the surface enters/leaves.
This is fairly basic tracking though, we do not keep a full list of
outputs a surface may be covering partially, we just keep the output
the surface entered last.
This is sufficient as a preparation work for fullscreen though.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Add a convenient function to get the xwl_output from a given wl_output.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
When running rootless as well as rootful, Xwayland gets its outputs
configuration from the Wayland compositor.
When running rootful, it means that we end up with a large black
surface the size of all monitors combined, that's not very convenient
and there is no way for set the desired size of the Xwayland window.
Add a new command line option "-geometry" to force a specific mode when
running rootful for the user to specify the root window size to use for
Xwayland.
That option has no effect when Xwayland is running rootless.
v2: Not using libxcvt as the mode may not be a valid CVT mode.
v3: Add a set of XRandR modes and the RR hooks to make that work.
Update the man page for Xwayland.
v4: Add RandR 1.0 support for older clients
v5: Fix XVidMode failing with a BadMatch
v6: Add a separate xwl_output specifically for fixed mode, instead of
using the existing output list - that will allow for further
improvements like a fullscreen mode eventually.
v7: Sort the RR modes
v8: Fix RandR 1.0
v9: Add physical size
v10: Cleanup
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1338
update_screen_size() takes an xwl_output argument, mostly for historical
reasons, whereas it actually applies to a screen (as its name implies).
Reshuffle the code to take an xwl_screen instead, in preparation for
the geometry mode in Xwayland - No functional change.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Xwayland uses an output serial number it increments each time a new
Wayland output is added.
On server regeneration, that static value is not cleared, and therfore
the output numbers keep increasing each time the Xserver restarts.
To avoid that issue, make the output serial part of the xwl_screen,
which gets recreated on server regeneration, so that index is reset to 0
automatically on server regeneration.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Xwayland's own SetWindowPixmap() handler would be ignored when running
rootful.
This is fine as long as we do not plan to resize the root window,
however this is becoming problematic if we plan to resize the root
window dynamically when running rootful.
Just add the xwl_window_set_window_pixmap() handler regardless of
rootful/rootless mode.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
The function xwl_output_remove() is called when removing a monitor, but
the actual status of the RandR output does not change.
So, when RRTellChanged() is called from update_screen_size(), it won't
have the output connection status up to date in the RandR event
RROutputChangeNotifyEvent and X11 applications relying on that event
like Qt will fail to emit their signal QGuiApplication::screenRemoved.
To avoid that issue, make sure to mark the RandR output as disconnected
prior to call xwl_output_remove().
Fix commit 204f10c29 ("xwayland: Call RRTellChanged if the RandR configuration may have changed")
Signed-off-by: zhoulei <zhoulei@kylinos.cn>
Signed-off-by: Morose <chenlinxiang@kylinos.cn>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
When the pointer leaves an X11 window, and enters a Wayland native
window, Xwayland has no idea about Wayland native windows and may
generate the wrong crossing events to another X11 window instead.
To avoid that issue, Xwayland implements its own XYToWindow() handler to
compare the Wayland focused surface with the X11 window found in the
window tree.
Commit 59ad0e6a ("xwayland: Fix use after free of cursors") changed the
logic in sprite_check_lost_focus() to use IsParent() to compare the
windows, which works when the X11 window is reparented by the window
manager, but fails in the case of an override redirect window.
To fix the issue, also check whether last_xwindow is the window itself.
Signed-off-by: Morose <chenlinxiang@kylinos.cn>
Fixes: 59ad0e6a - xwayland: Fix use after free of cursors
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Adds a -force-xrandr-emulation cmdline switch that always exposes extra
modes when viewporter isn't exposed by the Wayland compositor.
Having the additional modes exposed by the X server is important for
games to function and be configured
Compositors, such as Gamescope (the compositor for Steam Deck),
support only a single window that is rendered in the centre of the
screen that is scaled up to fill the screen by the compositor based
on some user scaling settings.
Exposing viewporter, wouldn't make sense here, and could mislead native
Wayland clients, so exposing dummy modesets in X is preferred here.
Signed-off-by: Joshua Ashton <joshua@froggi.es>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Adds the following 16:10 modes primarily for scaling up on Steam Deck:
- 1152x720
- 960x600
- 928x580
- 800x500
- 768x480
Signed-off-by: Joshua Ashton <joshua@froggi.es>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Xwayland does not change the actual XRANDR setup for real, it just
emulates the resolution changes using viewports in Wayland.
With a single output, if an X11 applications tries to change the CRTC
back to the native mode, RRCrtcSet() will simply ignore the request as
no actual change is induced by this.
Set the property "RANDR Emulation" on all Xwayland outputs to make sure
the optimizations in RRCrtcSet() get skipped and Xwayland can receive
and act upon the client request.
Also make sure we do not allow that property to be changed by X11
clients.
v2: Prevent X11 clients from changing the property value
(Pekka Paalanen <pekka.paalanen@collabora.com>)
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1305
drm_lease_device_handle_released uses the wrong pointer type in the
callback. This will cause crash when compositor removes drm lease device
object.
Fixes: 089e7f98f - Xwayland: implement drm-lease-v1
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Weng Xuetian <wengxt@gmail.com>
Even if there's no pending frame callback yet.
Without this, if there was no pending frame callback yet in
xwl_present_queue_vblank, xwl_present_msc_bump would only get called
from xwl_present_timer_callback, resulting in the MSC ticking at ~58
Hertz.
Doing this requires some adjustments elsewhere:
1. xwl_present_reset_timer needs to check for a pending frame callback
as well.
2. xwl_window_create_frame_callback needs to call
xwl_present_reset_timer for all child windows hooked up to
frame_callback_list, to make sure the timer length takes the pending
frame callback into account.
3. xwl_present_flip needs to hook up the window to frame_callback_list
before calling xwl_window_create_frame_callback, for 2. to work.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1309
Fixes: 9b31358c52 ("xwayland: Use frame callbacks for Present vblank events")
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Without this, xwl_present_reset_timer would call
xwl_present_timer_callback if the timer was originally armed over a
second ago. xwl_present_timer_callback would call xwl_present_msc_bump,
which could end up hooking up the window to
xwl_window->frame_callback_list again. This would lead to use-after-free
in xwl_present_cleanup:
Invalid write of size 8
at 0x42B65C: __xorg_list_del (list.h:183)
by 0x42B693: xorg_list_del (list.h:204)
by 0x42C041: xwl_present_cleanup (xwayland-present.c:354)
by 0x423669: xwl_destroy_window (xwayland-window.c:770)
by 0x4FDDC5: compDestroyWindow (compwindow.c:620)
by 0x5233FB: damageDestroyWindow (damage.c:1590)
by 0x501C5F: DbeDestroyWindow (dbe.c:1326)
by 0x4EF35B: FreeWindowResources (window.c:1018)
by 0x4EF687: DeleteWindow (window.c:1086)
by 0x4E24B3: doFreeResource (resource.c:885)
by 0x4E2ED7: FreeClientResources (resource.c:1151)
by 0x4ACBA4: CloseDownClient (dispatch.c:3546)
Address 0x12f44980 is 144 bytes inside a block of size 160 free'd
at 0x48470E4: free (vg_replace_malloc.c:872)
by 0x423115: xwl_unrealize_window (xwayland-window.c:621)
by 0x4FCDD8: compUnrealizeWindow (compwindow.c:292)
by 0x4F3F5C: UnrealizeTree (window.c:2805)
by 0x4F424B: UnmapWindow (window.c:2863)
by 0x4EF58C: DeleteWindow (window.c:1075)
by 0x4E24B3: doFreeResource (resource.c:885)
by 0x4E2ED7: FreeClientResources (resource.c:1151)
by 0x4ACBA4: CloseDownClient (dispatch.c:3546)
by 0x5E27EE: ClientReady (connection.c:599)
by 0x5E6CB7: ospoll_wait (ospoll.c:657)
by 0x5DE6CD: WaitForSomething (WaitFor.c:208)
Block was alloc'd at
at 0x4849464: calloc (vg_replace_malloc.c:1328)
by 0x4229CE: ensure_surface_for_window (xwayland-window.c:439)
by 0x4231E8: xwl_window_set_window_pixmap (xwayland-window.c:647)
by 0x5232D6: damageSetWindowPixmap (damage.c:1565)
by 0x4FC7BC: compSetPixmapVisitWindow (compwindow.c:129)
by 0x4EDB3F: TraverseTree (window.c:441)
by 0x4FC851: compSetPixmap (compwindow.c:151)
by 0x4F8C1A: compAllocPixmap (compalloc.c:616)
by 0x4FC938: compCheckRedirect (compwindow.c:174)
by 0x4FCD1D: compRealizeWindow (compwindow.c:274)
by 0x4F36EC: RealizeTree (window.c:2606)
by 0x4F39F5: MapWindow (window.c:2683)
Fixes: 288ec0e046 ("xwayland/present: Run fallback timer callback after more than a second")
Tested-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
When a window is unrealized, Xwayland would destroy the Wayland surface
prior to unrealizing the present window.
xwl_present_flip() will then do a wl_surface_commit() of that surface,
hence causing a use-after-free:
Invalid read of size 8
at 0x49F7FD4: wl_proxy_marshal_array_flags (wayland-client.c:852)
by 0x49F823A: wl_proxy_marshal_flags (wayland-client.c:784)
by 0x42B877: wl_surface_commit (wayland-client-protocol.h:3914)
by 0x42CAA7: xwl_present_flip (xwayland-present.c:717)
by 0x42CD0E: xwl_present_execute (xwayland-present.c:783)
by 0x42C26D: xwl_present_msc_bump (xwayland-present.c:416)
by 0x42C2D1: xwl_present_timer_callback (xwayland-present.c:433)
by 0x42BAC4: xwl_present_reset_timer (xwayland-present.c:149)
by 0x42D1F8: xwl_present_unrealize_window (xwayland-present.c:945)
by 0x4230E2: xwl_unrealize_window (xwayland-window.c:616)
by 0x4FCDD8: compUnrealizeWindow (compwindow.c:292)
by 0x4F3F5C: UnrealizeTree (window.c:2805)
Address 0x1390b8d8 is 24 bytes inside a block of size 80 free'd
at 0x48470E4: free (vg_replace_malloc.c:872)
by 0x49F8029: wl_proxy_destroy_caller_locks (wayland-client.c:523)
by 0x49F8029: wl_proxy_marshal_array_flags (wayland-client.c:861)
by 0x49F823A: wl_proxy_marshal_flags (wayland-client.c:784)
by 0x421984: wl_surface_destroy (wayland-client-protocol.h:3672)
by 0x423052: xwl_unrealize_window (xwayland-window.c:599)
by 0x4FCDD8: compUnrealizeWindow (compwindow.c:292)
by 0x4F3F5C: UnrealizeTree (window.c:2805)
by 0x4F424B: UnmapWindow (window.c:2863)
by 0x4EF58C: DeleteWindow (window.c:1075)
by 0x4E24B3: doFreeResource (resource.c:885)
by 0x4E2ED7: FreeClientResources (resource.c:1151)
by 0x4ACBA4: CloseDownClient (dispatch.c:3546)
Block was alloc'd at
at 0x4849464: calloc (vg_replace_malloc.c:1328)
by 0x49F7F29: zalloc (wayland-private.h:233)
by 0x49F7F29: proxy_create (wayland-client.c:422)
by 0x49F7F29: create_outgoing_proxy (wayland-client.c:664)
by 0x49F7F29: wl_proxy_marshal_array_flags (wayland-client.c:831)
by 0x49F823A: wl_proxy_marshal_flags (wayland-client.c:784)
by 0x4218CA: wl_compositor_create_surface (wayland-client-protocol.h:1291)
by 0x422A0D: ensure_surface_for_window (xwayland-window.c:445)
by 0x4231E8: xwl_window_set_window_pixmap (xwayland-window.c:647)
by 0x5232D6: damageSetWindowPixmap (damage.c:1565)
by 0x4FC7BC: compSetPixmapVisitWindow (compwindow.c:129)
by 0x4EDB3F: TraverseTree (window.c:441)
by 0x4FC851: compSetPixmap (compwindow.c:151)
by 0x4F8C1A: compAllocPixmap (compalloc.c:616)
by 0x4FC938: compCheckRedirect (compwindow.c:174)
To avoid that, call xwl_present_unrealize_window() before destroying the
Wayland surface.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
The composite overlay window (COW) can be queried from any X11 client,
not just the X11 compositing manager.
If a client tries to get the composite overlay window, the Xserver will
map the window and block all pointer events (the window being mapped and
on top of the stack).
To avoid that issue, unset the "mapped" state of the composite overlay
window once realized when Xwayland is running rootless.
Note: All Xservers are actually affected by this issue, but with most
regular X servers, the compositing manager will take care of dealing
with the composite overlay window, and an X11 client using
GetOverlayWindow() won't break pointer events for all X11 clients.
Wayland compositors however usually run Xwayland rootless and have no
use for the COW.
v2: Avoid registering damage for the COW (Michel)
v3: Remove the "mapped" test to avoid calling register_damage() if the
COW is not mapped (Michel)
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1314
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
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>
Xwayland may open a fair amount of file descriptors for passing Wayland
buffers, even more so when using the `wl_shm` either for the pointer
cursors or for when GLAMOR is not usable.
As a result, Xwayland may hit the (soft) limit of file descriptors
leading to a Wayland protocol error and the termination of Xwayland.
To mitigate that risk, raise the limit to the maximum (hard) limit of
file descriptors (unless of course the limit was set explicitly from the
command line with "-lf").
Note that for completeness, the Wayland compositor may have to do the
same, otherwise the limit might get reached on the compositor side as
well.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Suggested-by: Simon Ser <contact@emersion.fr>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1283
If the Wayland compositor doesn't send a pending frame event, e.g.
because the Wayland surface isn't visible anywhere, it could happen that
the timer kept getting pushed back and never fired. This resulted in an
enormous list of pending vblank events, which could take minutes to
process when the frame event finally arrived.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1110
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Tested-by: Jaap Buurman <jaapbuurman@gmail.com>
This commit allows X11 clients running through Xwayland to lease
non-desktop connectors from the Wayland compositor by implementing
support for drm-lease-v1.
In order to not deadlock with the Wayland compositor if its response
to a lease request is delayed, the new interface in _rrScrPriv
introduced in the last commit is used, which makes it possible to
block the X11 client while a response is pending.
Leasing normal outputs is not yet supported, all connectors offered
for lease will be advertised as non-desktop.
Co-authored-by: Xaver Hugl <xaver.hugl@gmail.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
The compositor may send us wl_seat and its capabilities before sending
e.g. relative_pointer_manager or pointer_gesture interfaces. This would
result in devices being created in capabilities handler, but listeners
not, because the interfaces weren't available at the time. So we
manually attempt to setup listeners again.
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
The implementation is relatively straightforward because both wayland
and Xorg use libinput semantics for touchpad gestures.
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
Currently, when given the choice, Xwayland will pick the GBM backend
over the EGLstream backend if both are available, unless the command
line option “-eglstream” is specified.
The NVIDIA proprietary driver had no support for GBM until driver series
495, but starting with the driver series 495, both can be used.
But there are other requirements with the rest of the stack, typically
Mesa, egl-wayland, libglvnd as documented in the NVIDIA driver.
So if the NVIDIA driver series 495 gets installed, Xwayland will pick
the GBM backend even if EGLstream is available and may fail to render
properly.
To avoid that issue, prefer EGLstream if EGLstream and all the Wayland
interfaces are available, and fallback to GBM automatically unless
“-eglstream” was specified.
With this, the compositor, given the choice, can decide which actual
backend Xwayland would use by advertising (or not) the Wayland
"wl_eglstream_controller" interface.
This change has no impact on compositors which do not have support for
EGLstream in the first place.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Add (verbose) statements to trace the actual backend used with glamor.
That can be useful for debugging.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
On a normal startup sequence, the Xwayland glamor backend would log
an error whenever a required Wayland protocol is missing.
Those are not really errors though, more informational messages along
the glamor backend selection process.
Demote those errors to verbose messages to reduce the verbosity of
Xwayland at startup by default.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
If no EGLstream capable device is found at startup, Xwayland's EGLstream
backend will log an error message "glamor: No eglstream capable devices
found".
However, considering that the vast majority of drivers do not implement
EGLstream, the lack of EGLstream capable device is more of the norm than
the exception.
Change the error message to a log verbose message.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
We were storing the pointer to struct glamor_context. However, glamor
itself is storing the EGLContext pointer since the commit below. Since
the two values could never be equal, this resulted in constant
superfluous eglMakeCurrent calls. The implicit glFlush triggered by
those couldn't be good for performance.
Fixes: 7c88977d33 "glamor: Store the actual EGL/GLX context pointer in lastGLContext"
Reviewed-by: Olivier Fourdan <ofourdan@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>
Passing -noTouchPointerEmulation results in an error about the
flag not being recognized.
Signed-off-by: Simon Ser <contact@emersion.fr>
Fixes: 7d34b1f2b7 ("xwayland: add -noTouchPointerEmulation")
Olivier Fourdan
Jonas Ådahl
Simon Ser
Michel Dänzer
Minh Phan
Austin Shafer
Ivan A. Melnikov
Peter Hutterer
Joshua Ashton
Doğukan Korkmaztürk
Corentin Noël
Lucas Stach
Demi Marie Obenour
Jan Beich
David Jacewicz
zhoulei
Morose
Weng Xuetian
Drew DeVault
Povilas Kanapickas