Commit Graph

9 Commits

Author SHA1 Message Date
Ryan Gonzalez
aa849658c5 xwayland: Allow controlling global output scale via properties
This adds a new property, _XWAYLAND_GLOBAL_OUTPUT_SCALE, to control the
global output scale from the compositor.
2021-08-23 13:21:28 -05:00
Dario Nieuwenhuis
fbc7cefc43 xwayland: Multi DPI support via global factor rescaling
To benefit from Wayland's multi DPI capabilities in XWayland a global scaling
factor is introduced, which is applied to all outputs.

The RandR size of an output is calculated by the (integer-)multiplication of
this global scaling factor with its logical size received via the xdg-output
protocol.

In other words the size of any RandR screen corresponds to the mode size of
its wl_output multiplied with the quotient of global scaling factor divided by
the compositor's internal output-dependent scaling factor.

HiDPI aware X clients can then provide Pixmaps enlarged by the global scaling
factor and the Wayland compositor is supposed to downscale these buffers on
outputs scaled by less than the global scaling factor.

A Wayland compositor needs to scale all X communication in its XWM part by the
global scaling factor, such that X windows have the correct geometry.

In summary:
* All positions in Wayland internal communication must be carried out by the
compositor in logical coordinates, i.e. in its compositor space.
* All positions in X internal communication are based on RandR sizes.
* All positions in Wayland to X communication must be multiplied by the global
scaling factor.
* All positions in X to Wayland communication must be divided by the global
scaling factor.

In order to not break compositors that do not support these transformations,
the global scaling factor is set to 1 by default, which behaves the same as
before.

[dirbaio@dirbaio.net: fix incorrect scaling in a few places]
[rymg19@gmail.com: minor style fixes]
Signed-off-by: Roman Gilg <subdiff@gmail.com>
Signed-off-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
2021-08-23 13:21:28 -05:00
Olivier Fourdan
24fc8aea1e xwayland: Add preferred GLVND vendor to xwl_screen
If Xwayland's EGLstream backend supports hardware acceleration with the
NVIDIA closed-source driver, the GLX library also needs to be one
shipped by NVIDIA, that's what GLVND is for.

Add a new member to the xwl_screen that the backend can optionally set
to the preferred GLVND vendor to use.

If not set, "mesa" is assumed.

Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
2021-05-31 08:24:00 +00:00
Olivier Fourdan
ae225417c0 xwayland: Move dmabuf interface to common glamor code
This is preliminary work for hardware accelerated rendering with the
NVIDIA driver.

The EGLStream backend can possibly also use the dmabuf interface, so
move the relevant code from the GBM specific source to the common bits.

Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
2021-04-09 14:00:01 +00:00
Olivier Fourdan
785e59060c xwayland: Fix infinite loop at startup
Mutter recently added headless tests, and when running those tests the
Wayland compositor runs for a very short time.

Xwayland is spawned by the Wayland compositor and upon startup will
query the various Wayland protocol supported by the compositor.

To do so, it will do a roundtrip to the Wayland server waiting for
events it expects.

If the Wayland compositor terminates before Xwayland has got the replies
it expects, it will loop indefinitely calling `wl_display_roundtrip()`
continuously.

To avoid that issue, add a new `xwl_screen_roundtrip()` that checks for
the returned value from `wl_display_roundtrip()` and fails if it is
negative.

Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Roman Gilg <subdiff@gmail.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
2020-04-27 11:42:13 +02:00
mntmn
3d6efc4aaf xwayland: port rooted xwayland from wl_shell to xdg-shell protocol
Recently, rooted Xwayland crashes on wlroots-based compositors, because
wlroots removed the deprecated wl_shell protocol.
This MR fixes this by changing the code in question to the xdg-shell
protocol. My motivation do this: on etnaviv-based embedded platforms,
rooted Xwayland is much faster and doesn't cause UI rendering bugs
compared to rootless Xwayland.

Signed-off-by: Lukas F. Hartmann <lukas@mntre.com>
2020-02-28 16:23:58 +00:00
Hans de Goede
10df0437a2 xwayland: Also hook screen's MoveWindow method
Not only hook the ResizeWindow method of the screen (which really is
MoveAndResize) but also hook the MoveWindow method for checking if we
need to setup a viewport for resolution change emulation.

Our resolution change emulation check if the windows origin matches
the monitors origin and the windows origin can also be changed by just
a move without being resized.

Also checking on a move becomes esp. important when we move to checking
on changes to the top-level non-window-manager client (X11)Window instead
of on changes to the xwl_window later on in this patch series.

Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2020-02-23 18:05:05 +01:00
Hans de Goede
ded89300c1 xwayland: Cache client-id for the window-manager client
Instead of iterating over all clients which are listening for events on the
root window and checking if the client we are dealing with is the one
listening for SubstructureRedirectMask | ResizeRedirectMask events and thus
is the window-manager, cache the client-id of the window-manager in
xwl_screen and use that when checking if a client is the window-manager.

Note that we cache and compare the client-id rather then the ClienPtr,
this saves reading the ClientPtr from the global clients array when doing
the comparison.

Suggested-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2020-02-23 18:04:00 +01:00
Olivier Fourdan
0617c635fa xwayland: Separate Xwayland screen code
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>
2019-12-20 16:19:01 +01:00