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

[Pekka Paalanen]

On Wed, 1 Apr 2020 17:09:59 +0200
Lennart Poettering <mzxreary at 0pointer.de> wrote:

> On Mi, 01.04.20 11:34, Pekka Paalanen (ppaalanen at gmail.com) wrote:
> 
> > > > Is there a way to order a service in such a way, that it’s guaranteed that
> > > > udev rules to devices were applied?
> > > >
> > > > A small script applying permissions and ownership manually in
> > > > `ExecStartPre=` seems to work around the (graphics) issue.
> > > >
> > > > If it cannot be solved with ordering, what would you suggest?
> > > >
> > > > [1]: https://gitlab.freedesktop.org/wayland/weston/issues/382
> > > > [2]: https://gitlab.freedesktop.org/wayland/weston/-/blob/master/libweston/backend-drm/kms.c#L741  
> > >
> > > Ideally Weston would just wait for devices assigned to the seat it
> > > shall run on to appear to make this all safe.  
> >
> > Hi,
> >
> > there is an issue open about something like that:
> > https://gitlab.freedesktop.org/wayland/weston/-/issues/173
> >
> > If I understand it right, waiting for CanGraphical allows Weston's
> > DRM-backend to wait for any DRM device to appear on the seat, so that
> > you don't need to hardcode in advance which DRM device to depend on.  
> 
> 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?

> But Weston should know
> better what kind of devices it can deal with, hence I'd just subscribe
> to udev events and watch for all drm/fb/… devices Weston can deal

Right. Weston's DRM-backend only works with DRM devices. True, there
exists a fbdev-backend, but it already does not use logind to open the
fbdev device, and is a second class citizen anyway, intentionally left
to rot.

> 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.

> Hence, instead of watch CanGraphical, just watch udev, with a match
> for SUBSYSTEM=drm, SUBSYSTEM=input and so on, and then ignoring all
> devices that have ID_SEAT != the seat you are started for, except if
> you are started for seat0 in which case you also use all devices that
> have no ID_SEAT set.

For input devices it already works like this.

> This means that weston might run before any suitable graphics device
> popped up, in which case it should probably just hang in there and
> wait. It might also mean that more than one suitable graphics devices
> show up, in which case it might make sense to merge them somehow,
> either mirroring or expanding the desktop, you probably know better
> what would make sense there...

Sure, although there is no support written to use more than one DRM
device yet. So the first one to appear on a seat is the one whose
outputs will be driven and which is used for GPU compositing.

Once Weston picks a GPU for compositing, it cannot really change that
ever again, because clients (apps) may have started to depend on the
exact choice already. That is a bit unfortunate for any automatic
choosing in a multi-GPU system, I'm not sure what the best way to solve
that would be... Weston can switch from software compositing to GPU
compositing in flight though, so maybe Weston should be made to always
start with software compositing, wait for N seconds, and then switch to
the "best" GPU there is, if any. But then that means that apps started
before the switch are stuck with software rendering, since none of them
handle the GPU support appearing dynamically. Hmm...

> > Weston itself does not know which device it should wait for appearing
> > either, otherwise it could watch udev for it. Or, I guess Weston could
> > wait for any DRM device assigned to the seat, so essentially what
> > CanGraphical does.  
> 
> Exactly, that's what I would find best. I mean it already watches for
> input devices, right? so watching for graphics devices is just a small
> step further.

A small step probably, but not exactly the same, because the compositor
as a whole with DRM-backend cannot initialize without a DRM device.
Yet, at least. Once we implement multi-DRM-KMS-device support, starting
without a KMS device should be ok.

Thanks for the suggestion, I'll change the plans.

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.


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/f553269a/attachment.sig>