[systemd-devel] Ordering after udev applied rules to `/dev/dri/card0`

[Pekka Paalanen]

On Thu, 2 Apr 2020 10:08:06 +0200
Lennart Poettering <lennart at poettering.net> wrote:

> On Do, 02.04.20 10:35, Pekka Paalanen (ppaalanen at gmail.com) 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 at .service template to weston at .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?)

Hi,

yeah, that sounds attractive, but it has one problem: the idea of a
usable graphics device might be different between logind and the
compositor, like you explained.

Currently in Weston's case, you have to pick the backend before
launching weston. DRM-backend handles only DRM devices, fbdev-backend
handles only fbdev, and nothing else exists for bare hardware. We would
need to add some detection logic in the Weston frontend for choosing
the right backend. There already is some, but it only applies to
running Weston nested on X11 or Wayland. Not impossible.

It would work for auto-login cases I guess, but I'm not sure about how
well it would serve login managers. Wouldn't a login manager like GDM
be still needed, but instead of listening to SeatAdded/SeatRemoved it
would have to listen to login-UI actions? I'm really not the right
person to evaluate that.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20200402/5e8a04b0/attachment.sig>