• 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
meson.build 19.1 KB