These devices do not become user-accessible this way, but they are
logically assigned to a seat, which makes a lot of sense, since they are
human-facing output devices, and such should belong to one.
When 'nomodeset' is specified, there's no DRM driver to take over from
efifb. This means no device will be marked as a seat master, so gdm will
never find a sufficiently active seat to start on.
I'm not aware of an especially good way to detect this through a proper
kernel API, so check for the word 'nomodeset' on the command line and
allow fbdev devices to be seat masters if found.
For https://bugzilla.redhat.com/show_bug.cgi?id=1683197.
This enables graphical capability for a video adapter of Parallels
virtualization platform (Parallels Desktop for Mac product) which is not
a DRM device at the moment.
This fixes GUI in Fedora 29 guest on Parallels Desktop where gdm now
strictly checks for CanGraphical property of a seat, see [1].
Should be noted that there's no in-kernel driver for Parallels video at
the moment so device matching is done by vid/pid.
[1] https://gitlab.gnome.org/GNOME/gdm/merge_requests/37
Currently we consider any framebuffer device as enough to have a
valid graphical session, but this might lead to many false postives
like in the case of framebuffer devices that have a linked drm card
which is still in the process of being added, or for vesa fb, and
so it doesn't ensure us that we can have a proper graphical session.
Since these days we normally don't consider anything without a DRM
card able to provide a full graphical session, let's not set this
at this level.
Drivers which can provide a graphical session with the sole fb are
still free to mark any device as `master-of-seat`
Fixes#10435
Qemu provides a separate pci-bridge exclusively for multi-seat setups.
The normal pci-pci bridge ("-device pci-bridge") has 1b36:0001. The new
pci-bridge-seat was specifically added to simplify guest-side
multiseat configuration. It is identical to the normal pci-pci bridge,
except that it has a different id (1b36:000a) so we can match it and
configure multiseating automatically.
Make sure we always treat this as separate seat if we detect this, just
like other "Pluggable" devices.
(David: write commit-message)
This is needed for generic DRM devices like the VirtualBox vboxvideo
driver, which exposes itself as a generic, ID-less DRM device at
/dev/dri/card0 (after applying this commit):
$ udevadm info --query=all --path \
/sys/devices/pci0000:00/0000:00:02.0/drm/card0
P: /devices/pci0000:00/0000:00:02.0/drm/card0
N: dri/card0
E: DEVNAME=/dev/dri/card0
E: DEVPATH=/devices/pci0000:00/0000:00:02.0/drm/card0
E: DEVTYPE=drm_minor
E: ID_FOR_SEAT=drm-pci-0000_00_02_0
E: ID_PATH=pci-0000:00:02.0
E: ID_PATH_TAG=pci-0000_00_02_0
E: MAJOR=226
E: MINOR=0
E: SUBSYSTEM=drm
E: TAGS=:master-of-seat:seat:uaccess:
E: USEC_INITIALIZED=59893
Without this patch, the capabilities for a seat on a VirtualBox
installation of systemd v219 incorrectly show it as non-graphical, even
though I can type these commands from an xterm:
$ loginctl show-seat seat0
Id=seat0
CanMultiSession=yes
CanTTY=yes
CanGraphical=no
…
https://bugs.freedesktop.org/show_bug.cgi?id=90822
We currently enforce that seats are to be named in the form of
"seatXXX", i.e. need to begin with the 4 characters "seat". Thus,
"seat-master" would qualify as a seat name. As seat names are frequently
used as tags on devices, the "seat-master" tag might hence confuse
logind if the user decides to name a seat "seat-master".
Hence, avoid any ambuigity: let's rename the "seat-master" tag to
"master-of-seat".
