OpenGL interface change in master broke GLES on the pi devices

snapd
1

I was approached yesterday by @greyback that he was not able to get mir-kiosk up on the pi3 in the daily edge images. Sadly tyring to look into this made me find another serious bug with the images (regression in setting the clock on first boot) that ate my day to fix …

Today i finally got around to inspect the GLES issue… installing mir-libs and mir-kiosk on the latest edge core (16-2.27.5+git352.186fdc0 ) makes mir-kiosk not start with " Error opening DRM device", switching core to --beta or --candidate makes it start up fine.

A log of the failing setup is at http://paste.ubuntu.com/25445732/

The only change to the opengl interface i see is @zyga-snapd’s
https://github.com/snapcore/snapd/pull/3833

Now to the most interesting part:

If mir-kiosk started once under the candidate or beta core snap it keeps working when switching back to edge … seemingly the switch to candidate/beta puts the “broken” udev rule in place and switching back to edge does not update it (to the “fixed” rule that breaks GLES):

ogra@localhost:~$ grep SUBSYSTEM /etc/udev/rules.d/70-snap.mir-kiosk.rules
SUBSYSTEM="drm", KERNEL=="card[0-9]*", TAG+="snap_mir-kiosk_mir-kiosk"

So there seem to be two issues here …

  • the new rule breaks GLES on arm devices
  • the rules do not get dynamically updated when switching to a different core version
2

Digging a little deeper it seems there are some differences in the subsystem, running:

sudo udevadm trigger -v|grep drm

…on different devices points out the following:

Intel based:

/sys/devices/pci0000:00/0000:00:02.0/drm/card0
/sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-DP-1
/sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-HDMI-A-1
/sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-VGA-1
/sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-eDP-1
/sys/devices/pci0000:00/0000:00:02.0/drm/controlD64
/sys/devices/pci0000:00/0000:00:02.0/drm/renderD128
/sys/devices/pci0000:00/0000:00:02.0/drm_dp_aux_dev/drm_dp_aux0
/sys/devices/pci0000:00/0000:00:02.0/drm_dp_aux_dev/drm_dp_aux1

Nvidia:

/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card0
/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/renderD128

Raspberry Pi:

/sys/devices/platform/soc/soc:gpu/drm/card0
/sys/devices/platform/soc/soc:gpu/drm/card0/card0-HDMI-A-1
/sys/devices/platform/soc/soc:gpu/drm/controlD64
/sys/devices/platform/soc/soc:gpu/drm/renderD128

looking at the opengl interface source i see:

/sys/devices/pci[0-9]*/**/

but nothing that allows access to /sys/devices/platform

There are also:

/run/udev/data/+platform:soc:gpu

and

/sys/bus/platform/devices/soc:gpu/

…that don’t seem to be mentioned in opengl.go

3

So, the SUBSYSTEM=drm is the part that is broken and since it is a parse error, udev proably stops right there. That particular bug is in snapd in master (it was fixed last week) and when you change channels you may end up with a non-loading udev rule. That may, in turn, disable udev tagging so all the confinement is in apparmor control (not the device cgroup). Long story short I think it will be fine with the next master build.

4

Oh so you mean the commit that landed last week is not in any daily build (if thats the case our build policy of the daily snapd deb seem to be wrong (did the build not happen ?))

5

Hey @ogra and @zyga-snapd
thanks for looking into this for me. If there is a build available I can test with, let me know and I’ll give it a go
-G

6

you can easily just hack the udev rule and reboot …

turn SUBSYSTEM=“drm” into SUBSYSTEM==“drm” in

/etc/udev/rules.d/70-snap.mir-kiosk.rules

7

Ack, that’ll get me up and running, thanks!

8

I’ll take a look at these other paths.