When a screen cast session is stand-alone, i.e. not created given a
remote desktop session managing it, allow calling the Start/Stop
methods to start and stop it.
https://bugzilla.gnome.org/show_bug.cgi?id=784199
As of commit 5f5ef3de2cdc816dab82cb7eb5d7171bee0ad2c5 in pipewire the
stream creator can find out the node ID of the stream it created.
So instead of using a special purpose entry to the info property box to
let the application discover stream by monitoring added nodes searching
for the given special purpose entry, just pass the node directly.
https://bugzilla.gnome.org/show_bug.cgi?id=784199
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
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
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
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
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
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
This will allows us to support the XF86Display key present on some
laptops, directly in mutter. This is also known, in evdev, as
KEY_SWITCHVIDEOMODE.
The common usage for this key is to alternate between a few well known
multi-monitor configurations though these aren't officially
standardized. As an example, Lenovo documents it as:
"Switches the display output location between the computer display
and an external monitor."
On this patch, we're just introducing the configurations that have been
implemented in g-s-d until now, which go a bit beyond the above
description.
https://bugzilla.gnome.org/show_bug.cgi?id=781906
Instead of letting MetaMonitor derive the logical monitor size, then
using the main monitor for the position, just let MetaMonitor derive
the whole layout including the position. This means it can deal with
tiled monitors better, for example when the main output (the output
always active when the monitor is active) is not the origin output (the
output with tile position (0, 0)).
https://bugzilla.gnome.org/show_bug.cgi?id=781723
Just like we do for buttons, with a few twists. These have 2 directions
mappable to different keycombos, and are affected by the current mode
in their group.
https://bugzilla.gnome.org/show_bug.cgi?id=782033
This basically moves g-s-d's orientation plugin into mutter so that
eventually g-s-d doesn't need to build monitor configurations by
itself anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=781906
When verifying if a configuration is applicable, don't set it as
current when applying succeeded, or else reverting to a previous
configuration doesn't work after having verified.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
Differentiate between non-interlaced and interlaced modes. This is done
by appending an "i" after the resolution part of the mode ID, and
adding a 'is-interlaced' (b) property to the mode properties.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
To be more flexible without having to change any D-Bus type signatures
in the future, replace the 'uint' flags value (currently determining
whether a mode is current and/or preferred) with a variant lookup table.
The keys 'is-current' (b) and 'is-preferred' (b) replace the existing
flags.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
To be able to add more modes types that happen to have the same
resolution and refresh rate, change the API to specify modes using an
ID string. The ID string is temporary, and only works for associating a
mode for the monitor instance that it was part of.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
When calculating sizes given some size and a fractional logical monitor
scale with precision loss, round the result of the floating point
calculation to the closest integer, as otherwise we might end up with
result smaller by 1 if there was a loss of precision when calculating
the scale.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
To be able to render the pointer cursor sprite at sub-(logical)-pixel
positions, track the pointer position using floats instead of ints.
This also requires users of the cursor sprite rect to deal with
floating points, when e.g. finding the logical monitor etc.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
When passing scales over D-Bus, we'll loose some precision. To set the
correct scale, use the configured scale and look up the one actually
supported by the monitor mode, and use that. To match the supported one
with the configured one, the difference must be within rounding error
range.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
We manually scaled pointer motions when they travel over a scaled
monitor. When a stage view of a monitor is also scaled, in practice this
meant we scaled twice. Avoid this by only manually scaling the pointer
motion when stage views are not scaled.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
When using logical sized monitors we are allowed to use fractional scaling
but only if the resulting scaled logical monitor size is in integer form.
So, in order to get this, we allow to scale the monitor to up to
8 fractional values per integer, doing some computation in order to
fetch the nearest values which are closer to the scaling factors we can
permit.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
This changes the API to pass supported scales per mode instead of
providing a global list. This allows for more flexible scaling
scenarious, where a scale compatible with one mode can still be made
available even though another mode is incompatible.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
When the logical layout mode is used, allow configuring the scaling to
be non-integer. Supported scales are so far hard coded to include at
most 1, 1.5 and 2, and scales that doesn't result in non-fractional
logical monitor sizes are discarded.
Wayland outputs are set to have scale ceil(actual_scale) meaning well
behaving Wayland clients will provide buffers with buffer scale 2, thus
being scaled down to the fractional scale.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
To support fractional scaling, change the stage view scale to be a
float instead of an int. Also change the places where it is retrieved
and used when scaling things.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
Previously gnome-shell listened on the Xft Xsettings via GTK+s
GtkSettings to get the font DPI setting. The Xsetting might not
be what we want, and we should not rely on Xsettings when we don't need
to, so lets manage it ourself.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
The caller in clutter really expects an error if fd==-1, so make
sure we set one here. Otherwise we get a nice crash in addition to
the failure to open the /sys file. Also, retry on EINTR.
https://bugzilla.gnome.org/show_bug.cgi?id=784881
With GLVND, whenever we have both Mesa's and NVIDIA's drives installed
in the system, initializing the GBM backend will always succeed,
regardless of what GPU you have on your system.
This is due to GBM's software rendering fallback.
It seems better to initialize the EGLDevice backend first, which will
fail to find a device match when given a non-NVIDIA GPU.
https://bugzilla.gnome.org/show_bug.cgi?id=784272
Wacom's display tablets typically do not have (0,0) coincident with the top
left corner of the screen. This "outbound" area must be taken into account
when setting the area or else an unexpected offset of the pointer will
occur.
https://bugzilla.gnome.org/show_bug.cgi?id=784009
It is possible to interpret the ammount of padding provided to the
*_set_tablet_area functions in two different and incompatible ways. The X11
backend effectively treats them as being input-centric (i.e., the padding
defines the size of the "dead zone" on the tablet) while the native backend
has an output-centric viewpoint (i.e., the padding defines the size of the
"dead zone" on the display) viewpoint. This difference in opinion causes the
cursor offset to change when switching between Xorg and a Wayland sessions.
The calibration utility within g-c-c does its calculations with an input-
centric viewpoint, so this patch modifies the native backend to work
correctly with these values. To change viewpoints, we can simply invert
the scale and negate the offset. It should be noted that this function
also forgot to apply scaling to the offsets (as required by the matrix
transform done by libinput) which would have further compounded the
cursor offset issue under Wayland.
https://bugzilla.gnome.org/show_bug.cgi?id=784009
It would only allow to alternate between the logical monitors, we actually
want to return NULL here so it can cycle to the whole span of monitors.
https://bugzilla.gnome.org/show_bug.cgi?id=782032
Instead of checking all MetaMonitors in the monitor manager, we want to
look (as the function name says) in the MetaMonitors contained in the
given logical monitor.
Otherwise, it will return TRUE for every logical monitor, given we are
querying for an existing EDID.
https://bugzilla.gnome.org/show_bug.cgi?id=782032
Due to the pen/eraser device separation in X11, CLUTTER_TABLET_DEVICE does
not apply there, this device type is only used in native/evdev. Checking
for CLUTTER_PEN/ERASER_DEVICE makes the left-handed mode correctly applied
on tablets.
https://bugzilla.gnome.org/show_bug.cgi?id=782027
For devices connected via HDMI (supposedly TVs) we want have a
scale factor of 1 if we are *below* the smallest 4k resolution
width (not equal or above) and do the scaling factor computation
if we are above the limit. This check was apparently wrongly
ported from gnome-settings-daemon.
Based of a patch by Caolan McNamara <caolanm@redhat.com>.
https://bugzilla.gnome.org/show_bug.cgi?id=777347
We will both create and destroy monitors during initialization (when
using the X11 backend), so don't try to access the monitor manager from
the backend, but store a pointer to it instead.
It's stored in MetaMonitor even though only MetaMonitorTiled uses it,
mostly because it makes more sense to store such a pointer there.
https://bugzilla.gnome.org/show_bug.cgi?id=781723
In some circumstances, the origin tile (0, 0) is not the one that
should be used to drive the monitor when using a non-tiled mode. Update
MetaMonitorTiled to support this case. It also seems to be so that the
preferred mode might be some low resolution or bogus mode on these
monitors, so also adapt MetaMonitorTiled to manage to ignore the
preferred mode of a tiled monitor if the preferred mode doesn't use
both tiles.
https://bugzilla.gnome.org/show_bug.cgi?id=781723
Only support suggested monitor positioning if the monitor is non-tiled.
Normally this functionality is used by virtual machines to provide a
hint of how to place the virtual monitors, and they don't tend to use
tiled monitors anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=781723
This commit makes it possible to configure logical monitor scale also
when running on top of an X11 server using Xrandr. An extra property
'requires-globla-scale' is added to the D-Bus API is added to instruct
a configuration application to only allow setting a global logical
monitor scale.
This is needed to let gsd-xsettings use the configured state to set a
XSettings state that respects the explicit monitor configuration.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
The scale calculation doesn't really have anything to do with KMS, and
eventually we'll want to have mutter calculate the monitor scale for
non-KMS backends too, so move the scale calculation to MetaMonitor.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Introduce MetaSettings and add the settings managed by MetaBackend into
the new object. These settings include: experimental-features and UI
scaling factor.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
hotplug_mode_update is used (mostly by VMs nowadays, and
VMware has implemented it) to inform that modes list (including
the preferred one) might change after an uevent.
However, when using MetaMonitorConfigManager we should
ignore this value at initialization level, or mutter
won't restore the configured values at startup.
https://bugzilla.gnome.org/show_bug.cgi?id=783073
Disable-while-typing disables the touchpad while the user is typing.
This patch introduces the necessary backend code to implement the
org.gnome.desktop.peripherals.touchpad.disable-while-typing setting of
gsettings-desktop-schemas which was implemented in commit
4c5b1c1df399d6afaaccb237e299ccd1d5d29ddd and released as part of 3.24.
This is known as dwt in libinput.
This patch has been tested on X11 and Wayland.
https://bugzilla.gnome.org/show_bug.cgi?id=764852
Let the backend implementations create their own input settings
backend, as is done with other backend specific special purpose
backends. Also use the macro for declaring the GType.
https://bugzilla.gnome.org/show_bug.cgi?id=782152
meta_backend_real_post_init() had some open coded initialization with
some unexpected interdependencies. Split these up and move them to their
own functions in order to make meta_backend_real_post_init() a bit more
readable.
https://bugzilla.gnome.org/show_bug.cgi?id=782152
g_hash_table_insert() doesn't replace the key. This was a problem
because the key was owned by the value inserted into the hash table, so
when a value was removed, the key was freed, meaning that the key in
the hash table was no pointing to freed memory. Fix this by using
g_hash_table_replace() instead, which work the same except that it
replaces the key with the one passed. This means that the key of a
value in the hash table is always the key owned by the value.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
The guard for handling size differences between keys were broken, it
only checked if the key passed by the second argument ended up being
shorter.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
An inactive monitor will not be assigned to a logical monitor, so don't
try to match against those. This avoids a dereferencing a NULL when the
main output of an inactive monitor doesn't have an assigned CRTC.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Instead of looking at the GTK+ settings, check the logical monitor
state and determine the UI scaling factor given the maximum logical
monitor scale. This is only enabled when the monitor config manager
feature is enabled, as only then can a scale be explicitly configured.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
This adds a function to be used by gnome-shell to get the logical
monitor given a connector name. For now, use the same index integer
method to reference a logical monitor, but this should be revisited by
providing a better API later.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
The connector returned is the one of the main output. In other words,
for tiled monitors, it is the connector of the (0, 0) tile, and for
non-tiled, it is simply the connector of the output.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
