mir-kiosk-kodi fails on newer Mesa

[Saviq]

$ mir-kiosk-kodi 
VA error: wayland: Wayland roundtrip error: Protocol error (errno 71)
libva info: VA-API version 1.7.0
libva error: vaGetDriverNameByIndex() failed with invalid VADisplay, driver_name = (null)
terminate called after throwing an instance of 'std::system_error'
  what():  wl_display_roundtrip_queue: Protocol error
Crash report available at /root/snap/mir-kiosk-kodi/368/kodi_crashlog-20220721_113541.log

Things work on Frame, as well as on mir-kiosk when running on top of a Wayland desktop (e.g. Mutter).

The first revision where this occurs is:

$ snap refresh mir-kiosk --revision 8620
mir-kiosk 2.6.0+dev302-snap128 from Canonical✓ refreshed

Which corresponds to https://github.com/MirServer/mir/commit/2ad3b14b8a.

The last working revision:

$ snap refresh mir-kiosk --revision 8607
mir-kiosk 2.6.0+dev142-snap128 from Canonical✓ refreshed

[Saviq]

The real cause is likely the mesa/drm upgrade in this revision:

@@ -1059,18 +1059,18 @@
 - libboost-filesystem1.71.0=1.71.0-6ubuntu6
 - libboost-iostreams1.71.0=1.71.0-6ubuntu6
 - libboost-program-options1.71.0=1.71.0-6ubuntu6
-- libdrm-amdgpu1=2.4.105-3~20.04.2
-- libdrm-intel1=2.4.105-3~20.04.2
-- libdrm-nouveau2=2.4.105-3~20.04.2
-- libdrm-radeon1=2.4.105-3~20.04.2
-- libdrm2=2.4.105-3~20.04.2
-- libegl-mesa0=21.0.3-0ubuntu0.3~20.04.5
+- libdrm-amdgpu1=2.4.107-8ubuntu1~20.04.1
+- libdrm-intel1=2.4.107-8ubuntu1~20.04.1
+- libdrm-nouveau2=2.4.107-8ubuntu1~20.04.1
+- libdrm-radeon1=2.4.107-8ubuntu1~20.04.1
+- libdrm2=2.4.107-8ubuntu1~20.04.1
+- libegl-mesa0=21.2.6-0ubuntu0.1~20.04.1
 - libegl1=1.3.2-1~ubuntu0.20.04.1
 - libevdev2=1.9.0+dfsg-1ubuntu0.1
 - libfreetype6=2.10.1-2ubuntu0.1
-- libgbm1=21.0.3-0ubuntu0.3~20.04.5
-- libgl1-mesa-dri=21.0.3-0ubuntu0.3~20.04.5
-- libglapi-mesa=21.0.3-0ubuntu0.3~20.04.5
+- libgbm1=21.2.6-0ubuntu0.1~20.04.1
+- libgl1-mesa-dri=21.2.6-0ubuntu0.1~20.04.1
+- libglapi-mesa=21.2.6-0ubuntu0.1~20.04.1
 - libgles2=1.3.2-1~ubuntu0.20.04.1
 - libglvnd0=1.3.2-1~ubuntu0.20.04.1
 - libgudev-1.0-0=1:233-1

[AlanGriffiths]

This sounds weird. Typically, mir-kiosk-kodi and Frame will be using mesa-core20 with the more recent mesa.

But you see mir-kiosk fail with the more recent mesa?

[Saviq]

Actually mesa-core20/stable is still at 21.0.3-0ubuntu0.2~20.04.1 Mesa. Which would explain why Frame is fine.

[Saviq]

And yes, refreshing mesa-core20 to beta results in the same problem on Frame.

[Saviq]

A few experiments more, it's the server side that's problematic. I can have new Mesa connected to Kodi, but Frame needs the older one for Kodi to work.

[AlanGriffiths]

A bit more information: the problem seems to lie in the wl_drm protocol:

Here's a working exchange (with the "old" mesa from mesa-core20/stable). Note the "authentication" works:

