[01:24] -GitHub[m]:#mir-server- **[MirServer/mir]** RAOF opened [issue #2615](https://github.com/MirServer/mir/issues/2615): Mir semi-frequently dumps full output state for no obvious reason... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/0ce6155e7483cfb7cb177a9694d0b169a69e4602)
[08:33] -GitHub[m]:#mir-server- **[MirServer/mir]** AlanGriffiths drafted [pull request #2616](https://github.com/MirServer/mir/pull/2616): Avoid racy access to shm buffers
[08:34] <alan_g[m]> Saviq could you try ^ for your transparent buffers issue? (As I can't reproduce I need someone that can)
[08:37] <Saviq> Ofc. Will do
[09:51] <Saviq> alan_g RAOF (he/they) I'm having some input issues on latest Miriway. Doesn't seem to be your PR, as I experience the same on dev. Some input events seem to be lost. That includes keyboard and pointer. I'm on 22.10, so that may be a factor. Are you seeing this at all?
[09:51] <Saviq> s/your/above/
[09:52] <alan_g[m]> I'm on Mutter currently (Mir can't yet drive my DisplayLink dock)
[09:54] <Saviq> In other news, my DBus activation hack (re: `DISPLAY`) stopped working, as if the variable isn't yet set when `shell-components` are ran?
[09:54] <alan_g[m]> But I don't remember anything landing that might affect input
[09:55] <Saviq> I'll try `/release`. One more reason to have a Miriway snap to be able to roll back.
[09:56] <alan_g[m]> Just install the Mir stage snap and play with paths?
[09:56] <Saviq> That is an option indeed.
 "In other news, my DBus activatio..." <- alan_g would you have expected `DISPLAY` to always be set when running `shell-components`?
[10:01] <alan_g[m]> Saviq: If (and only if) Xwayland is available
[10:06] <Saviq> Right, but is there any race between actually starting Xwayland and setting the `DISPLAY` variable in time for `shell-components` to see it?
[10:06] <Saviq> I do have Xwayland, it starts, but we're setting empty `DISPLAY` through `dbus-update-activation-environment` :/
[10:08] <alan_g[m]> Actually, Xwayland is started "on demand". I'll check exactly when DISPLAY is selected...
 "I'll try `/release`. One more..." <- It's present on `/release`, too. So likely a `kinetic` issue. It's tricky to clock, because it could well be a PEBKAC, as it's missing characters, missed Alt+Tab or focus changes
[10:12] <Saviq> It's as if there's randomly a second when input isn't processed
[10:12] <Saviq> And depending on what you were doing, different symptoms present themselves.
[10:14] <Saviq> I vaguely associate it with switching focus or some time without input, after which this happens (but not immediately, either). Like, if I type a word, it's usually the second character that will be missed
[10:14] <Saviq> On attempted Alt+Tab, menu bars show up
[10:18] <alan_g[m]> DISPLAY is is selected during server "start", and the ConfigurationOption is processed after "init" and before "start", so I would expect it NEVER to be set
[10:21] <Saviq> I've filed https://github.com/Miriway/Miriway/issues/5 - maybe we should have `DISPLAY` before we launch any `shell-component`s... you could argue you shouldn't have X shell components, so another option is to explicitly set `DISPLAY` in DBus
 "I've filed https://github.com/..." <- I think we may need Mir changes to support fixing that efficiently. There's a MirAL option to process `ConfigurationOptions` before "init", but not after "start".
[10:30] <alan_g[m]> Actually: we have `MirRunner::add_start_callback()`, so we could do this in Miriway with a bit of "dancing".
[10:31] <Saviq> Right, parsing `ConfigurationOption`s is one thing, actually starting the shell components, another
[10:37] <Saviq> Too little time
[10:38] <Saviq> If I don't see it today, I'll switch to the older HW where I saw it more frequently
[10:39] <Saviq> How did you come up with the potentially relevant log message? From code analysis?
[15:49] <Saviq> alan_g all day today, couldn't see the flash. I'll try to work on my old laptop tomorrow, but so far so good
[15:54] <alan_g[m]> Saviq that's encouraging. (But not proof of course) I don't think the hack is quite right, but if it is working it shows we're looking in the right area
[15:55] <alan_g[m]> BTW I cooked up a Miriway fix for the DISPLAY environment
[16:41] -GitHub[m]:#mir-server- **[MirServer/mir]** bors[bot] merged [pull request #2606](https://github.com/MirServer/mir/pull/2606): Better grabbing popups
[16:41] -GitHub[m]:#mir-server- **[MirServer/mir]** bors[bot] closed [issue #2604](https://github.com/MirServer/mir/issues/2604): Popups dismissed by Mir when parent clicked
[16:56] <alan_g[m]> Saviq just wondering why `shell-component=dbus-update-activation-environment DISPLAY` (and, maybe, `WAYLAND_DISPLAY`) doesn't do the job?
[17:00] <Saviq> It may well do, I didn't RTFM
[17:11] <alan_g[m]> Anyway, it's goodbye from me...
[17:11] <Saviq> Me, too
[17:56] -GitHub[m]:#mir-server- **[MirServer/mir]** wmww drafted [pull request #2617](https://github.com/MirServer/mir/pull/2617): Ignore wl_pointer.set_cursor if incorrect serial is given
[17:56] -GitHub[m]:#mir-server-  
[17:56] -GitHub[m]:#mir-server- > Fixes #2532
[18:11] -GitHub[m]:#mir-server- **[MirServer/mir]** wmww marked [pull request #2617](https://github.com/MirServer/mir/pull/2617): Ignore wl_pointer.set_cursor if incorrect serial is given as ready for review
[18:19] -GitHub[m]:#mir-server- **[MirServer/mir]** wmww closed [issue #1793](https://github.com/MirServer/mir/issues/1793): When moving GTK apps, titlebar grab "slips" at start