The vidmode extension emulation in Xwayland reports the modeline based
on the current mode.
To do so, it searches for the mode using `xwl_output_find_mode(-1, -1)`
which is supposed to return the current mode, whatever that mode is.
With XRandR emulation, in rootless mode, the default value is the mode
at index 0. That assumption, however is not true when running rootful.
That means that the vidmode extension will always return the highest
mode available, which is 5120x2880, with Xwayland running rootful:
$ xwayland-run -geometry 1024x768 -- xvidtune -show
"5120x2880" 1276.50 5120 5560 6128 7136 2880 2883 2888 2982 -hsync +vsync
Luckily, when Xwayland is running rootful, we have the current mode size
conveniently stored in dedicated fields of the xwayland output struct,
so we can use that to search for the right mode being used and report
that through the vidmode extension:
$ xwayland-run -geometry 1024x768 -- xvidtune -show
"1024x768" 63.50 1024 1064 1176 1328 768 771 775 798 -hsync +vsync
That fixes legacy games using the vidmode extension and rendering at the
wrong size when running within Xwayland rootful.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1641>
This has been nothing but an alias for two decades now (somewhere in R6.6),
so there doesn't seem to be any practical need for this indirection.
The macro still needs to remain, as long as (external) drivers still using it.
Fixes: ded6147bfb
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1529>
Even though the name provided by either xdg-output or wl_output are
guaranteed to be unique, that might not be the case with output names
between different protocols, such as the one offered for DRM lease.
To avoid running into name conflicts, check that no other existing
output of the same name exists prior to changing the output name.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1492>
Since we already had to rename some of them, in order to fix name clashes
on win32, it's now time to rename all the remaining ones.
The old ones are still present as define's to the new ones, just for
backwards compatibility.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1355>
Add a list of outputs a window is placed on, adding an output whenever
the surface enters the output and removing it once it leaves the output.
Note that not all Wayland compositors actually send a leave surface
event on output removal, so we need to make sure to remove the output
from the list for each window, otherwise we might end up pointing to
freed memory.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-By: Kenny Levinsen <kl@kl.wtf>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1197>
Keep track of the output scales as advertised by the wl_output protocol.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-By: Kenny Levinsen <kl@kl.wtf>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1197>
Advertise the scaling factor applied to the Xwayland output using the
mechanism of CRTC transforms.
That allows for X11 clients to query the scale factor using XRandR.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-By: Kenny Levinsen <kl@kl.wtf>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1197>
Add a scale factor to the Xwayland output and take the scale into
account when computing the screen size.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-By: Kenny Levinsen <kl@kl.wtf>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1197>
The mode size can be different from the actual output size when a
transformation is at play.
Store the actual mode width/height as well in preparation for adding
support for transforms.
No functional change.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-By: Kenny Levinsen <kl@kl.wtf>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1197>
Use double precision floating point for the screen size to reduce the
rounding issues when using fractional scaling.
Introduce a couple of simple convenient functions that round the
floating point value into an integer and use it in place of directly
accessing the xwl_screen width/height for integer computation.
This is preparation work for the introduction of fractional scaling,
there should be no functional change at this point.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-By: Kenny Levinsen <kl@kl.wtf>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1197>
At startup, the names of the Wayland outputs are not yet known,
therefore we cannot rely on those when running fullscreen rootful.
Make sure to check the fullscreen state once the Wayland output name
changes.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Add a convenient function to search for an xwl_output based on its
XRandR name.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
When running rootful, we do not need to apply the output changes, these
are there just to track the names and show up as disconnected in XRandR.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
When running rootful, Xwayland would simply skip the creation of the CRTC
for the "real" outputs.
Instead, create the CRTC regardless of all outputs in rootful mode, but
mark them as disconnected when running rootful.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
The fixed output is called "XWAYLAND0", yet if the compositor does not
support Wayland output names, the "real" output names may collide with
the fixed output name.
Use the same output serial as with the (default) real output names to
avoid reusing the same names.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Use the simpler form `{ 0 }` instead of `{ '\0', }` for the
initialization of the output name buffer.
No functional change.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Move the code which may update the fullscreen state of the rootful
window to a dedicated helper function.
No functional change.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
When creating the output with the default "XWAYLAND<n>" name, we use
the MAX_OUTPUT_NAME value to allocate a lot more memory than necessary
to accommodate for future output names once they get updated, but by
doing so, we also send XRandR way too much (zeroed) data since the
"nameLength" value is (purposely) set too big.
So, instead, let's just update the name after creating the RR output,
this way we set both the name and nameLength to their correct values
while keeping the initial large allocation.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Fixes: 3c07a01c42 - xwayland: Use xdg-output name for XRandR
Reviewed-by: Simon Ser <contact@emersion.fr>
At creation, Xwayland uses a generic output name ("XWAYLAND0", etc.) for
the XRandR outputs, and later, once the name is known from the Wayland
protocols, updates the output names using the actual names from the
Wayland compositor.
However, when doing so, it simply updates the string, the "nameLength"
isn't updated, so the name passed to the clients might either end up
being truncated or contain portions of the previous (initial) output
name.
Note, this is using a fixed size buffer initialized with zeros, so this
cannot leak any data other than the previous output name, so this is
mainly a cosmetic issue.
Update the output's "nameLength" when updating the output name.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Fixes: 3c07a01c42 - xwayland: Use xdg-output name for XRandR
Reviewed-by: Simon Ser <contact@emersion.fr>
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>
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>
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 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>
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>
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>
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>
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>
The function xwl_output_remove() is called when removing a monitor, but
the actual status of the RandR output does not change.
So, when RRTellChanged() is called from update_screen_size(), it won't
have the output connection status up to date in the RandR event
RROutputChangeNotifyEvent and X11 applications relying on that event
like Qt will fail to emit their signal QGuiApplication::screenRemoved.
To avoid that issue, make sure to mark the RandR output as disconnected
prior to call xwl_output_remove().
Fix commit 204f10c29 ("xwayland: Call RRTellChanged if the RandR configuration may have changed")
Signed-off-by: zhoulei <zhoulei@kylinos.cn>
Signed-off-by: Morose <chenlinxiang@kylinos.cn>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
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>
Adds the following 16:10 modes primarily for scaling up on Steam Deck:
- 1152x720
- 960x600
- 928x580
- 800x500
- 768x480
Signed-off-by: Joshua Ashton <joshua@froggi.es>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Xwayland does not change the actual XRANDR setup for real, it just
emulates the resolution changes using viewports in Wayland.
With a single output, if an X11 applications tries to change the CRTC
back to the native mode, RRCrtcSet() will simply ignore the request as
no actual change is induced by this.
Set the property "RANDR Emulation" on all Xwayland outputs to make sure
the optimizations in RRCrtcSet() get skipped and Xwayland can receive
and act upon the client request.
Also make sure we do not allow that property to be changed by X11
clients.
v2: Prevent X11 clients from changing the property value
(Pekka Paalanen <pekka.paalanen@collabora.com>)
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1305
This commit allows X11 clients running through Xwayland to lease
non-desktop connectors from the Wayland compositor by implementing
support for drm-lease-v1.
In order to not deadlock with the Wayland compositor if its response
to a lease request is delayed, the new interface in _rrScrPriv
introduced in the last commit is used, which makes it possible to
block the X11 client while a response is pending.
Leasing normal outputs is not yet supported, all connectors offered
for lease will be advertised as non-desktop.
Co-authored-by: Xaver Hugl <xaver.hugl@gmail.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Some clients (typically Java, but maybe others) rely on ConfigureNotify
or RRScreenChangeNotify events to tell that the XRandR request is
successful.
When emulated XRandR is used in Xwayland, compute the emulated root size
and send the expected ConfigureNotify and RRScreenChangeNotify events
with the emulated size of the root window to the asking X11 client.
Note that the root window size does not actually change, as XRandR
emulation is achieved by scaling the client window using viewports in
Wayland, so this event is sort of misleading.
Also, because Xwayland is using viewports, emulating XRandR does not
reconfigure the outputs location, meaning that the actual size of the
root window which encompasses all the outputs together may not change
in a multi-monitor setup. To work around this limitation, when using an
emulated mode, we report the size of that emulated mode alone as the
root size for the configure notify event.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This makes sure RandR events are sent to interested clients as needed.
This was happening implicitly in some cases, but not in others, e.g. if
the root window size didn't change.
If this were to call RRTellChanged more often than necessary in some
cases, that should be harmless, as it only sends events if something
has actually changed since last time.
Should fix https://bugzilla.redhat.com/show_bug.cgi?id=1979892 .
v2:
* Call RRTellChanged at the very end of update_screen_size, just in
case.
Reviewed-by: Olivier Fourdan <ofourdan@redhat.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>
Enrico Weigelt, metux IT consult
Michel Dänzer
Olivier Fourdan
Joshua Ashton
Minh Phan
zhoulei
Drew DeVault
Simon Ser
Roman Gilg