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>
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>
In between the two phases introduced by the previous change. This makes
sure all pending drawing to the new buffers is flushed before they're
committed to the Wayland server.
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>
It flushes any pending drawing to the kernel, to make sure it'll be
visible to the Wayland server.
Without this, it was possible for the Wayland server to process surface
commits before Xwayland got around to flushing the corresponding
drawing, which could result in stale or even completely random window
contents being visible.
v2:
* Make EGL backend post_damage hook mandatory, don't check for NULL in
xwl_glamor_post_damage. (Olivier Fourdan)
Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/951
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Fixes build failure.
Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/954
Fixes: 89e32d00f6 "xwayland: Move Xwayland windows to its own sources"
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Olivier Fourdan <ofourdan@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 GLX declaration to its own header file.
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 the Xwayland CVT 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>
Currently, `xwayland.h` contains all the declarations, which is a bit
awkward and hard to follow.
Move the Xwayland structures declarations to their own header file.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Similar to what is done in Xorg. Not doing this prevented apps from
using GLX with a Composite visual, e.g. Firefox WebRender or Chromium.
v2:
* Fix inverted direct_color test, fixes Chromium as well.
* Drop Composite extension guards, since other Xwayland code calls
compRedirectWindow/compUnredirectWindow unconditionally anyway.
Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/921
Fixes: 8469241592 "xwayland: Add EGL-backed GLX provider"
Reviewed-by: Adam Jackson <ajax@redhat.com> # v1
Instead of only the fallback timer.
Fixes https://gitlab.freedesktop.org/xorg/xserver/issues/854
v2:
* Drop unused frame_callback member of struct xwl_present_window
(Olivier Fourdan)
Reviewed-by: Olivier Fourdan <ofourdan@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>
The Present code sends the idle notification event to the client after
xwl_present_flush returns. If we don't flush our GPU work here, the
client may race to draw another frame to the same buffer, so we may end
up copying (parts of) that new frame instead of the one we meant to.
Fixes https://gitlab.freedesktop.org/xorg/xserver/issues/835
Reviewed-by: Olivier Fourdan <ofourdan@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>
Add a mechanism to create, recycle and destroy window buffers when
needed.
Typically, this adds a new `xwl_window_buffer` structure which
represents a buffer for a given Xwayland window.
Each Xwayland window has two different pools of buffers:
- The available buffers pool:
Those are buffers which where created previously and that have either
not been submitted to the compositor or submitted and released.
- The unavailable buffers pool:
Those are typically the buffers which are being used by the
compositor, awaiting a release.
Initially, an Xwayland window starts with both pools empty. As soon as a
new buffer is needed, it's either created (if there is none available)
or picked from the pool of available buffers.
Once submitted to the compositor, the buffer is moved to the pool of
unavailable buffers. When the corresponding `wl_buffer` is released by
the compositor, it is moved back to pool of available buffers again to
be reused when needed.
To avoid keeping too many buffers around doing nothing, a garbage
collection of older, unused buffers also takes care of disposing the
buffers being unused for some time.
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
For some reason, indentation for EGL backend hooks was broken.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Currently, Xwayland pixmap SHM code uses `malloc()` to allocate the
xwl_pixmap.
Use `calloc()` instead, as the EGLstream backend does, as it is safer
(initializing the allocated data to 0).
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Currently, glamor GBM backend uses `malloc()` to allocate the
xwl_pixmap.
Use `calloc()` instead, as the EGLstream backend does, as it is safer
(initializing the allocated data to 0).
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
The definition by the manual is `calloc(size_t nmemb, size_t size)`.
Swap the arguments of calloc() calls to match the definition.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
When a pixmap is created with a backing FBO, the FBO should be cleared
to avoid rendering uninitialized memory. This could happen when the
pixmap is rendered without being filled in its entirety.
One example is when a top-level window without a background is
resized. The pixmap would be reallocated to prepare for more pixels,
but uninitialized memory would be rendered in the resize offset until
the client sends a frame that fills these additional pixels.
Another example is when a new top-level window is created without a
background. Uninitialized memory would be rendered after the pixmap is
allocated and before the client sends its first frame.
This issue is only apparent in OpenGL implementations that don't zero
the VRAM of allocated buffers by default, such as RadeonSI.
Signed-off-by: Dor Askayo <dor.askayo@gmail.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/636
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
`glGetString(GL_VERSION)` will return NULL without a current context.
Commit dabc7d8b (“xwayland: Fall back to GLES2 if we don't get at least
GL 2.1 in glamor”) would check the context is created, but it is made
current just after, so the call to `epoxy_gl_version()` would return 0,
hence defeating the version check.
Make the context current prior to call `epoxy_gl_version()`.
Fixes: dabc7d8b - xwayland: Fall back to GLES2 if we don't get at least
GL 2.1 in glamor
Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/932https://gitlab.freedesktop.org/xorg/xserver/merge_requests/324
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Some particularly unfortunate hardware (Intel gen3, mostly) will give
you GLES2 but not GL 2.1. Fall back to GLES2 for such cases so you still
get accelerated GLX.
Define EGL_NO_X11 everywhere were we also define MESA_EGL_NO_X11_HEADERS,
EGL_NO_X11 is the MESA_EGL_NO_X11_HEADERS equivalent for the egl headers
shipped with libglvnd.
This fixes the xserver not building with the libglvnd-1.2.0 headers:
In file included from /usr/include/EGL/eglplatform.h:128,
from /usr/include/epoxy/egl_generated.h:11,
from /usr/include/epoxy/egl.h:46,
from glamor_priv.h:43,
from glamor_composite_glyphs.c:25:
/usr/include/X11/Xlib.h:222:2: error: conflicting types for 'GC'
222 | *GC;
| ^~
In file included from glamor.h:34,
from glamor_priv.h:32,
from glamor_composite_glyphs.c:25:
../include/gcstruct.h:282:3: note: previous declaration of 'GC' was here
282 | } GC;
| ^~
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
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 fake mode changes using viewport, for apps which want to
change the resolution when going fullscreen.
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
crtc->mode reflects the mode set through the xrandr extension, once we
add support for also changing the mode through the vidmode extension this
will no longer correctly reflect the emulated resolution.
Add a new xwlVidModeGetCurrentRRMode helper which determines the mode by
looking at the emulated_mode instead.
Likewise add a xwlVidModeGetRRMode helper and use that in
xwlVidModeCheckModeForMonitor/xwlVidModeCheckModeForDriver to allow any
mode listed in the randr_output's mode list.
This is a preparation patch for adding emulated mode/resolution change
support to Xwayland's XF86 vidmode extension 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>
Roman Gilg
Hans de Goede
Olivier Fourdan
Michel Dänzer
David Seifert
Dor Askayo
Adam Jackson
Robert Mader