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>
The code in AttachDevice() may free the dev->spriteInfo->sprite under
some circumstances and later call GetCurrentRootWindow() which uses
the same dev->spriteInfo->sprite.
While it seems unlikely that this is actually an issue, considering the
cases where one or the other get called, it still makes the code look
suspicious.
Make sure to clear set dev->spriteInfo->sprite to NULL immediately
after it's freed to avoid any confusion, even if only to clarify the
code.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1436
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>
Wayland 1.21 was released on June 30, 2022 and our CI already installs
Wayland 1.21 so let's just require the version we actually use in our
CI.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
CVE-2023-0494, ZDI-CAN-19596
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
Withoug a proper implementation of DetermineClientCmd, clients that
connect via an ssh tunnel are miscategorized as local. This results
in failures when we try to use SCM_RIGHTS (eg: in MIT-SHM).
Fixes: https://github.com/XQuartz/XQuartz/issues/314
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
This provides a way to determine the pid of a peer connection on
systems like darwin that do not support getpeerucred() nor
SO_PEERCRED.
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
GetLocalClientCreds() was preferring getpeereid() above other implementations.
getpeereid(), however, only returns the effective uid and gid of the peer,
leaving the pid unset. When this happens, we are unable to use the pid to
determine the peer's command line arguments and incorrectly treat ssh-tunneled
traffic as local.
To address this, we now prioritize getpeerucred() or SO_PEERCRED as those two
implementations will return the pid in addition to uid and gid.
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
The event might be a DeviceEvent allocated on the stack, in
AccessXKeyboardEvent for instance. Fixes out-of-bounds read.
Signed-off-by: Mike Gorse <mgorse@suse.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>
In dri3_get_supported_modifiers we were previously intersecting
the drawable mods and the screen mods. This meant all screen mods
were returned, but the ones compatible with the drawable were
returned in the drawable mods list and the rest are returned in
the screen mods list.
This is a problem with linux_dmabuf v4 since the drawable mods may
contain different mods not found in the screen mods (such as scanout
entries). This change removes the intersection, and just returns
the drawable/screen mod lists directly.
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>
This updates rootless to treat pixmaps consistently with COMPOSITE,
using the screen_x and screen_y values rather than doing hacky math.
This will allow for proper bounds checking on a given PixmapRec.
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
This should no longer be necessary since we only support implementations
that handle preserving the bits across resize. We can use
RootlessNoCopyWindow instead.
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
This should no longer be necessary since we only support implementations that handle preserving the bits across resize
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
I don't see a reason why we would want to preserve pixels that are going to
not be visible anyways. The rootless implementation already handles
preserving the relevant bits for us.
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
If none of the four corners is fixed, we can use RL_GRAVITY_NORTH_WEST weighting
for the operation to let the implementation presetve the window bits for us.
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
The implementation owns the pointer during RootlessStopDrawing and
RootlessStartDrawing and is free to (does) change it. Rootless
cannot assume ownership of this memory region. This is possibly
the cause of some hard to diagnose crashes in XQuartz over the
years.
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.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>
Multiple reasons, in particular:
* Doing it in every build & test job duplicates effort, resulting in
the pipeline taking longer than necessary.
* We cannot limit the number of test processes spawned by meson dist.
* There's little point running tests for dist anyway, we just want to
make sure we can build & install from the generated tarball.
This lets us actually limit the number of test processes spawned in
parallel.
(ninja test runs meson test without --num-processes, so it ends up
spawning as many processes in parallel as there are CPU cores)
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>
This will allow us to remove build-time conditionalization on COMPOSITE
while still allowing XQuartz to disable it and use ROOTLESS.
This reverts commit 9c03733669.
Simon Ser
Olivier Fourdan
Michel Dänzer
Minh Phan
Dave Airlie
Peter Hutterer
Jeremy Huddleston Sequoia
Mike Gorse
orbea
Tamura Dai
Austin Shafer
Ivan A. Melnikov