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

[Lennart Poettering]

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

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.

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

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

Lennart

--
Lennart Poettering, Berlin