The configure handler for libdecor, namely handle_libdecor_configure(),
is where both the content and the decorations get resized (when needed).
If for any reason, the actual size of the Xwayland screen fails to be
updated, we would still appy the expected size rather than the actual
one for the libdecor state.
To avoid this, use the actual xwl_screen width/height for the libdecor
state.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
For libdecor, we will have to attach a new buffer and commit from two
different handlers (libdecor configure and commit).
Having xwl_window_attach_buffer() separate from xwl_window_post_damage()
is to allow for that.
This commit should not introduce any functional change.
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.
Second attempt, after fixing a few regressions from the first attempt.
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.
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>
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>
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 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>
Whenever the linux-dmabuf v4 feedback changes, we need to recreate the
existing buffers so they use the current linux-dmabuf v4 feedback.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
When creating the window buffer's backing pixmap, try the Xwayland
glamor hook first and fallback to the regular CreatePixmap() code path
otherwise.
That allows to enable direct scanout if possible, either through the
regular dmabuf v4 code path, or from the implicit fallback code path.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Before linux_dmabuf v4 support was added, the BO were created using
gbm_bo_create_with_modifiers() which incidentally creates scanout
capable buffers.
We now need to replicate that explicitly when using the fallback path,
with buffers window, otherwise direct scanout will not be possible in
that case.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1535
Suggested-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Add the implementation for create_pixmap_for_window() in the GBM glamor
backend.
To do so, we just rename the existing xwl_glamor_gbm_create_pixmap() as
internal and add an optional drawable parameter, so that it can be used
either from the regular CreatePixmap code path, or from the new direct
Xwayland glamor's hook.
v2: Fallback to xwl_glamor_get_modifiers() if
xwl_glamor_get_drawable_modifiers() returned 0 modifiers. (Michel)
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
With linux dmabuf v4 support, for direct scanout support, we need more
context that just what CreatePixmap() provides, as we need the actual
drawable to invoke xwl_glamor_get_drawable_modifiers().
Add a specific hook in Xwayland's glamor implementation that we can use
for that purpose.
This is preparation work for the direct scanout fixes.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
With implicit modifiers, DRM_FORMAT_MOD_INVALID is an allowed modifier,
to indicate that the server can support the format.
When looking for a scanout capable tranche with implicit modifiers, we
ought to check for the availability of a tranche with an invalid
modifier for the given format.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
The helper function xwl_feedback_is_modifier_supported() walks all the
formats of a feeedback tranche and checks for format/modifier support
availability.
Add scanout support to that so that a caller can easily restrict the
tranches to those which support scanout.
This is preparation work for the implicit scanout support, no functional
change.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Separate the callbacks for the default's feedback from the one for
regular windows.
This is preparation work to recreate the window buffer of feedback
updates, no functional change.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
It could happen with the following call path:
frame_callback
xwl_present_frame_callback
xwl_present_msc_bump
xwl_present_execute
xwl_present_flip
xwl_window_create_frame_callback
The nested loop called xwl_present_reset_timer, which may end up calling
xorg_list_del for the entry after the one frame_callback started the
chain for. This resulted in the outer loop never terminating, because
its next element wasn't hooked up to the list anymore.
We avoid this by calling xwl_present_reset_timer as needed in
frame_callback, and bailing from xwl_window_create_frame_callback if it
was called from the former.
We also catch nested calls and FatalError if they ever happen again due
to another bug.
v2:
* Leave xwl_present_reset_timer call in xwl_present_frame_callback,
needed if xwl_present_msc_bump didn't hook up the window to the frame
callback list again.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1442
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
When using TearFree, DRI clients have no way of accurately knowing when
their copied pixmaps appear on the display without utilizing the kernel
driver's notification indicating that the TearFree flip containing their
pixmap is complete. This is because the target CRTC's MSC can change while
the predicted completion MSC is calculated and even while the page flip
IOCTL is sent to the kernel due to scheduling delays and/or unfortunate
timing. Even worse, a page flip isn't actually guaranteed to be finished
after one vblank; it may be several MSCs until a flip actually finishes
depending on delays and load in hardware.
As a result, DRI clients may be off by one or more MSCs when they naively
expect their pixmaps to be visible at MSC+1 with TearFree enabled. This,
for example, makes it impossible for DRI clients to achieve precise A/V
synchronization when TearFree is enabled.
This change therefore adds a way for DRI clients to receive a notification
straight from the TearFree flip-done handler to know exactly when their
pixmaps appear on the display. This is done by checking for a NULL pixmap
pointer to modesetting's DRI flip routine, which indicates that the DRI
client has copied its pixmap and wants TearFree to send a notification when
the copied pixmap appears on the display as part of a TearFree flip. The
existing PageFlip scaffolding is reused to achieve this with minimal churn.
The Present extension will be updated in an upcoming change to utilize this
new mechanism for DRI clients' presentations.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
Acked-by: Martin Roukala <martin.roukala@mupuf.org>
It is possible for vblank events to run out of order with respect to one
another because the event which was queued to the kernel has the privilege
of running before all other events are handled. This allows kernel-queued
events to run before other, older events which should've run first.
Although this isn't a huge problem now, it will become more problematic
after the next change which ties DRI client notifications to TearFree page
flips. This increases the likelihood of DRI clients erroneously receiving
presentation-completion notifications out of order; i.e., a client could
receive a notification for a newer pixmap it submitted *before* receiving a
notification for an older pixmap.
Ensure vblank events always run in sequential order by removing the bias
towards kernel-queued events, and therefore forcing them to run at their
sequential position in the queue like other events.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
Reviewed-by: Martin Roukala <martin.roukala@mupuf.org>
There is more than one place with the confusing TearFree state check for a
CRTC. Instead of open-coding the TearFree check everywhere, introduce a
helper, ms_tearfree_is_active_on_crtc, to cover the TearFree state checks.
Suggested-by: Martin Roukala <martin.roukala@mupuf.org>
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
Reviewed-by: Martin Roukala <martin.roukala@mupuf.org>
Check that the VT is owned and that the CRTC is on before exporting info to
Present stating that TearFree is available. Also, since `trf->buf[0].px` is
checked, the `ms->drmmode.tearfree_enable` check is redundant and can
therefore be removed.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
Reviewed-by: Martin Roukala <martin.roukala@mupuf.org>
The event allocation for ms_do_pageflip is leaked on error because callers
of ms_do_pageflip have no way of knowing whether or not a page flip
succeeded for any CRTCs. If a page flip succeeded for at least one CRTC,
then it's not safe for the caller to free the event allocation, and the
allocation won't be leaked. The event allocation is only leaked when not a
single CRTC's page flip succeeded.
Since all callers of ms_do_pageflip allocate the event pointer, and all of
them intentionally leak the event allocation when ms_do_pageflip returns an
error, just free the event pointer inside ms_do_pageflip when a page flip
doesn't succeed for any CRTC.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
Reviewed-by: Martin Roukala <martin.roukala@mupuf.org>
The CRTC pointer will soon be needed in the TearFree flip handlers, so pass
it in instead of passing in drmmode_tearfree_ptr.
No functional change.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
Reviewed-by: Martin Roukala <martin.roukala@mupuf.org>
Rather than passing the reference CRTC's vblank pipe to ms_do_pageflip,
just pass the pointer to the reference CRTC directly instead. This is
clearer and more useful than the vblank pipe, since the vblank pipe is only
used to identify whether or not a given CRTC is the reference CRTC.
No functional change.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
Reviewed-by: Martin Roukala <martin.roukala@mupuf.org>
This #ifdef is redundant since ms_do_pageflip is already enclosed within a
larger GLAMOR_HAS_GBM #ifdef.
No functional change.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
Reviewed-by: Martin Roukala <martin.roukala@mupuf.org>
This moves lnx_platform.c to the shared directory and adds it to
the BSD build. This is needed for PRIME render offload.
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
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>
Make sure info->active and info->vt_active are false after
dropping drm master.
Normally, this is done when pausing the first input device, so it
breaks when there are no input device at all.
Fixes: da9d012a9 ("xf86/logind: Fix drm_drop_master before vt_reldisp")
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1387
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
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>
Commit 5145742fb6 accidentally bumped the videodrv ABI version from 26.0
to 26.6 in one go.
Change it back to 26.1 as per the documented process for minor additions.
Fixes: 5145742fb6 - randr: introduce rrCrtcGetInfo DDX function
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
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>
This allows rrCrtcGetInfo to override the values in the XRRCrtcGetInfo
reply. One use case is to allow Xwayland to return the current emulated
mode for the specific client instead of the global 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>
If atomic modesetting is to be enabled in the configuration file, log
whether this is supported and eventually enabled or disabled.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Martin Roukala <martin.roukala@mupuf.org>
The modesetting driver has atomic modesetting disabled by default but
can be enabled (if supported) using a configuration option.
Add this option in the man page.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Martin Roukala <martin.roukala@mupuf.org>
This adds support for TearFree page flips to eliminate tearing without the
use of a compositor. It allocates two shadow buffers for each CRTC, a back
buffer and a front buffer, and uses damage tracking to minimize excessive
copying between buffers and skip unnecessary flips when the screen's
contents remain unchanged. It works on transformed screens too, such as
rotated and scaled CRTCs.
When PageFlip is enabled, TearFree won't force fullscreen DRI clients to
synchronize their page flips to the vblank interval.
TearFree is disabled by default.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
The DRM event queue in the kernel is quite small and can be easily
exhausted by DRI clients. When the event queue is full, that means nothing
can be queued onto it anymore, which can lead to incorrect presentation
times for DRI clients and failure when attempting to queue a page flip.
To make matters worse, once an event is placed onto the kernel's event
queue, there's no straightforward way to prematurely remove it from the
kernel's event queue in userspace, which means that aborting a sequence
number doesn't free up space in the event queue.
Since vblank events from DRI clients are the largest consumers of the
event queue, and since it's often easy to know the desired target MSC of
their vblank events without querying the kernel for a CRTC's current MSC,
we can coalesce vblank events occurring at the same MSC such that only one
of them is placed onto the kernel's event queue, instead of allowing
duplicate vblank events to pollute the event queue.
This is achieved by tracking the next kernel-queued event's MSC on a
per-CRTC basis and then running all of that CRTC's vblank event handlers
which have reached their target MSC when the queued MSC is signaled.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
do_queue_flip_on_crtc() is about to be used to flip buffers other than the
primary scanout (`ms->drmmode.fb_id`), so make it generic to accept any
frame buffer ID, as well as x and y coordinates in the frame buffer, to
flip on a given CRTC. Move the retry logic from queue_flip_on_crtc() into
it as well, so that it's robust for all callers.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
Shadow buffers are about to be used for TearFree, so make the shadow buffer
helpers generic such that they can be used to create arbitrary per-CRTC
shadows aside from just the per-CRTC rotated buffer.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
xf86RotateCrtcRedisplay() is about to be used outside of xf86Rotate.c in
order to copy transformed pixmaps, so fix up its interface by specifying
the source drawable and destination pixmap rather than assuming the root
drawable and rotated pixmap, respectively. In addition, add an argument to
make xf86RotateCrtcRedisplay() not perform any transformations, which is an
indicator that it should only copy a transformed pixmap rather than
actually transform a pixmap.
These changes make it possible to use xf86RotateCrtcRedisplay() to not
only copy transformed pixmaps, but also actually transform pixmaps, making
it very useful outside of xf86Rotate.c.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.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>
The current X server infrastructure sets modesetting driver as default driver
to handle PCI-hotplug of a GPU device. This prevents the respective DDX driver
(like AMDGPU DDX driver) to take control of the card.
This patch:
- Adds a few functions and fine-tunes the GPU hotplug infrastructure to allow
the DDX driver to be loaded, if it is configured in the X config file
options as "hotplug-driver".
- Scans and updates the PCI device list before adding the new GPU device
in platform, so that the association of the platform device and PCI device
is in place (dev->pdev).
- Adds documentation of this new option
An example usage in the config file would look like:
Section "OutputClass"
Identifier "AMDgpu"
MatchDriver "amdgpu"
Driver "amdgpu"
HotplugDriver "amdgpu"
EndSection
V2:
Fixed typo in commit message (Martin)
Added R-B from Adam.
Added ACK from Alex and Martin.
V3:
Added an output class based approach for finding the DDX driver (Aaron)
Rebase
V4:
Addressed review comment from Aaron:
GPU hot-plug handling driver's name to be read from the DDX config file options.
In this way only the DDX drivers interested in handling GPU hot-plug will be
picked and loaded, for others modesetting driver will be used as usual.
V5:
Addressed review comments from Aaron:
- X config option to be listed in CamelCase.
- Indentation fix at one place.
- Code readability related optimization.
V6:
Addressed review comments from Aaron:
- Squash the doc in the same patch
- Doc formatting changes
Cc: Alex Deucher <alexander.deucher@amd.com>
Suggested-by: Aaron Plattner aplattner@nvidia.com (v3)
Acked-by: Martin Roukala martin.roukala@mupuf.org(v1)
Acked-by: Alex Deucher alexander.deucher@amd.com (v1)
Reviewed-by: Adam Jackson ajax@redhat.com(v1)
Signed-off-by: Shashank Sharma shashank.sharma@amd.com
Current error:
ld: error: undefined symbol: xf86EnableIO
>>> referenced by xf86Configure.c
>>> libxorg_common.a.p/xf86Configure.c.o:(DoConfigure) in archive hw/xfree86/common/libxorg_common.a
>>> referenced by xf86Events.c
>>> libxorg_common.a.p/xf86Events.c.o:(xf86VTEnter) in archive hw/xfree86/common/libxorg_common.a
>>> referenced by xf86Init.c
>>> libxorg_common.a.p/xf86Init.c.o:(InitOutput) in archive hw/xfree86/common/libxorg_common.a
>>> referenced 1 more times
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
Changes check for trying modesetting driver from if defined(__linux__)
to use meson check for if we built the driver for this platform.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
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
I wanted to simplify the logic, and thought this is a good opportunity
to eliminate local diffs.
I don't want to list OSes without wsfb, because I understand that is a
netbsd/openbsd driver, and always have it as a fallback for us.
Additionally, I understand "fbdev" is linux-specific, so have the logic
match this intent.
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>
Olivier Fourdan
Michel Dänzer
Russell Chou
Peter Hutterer
Xaver Hugl
Aaron Dill
Jessica Clarke
Tamura Dai
Jonas Ådahl
Simon Ser
Sultan Alsawaf
Alan Coopersmith
Austin Shafer
Minh Phan
Ivan A. Melnikov
Jeremy Huddleston Sequoia
Joshua Ashton
Jocelyn Falempe
John D Pell
Doğukan Korkmaztürk
Corentin Noël
Shashank Sharma
pkubaj
Lucas Stach
Demi Marie Obenour
Jan Beich
coypu@sdf.org
David Jacewicz