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

[Lennart Poettering]

On Do, 19.03.20 17:47, Paul Menzel (pmenzel+systemd-devel at molgen.mpg.de) wrote:

> Dear systemd folks,
>
>
> I am using Debian Sid/unstable with systemd 245.2 and Weston 8.0.0.
>
> I amtrying to start a graphical desktop as soon as possible. Currently, I
> use Weston, but unfortunately accessing `/dev/dri/card0` it gets a
> permission denied error. The Weston service unit is ordered after
> `systemd-logind.service`.
>
> Weston now fails to start, because it gets a permission denied error
> accessing `/dev/dri/card0` [1][2].
>
>     drmModeSetCrtc(backend->drm.fd, output->crtc_id,
> scanout_state->fb->fb_id, 0, 0, connectors, n_conn, &mode->mode_info);
>
> Right before Weston starts, the permission and ownership are like below.
>
>     $ ls -l /dev/dri:
>     insgesamt 0
>     crw------- 1 root root 226,   0 Mär 19 17:29 card0
>     crw------- 1 root root 226, 128 Mär 19 17:29 renderD128
>
> After udev applied the rules, it looks like below, meaning users in group
> `video` are allowed to access the device.
>
>     $ ls -l /dev/dri
>     insgesamt 0
>     drwxr-xr-x  2 root root         80 Mär 19 17:29 by-path
>     crw-rw----+ 1 root video  226,   0 Mär 19 17:29 card0
>     crw-rw----+ 1 root render 226, 128 Mär 19 17:29 renderD128
>
> 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. The thing is that we
don't know if a DRM device will show up or not. on some systems DRM
might show up, but on others (servers, containers, embedded devices,
…) it might never, since they have no actual graphics hw that can do
DRM. hence ordering a service after a device appearing means your
system will only boot up on machines that actually have a DRM device,
and not those anymore that do not...

What you could do is write a udev rule for your drm device that uses
the SYSTEMD_WANTS property to pull in has-drm.target, and then hook
your weston service into that with a Requisite=multi-user.target or
so. That way weston gets pulled in only if DRM shows up and when DRM
shows up, but not before and not on systems that do not have it, and
boot is not delayed for it...

If you develop your stuff for a very specific device only, and do not
attempt to build an OS that can boot on generic systems, then you
could also just change your weston service to do
"Wants=dev-dri-card0.device" + "After=dev-dri-card0.device". and thus
leave weston in the initial transaction and time out if DRM never
shows up...

Lennart

--
Lennart Poettering, Berlin