Commit Graph

9 Commits

Author SHA1 Message Date
Jonas Ådahl
2731f0cda4 wayland: Setup and use ownership chains
As elsewhere, make sure objects that need to have a ownership up to the
context, and use this ownership chain to find relevant components, such
as the backend or the Wayland compositor object instance.

wayland/data-device: Hook up data devices to seats

They are tied to a seat - make that connection in struct fields too, so
that related objects can get to the context via it.

wayland: Don't get Wayland compositor via singleton getter

This means via the ownership chain or equivalent.

xwayland: Hook up manager to Wayland compositor

Same applies to the drag-n-drop struct.

xwayland: Make X11 event handling compositor instance aware

This avoids finding it via singletons in the callee.

xwayland: Don't get Wayland compositor from singleton

xwayland: Pass manager when handling dnd event

window/xwayland: Don't get Wayland compositor from singleton

xwayland/grab-keyboard: Don't get backend from singleton

xwayland: Don't get backend from singleton

wayland: Always get the backend from the context

This means traveling up the ownership chain or equivalent when
necessary.

wayland: Hook up data devices, offers and sources to the compositor

This allows tying them to a context without going through any
singletons.

wayland: Don't get display from singleton

xwayland: Don't get display from singleton

tablet: Don't get display from singleton

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2718>
2022-12-17 15:13:48 +01:00
Jonas Ådahl
75ec27966d wayland/buffer: Only query Wayland EGL buffer if display bound
It's not allowed to call eglQueryWaylandBuffer() if the call to
eglBindWaylandDisplay() failed, and will result in an assert being hit
in mesa if called.

Avoid that by keeping track whether we succeeded to bind, and only
attempt to realize a legacy EGL wl_buffer if binding succeeded.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2415>
2022-05-17 10:09:27 +00:00
Jonas Ådahl
76ee026caa wayland/egl-stream: Cache texture snippet
While it's not very relevant now, as we would rarely create it anyway
since the buffer nor texture never changes for a surface, it will be in
the future, as the actor state (including its content,
MetaShapedTexture) will be synchronized by the MetaWaylandActorSurface
at a later point in time, and not by MetaWaylandSurface, at state
application time.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/961
2020-01-10 16:01:21 +00:00
Niels De Graef
5e7fa20f06 wayland-egl-stream: Add log message on sucessful dlopen
Right now, there is no feedback message that tells you whether the
nvidia-egl-wayland module was succesfully loaded.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/853
2019-10-14 10:53:38 +02:00
Jonas Ådahl
417c00b8fa wayland/eglstream: Don't build skeleton when disabled
Instead of calling no-op functions when EGLStream support isn't enabled,
make it clear at the call site that EGLStream support is optional.
2018-11-06 17:17:36 +01:00
Jonas Ådahl
2f4a68c8c3 Clean up include macros mess
The order and way include macros were structured was chaotic, with no
real common thread between files. Try to tidy up the mess with some
common scheme, to make things look less messy.
2018-11-06 17:17:36 +01:00
Miguel A. Vico
435b3c4bdb wayland: Create EGLStream-backed buffers through wl_eglstream_controller
One of the current limitations of EGLStreams is that there's no way to
resize a surface consumer without re-creating the entire stream.

Therefore, while resizing, clients will send wl_surface::attach requests
so the compositor can re-create its endpoint of the stream, but no
buffer will be available actually. If we proceed with the rest of the
attach operation we'll be presenting an empty buffer.

In order to fix this, a separate wl_eglstream_controller protocol has
been introduced that clients can use to request a stream re-creation
without overloading wl_surface::attach for that purpose.

This change adds the required logic to create the corresponding
wl_eglstream_controller global interface that clients can bind to.

Whenever a client requests a stream to be created, we just need to
create and realize the new EGLStream buffer. The same buffer resource
will be given at a later time to wl_surface::attach, whenever new
content is made available by the application, so we can proceed to
acquire the stream buffer and update the surface state.

https://bugzilla.gnome.org/show_bug.cgi?id=782575
2018-06-15 13:45:29 -07:00
Jonas Ådahl
2df35d636e MetaWaylandEglStream: Use EGL_WL_wayland_eglstream instead of fd hack
Use the proposed EGL_WL_wayland_eglstream EGL extension instead of the
file descriptor hack that was used as a temporary solution.

Note that this results in EGL clients will no longer work if they are
running on a Nvidia driver with a version older than 370.

https://bugzilla.gnome.org/show_bug.cgi?id=773629
2017-01-03 17:50:03 +08:00
Jonas Ådahl
eed4dab0fc wayland: Add support for EGLStream client buffers
This commit adds for a new type of buffer being attached to a Wayland
surface: buffers from an EGLStream. These buffers behave very
differently from regular Wayland buffers; instead of each buffer
reperesenting an actual frame, the same buffer is attached over and
over again, and EGL API is used to switch the content of the OpenGL
texture associated with the buffer attached. It more or less
side-tracks the Wayland buffer handling.

It is implemented by creating a MetaWaylandEglStream object, dealing
with the EGLStream state. The lifetime of the MetaWaylandEglStream is
tied to the texture object (CoglTexture), which is referenced-counted
and owned by both the actors and the MetaWaylandBuffer.

When the buffer is reattached and committed, the EGLStream is triggered
to switch the content of the associated texture to the new content.
This means that one cannot keep old texture content around without
copying, so any feature relying on that will effectively be broken.

https://bugzilla.gnome.org/show_bug.cgi?id=773629
2016-11-18 00:00:10 +08:00