Re: Ordering after udev applied rules to `/dev/dri/card0`

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Do, 02.04.20 10:35, Pekka Paalanen (ppaalanen@xxxxxxxxx) wrote:

> > I don't think you need to wait for CanGraphical. I mean, the value of
> > that field just reflects whether at least one DRM or other graphical
> > device was discovered associated with the seat.
>
> Hi,
>
> what other graphical devices than DRM devices? Or is that for the
> sysadmin to decide somehow?

All devices with the udev tag "master-of-seat" are
considered. In our default udev rules file that's some select fb
devices (hyperv, efifb, uvesafb), DRM, parallels
PCI graphics device. Also any PCI graphics card when the system is
booted with nomodeset. See 71-seat.rules.

> > with, and match against the seat id specified. All video/input devices
> > that make sense to be associated to a seat have ID_SEAT= set to the
> > seat name, except for those associated with the primary seat (seat0),
> > which may have the property absent.
>
> That is implemented in Weston already, for both input and DRM
> devices.

Excellent!

> What is CanGraphical useful for then? I've never really read about it,
> I only saw the GNOME Mutter MR and assumed it was a good idea.

It's more interesting for display managers than for
compositors. i.e. the idea is "gdm" and such start "gnome-shell" (or
weston) and such on all seats as soon as CanGraphical is turned on for
them. gdm should not have understanding about devices, unlike
gnome-shell/weston. hence we hide the basic understanding in logind
there.

Thinking about this: it might make sense to revisit this
eventually... for example maybe instead of having gdm run all the time
and just listening to SeatAdded/SeatRemoved and CanGraphical property
changes and then spawn off a login UI for that seat, maybe we should
just add this behaviour to logind itself that it can spawn
compositor@$SEAT.service whenever this happens. That should be easy to
do and might be interesting for weston-like setups: i.e. you'd just
symlink the compositor@.service template to weston@.service and then
weston would get started automatically whenever a graphical seat shows
up. does that make sense? i kinda like the idea. it would solve all
your problems too, right?)

Lennart

--
Lennart Poettering, Berlin
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel