EGLStream implementation in Xwayland keeps a list of pending streams for
a window.
If the windows's pixmap is destroyed while there is a pending stream,
the pending stream will point to freed memory once the callback is
triggered.
Make sure to cancel the pending stream if there's one when the pixmap is
destroyed.
v2:
* Use xorg_list_for_each_entry() instead of the safe variant (Michel
Dänzer <mdaenzer@redhat.com>)
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Tested-by: Karol Szuster <karolsz9898@gmail.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Closes https://gitlab.freedesktop.org/xorg/xserver/-/issues/1096
Commit 77658741 - "xwayland: Add buffer release callback" added an API
to deal with Wayland buffer release callbacks.
The EGLstream implementation has its own wl_buffer callback, move that
to the buffer release API instead so we don't have to deal with Wayland
buffers directly and match the other Xwayland pixmap backend
implementations.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Tested-by: Erik Kurzinger <ekurzinger@nvidia.com>
It runs XTS via piglit on (non-rootless) Xwayland on weston using the
headless backend.
Xwayland might use glamor if enabled in the build, but we're making sure
it uses software rendering.
v2:
* Use weston-info to wait for weston to be ready, instead of just a
fixed sleep. (Martin Peres)
v3:
* Build wayland 1.18 & weston 9.0 locally, since the packages in Debian
buster are too old for current Xwayland.
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
As Xwayland is usually spawned by the Wayland server/compositor, its
command line options are not always adjustable.
Yet, if EGLStream is not supported in a given Xwayland build, the option
will do nothing (yet we must still accept it otherwise Xwayland would
refuse to run if the Wayland compositor uses it).
If Xwayland was built without support for EGLStream, there is not point
in showing the option in the help message though.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Martin Peres <martin.peres@mupuf.org>
The command line options "-shm" is used to instruct Xwayland to prefer
shared-memory for passing buffers to the Wayland server, rather than
using glamor and DRI3.
The option was there from the beginning, yet not documented in the
"-help" message.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Martin Peres <martin.peres@mupuf.org>
One general assumption in Xwayland is that the xwl_window remains the
same for all the child windows of the toplevel window.
When mapping a new X11 window, ensure_surface_for_window() checks for an
existing xwl_window by using xwl_window_get() which will just check for
the registered xwl_window for the window.
That means that a client mapping a child window of an existing window
with a xwl_window will get another different xwl_window.
If an X11 client issues a Present request on the parent window, hence
placed underneath its child window of the same size, the Wayland
compositor may not send the frame callback event for the parent's
Wayland surface which is reckoned to be not visible, obscured behind
the other Wayland surface for the child X11 window.
That bug affects some games running in wine which may get 1 fps because
the repaint occurs only on timeout with a long interval (as with, e.g.
https://bugs.winehq.org/show_bug.cgi?id=47066)
Fix ensure_surface_for_window() by using xwl_window_from_window() which
will walk the window tree, so that a child window won't get another
xwl_window than its parent.
https://gitlab.freedesktop.org/xorg/xserver/-/issues/1099
See-also: https://bugs.winehq.org/show_bug.cgi?id=47066
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
When running non-rootless, Xwayland requires that the Wayland compositor
supports the XDG-WM-Base protocol.
Check for XDG-WM-Base protocol support at startup and exit cleanly if
missing rather than segfaulting later in ensure_surface_for_window()
while trying to use xdg_wm_base_get_xdg_surface().
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Instead, bump the pixmap's refcount at the bottom of post_damage to
reflect the compositor's hold on the buffer, and "destroy" the pixmap in
the buffer release callback (which will dec the pixmap's refcount and
free if necessary).
Signed-off-by: Adam Jackson <ajax@redhat.com>
The EGLStream backend keeps a queue of pending streams for each Xwayland
window.
However, when this pending queue is freed, the corresponding private
data may not be cleared (typically if the pixmap for this window has
changed before the compositor finished attaching the consumer for the
window's pixmap's original eglstream), leading to a use-after-free and a
crash when trying to use that data as the window pixmap.
Make sure to clear the private data when the pending stream is freed.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1055
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Tested-by: Karol Szuster <karolsz9898@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Using multiple window buffers crashes with EGLStream, which does not
need it anyway as this is handled through EGL directly.
Add a flag to the EGL backend to indicate whether it would benefit from
multiple buffers and use this in the get_buffer() function.
Thanks to Adam Jackson <ajax@redhat.com> for pointing out that issue
with EGLStream.
v2: Fix logical test (Adam Jackson <ajax@redhat.com>)
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
The present flip does not work with the EGLStream backend. Similarly,
the EGLStream backend does not require the buffer to be flushed as
eglSwapBuffers() should take care of this.
Instead of actually checking the backend in use in the present code,
add a flag in the form of a bitfield to the EGL backend to indicate
its features and requirements.
This should not introduce any functional change.
v2: Fix logical test (Adam Jackson <ajax@redhat.com>)
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Major/minor numbers are a.. major (ha) source of pain in FreeBSD porting.
In this case, Xwayland was thinking that /dev/dri/card0 is already a render node,
because the st_rdev on FreeBSD was passing the Linux-style check,
and because of the assumption, acceleration would fail because
various ioctls like AMDGPU_INFO would be denied on the non-render node.
Switch to libdrm's function that already works correctly on all platforms.
Signed-off-by: Greg V <greg@unrelenting.technology>
Reviewed-by: Emmanuel Vadot <manu@FreeBSD.org>
We can only flip if the window pixmap matches that of the toplevel
window. Doing so regardless could cause the toplevel window pixmap to
get destroyed while it was still referenced by the window, resulting in
use-after-free and likely a crash.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1033
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Roman Gilg <subdiff@gmail.com>
The need_rotate variable is only used once anymore and had semantics which lead
to errors in the past. In particular when negated we are dealing with a double
negation.
The variable gets replaced with a simple check on the xdg-output directly.
Signed-off-by: Roman Gilg <subdiff@gmail.com>
This reverts commit 427f8bc009.
When receiving an output update for the mode size we need to rotate the stored
width and height values if and only if we have an xdg-output for this output
since in this case the stored values describe the output's size in logical
space, i.e. rotated.
The here reverted commit made a code change with which we would not rotate though
when an xdg-output was available since in this case the need_rotate variable was
set to False what caused in the check afterwards the first branch to execute.
That is just a small style-change to the output_get_new_size function. The
function before did take first the height and then the width argument, what
is unusual since resolutions are normally named the other way around, for
example 1920x1080. Also compare the update_screen_size function.
Therefore change the order of arguments for output_get_new_size.
Signed-off-by: Roman Gilg <subdiff@gmail.com>
We can just read out the xdg_output field of the provided xwl_output to check
if a rotation is necessary or not.
This makes the function easier to understand. Additionally some documentation
is added.
Signed-off-by: Roman Gilg <subdiff@gmail.com>
Xwayland is just a Wayland client, no X11 screensaver should be
expected to work reliably on Xwayland when running rootless because
Xwayland cannot grab the input devices so it has no way to actually
lock the screen managed by the Wayland compositor.
Turn off the screensaver on Xwayland when running rootless by setting
the screensaver timeout and interval and their default values to zero
and disable the MIT-SCREEN-SAVER extension.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1051
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Instead of optionally return early when an event is aborted and potentially
clean it up in there we can only optionally inform Present if not aborted and
afterwards clean it up if required.
Saves some lines of code and conditional branches.
Signed-off-by: Roman Gilg <subdiff@gmail.com>
With the newly introduced separate API method for idling a presented Pixmap in
window mode we can simplify the logic by allowing calls to it at any point in
time.
This is done by setting the flip_idler flag if the Pixmap was idled before
being presented.
Signed-off-by: Roman Gilg <subdiff@gmail.com>
Notifying Present about events' states was done prior with the single function
present_wnmd_event_notify just like in screen mode. But it is more intelligible
if at least in window mode we make use of three different functions with names
that directly indicate what their purpose is:
* present_wnmd_event_notify only for queued events feedback.
* present_wnmd_flip_notify for when a presentation occured (flip).
* present_wnmd_idle_notify for when the Pixmap of the event can be reused.
This is an API-breaking change in regards to window mode. DDX written against
the previous version won't work anymore. It is assumed that there only exists
the XWayland DDX at the moment using the window mode such that this is not an
issue for the overall ecosystem.
Signed-off-by: Roman Gilg <subdiff@gmail.com>
Rename the lists release_queue to release_list and event_list to
wait_list.
The prior names release_queue and event_list were ambiguous: in both are event-
like vblanks which can be removed from the lists in random order. In the
release_queue can be flips that are already released but still wait for the
sync or frame callback but normally the release comes later. In the event_list
are queued events waiting for a later msc.
Signed-off-by: Roman Gilg <subdiff@gmail.com>
This (so-far) Linux-only API lets users create file descriptors purely
in memory, without any backing file on the filesystem and the race
condition which could ensue when unlink()ing it.
It also allows seals to be placed on the file, ensuring to every other
process that we won’t be allowed to shrink the contents, potentially
causing a SIGBUS when they try reading it.
This patch is best viewed with the -w option of git log -p.
This is a port of this commit from Weston:
deae98ef45Fixes#848.
Signed-off-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
When a slave device causes the master virtual pointer device to change
device types, the device's private data pointer
(device->public.devicePrivate) is also changed to match the type of the
slave device. This can be a problem though, as tablet pad devices will
set the device's private data pointer to their own xwl_tablet_pad
struct. This can cause us to dereference the pointer as the wrong type,
and result in a segfault:
Thread 1 "Xwayland" received signal SIGSEGV, Segmentation fault.
wl_proxy_marshal (proxy=0x51, opcode=opcode@entry=0) at src/wayland-client.c:792
792 va_start(ap, opcode);
(gdb) bt
0 wl_proxy_marshal (proxy=0x51, opcode=opcode@entry=0) at
src/wayland-client.c:792
1 0x00005610b27b6c55 in wl_pointer_set_cursor (hotspot_y=0,
hotspot_x=0, surface=0x0, serial=<optimized out>, wl_pointer=<optimized
out>) at /usr/include/wayland-client-protocol.h:4610
2 xwl_seat_set_cursor (xwl_seat=xwl_seat@entry=0x5610b46d5d10) at
xwayland-cursor.c:137
3 0x00005610b27b6ecd in xwl_set_cursor (device=<optimized out>,
screen=<optimized out>, cursor=<optimized out>, x=<optimized out>,
y=<optimized out>) at xwayland-cursor.c:249
4 0x00005610b2800b46 in miPointerUpdateSprite (pDev=0x5610b4501a30) at
mipointer.c:468
5 miPointerUpdateSprite (pDev=0x5610b4501a30) at mipointer.c:410
6 0x00005610b2800e56 in miPointerDisplayCursor (pCursor=0x5610b4b35740,
pScreen=0x5610b3d54410, pDev=0x5610b4501a30) at mipointer.c:206
7 miPointerDisplayCursor (pDev=0x5610b4501a30, pScreen=0x5610b3d54410,
pCursor=0x5610b4b35740) at mipointer.c:194
8 0x00005610b27ed62b in CursorDisplayCursor (pDev=<optimized out>,
pScreen=0x5610b3d54410, pCursor=0x5610b4b35740) at cursor.c:168
9 0x00005610b28773ee in AnimCurDisplayCursor (pDev=0x5610b4501a30,
pScreen=0x5610b3d54410, pCursor=0x5610b4b35740) at animcur.c:197
10 0x00005610b28eb4ca in ChangeToCursor (pDev=0x5610b4501a30,
cursor=0x5610b4b35740) at events.c:938
11 0x00005610b28ec99f in WindowHasNewCursor
(pWin=pWin@entry=0x5610b4b2e0c0) at events.c:3362
12 0x00005610b291102d in ChangeWindowAttributes (pWin=0x5610b4b2e0c0,
vmask=<optimized out>, vlist=vlist@entry=0x5610b4c41dcc,
client=client@entry=0x5610b4b2c900) at window.c:1561
13 0x00005610b28db8e3 in ProcChangeWindowAttributes (client=0x5610b4b2c900)
at dispatch.c:746
14 0x00005610b28e1e5b in Dispatch () at dispatch.c:497
15 0x00005610b28e5f34 in dix_main (argc=16, argv=0x7ffc7a601b68,
envp=<optimized out>) at main.c:276
16 0x00007f8828cde042 in __libc_start_main (main=0x5610b27ae930 <main>,
argc=16, argv=0x7ffc7a601b68, init=<optimized out>, fini=<optimized
out>, rtld_fini=<optimized out>, stack_end=0x7ffc7a601b58) at
../csu/libc-start.c:308
17 0x00005610b27ae96e in _start () at cursor.c:1064
Simple reproducer in gnome-shell: open up an Xwayland window, press some
tablet buttons, lock and unlock the screen. Repeat if it doesn't crash
the first time.
So, let's fix this by registering our own device-specific private key
for storing a backpointer to xwl_tablet_pad, so that all input devices
have their private data pointers set to their respective xwl_seat.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Lyude Paul <lyude@redhat.com>
In 9141196d positional coordinates were added to the damage call of pixmap
flips. The damage box coordinates are in screen space though and we need
to convert them first to surface-relative ones by substracting the origin
of the window.
Signed-off-by: Roman Gilg <subdiff@gmail.com>
Xwayland is usually spawned by the Wayland compositor which sets the
command line options.
If a command line option is not supported, Xwayland will fail to start.
That somehow makes the Xwayland command line option sort of ABI, the
Wayland compositor need to know if a particular option is supported by
Xwayland at build time.
Also, currently, Xwayland is being installed along with the rest of the
common executable programs that users may run, which is sub-optimal
because, well, Xwayland is not a common executable program, it's meant
to be a proxy between the Wayland compositor and the legacy X11 clients
which wouldn't be able to run on Wayland otherwise.
Xwayland would be better installed in `libexec` but that directory is
(purposedly) not in the user `PATH` and therefore the Wayland compositor
may not be able to find Xwayland in that case.
To solve both problems (which options are supported by Xwayland and
where to look for it), add a `pkg-config` file specifically for Xwayland
which gives the full path to Xwayland (`xwayland`) and which options it
supports (using `pkg-config` variables).
The `pkg-config` file also provides the `Version` so the build scripts
can check for a particular version if necessary.
Obviously, Wayland compositors are not required to use the `pkg-config`
file and can continue to use whatever mechanism they deem preferable.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Most (but not all) of these were found by using
codespell --builtin clear,rare,usage,informal,code,names
but not everything reported by that was fixed.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
The way Xwayland works (like all Wayland clients), it first queries the
Wayland registry, set up all relevant protocols and then initializes its
own structures.
That means Xwayland will get the Wayland outputs from the Wayland
compositor, compute the physical size of the combined outputs and set
the corresponding Xwayland screen properties accordingly.
Then it creates the X11 screen using fbScreenInit() but does so by using
a default DPI value of 96. That value is used to set the physical size
of the X11 screen, hence overriding the value computed from the actual
physical size provided by the Wayland compositor.
As a result, the DPI computed by tools such as xdpyinfo will always be
96 regardless of the actual screen size and resolution.
However, if the Wayland outputs get reconfigured, or new outputs added,
or existing outputs removed, Xwayland will recompute and update the
physical size of the screen, leading to an unexpected change of DPI.
To avoid that discrepancy, use a fixed size DPI (defaults to 96, and can
be set using the standard command lime option "-dpi") and compute a
physical screen size to match that DPI setting.
Note that only affects legacy core protocols, X11 clients can still get
the actual physical output size as reported by the Wayland compositor
using the RandR protocol, which also allows for the size to be 0 if the
size is unknown or meaningless.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/731
ProcVidModeGetGamma() relies on GetGamma() to initialise values if it
returns TRUE. Without this, we're sending uninitialised values to
clients.
Fixes: xorg/xserver#1040
When running with a weston session without a pointer device (thus with
the wl_seat not having a pointer) xwayland pointer warping and pointer
confining should simply be ignored to avoid crashes.
Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
These events aren't reachable after xwl_present_cleanup, so they're
leaked if we don't free them first.
This requires storing the pixmap pointer in struct xwl_present_window.
Luckily, the buffer pointer isn't used for anything, so just replace
that.
v2:
* Bump pixmap reference count in xwl_present_flip and drop it in
xwl_present_free_event, fixes use-after-free in the latter due to the
pixmap already being destroyed.
Reviewed-by: Dave Airlie <airlied@redhat.com>
When the linux-dmabuf protocol is available, prefer it over the old
wl_drm protocol. Previously wl_drm was used when modifiers aren't
supported, however linux-dmabuf supports formats without modifiers too.
In this case, linux-dmabuf will send a DRM_FORMAT_MOD_INVALID modifier
for each supported format [1].
This allows compositors to better handle these buffers, getting a
DMA-BUF and implementing features like direct scan-out.
A similar logic has been implemented for EGL [2].
DRM_FORMAT_MOD_INVALID is now stored in the xwl_screen->formats list.
glamor_get_modifiers still returns FALSE with zero modifiers if the
only advertised modifier is DRM_FORMAT_MOD_INVALID.
[1]: fb9b2a8731
[2]: c376865f5e
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Previously, linux-dmabuf was used unconditionally if the buffer had a
modifier. However creating a linux-dmabuf buffer with a format/modifier
which hasn't been advertised will fail.
Change xwl_glamor_gbm_get_wl_buffer_for_pixmap to use linux-dmabuf when
the format/modifier has been advertised only.
Signed-off-by: Simon Ser <contact@emersion.fr>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1035
Tested-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
This flag should only be used when the caller intends to display the
buffer on a hardware plane. Xwayland isn't a DRM client, so it doesn't
make sense to use this flag.
This change will allow the driver to potentially use buffer parameters
that are more optimized.
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Without this the client library will flail around looking for a default
provider, probably one named "indirect", and that defeats the point of
having the EGL provider for direct context support in the first place.
This assumes that "mesa" will work, of course, and in general it should.
Mesa drivers will DTRT through the DRI3 setup path, and if our glamor is
atop something non-Mesa then you should fall back to llvmpipe like 1.20.
In the future it might be useful to differentiate the vendor here based
on whether glamor is using gbm or streams.
Fixes: xorg/xserver#1032
Xwayland uses the device private to point to the `xwl_seat`.
Device may be removed at any time, including on suspend.
On resume, if the DIX code ends up calling a function that requires the
`xwl_seat` such as `xwl_set_cursor()` we may end up pointing at random
data.
Make sure the clear the device private data on removal so that we don't
try to use it and crash later.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
https://gitlab.freedesktop.org/xorg/xserver/issues/709
Drop GBM_BO_USE_SCANOUT from the GBM_BO_IMPORT_FD import, add
GBM_BO_USE_RENDERING to the GBM_BO_IMPORT_FD_MODIFIER import.
If the DMA-BUF cannot be scanned out, gbm_bo_import with
GBM_BO_USE_SCANOUT will fail. However Xwayland doesn't need to scan-out
the buffer and can work fine without scanout. Glamor only needs
GBM_BO_USE_RENDERING.
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
In this pretty Wine/Proton specific kludge, we try to handle confining grabs
on InputOnly windows by trying to find the InputOutput window that the pointer
would get visually confined to.
The grabbing window and the visible window come from different clients, so
we used to simply resort to the pointer focus. This is troublesome though, as
the call may happen very soon at a time that the toplevel wasn't yet mapped by
the Wayland compositor, so the pointer focus may well be out of date soon.
In these situations, it does seem that even though the confining grab happens
too early to have the wayland surface mapped, the xserver view of the WindowPtr
does already reflect the size. Use this to find out the better window to
assign the confining grab to, one whose geometry fully contains the InputOnly
window's.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
xwl_seat_maybe_lock_on_hidden_cursor() checks that the value of
cursor_confinement_window is not NULL, yet there is no code path
that could lead to this.
Remove the test for cursor_confinement_window being set, it's useless.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
When an X11 client issues a ConfinePointer wit ha hidden cursor,
Xwayland may translate that as a pointer lock.
However, if the pointer is located on another window at the time,
the request may be ignored, even if the pointer later enters the window.
To avoid that issue, check again if locking the pointer with a hidden
cursor is needed when pointer enters a surface.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
