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>
If the glamor backend failed to post damage, the caller should do the
same to avoid a failure to attach the buffer to the Wayland surface.
Change the API of Xwayland's glamor backend post_damage() to return a
status so that xwl_window_post_damage() can tell whether the callee
failed.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
https://gitlab.freedesktop.org/xorg/xserver/-/issues/1156
If the buffer is NULL, do not even try to attach it, and risk a Wayland
protocol error which would be fatal to us.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Martin Peres <martin.peres@mupuf.org>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
https://gitlab.freedesktop.org/xorg/xserver/-/issues/1156
There are currently no callers that make use of the "created" output parameter
of xwl_glamor_pixmap_get_wl_buffer. Remove it, along with the corresponding
argument of the associated EGL backend entrypoint.
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>
One general assumption in Xwayland is that the xwl_window remains the
same for all the child windows of the toplevel window.
When mapping a new X11 window, ensure_surface_for_window() checks for an
existing xwl_window by using xwl_window_get() which will just check for
the registered xwl_window for the window.
That means that a client mapping a child window of an existing window
with a xwl_window will get another different xwl_window.
If an X11 client issues a Present request on the parent window, hence
placed underneath its child window of the same size, the Wayland
compositor may not send the frame callback event for the parent's
Wayland surface which is reckoned to be not visible, obscured behind
the other Wayland surface for the child X11 window.
That bug affects some games running in wine which may get 1 fps because
the repaint occurs only on timeout with a long interval (as with, e.g.
https://bugs.winehq.org/show_bug.cgi?id=47066)
Fix ensure_surface_for_window() by using xwl_window_from_window() which
will walk the window tree, so that a child window won't get another
xwl_window than its parent.
https://gitlab.freedesktop.org/xorg/xserver/-/issues/1099
See-also: https://bugs.winehq.org/show_bug.cgi?id=47066
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
We were only calling xwl_present_unrealize_window for the toplevel
window, but the list can contain entries from child windows as well,
in which case we were leaving dangling pointers to freed memory.
Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/1000
Fixes: c5067feaee "xwayland: Use single frame callback for Present
flips and normal updates"
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Tested-by: Olivier Fourdan <ofourdan@redhat.com>
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>
For window-manager managed windows, xwl_realize_window is only called for
the window-manager's decoration window and not for the actual client window
on which we should set the _XWAYLAND_RANDR_EMU_MONITOR_RECTS prop.
Usualy this is not a problem since we walk all client windows to update
the property when the resolution is changed through a randr call.
But for apps which first do the randr change and only then create their
window this does not work, and our xwl_output_set_window_randr_emu_props
call in xwl_realize_window is a no-op as that is only called for the wm
decoration window and not for the actual client's window.
This commit fixes this by making ensure_surface_for_window() call
xwl_output_set_window_randr_emu_props on the first and only child of
window-manager managed windows.
Note this also removes the non-functional xwl_output_set_window_randr_emu_props
call from xwl_realize_window, which was intended to do this, but does not
work.
This fixes apps using the ogre3d library always running at the
monitors native resolution.
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Some clients, which use vidmode to change the resolution when going fullscreen,
create an override-redirect window and never trigger the screen->ResizeWindow
callback we rely on to do the xwl_window_check_resolution_change_emulation().
This causes us to not apply a viewport to them, causing the fullscreen window
to not fill the entire monitor.
This commit adds a call to xwl_window_check_resolution_change_emulation()
at the end of ensure_surface_for_window() to fix this. Note that
ensure_surface_for_window() exits early without creating an xwl_window
for new windows which will not be backed by a wayland surface and which
thus will not have an xwl_window.
This fixes ClanLib-0.6.x and alleggl-4.4.x using apps not properly
fullscreening.
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
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>
The recent change to use the top-level non-window-manager Window drawable
coordinates from xwl_window_check_resolution_change_emulation() in
combination with only calling it on a resize when the top-level window
is moved breaks things with mutter/gnome-shell.
When fullscreening a X11 window, mutter moves its window-decoration Window
wrapping the top-level Window to the monitor's origin coordinates (e.g. 0x0)
last. This updates the top-level's drawable coordinates, but as the
actual MoveWindow is called on the wrapper Window and not on the toplevel
we do not call xwl_window_check_resolution_change_emulation() and we never
enable the viewport.
This commit fixes this by also calling
xwl_window_check_resolution_change_emulation() if the Window being moved
is an xwl_window itself.
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
When a reparented window is resized directly check the emulation instead of
doing this only when the window manager parent window is resized, what might
never happen.
For that to work we need to make sure that we compare the current size of the
client toplevel when looking for an emulated mode.
Changes by Hans de Goede:
- Remove xwl_window x, y, width and height members as those are no longer used.
- Add check for xwl_window_from_window() returning NULL.
Signed-off-by: Roman Gilg <subdiff@gmail.com>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Make window_get_none_wm_owner return the first non-wm-window instead of the
owner (client) of the first non-wm-window and rename it to
window_get_client_toplevel to match its new behavior.
This is a preparation patch for switching to using the drawable coordinates
in xwl_window_should_enable_viewport()
Changes by Hans de Goede:
- Split this change out into a separate patch for easier reviewing
- Rename window_get_none_wm_owner to window_get_client_toplevel to match
its new behavior
Signed-off-by: Roman Gilg <subdiff@gmail.com>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
An X11 window manager might add a chain of parent windows when reparenting to a
decoration window.
That is for example the case for KWin, which reparents client windows to one
decoration and another wrapper parent window.
Account for that by a recursion into the tree. For now assume as before that
all X11 window managers reparent with one child only for these parent windows.
Changes by Hans de Goede:
- Move the xwl_window_is_toplevel() from a later patch in this series here
as it really belongs together with these changes
- Drop no longer necessary xwl_window argument from window_get_none_wm_owner
parameters
Signed-off-by: Roman Gilg <subdiff@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
When a viewport is already created we can reuse this object instead of
destroying it and getting a new one for updating the source rectangle and
destination size.
Signed-off-by: Roman Gilg <subdiff@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
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>
The first phase sets the new surface properties for all damaged
windows, then the second phase commits all surface updates.
This is preparatory for the next change, there should be no observable
change in behaviour (other than the order of Wayland protocol
requests).
Reviewed-by: Adam Jackson <ajax@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 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 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>
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>
Andrea Cavalli
Christopher Snowhill
Dario Nieuwenhuis
Olivier Fourdan
Erik Kurzinger
Mariusz Ceier
Michel Dänzer
mntmn
Hans de Goede
Roman Gilg