On Wed, 1 Apr 2020 17:09:59 +0200 Lennart Poettering <mzxre...@0pointer.de> wrote:
> On Mi, 01.04.20 11:34, Pekka Paalanen (ppaala...@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
pgppbf6jvOcva.pgp
Description: OpenPGP digital signature
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
