On a number of systems with separate render-only gpu, for example
everything with a Mali GPU, the graphics output will be the regular
/dev/dri node, but for accelerated loads via mesa will render on the
separate render-node - /dev/dri/renderD128 for example.

Installing and starting lightdm on such an ARM device with a Mali GPU
using standard MESA will result in a black screen and a log like

$ cat /var/log/lightdm/seat0-greeter.log
[...]
failed to open /dev/dri/renderD128: Permission denied
glx: failed to create dri3 screen
failed to load driver: rockchip


Adding the lightdm-user to group render, solves this issue and allows
lightdm to start.

Hi, it looks to me that this should be dynamically granted through ACL with
udev, not statically using groups.

Can you check with getfacl for example? Here's the result (once my user is
logged in):

getfacl /dev/dri/renderD128
getfacl: Removing leading '/' from absolute path names
# file: dev/dri/renderD128
# owner: root
# group: render
user::rw-
user:corsac:rw-
group::rw-
mask::rw-
other::---


Regards,

Hi,

Am Samstag, 15. Februar 2025, 10:09:17 MEZ schrieb Yves-Alexis Perez:

The problem is not the logged in user, but the user lightdm itself runs at.
I.e. user "lightdm".

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.


Thanks a lot for looking into this
Heiko

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.

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.

I'm unsure if it's mali-related (I don't really see why) or more software
related.

Regards,

Am Samstag, 15. Februar 2025, 11:09:27 MEZ schrieb Yves-Alexis Perez:

For me it's also just the lightdm-gtk-greeter.

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

control: tag -1 help
control: retitle lightdm user needs access to DRI render nodes on some
platforms

Ok. So it's more about something with the whole device stack. I have no clue
here so help from the systemd/loginctl/dbus folks will likely be needed.

Since it wasn't clear: I'm not adding lightdm user to the render group, that
should be done dynamically. I have no idea how to make that happens similarly
to more interactive users (for which it works just fine) so any pointer
appreciated.

Regards,

This email was set as the recovery address for your Proton Account.

Please verify this email belongs to you.

[Verify email](https://account.proton.me/verify-email?email=dublincoolevents@protonmail.com#eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpYXQiOjE3NTUxMTA4NzEuNjE2MTU5OSwiZXhwIjoxNzU1NzE1NjcxLCJVc2VySUQiOiJPWERkY3M1dHAyc01Dc1dsbTVleWN3IiwiU2NvcGUiOjMyNzY4LCJpc3MiOiJwcm90b24ubWUiLCJhdWQiOiJwcm90b24ubWUiLCJUeXBlIjozLCJFbWFpbCI6ImlqaEN0TDhnaFB3ZHAxdzlobWl0Vk5mWVdpYTZVejlIbFVjZWVIeE5pakE9In0.BG4o8sYS4MHJVT8W80F8NzFeid2D6bgWxyNHfqf91Xo)

Verification ensures we can safely assist you in case of sign-in issues or suspicious activity.

Thank you,
The Proton Team