[01:06] -GitHub[m]:#mir-server- **[MirServer/mir]** JamiKettunen opened [issue #2596](https://github.com/MirServer/mir/issues/2596): Tests always fail for non-Debian systems on package-abis due to missing debian/ dir... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/19c1fdef5b15439dabb7bae9c362dafd56f3321b)
[01:33] -GitHub[m]:#mir-server- **[MirServer/mir]** JamiKettunen opened [issue #2597](https://github.com/MirServer/mir/issues/2597): test_wayland_generator (expected.h vs generated.h) fails on Void Linux... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/a6455b5ce8ce83ebce92b1f009409349cf56451e)
[07:11] <Saviq> > Finally got a demo working of the CrashReporter
[07:11] <Saviq> Cool :)
[07:11] <Saviq> > I can't figure out how to ensure that it's done writing to the file before I call `exit()`.
[07:11] <Saviq> You have to exit it anyway, for the client to go away, no?
[07:12] <Saviq> grayson-g what's your plan wrt. delay before showing the diagnostic? (so that if the client restarts within a certain threshold, we don't show it)
[07:16] -GitHub[m]:#mir-server- **[MirServer/mir]** Saviq opened [issue #2598](https://github.com/MirServer/mir/issues/2598): Can't interact with window after move until the cursor is moved... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/58f037287910dfbd25c6238f59c40f6b1d413f41)
[07:17] -GitHub[m]:#mir-server- **[MirServer/mir]** Saviq added bug to [issue #2598](https://github.com/MirServer/mir/issues/2598): Can't interact with window after move until the cursor is moved
[11:33] -GitHub[m]:#mir-server- **[MirServer/mir]** dos1 opened [issue #2599](https://github.com/MirServer/mir/issues/2599): Support wp_viewporter... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/08f740b6d772cd94fce05ab0e74c6972217129cc)
[11:36] -GitHub[m]:#mir-server- **[MirServer/mir]** AlanGriffiths added enhancement to [issue #2599](https://github.com/MirServer/mir/issues/2599): Support wp_viewporter
[11:57] -GitHub[m]:#mir-server- **[MirServer/mir]** AlanGriffiths added bug to [issue #2597](https://github.com/MirServer/mir/issues/2597): test_wayland_generator (expected.h vs generated.h) fails on Void Linux
[13:03] <grayson-g[m]> Is the delay totally necessary? Now that we’re displaying a separate diagnostic file and not trailing a log, the screen won’t display until ‘diagnostic’ has been modified and the app stops displaying.
[13:04] <grayson-g[m]> * stops displaying. I’m not saying it’s unnecessary, I’m just questioning if it is. 
[13:13] <Saviq> I'm imaginging something else actually writing the diagnostic, like an on-boot script
[13:14] <Saviq> That the app crashes may well be outside of your "jurisdiction" (think wpe-webkit-mir-kiosk)
[13:15] <Saviq> The diagnostic is primarily useful if the app doesn't start or dies and doesn't come back up
[13:16] <Saviq> The idea is that the operator sets it up so the device displays e.g. a device ID and a support number
[13:18] <grayson-g[m]> Ok cool. That shouldn’t be a big modification. The CrashReporter wont draw unless ‘draws_crash = true’ so that should be a quick thing to set a user-defined delay on.
[13:18] <grayson-g[m]> grayson-g[m]: Oh wait I already have one dont i! Maybe I broke it and forgot to test it 😵‍💫
[13:26] <grayson-g[m]> > <@grayson-g:matrix.org> Ok cool. That shouldn’t be a big modification. The CrashReporter wont draw unless ‘draws_crash = true’ so that should be a quick thing to set a user-defined delay on.
[13:26] <grayson-g[m]>  * Oh wait I already have one dont i! Maybe I broke it and forgot to test it 😵‍💫
[13:26] <grayson-g[m]> EDIT: That's exactly what happened. Should be a quick fix. I'll just have `CrashReporter::Self` log when it's initialized, then if `draws_crash == true`, it'll either draw if enough time has passed or sleep until it has.  
[13:54] -GitHub[m]:#mir-server- **[MirServer/mir]** Saviq opened [issue #2600](https://github.com/MirServer/mir/issues/2600): Improve error reporting when display configuration won't do... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/b0c66ac4ede77033f56ccade2792199e5531417a)
[14:03] -GitHub[m]:#mir-server- **[MirServer/mir]** AlanGriffiths edited [issue #2597](https://github.com/MirServer/mir/issues/2597): test_wayland_generator fails (but not run by ptest target)
[14:32] -GitHub[m]:#mir-server- **[MirServer/mir]** AlanGriffiths opened [pull request #2601](https://github.com/MirServer/mir/pull/2601): Ensure test_wayland_generator runs (and fix test)
[14:46] -GitHub[m]:#mir-server- **[MirServer/mir]** bors[bot] merged [pull request #2562](https://github.com/MirServer/mir/pull/2562): Release 2.9.0
[14:48] -GitHub[m]:#mir-server- **[MirServer/mir]** AlanGriffiths edited [pull request #2601](https://github.com/MirServer/mir/pull/2601): Ensure test_wayland_generator runs (and fix test)
[16:16] <Saviq> G'night o/
[16:55] <grayson-g[m]> It's not the end of the world if I try to draw to the screen on a separate thread if drawing is under lock, right? I got a predicament where if I make Frame sleep until `diagnostic_sleep_time` has passed, it blocks and Frame cannot be closed until that threshold is met.
[16:55] <grayson-g[m]> The only solution I can come up with is if `diagnostic_sleep_time` has not passed, spin up a thread to sleep until the time has passed then call `on_draws_crash()`. Is there a better alternative that doesn't involve threading?
[16:58] <grayson-g[m]>  * It's not the end of the world if I try to draw to the screen on a separate thread if drawing is under lock, right? I got a predicament where if I make Frame sleep until `diagnostic_sleep_time` has passed, it blocks and Frame cannot be closed until that threshold is met. The advice I've been given is to only draw exclusively with the main thread.
[16:58] <grayson-g[m]> The only solution I can come up with is if `diagnostic_sleep_time` has not passed, spin up a thread to sleep until the time has passed then call `on_draws_crash()`. Is there a better alternative that doesn't involve threading? I can't think of any other solutions that wouldn't require a massive architecture change to avoid Frame locking up for a few seconds.
[17:24] <alan_g[m]> Spinning up a thread also has downsides - e.g. how to terminate it if the application closes. Mir needs a better solution: https://github.com/MirServer/mir/issues/2543
[17:25] <grayson-g[m]> alan_g[m]: Should I just push the blocking solution with a TODO this this should be readdressed with improvements to Mir?
[17:25] <alan_g[m]> Anyway, time for me to go also. o/
[18:17] <alan_g[m]> No, blocking is not a solution. Even on a new thread
[18:43] -GitHub[m]:#mir-server- **[MirServer/mir]** bors[bot] merged [pull request #2579](https://github.com/MirServer/mir/pull/2579): X11 platform: send discrete scroll
[19:20] -GitHub[m]:#mir-server- **[MirServer/mir]** wmww opened [pull request #2602](https://github.com/MirServer/mir/pull/2602): Simplify timestamp calibration
[19:20] -GitHub[m]:#mir-server-  
[19:20] -GitHub[m]:#mir-server- > Use the timestamp if it is reasonable, and use the measured current time otherwise. As discussed in #2591.
 "No, blocking is not a solution..." <- I've been looking at `boost::asio::deadline_timer` as a solution. My initial approach isn't working as `on_draws_crash()` doesn't seem to fit the requirements for the handler in `async_wait()`. Reading about this at the moment. Can't tell if I'm way off base in making a non-blocking timer.