When the PipeWire context or stream ends up in an error state, signal
that the source has closed. This then triggers the stream and finally
the session to be closed too.
https://bugzilla.gnome.org/show_bug.cgi?id=784199
This commit adds basic screen casting and remote desktoping
functionalty. This works by exposing two D-Bus API services:
org.gnome.Mutter.ScreenCast and org.gnome.Mutter.RemoteDesktop.
The remote desktop API is used to create remote desktop sessions. For
each session, a D-Bus object is created, and an application can manage
the session by sending messages to the session object. A remote desktop
session the user to emit input events using the D-Bus methods on the
session object. To get framebuffer content, the application should
create an associated screen cast session.
The screen cast API is used to create screen cast sessions. One can so
far either create stand-alone screen cast sessions, or a screen cast
session associated with a remote desktop session. A remote desktop
associated screen cast session is managed by the remote desktop session.
So far only remote desktop managed screen cast sessions are implemented.
Each screen cast session may have one or more streams. A screen cast
stream is a stream of buffers of some part of the compositor content.
So far API exists for creating streams of monitors and windows, but
only monitor streams are implemented.
When a screen cast session is started, the one PipeWire stream is
created for each screen cast stream created for the session. When this
has happened, a PipeWireStreamAdded signal is emitted on the stream
object, passing a unique identifier. The application may use this
identifier to find the associated stream being advertised by the
PipeWire daemon.
The remote desktop and screen cast functionality must be explicitly be
enabled at ./configure time by passing --enable-remote-desktop to
./configure. Doing this will build both screen cast and remote desktop
support.
To actually enable the screen casting and remote desktop, the user must
enable the experimental feature. See
org.gnome.mutter.experimental-features.
https://bugzilla.gnome.org/show_bug.cgi?id=784199
Add MetaFraction, which consists of two integers, the numerator an the
denominator. The utility function to convert a double to a MetaFraction
comes from gstreamer.
https://bugzilla.gnome.org/show_bug.cgi?id=784199
When monitors changed, previous monitor instances are defunct, and any
reference holder should drop its reference. Sometimes they will want to
continue having a reference to the same monitor, so add this function
to make it possible to find it.
Currently the output and crtc references are invalid, as they are not
yet reference counted, so this can only look at cached fields.
https://bugzilla.gnome.org/show_bug.cgi?id=784199
Apparently my understanding of Cogl pixel formats, or at least their
use, was somewhat shaky.
Un-invert the inversion of the DRM FourCC -> Cogl pixel format mapping
when creating dmabufs from clients, fixing inverted channel ordering
seen from GL clients, e.g. gold highlights in gtk4-demo when using the
GSK GL backend when they should be blue.
https://bugzilla.gnome.org/show_bug.cgi?id=786677
Trying to unilaterally require eglGetPlatformDisplayEXT causes problems in
scenarios where this method is not available. Besides, this should only be
required on Wayland, so we can stop requiring it always and simply let the
eglGetPlatformDisplay() function error accordingly when needed.
https://bugzilla.gnome.org/show_bug.cgi?id=786619
The HW cursor plane can't do any transformations, and as we still don't
pre-transform any buffer before uploading to the cursor plane, we must
disable the HW cursor when a logical monitor is transformed.
This worked previously because the transform of a MetaCrtc did not
correspond to the transform of a CRTC, but the transform of the logical
monitor the CRTC was assigned to.
https://bugzilla.gnome.org/show_bug.cgi?id=786023
When another D-Bus call that just tries to verify a configuration is
made, don't cancel any active monitor configuration dialog, as doing so
would effectively confirm queried configuration.
https://bugzilla.gnome.org/show_bug.cgi?id=786023
When resolving what keycodes a key binding resolves to, only look up
key codes from the current layout group. Without this, unwanted
overlaps may occur. For example when a keymap has both a dvorak and a
qwerty layout on different layout groups, one keybinding may be bound
on multiple keys, arbitrarily "shadowing" another.
https://bugzilla.gnome.org/show_bug.cgi?id=786408
Add API to get the layout group (layout index) currently active. In the
native backend this is done by fetching the state directly from the
evdev backend; on X11 this works by listening for XkbStateNotify
events, caching the layout group value.
https://bugzilla.gnome.org/show_bug.cgi?id=786408
Don't wait for clutter to initialize for connecting to X11; do it when
constructing the backend instance. This way we can later depend on
having an X11 connection earlier during initialization.
https://bugzilla.gnome.org/show_bug.cgi?id=786408
When opening a laptop lid, one will likely want to restore the
configuration one had prior to closing it, so when ensuring monitor
configuration, first try to see if the previously set configuration is
both complete (all connected monitors are configured) and applicable
(it is a valid configuration) and only try to generate a new from
scratch if that failed.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
In order to go back in monitor configurations, save them to a history.
The history is implemented as a max 3 element long queue, where newly
set configurations are pushed to the head, and old are popped from the
tail.
The difference between using a single previous config reference and a
queue is that we can now remember the configuration used prior to a
D-Bus triggered configuration when the user discarded the configuration.
This will later be used to restore a previous configuration when a
laptop lid is opened.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
So far some basic testing, including:
* Test that the migrated configuration is applicable
* Test that a monitors.xml with multiple configurations are translated
* Test rotation
* Test tiled monitor discovery (well, test a made up tiled monitor
configuration since I don't have a real one)
https://bugzilla.gnome.org/show_bug.cgi?id=777732
This commit changes the new configuration system to use monitors.xml
instead of monitors-experimental.xml. When starting up and the
monitors.xml file is loaded, if a legacy monitors.xml file is
discovered (it has the version number 1), an attempt is made to migrate
the stored configuration onto the new system.
This is done in two steps:
1) Parsing and translation of the old configuration. This works by
parsing file using the mostly the old parser, but then translating the
resulting configuration structs into the new configuration system. As
the legacy configuration system doesn't carry over some state (such as
tiling and scale used), some things are not available. For tiling, the
migration paths makes an attempt to discover tiled monitors by
comparing EDID data, and guessing what the main tile is. Determination
of the scale of a migrated configuration is postponed until the
configuration is actually applied. This works by flagging the
configuration as 'migrated'.
2) Finishing the migration when applying. When a configuration with the
'migrated' flag is retrieved from the configuration store, the final
step of the migration is taken place. This involves calculating the
preferred scale given the mode configured, while making sure this
doesn't result in any overlapping logical monitor regions etc.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
The zero-initialized winsys id was incorrectly used as the key to find
the old output to base active/primary state from, which would never
succeed unless the winsys id happened to be 0. Fix this by using the
winsys id that will be used, i.e. the connector id.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
The 'normal' transform has the value 0, so the g_warn_if_fail()
expression failed. Correct it so that it doesn't complain when no
transform is checked.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
The problem is that libinput offers the possibility to not enabled
dragging when tap-to-click is enabled but mutter doesn't. For people who
have a sensitive touchpad and who like tap-to-click option, dragging is
launched even when you don't want it : for example, when you select a
folder, most of the time the folder is dragging whereas just selected or
when you want to select some lines of a text file, several lines are
moved as a cut-paste which is not expected and erase datas.
To fix it, you need to have the possibility to desactivate the drag
option when you use tap-to-click in mutter. Because it's already a
specification of libinput, it remains to add it to mutter.
Implementation with X11 is added too.
https://bugzilla.gnome.org/show_bug.cgi?id=775755
The meta_wayland_surface_hide_inhibit_shortcuts_dialog() function
disconnected the "destroy" handler, but we'd still be listening on
response events. Change this to just hide the dialog, leaving the data
intact with the proper life time signal in place.
https://bugzilla.gnome.org/show_bug.cgi?id=786385
The 'data' object is attached to the MetaWaylandSurface as a GObject
qdata. It is created once, and stays allocated until the surface is
destroyed. To make things clearer, connect to the "destroy" signal just
after creating, and from a on_surface_destroyed() callback call the
.._free() function.
https://bugzilla.gnome.org/show_bug.cgi?id=786385
When suspending (i.e. VT switching away, the GDM gnome-shell instance
gets hidden, or changing user), destroy the onscreen and offscreen
monitor framebuffers. When resuming, the stage views and framebuffers
will be recreated anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=786299
Plug the new MetaInhbitShortcutsDialog to the relevant Wayland protocol
implementation.
Also, remember the last user choice for a given surface to avoid asking
continuously the same question.
https://bugzilla.gnome.org/show_bug.cgi?id=783342
Add a mechanism to MetaWaylandSurface that inhibits compositor's own
shortcuts when the surface has input focus, so that clients can receive
all key events regardless of the compositor own shortcuts.
This will help with implementing "fake" active grabs in Wayland and
XWayland clients.
https://bugzilla.gnome.org/show_bug.cgi?id=783342
The cursor surface would be remembered until the next proximity in
event, causing flashing of the old cursor till the client underneath
the tablet tool sent the zwp_tablet_tool.set_cursor request.
Forgetting about the cursor surface on proximity out makes the cursor
invisible till the request is made.
More specifically, avoid crossing events, since clutter does not set
modifier/button state on those. Fixes implicit grabs being broken when
the pointer moves past the surface boundaries.
https://bugzilla.gnome.org/show_bug.cgi?id=785347
Since a wl_buffer is independent of the GL context in use (unlike, e.g.,
a GL renderbuffer), EGLImages with the EGL_WAYLAND_BUFFER_WL target must
pass EGL_NO_CONTEXT as the context. Quoting from the
EGL_WL_bind_wayland_display spec:
After querying the wl_buffer layout, create EGLImages for the
planes by calling eglCreateImageKHR with wl_buffer as
EGLClientBuffer, EGL_WAYLAND_BUFFER_WL as the target, NULL
context.
The check was already present inside _cogl_egl_create_image.
https://bugzilla.gnome.org/show_bug.cgi?id=785263
Signed-off-by: Daniel Stone <daniels@collabora.com>
