Consider the following window hierarchy, from ancestors to descendants:
A
|
B
|
C
If both A & C have depth 32, but B has depth 24, C must effectively
behave as if it had depth 24, even if its backing pixmap has depth 32
as well.
Fixes the xmag issue described in the GitLab issue below.
Issue: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1564
If "-decorate" is used but no "-geometry" is specified, Xwayland rootful
would take its size from the actual Wayland outputs combined.
That is not practical, especially when using multiple outputs, as the
resulting Xwayland window would be much larger than a single monitor.
To avoid that, set a sensible default size for the Xwayland decorate
window, using 640x480 to match what Xephyr does.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
libdecor support seems quite stable, no need to mark that experimental.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
By default, the Xwayland window in rootful mode was not resizable.
Make the Xwayland window resizable using libdecor in rootful mode.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
This is preparation work for making Xwayland rootful resizeable.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
glamor ensures that a depth 32 pixmap backing a depth 24 window contains
fully opaque alpha channel values for the window's pixels, so we can
allow this without implicit redirection, saving pixmap storage and
intermediate copies.
This will be needed with the next commit: If a child window completely
obscures a toplevel ancestor of different depth, the child window can
use page flipping only if the depth of the presented pixmap matches that
of the window's backing pixmap, or the former may contain pixel values
which are not suitable for the toplevel window's depth.
It's needed for a depth 24 window backed by a depth 32 pixmap, to make
sure the window's pixels sample alpha as 1.0.
v2:
* Make sure glamor_finish_access doesn't pass in a NULL pointer.
Pass the DrawablePtr directly from glamor_finish_access to
glamor_upload_boxes. This will allow for better results if the window
depth doesn't match the backing pixmap depth.
With optional EI support in Xwayland, we would route XTEST events to EI
so that they get actually emulated in the Wayland compositor.
However, this implies that EI is actually supported in various places,
including the Wayland compositor of course. If, for whatever reason, we
fail to use EI, the actual XTEST events will be dropped.
That might be seen as a regression, as previously those would go through
the usual X11 processing of events and might have worked with X11 native
clients.
So, to keep backward compatibility, fallback to the plain old XTEST
method if EI is not available or not usable.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
This adds support for XTEST in Xwayland using EIS, the emulated input
library [1].
To differentiate between X11 clients using XTEST, initiate a EI context
for each client and use the actual client name, from its command
line.
When an X11 client first tries to use XTEST to generate emulated input
events, a new connection to libEI is initiated by Xwayland on behalf
of the X11 client.
During that connection phase, the EI server will not be accepting
events until the emulated device is actually created, meaning that any
XTEST request from the X11 client will be discarded until the EI server
is willing to accept events.
To avoid that issue, add an event queue in Xwayland per X11 client that
will keep those requests, and dequeue them as soon as the EI server is
ready, i.e. once the EI device is added.
If the X11 client disconnects from the Xserver before the EI server is
ready, or if the connection is closed by the EI server, those events are
discarded and the queue cleared from any pending events.
For 10 minutes after the client disconnects, keep the internal struct
alive. If a client with the same commandline arguments connects again,
re-use the same struct. This means we are faster with the events the
second time around but it also allows the EIS server to pause individual
clients that keep sending intermittent events and disconnect immediately
(e.g. it'd be possible to pause xdtotool while an authentication prompt
is active).
[1] https://gitlab.freedesktop.org/libinput/libei
Thanks to Jan Beich <jbeich@FreeBSD.org> for fixing the build on BSD.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Co-authored-by: Olivier Fourdan <ofourdan@redhat.com>
Co-authored-by: David Redondo <kde@david-redondo.de>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
For Xwayland, we need to be able to send the events that would normally
be processed by the normal Xserver event processing to be forwarded to
the Wayland compositor (somehow).
Add a new hook “DeviceSendEventsProc” attached to the device so that
Xwayland can implement its own routine instead of the “normal” XTEST
implementation which generates and processes X input events.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
This is needed for tearing-updates-v1
Signed-off-by: Xaver Hugl <xaver.hugl@gmail.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
This is needed for tearing-updates-v1
Signed-off-by: Xaver Hugl <xaver.hugl@gmail.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
This allows manual handling of IdleAction and IdleHint rather than automatically
calling the IdleAction every IdleSecs, due to inactivity on the underlying tty.
Fixes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1194
Signed-off-by: aarondill <aaronsacks2006@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Nothing should be relying on this anymore, so use a counter like other
places in the tree instead. This ensures that the event_id doesn't get
cast back into a pointer again in future, and also may be slightly less
confusing in cases where calloc reuses an address as debug logs would
show the same event_id for those but now they will be distinct.
Signed-off-by: Jessica Clarke <jrtc27@jrtc27.com>
On traditional 32-bit and 64-bit architectures, uint64_t can be abused
to hold a uintptr_t and be cast back to a valid pointer. However, on
CHERI, and thus Arm's Morello prototype, pointers are capabilities,
which contain a traditional address alongside additional metadata,
including a tag bit that ensures it cannot be forged (the only way to
get a capability with the tag bit set is by using instructions that take
in another valid capability with sufficient bounds/permissions/etc for
the request, and any other operation, like overwriting individual bytes
in memory, will give a capability whose tag is clear). Casting a pointer
to a uintptr_t is fine as uintptr_t is represented as a capability, but
casting to a uint64_t yields just the address, losing the metadata and
tag. Thus, when cast back to a uintptr_t, the capability remains invalid
and faults on any attempt to dereference.
As with various other places in the tree, address this by searching for
the pointer in a list so that we no longer rely on this undefined
behaviour.
Signed-off-by: Jessica Clarke <jrtc27@jrtc27.com>
All these arguments other than damage come from the vblank itself so
passing the vblank simplifies the caller. Moreover, we pass the event_id
solely so we can get back to the event, which is just the (extended)
vblank, so passing the vblank avoids that round trip.
Signed-off-by: Jessica Clarke <jrtc27@jrtc27.com>
By adding a new xwl_present_event_from_vblank function we can avoid
turning the vblank into an event_id, and also abstract away the exact
encoding for event_id from most places.
Signed-off-by: Jessica Clarke <jrtc27@jrtc27.com>
The current code, as changed by commit ad2d461de „Do not round
non-standard modes“ is reported to be logically incongruent.
We should either drop libxcvt entirely or simply fix the size, keeping
the CVT timings unchanged.
For backward compatibility and simplicity, I'd rather simply fix the
hdisplay/vdisplay to match the given size.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Fixes: ad2d461de - xwayland: Do not round non-standard modes
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1549
Commit ad2d461de „xwayland: Do not round non-standard mode“ introduced a
spelling error in the names of the local functions.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Fixes: ad2d461de - xwayland: Do not round non-standard modes
ki->name has already initialized in KdNewKeyboard() with strdup().
But initialized in KdParseKeyboard() again.
Signed-off-by: Tamura Dai <kirinode0@gmail.com>
Now that our CVT function is able to deal with non-standard modes, we
can safely use it for the fixed mode as well.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Currently, Xwayland uses libxcvt to generate the mode info and then
passes that to RRModeGet() to generate a RRMode.
However, libxcvt may round down the width to match the horizontal
granularity (8), and that's a problem when the Wayland compositor is
running a non-standard size (like, e.g. running nested with a custom
size) because XRandR would report a width smaller than the actual size.
To avoid that, check whether the CVT computed size differs from the
expected size, and fallback to a simpler computation not doing any
rounding if that's the case.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1540
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Compositors may use XWAYLAND_ALLOW_COMMITS to communicate when Xwayland
may or may not commit new buffers to a wl_surface. If commits are
denied, then later allowed, we'll only get a buffer attached if there is
actual damage posted, which might be long after.
This fixes an issue where the window manager would reparent a window
while denying commits, then after reparenting, allow commits. The window
in question belonged to a game and took several seconds produce the next
frame, resulting in an empty window appearing as if it had just
disappeared.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
xf86-video-nouveau calls wfbScreenInit without defining
FB_ACCESS_WRAPPER (which has other unintended side effects).
Presently, this compiles and links because compilers still support
implicit function declarations, but this is going to change fairly
soon. This seems to be the most straightforward change to keep
the driver building.
SO_PEERCRED is not POSIX, so might be hidden unless _GNU_SOURCE
is defined.
See [1]: cc.has_header_symbol() does not inherit the project
arguments.
[1]: https://github.com/mesonbuild/meson/issues/3301
Signed-off-by: Simon Ser <contact@emersion.fr>
If the format and modifiers are from a tranche which supports scanout,
we can set the corresponding flag to gbm_bo_create_with_modifiers2() to
benefit from scanout buffers where applicable.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Add a new API similar to xwl_glamor_get_drawable_modifiers() but also
returning whether the format and modifiers are from a tranche which
supports scanout.
This is preparation work for adding scanout support with
gbm_bo_create_with_modifiers2() when supported.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
This allows us to pass flags to the function, avoiding the forced
implicit GBM_BO_USE_SCANOUT which happens with the older version.
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
The present code in Xwayland cannot be used without GBM, so if GBM is
not available (or too old), the build would fail.
Make sure we do not use the present code without GBM support.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
The functions glamor_egl_fd_from_pixmap()/glamor_egl_fds_from_pixmap()
are not available without GBM support.
So if GBM is not available or too old, the code would fail to link
trying to find the references to those functions.
Make sure we skip that code when glamor is built without GBM.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
The Wayland library may log warnings, we do not need to make that fatal
to the Xserver.
By killing the Xserver whenever a warning is raised, we hide other log
messages that might be also interesting.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>