$ grep wl_drm old_mesa.log 
[919469.074]  -> wl_registry@2.global(1, "wl_drm", 2)
[964292.309]  -> wl_registry@2.global(1, "wl_drm", 2)
[964294.030]  -> wl_registry@3.global(1, "wl_drm", 2)
[964294.792] wl_registry@3.bind(1, "wl_drm", 2, new id [unknown]@8)
[964294.897]  -> wl_drm@8.device("/dev/dri/card0")
[964294.925]  -> wl_drm@8.format(808669761)
[964294.963]  -> wl_drm@8.format(808669784)
[964295.001]  -> wl_drm@8.format(808665665)
[964295.075]  -> wl_drm@8.format(875713089)
[964295.099]  -> wl_drm@8.format(875713112)
[964295.123]  -> wl_drm@8.format(909199186)
[964295.159]  -> wl_drm@8.format(961959257)
[964295.185]  -> wl_drm@8.format(825316697)
[964295.209]  -> wl_drm@8.format(842093913)
[964295.234]  -> wl_drm@8.format(909202777)
[964295.259]  -> wl_drm@8.format(875713881)
[964295.284]  -> wl_drm@8.format(842094158)
[964295.308]  -> wl_drm@8.format(909203022)
[964295.333]  -> wl_drm@8.format(1448695129)
[964295.358]  -> wl_drm@8.capabilities(1)
[964302.290] wl_drm@8.authenticate(1)
[964302.329]  -> wl_drm@8.authenticated()
[964353.603]  -> wl_registry@7.global(1, "wl_drm", 2)
[964354.670] wl_registry@7.bind(1, "wl_drm", 2, new id [unknown]@11)
[964354.751]  -> wl_drm@11.device("/dev/dri/card0")
[964354.778]  -> wl_drm@11.format(808669761)
[964354.815]  -> wl_drm@11.format(808669784)
[964354.855]  -> wl_drm@11.format(808665665)
[964354.928]  -> wl_drm@11.format(875713089)
[964354.954]  -> wl_drm@11.format(875713112)
[964354.980]  -> wl_drm@11.format(909199186)
[964355.005]  -> wl_drm@11.format(961959257)
[964355.029]  -> wl_drm@11.format(825316697)
[964355.054]  -> wl_drm@11.format(842093913)
[964355.079]  -> wl_drm@11.format(909202777)
[964355.104]  -> wl_drm@11.format(875713881)
[964355.128]  -> wl_drm@11.format(842094158)
[964355.153]  -> wl_drm@11.format(909203022)
[964355.178]  -> wl_drm@11.format(1448695129)
[964355.202]  -> wl_drm@11.capabilities(1)
[964355.398] wl_drm@11.authenticate(2)
[964355.433]  -> wl_drm@11.authenticated()
[964373.909]  -> wl_registry@10.global(1, "wl_drm", 2)
[964374.701] wl_registry@10.bind(1, "wl_drm", 2, new id [unknown]@13)
[964374.764]  -> wl_drm@13.device("/dev/dri/card0")
[964374.796]  -> wl_drm@13.format(808669761)
[964374.824]  -> wl_drm@13.format(808669784)
[964374.854]  -> wl_drm@13.format(808665665)
[964374.917]  -> wl_drm@13.format(875713089)
[964374.936]  -> wl_drm@13.format(875713112)
[964374.955]  -> wl_drm@13.format(909199186)
[964374.972]  -> wl_drm@13.format(961959257)
[964374.990]  -> wl_drm@13.format(825316697)
[964375.007]  -> wl_drm@13.format(842093913)
[964375.025]  -> wl_drm@13.format(909202777)
[964375.042]  -> wl_drm@13.format(875713881)
[964375.059]  -> wl_drm@13.format(842094158)
[964375.078]  -> wl_drm@13.format(909203022)
[964375.095]  -> wl_drm@13.format(1448695129)
[964375.113]  -> wl_drm@13.capabilities(1)
[964375.262] wl_drm@13.authenticate(2)
[964375.292]  -> wl_drm@13.authenticated()
[964376.359]  -> wl_registry@14.global(1, "wl_drm", 2)
[964377.378]  -> wl_registry@15.global(1, "wl_drm", 2)
[964378.247]  -> wl_registry@21.global(1, "wl_drm", 2)
[964379.206]  -> wl_registry@19.global(1, "wl_drm", 2)
[964415.819]  -> wl_registry@31.global(1, "wl_drm", 2)

