For secondary GPU rendering contexts we currently might choose an EGL
config with a format which is not supported on all primary planes. The
renderer is created when a GPU is detected and lighting up outputs and
thus assigning CRTC and primary planes can happen at any point after
that. This means we have to make sure that all possible plane
assignments will work with the rendering context when we create it.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3235
Fixes: cc7bca073 ("crtc/kms: Dynamically assign primary and cursor planes")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3512>
It can be used to force a specific RGB range. Some monitors don't follow
the specification and expect a signal different from what we send. This
property allows to force a mode which hopefully then works correctly for
the sink.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3535>
BTN_STYLUS is the lower one and traditionally (read: in X) maps to
middle button (2), BTN_STYLUS2 is the upper one and traditionally maps
to right button (3).
This is also what GTK does and our desktop actions too map MIDDLE to
BTN_STYLUS and RIGHT to BTN_STYLUS2.
See also gtk!6168
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3541>
adwaita-icon-theme updated its cursor metaphors and changed all DnD
cursors to use arrows instead of hands, except for the grab related
ones. Mutter was using "grabbing" as default DnD cursor, which now
does not match the other DnD cursors ("copy" and "no-drop") anymore.
Change this to the "default" cursor.
Additionally, because the "no-drop" cursor now puts a stronger emphasis
on the crossed out symbol also prefer "default" for
META_CURSOR_DND_IN_DRAG and only use "no-drop" for things that
explicitly don't accept a drop.
Related: https://gitlab.gnome.org/GNOME/adwaita-icon-theme/-/merge_requests/63
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3532>
In various public APIs, Clutter used to return a PangoDirection
while we have a text direction enum defined in Clutter.
This allows us to drop pango dependency from meta making it specific
to cogl-pango & clutter
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3531>
Set the deadline timer state as "inhibited" in case a permission error
is returned while attempting to arm the deadline timer. This makes each
device enable its deadline timer again after a VT switch.
Also print a note in this case instead of a warning as such errors are
expected during a VT switch and should not raise concerns.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3259
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3534>
For now, this function only enables the deadline timer in case it was
inhibited. This would result in an attempt to use the deadline timer
again after a device is resumed.
If the conditions that resulted in the timer becoming inhibited
remain, it is expected to return to this state after the next frame
and before being armed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3534>
The "disabled" state indicates that the deadline timer is disabled
for the lifetime of the device, while the "inhibited" state indicates
that it is disabled temporarily for the device.
This distinction is needed to handle each state differently in a
following commit. For now, only "disabled" is used.
No change in behavior.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3534>
This allows GNOME Shell to communicate the user desired XKB model
to the compositor instead of sticking with the pc105 default.
Particularly useful for those with a custom keyboard layout/irregular
keyboards.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2760>
Some panels only support fixed resolutions and fixed refresh rate with reduced blanking:
Established Timings I & II: none
Standard Timings: none
Detailed Timing Descriptors:
DTD 1: 2560x1600 120.001823 Hz 8:5 203.283 kHz 552.930000 MHz (345 mm x 215 mm)
Hfront 48 Hsync 32 Hback 80 Hpol P
Vfront 3 Vsync 6 Vback 85 Vpol N
DTD 2: 2560x1600 48.000295 Hz 8:5 81.312 kHz 221.170000 MHz (345 mm x 215 mm)
Hfront 48 Hsync 32 Hback 80 Hpol P
Vfront 3 Vsync 6 Vback 85 Vpol N
...
Minimum Pixel Clock: 552922 kHz
Maximum Pixel Clock: 552922 kHz
When using mirror mode, resolutions like 2560x1440 120Hz can be too high
to meet the pixelclock limitation, so 2560x1440 90Hz is selected
instead. However, the panel only supports 120Hz so using 90Hz result to
failed mode set.
So add reduced blanking to fallback mode, so correct refresh rate can be
used.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3449>
To paraphrase jadahl: we have a dedicated KMS thread now, which also
has realtime scheduling enabled unconditionally. realtime scheduling
on the main thread isn't too great of an idea, considering GC can
take a hot minute.
And to quote rmader: we most likely won't be able to make the main
thread rt as long as we use GJS and thus have GC.
So let's get rid of it! It's just been breaking things anyways.
This just ignores the setting; we'll fully remove it when GNOME 46
comes around.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3296>
For tablet device, the tool was created when the "Wacom Serial IDs" prop
changed values. This property does not exist on the xf86-input-libinput
driver but v1.5.0 of that driver has a different property for the serial.
The serial is constant (the driver creates one X device per serial), so
we can fetch it after device creation and set it then. For earlier
versions of the driver we assign the random serial 0xffffffaa - good
enough to have at least a tool.
This fixes the crash in #3120 - clutter_event_motion_new()
overrides event->device to the tool's device (if any). Without a tool
motion events use the Virtual Core Pointer instead and our source device
is never added to the stage's priv->pointer_devices.
When we generate an crossing event (which uses the source device) we
fall afoul of an assert in clutter_stage_update_device() that expects
our source device to be in priv->pointer_devices.
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/3120
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3383>
DRM's kms atomic code was updated to include an API to set the mouse
cursor hotspot. This has historically been missing in the atomic kms
which meant that the virtualized drivers which require mouse cursor
hotspot info to properly render had to be put on a deny list and
had to fallback to the legacy DRM kms code.
Implement the new hotspot API by checking whether the device supports
hotspot properties and if it does set them on the cursor plane. This
enables atomic kms on all virtualized drivers for kernels where
mouse cursor hotspots are in drm core.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3337>
