Am Samstag, 15. Februar 2025, 11:09:27 MEZ schrieb Yves-Alexis Perez: > On Sat, 2025-02-15 at 10:22 +0100, Heiko Stübner wrote: > > The problem is not the logged in user, but the user lightdm itself runs at. > > I.e. user "lightdm". > > Hey Heiko, > > I got that the first time, but I think that should be exactly the same thing. > Unfortunately it seems that the greeter session doesn't have the same > permissions through loginctl/systemd/udev stack, at least I don't have the acl > either. > > I don't have much clue here but I don't think it's something specific to > LightDM though. > > > > Hence without user "lightdm" being in group render, lightdm only displays > > said black screen and the error in the seat-log and does _not_ reach any > > login prompt at all. > > What greeter do you use? Here (with lightdm-gtk-greeter) even without the > correct acl on /dev/dri/renderD128 I don't have permission access in the log, > and obviously it works just fine for everyone else.
For me it's also just the lightdm-gtk-greeter. > I'm unsure if it's mali-related (I don't really see why) or more software > related. It's not specific to Mali itself, this should happen on all render-only gpus. Instead it's all "just" Mesa's standard doing ;-) Of course on a "regular" graphics card this never appears, as there Mesa will not needcto access the render node at all. On embedded systems, you most of the time have separate video-output components, that handle just the scanout of display data through hdmi, dp, dsi or whatever other means. And completely separate render-only GPU (for example Mali) that do not have any output capabilities itself. Both of them are independent drm-drivers in the system which talk via the kernel's prime mechanism to hand over data. So when an application does hand over to Mesa for anything, Mesa knows that "oh, rockchip-drm does not do GPU stuff" and will on its own go looking for said render-only device to get accelerated things from there. Heiko
