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>
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>
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>
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
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
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>
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 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
Adds a -force-xrandr-emulation cmdline switch that always exposes extra
modes when viewporter isn't exposed by the Wayland compositor.
Having the additional modes exposed by the X server is important for
games to function and be configured
Compositors, such as Gamescope (the compositor for Steam Deck),
support only a single window that is rendered in the centre of the
screen that is scaled up to fill the screen by the compositor based
on some user scaling settings.
Exposing viewporter, wouldn't make sense here, and could mislead native
Wayland clients, so exposing dummy modesets in X is preferred here.
Signed-off-by: Joshua Ashton <joshua@froggi.es>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Xwayland may open a fair amount of file descriptors for passing Wayland
buffers, even more so when using the `wl_shm` either for the pointer
cursors or for when GLAMOR is not usable.
As a result, Xwayland may hit the (soft) limit of file descriptors
leading to a Wayland protocol error and the termination of Xwayland.
To mitigate that risk, raise the limit to the maximum (hard) limit of
file descriptors (unless of course the limit was set explicitly from the
command line with "-lf").
Note that for completeness, the Wayland compositor may have to do the
same, otherwise the limit might get reached on the compositor side as
well.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Suggested-by: Simon Ser <contact@emersion.fr>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1283
Passing -noTouchPointerEmulation results in an error about the
flag not being recognized.
Signed-off-by: Simon Ser <contact@emersion.fr>
Fixes: 7d34b1f2b7 ("xwayland: add -noTouchPointerEmulation")
In some scenarios, the Wayland compositor might have more knowledge
than the X11 server and may be able to perform pointer emulation for
touch events better. Add a command-line switch to allow compositors
to turn Xwayland pointer emulation off.
Signed-off-by: Simon Ser <contact@emersion.fr>
This bumps the minimum Wayland version to 1.5 (released in 2014).
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Martin Peres <martin.peres@mupuf.org>
LogMessage logs only when the XLOG_VERBOSITY is >= 1, but by default
XLOG_VERBOSITY is 0, so for example warning about deprected -listen
parameter is never shown when running "Xwayland -listen 32 -help".
Signed-off-by: Mariusz Ceier <mceier+freedesktop@gmail.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>
Xorg supports the '-version' command line option, add something similar
to Xwayland.
Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/976
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Now that each source and header should be in order, we can safely cleaup
the last remaining bits from the main `xwayland.h` which is not needed
anymore and can be removed.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Move the Xwayland vidmode declaration to its own header file.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Move Xwayland screen related code to a separate source file and header.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Move the Xwayland cursor declarations to their own header file.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Move the Xwayland output declarations to their own header file.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Move the Xwayland input declarations to their own header file.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Move the Xwayland Present declarations to their own header file.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Move Xwayland generic pixmap code to a separate source file and header.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Over time, Xwayland main source file `xwayland.c` has grown in size
which makes it look cluttered and harder to read.
Move the code dealing with Xwayland window to its own source and header
files.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Currently, `xwayland.h` contains all the declarations, which is a bit
awkward and hard to follow.
Move the GLAMOR relevant declarations to their own header file.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Currently, `xwayland.h` contains all the declarations, which is a bit
awkward and hard to follow.
Move the SHM relevant declarations to their own header file.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Using a list of Present windows that need to be called back.
This prepares for the following change, there should be no change in
observed behaviour.
v2:
* Use xwl_window_create_frame_callback instead of making the
frame_listener struct non-static (Olivier Fourdan)
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Damage coordinates are relative to the drawable, (0,0) being the top
left corner inside the border.
Therefore, when applying damages or accumulating damages between window
buffers, we need to take the window border width into account as well,
otherwise the updates might be only partial or misplaced.
Related: https://gitlab.freedesktop.org/xorg/xserver/issues/951
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Right now, we would recycle the window buffers whenever the window the
window is resized.
This, however, is not sufficient to guarantee that the buffers are up
to date, since changing the window border width for example would not
trigger a `WindowResize` (the border being outside the window).
Make sure we recycle the buffers on `SetWindowPixmap` to ensure that
the buffers will be recycled whenever the pixmap size is changed.
Related: https://gitlab.freedesktop.org/xorg/xserver/issues/951
Suggested-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Xwayland takes care of not attaching a new buffer if a frame callback is
pending.
Yet, the existing buffer (which was previously attached) may still be
updated from the X11 side, causing unexpected visual glitches to the
buffer.
Add multiple buffering to the xwl_window and alternate between buffers,
to leave the Wayland buffer untouched between frame callbacks and avoid
stuttering or tearing issues.
Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/835
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
The API `wl_buffer_add_listener` is misleading in the sense that there
can be only one `wl_buffer` release callback, and trying to add a new
listener when once is already in place will lead to a protocol error.
The Xwayland EGL backends may need to set up their own `wl_buffer`
release listener, meaning that there is no way to our own `wl_buffer`
release callback.
To avoid the problem, add our own callback API to be notified when the
`wl_buffer` associated with an `xwl_pixmap` is released, triggered from
the different `xwl_pixmap` implementations.
Also update the Present code to use the new buffer release callback API.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Currently, when a X11 client (usually the X11 window manager from a
Wayland compositor) changes the value of the X11 property
`_XWAYLAND_ALLOW_COMMITS` from `false` to `true`, all pending frame
callbacks on the window are discarded so that the commit occurs
immediately.
Weston uses that mechanism to prevent the content of the window from
showing before it's ready when mapping the window initially, but
discarding the pending frame callbacks has no effect on the initial
mapping of the X11 window since at that point there cannot be any frame
callback on a surface which hasn't been committed yet anyway.
However, discarding pending frame callbacks can be problematic if we
were to use the same `_XWAYLAND_ALLOW_COMMITS` mechanism to prevent
damages to be posted before the X11 toplevel is updated completely
(including the window decorations from the X11 window manager).
Remove the portion of code discarding the pending frame callback,
Xwayland should always wait for a pending frame callback if there's one
before posting new damages.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
https://gitlab.freedesktop.org/xorg/xserver/merge_requests/333
Apps using randr to change the resolution when going fullscreen, in
combination with _NET_WM_STATE_FULLSCREEN to tell the window-manager (WM)
to make their window fullscreen, expect the WM to give the fullscreen window
the size of the emulated resolution as would happen when run under Xorg (*).
We need the WM to emulate this behavior for these apps to work correctly,
with Xwaylands resolution change emulation. For the WM to emulate this,
it needs to know about the emulated resolution for the Windows owning
client for each monitor.
This commit adds a _XWAYLAND_RANDR_EMU_MONITOR_RECTS property, which
contains 4 Cardinals (32 bit integers) per monitor with resolution
emulation info. Window-managers can use this to get the emulated
resolution for the client and size the window correctly.
*) Since under Xorg the resolution will actually be changed and after that
going fullscreen through NET_WM_STATE_FULLSCREEN will size the window to
be equal to the new resolution.
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Games based on the allegro gaming library or on ClanLib-1.0 do not size
their window to match the fullscreen resolution, instead they use a
window covering the entire screen, drawing only the fullscreen resolution
part of it.
This commit adds a check for these games, so that we correctly apply a
viewport to them making fullscreen work properly for these games under
Xwayland.
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Add support for per client randr-resolution change emulation using viewport,
for apps which want to change the resolution when going fullscreen.
Partly based on earlier work on this by Robert Mader <robert.mader@posteo.de>
Note SDL2 and SFML do not restore randr resolution when going from
fullscreen -> windowed, I believe this is caused by us still reporting the
desktop resolution when they query the resolution. This is not a problem
because when windowed the toplevel window size includes the window-decorations
so it never matches the emulated resolution.
One exception would be the window being resizable in Windowed mode and the
user resizing the window so that including decorations it matches the
emulated resolution *and* the window being at pos 0x0. But this is an
extreme corner case. Still I will submit patches upstream to SDL2
and SFML to always restore the desktop resolution under Xwayland,
disabling resolution emulation all together when going windowed.
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Add per client private data, which for now is empty.
This is a preparation patch for adding randr/vidmode resolution
change emulation.
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
This is a preparation patch for adding support for apps which want to
change the resolution when they go fullscreen because they are hardcoded
to render at a specific resolution, e.g. 640x480.
Follow up patches will fake the mode-switch these apps want by using
WPviewport to scale there pixmap to cover the entire output.
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
When a viewport is set, damage will only work properly when using
wl_surface_damage_buffer instead of wl_surface_damage.
When no viewport is set, there should be no difference between
surface and buffer damage.
This is a preparation patch for using viewport to add support for fake
mode-changes through xrandr for apps which want to change the resolution
when going fullscreen.
Changes by Hans de Goede <hdegoede@redhat.com>:
-Split the damage changes out into their own patch
-Add xwl_surface_damage helper
-Also use buffer_damage / the new helper for the present and cursor code
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
This commit adds support for the wayland wp_viewport extension, note
nothing uses this yet.
This is a preparation patch for adding support for fake mode-changes through
xrandr for apps which want to change the resolution when going fullscreen.
[hdegoede@redhat.com: Split the code for the extension out into its own patch]
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
This FD also triggers the "wait for WM_S0" paths, so that the
compositor may set up a "maintenance line" for Xwayland, for
services that are essential to run before any client (eg. xrdb).
Those services would use this FD, disguised as an extra display
connection.
This -initfd can be seen as a generalization of -wm, a Wayland
compositor may use -initfd to launch its WM and any other clients
that should start up, or it may use -wm as a dedicated connection for
the WM and optionally use -initfd for the misc. startup clients.
If either of -wm or -initfd is passed, Xwayland will expect a selection
notification on WM_S0 before incorporating the FDs in -listen to the
poll list.
Also, correct a minor typo in the listenfd argument output,
give → given.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
If Xwayland gets to realize a window meant for composition before the
compositor redirected windows (i.e. redirect mode is not RedirectDrawManual
yet), the window would stay "invisible" as we wouldn't create a
wl_surface/wl_shell_surface for it at any later point.
This scenario may happen if the wayland compositor sets up a X11 socket
upfront, but waits to raise Xwayland until there are X11 clients. In this
case the first data on the socket is the client's, the compositor can hardly
beat that in order to redirect subwindows before the client realizes a
Window.
In order to jump across this hurdle, allow the late creation of a matching
(shell) surface for the WindowPtr on SetWindowPixmapProc, so it is ensured
to be created after the compositor set up redirection.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
This will be dissociated in future commits to handle the cases
where windows are being realized before there is a compositor
handling redirection.
In that case, we still want the DamagePtr to be registered upfront
on RealizeWindowProc before a corresponding xwl_window might be
created. Most notably, it cannot be lazily created on
SetWindowPixmapProc as damage accounting gets broken.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
This adds support for xdg-output-unstable-v1 version 3, added in [1].
This new version deprecates zxdg_output_v1.done and replaces it with
wl_output.done. If the version is high enough, there's no need to wait for both
an xdg_output.done event and a wl_output.done event -- we only care about
wl_output.done.
[1]: 962dd53537
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Olivier Fourdan
Michel Dänzer
Peter Hutterer
Joshua Ashton
Simon Ser
Misha Gusarov
Mariusz Ceier
David Seifert
Hans de Goede
Robert Mader
Carlos Garnacho