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

[Pekka Paalanen]

On Tue, 31 Mar 2020 17:08:49 +0200
Lennart Poettering <lennart at poettering.net> wrote:

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

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.

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.

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

Yeah, that's a problem. In Weston's case, if Weston is started with
DRM-backend, then that can be taken to mean that there will be a DRM
device and it's ok to wait for it indefinitely. If not, the user should
use another backend, like headless-backend.

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

That sounds nice to me.


Thanks,
pq

> 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
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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