Skip to content

GitLab

xserver
xserver
Switch branch/tag
  1. 28 Feb, 2020 1 commit
    • mntmn's avatar
      xwayland: port rooted xwayland from wl_shell to xdg-shell protocol · 3d6efc4a
      mntmn authored 
      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: default avatarLukas F. Hartmann <lukas@mntre.com>
      3d6efc4a
  3. 20 Dec, 2019 13 commits
  5. 28 Nov, 2019 1 commit
    • Olivier Fourdan's avatar
      xwayland: Add multiple window buffering support · 1c6f875f
      Olivier Fourdan authored 
      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: default avatarOlivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer's avatarMichel Dänzer <mdaenzer@redhat.com>
      1c6f875f
  7. 12 Oct, 2019 1 commit
  9. 15 Aug, 2019 1 commit
  11. 23 May, 2019 1 commit
  13. 24 Apr, 2018 2 commits
    • Lyude Paul's avatar
      xwayland: Add glamor egl_backend for EGLStreams · 54ac0971
      Lyude Paul authored 
      This adds initial support for displaying Xwayland applications through
the use of EGLStreams and nvidia's custom wayland protocol by adding
another egl_backend driver. This also adds some additional egl_backend
hooks that are required to make things work properly.

EGLStreams work a lot differently then the traditional way of handling
buffers with wayland. Unfortunately, there are also a LOT of various
pitfalls baked into it's design that need to be explained.

This has a very large and unfortunate implication: direct rendering is,
for the time being at least, impossible to do through EGLStreams. The
main reason being that the EGLStream spec mandates that we lose the
entire color buffer contents with each eglSwapBuffers(), which goes
against X's requirement of not losing data with pixmaps.  no way to use
an allocated EGLSurface as the storage for glamor rendering like we do
with GBM, we have to rely on blitting each pixmap to it's respective
EGLSurface producer each frame. In order to pull this off, we add two
different additional egl_backend hooks that GBM opts out of
implementing:

- egl_backend.allow_commits for holding off displaying any EGLStream
  backed pixmaps until the point where it's stream is completely
  initialized and ready for use
- egl_backend.post_damage for blitting the content of the EGLStream
  surface producer before Xwayland actually damages and commits the
  wl_surface to the screen.

The other big pitfall here is that using nvidia's wayland-eglstreams
helper library is also not possible for the most part. All of it's API
for creating and destroying streams rely on being able to perform a
roundtrip in order to bring each stream to completion since the wayland
compositor must perform it's job of connecting a consumer to each
EGLstream. Because Xwayland has to potentially handle both responding to
the wayland compositor and it's own X clients, the situation of the
wayland compositor being one of our X clients must be considered. If we
perform a roundtrip with the Wayland compositor, it's possible that the
wayland compositor might currently be connected to us as an X client and
thus hang while both Xwayland and the wayland compositor await responses
from eachother. To avoid this, we work directly with the wayland
protocol and use wl_display_sync() events along with release() events to
set up and destroy EGLStreams asynchronously alongside handling X
clients.

Additionally, since setting up EGLStreams is not an atomic operation we
have to take into consideration the fact that an EGLStream can
potentially be created in response to a window resize, then immediately
deleted due to another pending window resize in the same X client's
pending reqests before Xwayland hits the part of it's event loop where
we read from the wayland compositor. To make this even more painful, we
also have to take into consideration that since EGLStreams are not
atomic that it's possible we could delete wayland resources for an
EGLStream before the compositor even finishes using them and thus run
into errors. So, we use quite a bit of tracking logic to keep EGLStream
objects alive until we know the compositor isn't using them (even if
this means the stream outlives the pixmap it backed).

While the default backend for glamor remains GBM, this patch exists for
users who have had to deal with the reprecussion of their GPU
manufacturers ignoring the advice of upstream and the standardization of
GBM across most major GPU manufacturers. It is not intended to be a
final solution to the GBM debate, but merely a baindaid so our users
don't have to suffer from the consequences of companies avoiding working
upstream. New drivers are strongly encouraged not to use this as a
backend, and use GBM like everyone else. We even spit this out as an
error from Xwayland when using the eglstream backend.
Signed-off-by: Lyude Paul's avatarLyude Paul <lyude@redhat.com>
Acked-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      54ac0971
    • Lyude Paul's avatar
      xwayland: Decouple GBM from glamor · 1545e2db
      Lyude Paul authored 
      This takes all of the gbm related code in wayland-glamor.c and moves it