And a failing interaction with a "new" mesa (actually 22.04 archive)

$ grep wl_drm new_mesa.log 
[  86304.119]  -> wl_registry@2.global(1, "wl_drm", 2)
[  86306.243]  -> wl_registry@3.global(1, "wl_drm", 2)
[  86307.412] wl_registry@3.bind(1, "wl_drm", 2, new id [unknown]@8)
[  86307.491]  -> wl_drm@8.device("/dev/dri/renderD128")
[  86307.513]  -> wl_drm@8.format(808669761)
[  86307.540]  -> wl_drm@8.format(808669784)
[  86307.561]  -> wl_drm@8.format(808665665)
[  86307.618]  -> wl_drm@8.format(875713089)
[  86307.633]  -> wl_drm@8.format(875713112)
[  86307.646]  -> wl_drm@8.format(909199186)
[  86307.659]  -> wl_drm@8.format(961959257)
[  86307.671]  -> wl_drm@8.format(825316697)
[  86307.684]  -> wl_drm@8.format(842093913)
[  86307.696]  -> wl_drm@8.format(909202777)
[  86307.709]  -> wl_drm@8.format(875713881)
[  86307.721]  -> wl_drm@8.format(842094158)
[  86307.734]  -> wl_drm@8.format(909203022)
[  86307.747]  -> wl_drm@8.format(1448695129)
[  86307.760]  -> wl_drm@8.capabilities(1)
[  86365.780]  -> wl_registry@7.global(1, "wl_drm", 2)
[  86366.984] wl_registry@7.bind(1, "wl_drm", 2, new id [unknown]@11)
[  86367.045]  -> wl_drm@11.device("/dev/dri/renderD128")
[  86367.074]  -> wl_drm@11.format(808669761)
[  86367.105]  -> wl_drm@11.format(808669784)
[  86367.133]  -> wl_drm@11.format(808665665)
[  86367.203]  -> wl_drm@11.format(875713089)
[  86367.219]  -> wl_drm@11.format(875713112)
[  86367.241]  -> wl_drm@11.format(909199186)
[  86367.266]  -> wl_drm@11.format(961959257)
[  86367.290]  -> wl_drm@11.format(825316697)
[  86367.308]  -> wl_drm@11.format(842093913)
[  86367.331]  -> wl_drm@11.format(909202777)
[  86367.355]  -> wl_drm@11.format(875713881)
[  86367.379]  -> wl_drm@11.format(842094158)
[  86367.402]  -> wl_drm@11.format(909203022)
[  86367.427]  -> wl_drm@11.format(1448695129)
[  86367.452]  -> wl_drm@11.capabilities(1)
[  86367.644] wl_drm@11.authenticate(0)
[  86367.683]  -> wl_display@1.error(wl_drm@11, 0, "authenticate failed")

[AlanGriffiths]

And one more datapoint before EOD: unconfined Kodi from the 22.04 archive works fine with both Mesa versions on the server side.

@RAOF: ping - you might be able to offer some insight

[AlanGriffiths]

And the immediate reason Kodi from the 22.04 archive works would appear to be that wl_drm.authenticate(0) is not called (and therefore doesn't fail)

[AlanGriffiths]

Note that running mir-kiosk-kodi/frame on mesa-core20/stable I note we see:

libEGL warning: Wayland client render node authentication is unnecessary

Which strongly suggests that libEGL has changed the server behaviour. Formerly it "warned and allowed" the authenticate, now it simply fails to authenticate.

[AlanGriffiths]

So this is libva:

https://bugs.launchpad.net/ubuntu/+source/libva/+bug/1961484