[05:38] <Saviq> I think we primarily wanted to note why we think it's good to do. Like, it's not because apps can't do (fractional) scaling, but because it can be more efficient if the compositor did it. Still, IMO for _scaling_ there should be a different mechanism, where it's the compositor decides what to do, rather than app, in response to a scale it can't do
[05:40] <Saviq> Like, it may be better to scale at a higher integral value and then scale down - but it should be the compositor that decides. Maybe scaleb communicated to the app could be a list of preference? `[1.7, 2.0, 1.0]`
[08:30] -GitHub[m]:#mir-server- **[MirServer/mir]** Saviq unassigned RAOF from [issue #2599](https://github.com/MirServer/mir/issues/2599): Support wp_viewporter
[08:30] -GitHub[m]:#mir-server- **[MirServer/mir]** Saviq unassigned wmww from [issue #2599](https://github.com/MirServer/mir/issues/2599): Support wp_viewporter
[09:44] <alan_g[m]> Saviq did you find time to try #2684? Any impact on #2674?
[09:44] <Saviq> I was running it all day yesterday and I had zero similar issues
[09:47] <alan_g[m]> Good enough for me. (It is plausibly the same root cause)
[09:48] -GitHub[m]:#mir-server- **[MirServer/mir]** AlanGriffiths edited [pull request #2684](https://github.com/MirServer/mir/pull/2684): Deal with confused state of KMS outputs better
[09:57] <Saviq> alan_g to follow up from our chat yesterday, the behaviour to place fullscreen surfaces on empty displays, would you say that should go into `FrameWindowManagerPolicy`, or further up the inheritance chain?
[09:58] <Saviq> IOW: should it be a Frame behaviour, or a default one?
[10:02] <alan_g[m]> Same place as the existing "fullscreen" logic: Frame
[10:05] <alan_g[m]> Note that the "default" with Frame is "clone displays", so there needs to be some configuration before this logic activates
[10:06] <Saviq> Well, in our current version of "clone" it wouldn't be any worse, would it - it would either fill the display… or not, if they were of different sizes? ;)
[10:11] <alan_g[m]> Saviq I've done a pass over our issue labels (and deleted 7 of them) do you want to do any more before I mark it "done"?
[10:11] <Saviq> No, go for it
[10:13] <alan_g[m]> We also have the "daily" presentation to review... are you going to schedule something?
[10:14] <Saviq> That's "what do we want to do?", or at least these are a prerequisite
[10:19]  * Saviq uploaded an image: (1807KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/FDQkrbZjTGttYfVUJPXXxuZa/frame_2022-10-05T12%3A12%2B02%3A00_1.png >
[10:19]  * Saviq uploaded an image: (1821KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/TVFDzzRlJTqtmDifQuYWfwrT/frame_2022-10-05T12%3A13%2B02%3A00.png >
[10:19] <Saviq> I mean, the round-robin placement in case of cloning like that is not going to make this worse
[10:20] <Saviq> (the difference between those two is the order of displays)
[10:21] <Saviq> And after https://github.com/MirServer/mir/issues/2612 there would only effectively be one display? Or at least they would cover exactly the same geometry, so still, placement would be unaffected?
[10:30] <alan_g[m]> There's a debate to be had about what "clone" means for, for example, wl_output
[10:34] <Saviq> ➕1 on that
[13:17] <Saviq> alan_g you added a `wontfix` here: https://github.com/MirServer/mir/issues/1437
[13:17] <Saviq> Shall we close?
[13:20] <alan_g[m]> I think we've left issues open + "won't fix" as documentation that we know about them
[13:20] <Saviq> Uuh huh.
[16:12] -GitHub[m]:#mir-server- **[MirServer/mir]** bors[bot] merged [pull request #2682](https://github.com/MirServer/mir/pull/2682): XWayland: refactor state management
[16:17] <Saviq> It does crash on startup a bunch…
[16:17] <Saviq> Oooh a refresh of element-desktop (having [convinced it to run through Wayland](https://forum.snapcraft.io/t/call-for-testing-mattermost-desktop-5-1-0/30403/14)) makes it actually look normal on Wayland
[16:18] <Saviq> Though it breaks OSK it looks like 🤦
[16:56] <Saviq> G'nite o/
[17:11] <alan_g[m]> See you! o/
[17:15] -GitHub[m]:#mir-server- **[MirServer/mir]** wmww unassigned wmww from [issue #2583](https://github.com/MirServer/mir/issues/2583): Can't paste when copied from Firefox address bar or Thunderbird "copy link"
[17:15] -GitHub[m]:#mir-server- **[MirServer/mir]** wmww unassigned graysonguarino from [issue #2583](https://github.com/MirServer/mir/issues/2583): Can't paste when copied from Firefox address bar or Thunderbird "copy link"
[17:30] -GitHub[m]:#mir-server- **[MirServer/mir]** wmww removed wmww review required from [issue #2240](https://github.com/MirServer/mir/issues/2240): Interacting with server-side decorations does not dismiss popups
[17:30] -GitHub[m]:#mir-server- **[MirServer/mir]** wmww added wontfix to [issue #2240](https://github.com/MirServer/mir/issues/2240): Interacting with server-side decorations does not dismiss popups
[17:34] -GitHub[m]:#mir-server- **[MirServer/mir]** wmww removed wmww review required from [issue #2145](https://github.com/MirServer/mir/issues/2145): Support virtual keyboard modifiers
[18:37] -GitHub[m]:#mir-server- **[MirServer/mir]** wmww closed [issue #1689](https://github.com/MirServer/mir/issues/1689): Wayland globals removed on wrong thread
[18:37] -GitHub[m]:#mir-server- **[MirServer/mir]** wmww removed wmww review required from [issue #1689](https://github.com/MirServer/mir/issues/1689): Wayland globals removed on wrong thread
[18:37] <sophie-w> RAOF (he/they): we call `allocator->unbind_display(display.get());` in `~WaylandConnector()` before joining the Wayland thread, is that safe to do when not on the Wayland thread?
[18:47] -GitHub[m]:#mir-server- **[MirServer/mir]** wmww opened [pull request #2688](https://github.com/MirServer/mir/pull/2688): Close all Wayland clients on server stop
[18:47] -GitHub[m]:#mir-server-  
[18:47] -GitHub[m]:#mir-server- > By closing clients explicitly instead of waiting for the destruction of the display to do it, clients do not see all globals disappear (which they may not be designed to handle)
[18:51] <grayson-g[m]> Frame Diagnostic documentation is (now up)[https://mir-server.io/docs/ubuntu-frame-diagnostic-documentation]. 
[18:51] <grayson-g[m]> A couple things:
[18:51] <grayson-g[m]> 1. Are we going to add beta configuration options to the reference?
[18:51] <grayson-g[m]> 2. I have this listed under "Reference" because it's based off of the OSK Documentation by @wmww. Should we move both of these into "How-to Guides" or leave them there?
[18:51] <grayson-g[m]>  * Frame Diagnostic documentation is [now up]\(https://mir-server.io/docs/ubuntu-frame-diagnostic-documentation\).
[18:51] <grayson-g[m]> A couple things:
[18:51] <grayson-g[m]> 1. Are we going to add beta configuration options to the reference?
[18:51] <grayson-g[m]> 2. I have this listed under "Reference" because it's based off of the OSK Documentation by @wmww. Should we move both of these into "How-to Guides" or leave them there?
[18:51] <grayson-g[m]>  * Frame Diagnostic documentation is [now up](https://mir-server.io/docs/ubuntu-frame-diagnostic-documentation).
[18:51] <grayson-g[m]> A couple things:
[18:51] <grayson-g[m]> 1. Are we going to add beta configuration options to the reference?
[18:51] <grayson-g[m]> 2. I have this listed under "Reference" because it's based off of the OSK Documentation by @wmww. Should we move both of these into "How-to Guides" or leave them there?
[21:30] -GitHub[m]:#mir-server- **[MirServer/ubuntu-frame]** graysonguarino drafted [pull request #89](https://github.com/MirServer/ubuntu-frame/pull/89): Add Frame Diagnostic delay... (full message at <https://libera.ems.host/_matrix/media/r0/download/libera.chat/af8b8ecaa2a40e3de752755ee210afbbdca58aa3>)