into it's own EGL backend for Xwayland, xwayland-glamor-gbm.c.
Additionally, we add the egl_backend struct into xwl_screen in order to
provide hooks for alternative EGL backends such as nvidia's EGLStreams.
Signed-off-by: Lyude Paul's avatarLyude Paul <lyude@redhat.com>
Reviewed-by: Lyude Paul's avatarLyude Paul <lyude@redhat.com>
Reviewed-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      1545e2db
  15. 16 Apr, 2018 1 commit
  17. 05 Apr, 2018 1 commit
  19. 28 Mar, 2018 1 commit
    • Roman Gilg's avatar
      xwayland: Preliminary support for Present's new window flip mode · 0fb2cca1
      Roman Gilg authored 
      Introduce support for Present's window flip mode. The support is not yet
complete, but works reasonable well for the most important use case, that
is fullscreen applications.

We take a Present flip and if the xwl_window->window has the same dimensions
as the presenting window, the flip is represented by a wl_buffer and attached
to the main wl_surface of the xwl_window.

After commit we are listening for the sync callback in order to tell Present,
that the pixmap flip is not longer pending, for the frame callback in order
to update the msc counter and for the buffer release callback in order to tell
Present that the pixmap is idle again.

The following functionality is missing from this patch:
* (slowed down) flips in case the compositor is not sending frame callbacks,
* queuing events to MSC times,
* per window flips for child windows with smaller size than the xwl_window.

To make use of this functionality Xwayland must run rootless and with
Glamor/GBM.
Signed-off-by: Roman Gilg's avatarRoman Gilg <subdiff@gmail.com>
Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      0fb2cca1
  21. 05 Mar, 2018 1 commit
  23. 14 Feb, 2018 1 commit
    • Adam Jackson's avatar
      glx: Use vnd layer for dispatch (v4) · d8ec33fe
      Adam Jackson authored 
      The big change here is MakeCurrent and context tag tracking. We now
delegate context tags entirely to the vnd layer, and simply store a
pointer to the context state as the tag data. If a context is deleted
while it's current, we allocate a fake ID for the context and move the
context state there, so the tag data still points to a real context. As
a result we can stop trying so hard to detach the client from contexts
at disconnect time and just let resource destruction handle it.

Since vnd handles all the MakeCurrent protocol now, our request handlers
for it can just be return BadImplementation. We also remove a bunch of
LEGAL_NEW_RESOURCE, because now by the time we're called vnd has already
allocated its tracking resource on that XID.

v2: Update to match v2 of the vnd import, and remove more redundant work
like request length checks.

v3: Add/remove the XID map from the vendor private thunk, not the
backend. (Kyle Brenneman)

v4: Fix deletion of ghost contexts (Kyle Brenneman)
Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      d8ec33fe
  25. 24 Jan, 2018 1 commit
    • Olivier Fourdan's avatar
      xwayland: Add optional xdg-output support · da8de2a7
      Olivier Fourdan authored 
      The xdg-output protocol aims at describing outputs in way which is
more in line with the concept of an output on desktop oriented systems.

For now it just features the position and logical size which describe
the output position and size in the global compositor space.

This is however much useful for Xwayland to advertise the output size
and position to X11 clients which need this to configure their surfaces
in the global compositor space as the compositor may apply a different
scale from what is advertised by the output scaling property (to achieve
fractional scaling, for example).

This was added in wayland-protocols 1.10.
Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
Signed-off-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      da8de2a7
  27. 02 Aug, 2017 1 commit
  29. 28 Apr, 2017 1 commit
  31. 26 Apr, 2017 1 commit
    • Eric Anholt's avatar
      Add a Meson build system alongside autotools. · 1549e303
      Eric Anholt authored 
      This is a work in progress that builds Xvfb, Xephyr, Xwayland, Xnest,
and Xdmx so far.  The outline of Xquartz/Xwin support is in tree, but
hasn't been built yet.  The unit tests are also not done.

The intent is to build this as a complete replacement for the
autotools system, then eventually replace autotools.  meson is faster
to generate the build, faster to run the bulid, shorter to write the
build files in, and less error-prone than autotools.

v2: Fix indentation nits, move version declaration to project(), use
    existing meson_options for version-config.h's vendor name/web.
Signed-off-by: Eric Anholt's avatarEric Anholt <eric@anholt.net>
Acked-by: Keith Packard's avatarKeith Packard <keithp@keithp.com>
Reviewed-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      1549e303