[07:54] <Saviq> OK so XKB_CONFIG_ROOT is ignored. Because why not.
[08:00] <Saviq> > Note: Where libxkbcommon runs in a privileged context, only the system (datadir) path is available.
[08:01]  * alan_g[m] wonders which context Saviq is in
[08:03] <Saviq> Xwayland, it's dying because it can't see /usr/share/X11/xkb, because it ignores $XKB_CONFIG_ROOT
[08:07] <Saviq> Wonder what "a privileged context" is.
[08:14] -GitHub[m]:#mir-server- **[MirServer/mir]** Saviq transferred [issue #2885](https://github.com/MirServer/mir/issues/2885): core22: XWayland tests failing to start
[08:38] <alan_g[m]> "a privileged context" is probably user 0
[08:38] <Saviq> Don't think so, or at least that's not what I'm experiencing
[08:39] <Saviq> It may be that when running as an X server, that's privileged (I suppose…)
[08:39] <Saviq> Didn't find confirmation in code yet
[08:39] <alan_g[m]> Ah, true.
[08:39] <alan_g[m]> Anyway I think we need this too: https://github.com/MirServer/mir-test-tools/pull/62
[08:39] <Saviq> Yup, will get to it today
[09:08] -GitHub[m]:#mir-server- **[MirServer/mir]** Saviq opened [issue #2887](https://github.com/MirServer/mir/issues/2887): "Mir internal error processing create_buffer_eglstream_resource request" with GLMark2Xwayland.windowed on eglstream... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/4434b67834133a4a2d1149f11e2f6b1588199702>)
[10:13] -GitHub[m]:#mir-server- **[MirServer/mir]** Saviq edited [issue #2462](https://github.com/MirServer/mir/issues/2462): Nested on Nvidia/eglstream doesn't work
[11:08] -GitHub[m]:#mir-server- **[MirServer/mir]** AlanGriffiths opened [issue #2888](https://github.com/MirServer/mir/issues/2888): Unclean interface: scene::Session::create_surface() takes Wayland specific types... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/74c9aad123f078d1fb19f37a4ab42064a89347e4>)
[11:25] <alan_g[m]> Saviq, isn't it about time for some reviews on your store requests?
[11:26] <Saviq> Yeah am looking for someone to bribe with 🍰
[11:45] <alan_g[m]> I think you misspoke: "Miriway itself needs to be confined" -> unconfined
[11:46] <Saviq> D'oh.
[11:46] <Saviq> There. Fixeded.
[11:52] <alan_g[m]> I have another architecture as a fallback - put launcher & terminal (+ ...) as apps in a classic snap and use desktop-launch to start them. Then the miriway-shell component could be confined.
[12:41] <Saviq> alan_g we should have a writable content interface for `frame.display-layout`, shouldn't we?
[12:59] <alan_g[m]> We don't (first I heard of that idea). We do have snap set display-layout=foo
[13:00] <Saviq> Well, yes, but you can't do that from a confined snap
[13:02] <alan_g[m]> True, we haven't decided mechanisms to support that. (DIscussions have included bespoke Wayland extension & dbus)
[13:03] <alan_g[m]> I'm not saying I'm against. Just that we've not got there yet
[13:03] <Saviq> I think I'd go for the simplest - just like we did for the diagnostic
[13:04] <Saviq> Like, this is not meant to be a generic mechanism for clients requesting screen settings
[13:04] <Saviq> Since .display is separate, just letting another snap toggle the layout would IMO be appropriate
[13:04] <alan_g[m]> Maybe we should just have the one content interface, with multiple files?
[13:04] <Saviq> That'd be preferable for sure
[19:19] <Saviq> RAOF (he/they) found a hybrid system in the lab:... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/d397bf88f85b8e1c967ca36737fc1dc7e286dca6>)