Hi guys,
These issues I am describing result from an analysis I did on an Orin Nano Super devkit.
What I was trying to achieve is to automatically start weston in a “kiosk” mode during the system boot (i.e. without the need to login).
I ran into a few issues that made this more difficult than it should be, and I thought I should report these here in case this can be useful to others, and maybe receive a proper fix from NVIDIA.
To get started I managed, with little effort, to start weston by logging in through SSH and running it manually, after making sure to run “modprobe nvidia_drm” first.
The problems started when I tried to automate this process using systemd.
This involved creating a weston.service file that would autologin under a kiosk user and run weston. (I borrowed code from yocto as a starting point that can be found in the weston-init recipe).
It also involved making sure that the nvidia_drm module was modprobe’d during the boot process prior to starting weston.
What I noticed is the following:
- If the nvidia_drm module was modprobe’d during the boot process (either through a dependency on modprobe@nvidia_drm.service or an addition in /etc/modules-load.d/):
- in this case weston would fail to start…
- If I did NOT modprobe the nvidia_drm module during the boot process and then manually ran “modprobe nvidia_drm”, and started the service manually using “systemctl start weston.service”:
- in this case weston would start successfully…
That led me to believe that “modprobe nvidia_drm” had different outcomes depending on when it was run.
And indeed this is what the content of the /dev/dri directory looks like when running modprobe manually:
laurent@ubuntu:~$ ls -lR /dev/dri
/dev/dri:
total 0
drwxr-xr-x 2 root root 120 Oct 25 23:56 by-path
crw-rw---- 1 root video 226, 0 Jun 4 16:17 card0
crw-rw---- 1 root video 226, 1 Oct 25 23:56 card1
crw-rw---- 1 root render 226, 128 Jun 4 16:17 renderD128
crw-rw---- 1 root render 226, 129 Oct 25 23:56 renderD129
/dev/dri/by-path:
total 0
lrwxrwxrwx 1 root root 8 Oct 25 23:56 platform-13800000.display-card -> ../card1
lrwxrwxrwx 1 root root 13 Oct 25 23:56 platform-13800000.display-render -> ../renderD129
lrwxrwxrwx 1 root root 8 Jun 4 16:17 platform-13e00000.host1x-card -> ../card0
lrwxrwxrwx 1 root root 13 Jun 4 16:17 platform-13e00000.host1x-render -> ../renderD128
laurent@ubuntu:~$
And this is what it looks like when running modprobe is automated:
laurent@ubuntu:~$ ls -lR /dev/dri
/dev/dri:
total 0
drwxr-xr-x 2 root root 120 Jun 4 16:17 by-path
crw-rw---- 1 root video 226, 0 Jun 4 16:17 card0
crw-rw---- 1 root video 226, 1 Jun 4 16:17 card1
crw-rw---- 1 root render 226, 128 Jun 4 16:17 renderD128
crw-rw---- 1 root render 226, 129 Jun 4 16:17 renderD129
/dev/dri/by-path:
total 0
lrwxrwxrwx 1 root root 8 Jun 4 16:17 platform-13800000.display-card -> ../card0
lrwxrwxrwx 1 root root 13 Jun 4 16:17 platform-13800000.display-render -> ../renderD128
lrwxrwxrwx 1 root root 8 Jun 4 16:17 platform-13e00000.host1x-card -> ../card1
lrwxrwxrwx 1 root root 13 Jun 4 16:17 platform-13e00000.host1x-render -> ../renderD129
laurent@ubuntu:~$
Notice how the cards and render “character devices” mapping to the actual hardware are interverted.
This resulted in weston failing as follows:
weston-0.txt (1.4 KB)
After quite some research, and coming up with nothing, I made a bet and managed to overcome the problem in gl-renderer.so by swapping the renderD128 and renderD129 “character devices” under “/dev/dri/”.
And this solved the problem of starting weston. Here is a successful log:
weston-1.txt (5.3 KB)
As a conclusion on this issue it appears that gl-renderer.so will always try to use /dev/dri/renderD129. I found no obvious way to influence this other than swapping the two corresponding character devices.
REQUEST #1:
- I would hope that there is a way for the gl-renderer.so to select the proper render device, but my assumption is that this might require a change on the NVIDIA weston package.
- That would avoid having to use such a ridiculous hack…
REQUEST #2:
- In addition to this I would like to request that the NVIDIA weston package include the kiosk-shell.so, in the future, as it would be the simplest way for me to support my kiosk use-case.
- The alternative to the kiosk-shell is probably to use ivi-shell, but as you might probably know this is not especially lightweight to take on.
REQUEST #3:
- It would also be nice to have the systemd-notify.so module included, but that’s definitely a “nice to have”.
Kind Regards, Laurent.