When the native backend is paused we still process the udev events
even though this isn't needed and may just cause unneeded events to be
triggered afterwards.
Since we'll resume with full changes on such event, we can just block
the signal hander when paused and restore it afterwards.
As per this we can cleanup also a bit the device adding signal handling
given that now we don't have to disconnect/reconnect it again.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1964>
Virtual Kernel Mode Setting (vkms) is a virtual /dev/dri/card* device
not backed by any actual hardware. It's intended for testing purposes,
e.g. to run tests suites with a reproducable setup, or in continuous
integration pipelines.
Currently mutter don't have any tests that can run on top of vkms, but
will eventually get that. To prepare for the ability to do that, and
having said kernel module loaded without causing wierd issues with any
active session, add an udev rule that tells mutter to ignore any vkms
device.
Otherwise, when vkms is loaded, mutter would detect it, assume it's a
regular monitor, configure it as such, thus add a region of the stage
that ends up nowhere, which isn't very helpful. It might also conflict
with running actual tests that need to interact with vkms if the active
session has taken control of it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1740>
The intel DRM driver is known for not being able to handle multi head
setups when KMS modifiers are enabled, due to the implicitly selected
modifiers, while being more suitable for single head setups, cause
bandwidth issues when a certain number of monitor times resolution and
refresh rate is configured.
We don't yet support automatically finding a combination of modifiers
that work, and have because of this disabled KMS modifiers unless the
driver actually needs it.
Lets flip this configuration the other way around, changing the current
udev rule to decide wen to *disable* KMS modifier support, as it so that
only the Intel driver has this problem, while on the other hand, there
several drivers that requires modifiers to function at all.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1792>
Sometimes the automatically selected primary GPU isn't suitable with no
way to make an well educated guess to do it better. To make it possible
for the user to override the automatically calculated default, make it
possible to override it using a udev rule.
E.g. to select /dev/dri/card1 as the primary GPU, add a file e.g.
/usr/lib/udev/rules.d/61-mutter-primary-gpu.rules (path my vary
depending on distribution) containing the fellowing line:
ENV{DEVNAME}=="/dev/dri/card1", TAG+="mutter-device-preferred-primary"
Reboot or manual triggering of udev rules to make it take effect may be
required.
Related: https://gitlab.gnome.org/GNOME/mutter/merge_requests/1057https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1562
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1562>
