[07:15] Dzień dobry ;) [07:57] \o Dobre rano [09:50] -GitHub[m]:#mir-server- **[MirServer/mir]** bors[bot] merged [pull request #2710](https://github.com/MirServer/mir/pull/2710): Improve logging by DisplayConfigurationReport [09:50] -GitHub[m]:#mir-server- **[MirServer/mir]** bors[bot] closed [issue #2615](https://github.com/MirServer/mir/issues/2615): Mir semi-frequently dumps full output state for no obvious reason [10:34] sophie https://meet.google.com/oof-hjna-cff [10:34] Be right there [10:37] -GitHub[m]:#mir-server- **[MirServer/mir]** Saviq assigned to [pull request #2710](https://github.com/MirServer/mir/pull/2710): Improve logging by DisplayConfigurationReport [10:37] -GitHub[m]:#mir-server- **[MirServer/mir]** Saviq assigned AlanGriffiths to [issue #2615](https://github.com/MirServer/mir/issues/2615): Mir semi-frequently dumps full output state for no obvious reason [11:46] alan_g sophie RFC: [11:46] One: I found only one client (TigerVNC, out of 4 others) that works with wayvnc's authentication / encryption mechanisms. Does it even make sense to expose it, or better to just lock it down to 127.0.0.1 and say that the user is responsible for protecting it (e.g. SSH tunnel)? [11:46] Second: "--gpu Enable features that need GPU", basically enables linux_dmabuf - could there be a reason to disable it? E.g. on some hardware? How should we expose it to users? `snap set ubuntu-frame-vnc dmabuf-acceleration=false`? [11:47] Third: wayvnc only (currently) streams one display at a time, `snap set ubuntu-frame-vnc output=OUT-3`? `=3`? [11:48] Can the client select the output? Or is it fixed by wayvnc? [11:49] Currently fixed by wayvnc on the command line [11:49] https://github.com/any1/wayvnc/issues/112 [11:52] > basically enables linux_dmabuf [11:52] That's for communucation with Frame, not the client I presume? We can just enable that [11:52] Correct, wayland side [11:52] Urgh, that doesn't look like it did when I wrote it [11:53] We can expose authentication if/when the situation improves [11:53] The network ought to be secured for other reasons [11:54] Yeah, and deprecate `out=` [11:54] *`output=` [11:54] Or simply fix it to 1 for the first release [11:57] That, too - and react to need. [11:57] OK that's a plan :) [12:02] How about snap channels, I'm thinking stable wayvnc and deps on beta, manually published to stable, but tips of wayvnc and deps on edge, built daily? This way we get early feedback when it breaks? [12:02] Could also be applied to -osk [12:07] I'm not super happy with these diagrams, but they're good enough to help me implement primary selection. Probably not worth turning into a blogpost https://docs.google.com/drawings/d/1SRkgVgwC20dBYph2hnPiU7NJfGzZG0FVn3GeCve0Gu8/edit?usp=sharing [14:22] OK so I'm trying this approach: [14:22] https://github.com/MirServer/ubuntu-frame-vnc/commit/3f866b4dd95f031319099b4fb6997182646b016c [14:22] `main` has the dependencies pinned, but pushing to `main` triggers this, which unpins them and pushes to `edge`. `main` builds to `beta`, `edge` builds to `edge`. This way we have cross-platform builds of both and will get notified when they fail. [14:23] Unfortunately have no trigger for when dependencies change, yet. [15:34] Can we not use C++20? Some of the build servers can't find `` [15:34] Likely not as long as we're stuck with 20.04 as our base [15:34] Mmm okay. Back to the drawing board. [15:35] Well. Unless. https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/ppa [15:36] It seems to become more and more annoying that we don't have a newer toolchain [15:37] gcc-10 is available in plain focal, too [15:37] If that'd be enough [15:37] It libstdc++ that's behind the standard [15:37] Just found RAOF (he/they)'s silly warning under a conditional `` include in `src/common/thread_pool_executor.cpp` :P [15:37] Then yeah, we'd need the toolchain bumped [15:37] Chris? Silly? Nevah. [15:39] Looks like that covers the necessary [15:39] Just move it to a "semaphore.h" header [16:42] Good night o/ [17:25] Dobranoc o/ [18:43] "Just move it to a "semaphore.h..." <- The only issue with this is I was using `try_aquire_for()` which was unimplemented, and to implement would need a non-blocking wait solution (unless I'm not thinking creatively enough 😉). [18:43] I went back to implementing this with a condition variable and using `wait_for()` on it instead to it doesn't hang. Local tests pass, waiting to see what CI thinks about it. [19:21] -GitHub[m]:#mir-server- **[MirServer/wlcs]** wmww opened [pull request #245](https://github.com/MirServer/wlcs/pull/245): Create surface in primary selection tests [19:21] -GitHub[m]:#mir-server- [19:21] -GitHub[m]:#mir-server- > Mir's primary selection implementation will not allow clients to paste when they do not have focus, so the tests fail without this. [19:28] WLCS CI having problems: https://github.com/MirServer/wlcs/pull/245 [19:31] Need to drop impish [19:34] -GitHub[m]:#mir-server- **[MirServer/wlcs]** Saviq opened [pull request #246](https://github.com/MirServer/wlcs/pull/246): ci: refresh Ubuntu [19:37] Man it's tricky from a phone, but I think it's good now ;) [19:38] Meh. Too fast, LXD images Mir there yet. Will drop impish only, first [19:42] Grr. [19:44] Ok just pushed to main, should be good now [19:45] -GitHub[m]:#mir-server- **[MirServer/wlcs]** Saviq reopened [pull request #245](https://github.com/MirServer/wlcs/pull/245): Create surface in primary selection tests [19:45] -GitHub[m]:#mir-server- **[MirServer/wlcs]** Saviq closed [pull request #245](https://github.com/MirServer/wlcs/pull/245): Create surface in primary selection tests [19:45] Kicked your pr to synchronize [19:50] -GitHub[m]:#mir-server- **[MirServer/mir]** wmww opened [pull request #2711](https://github.com/MirServer/mir/pull/2711): Implement wp_primary_selection_unstable_v1... (full message at ) [19:52] sophie FWIW within-app worked without your PR, too [19:52] ack [19:52] So it's more like "GTK doesn't seem to consistently work, period" [20:02] Yes. Copypasta from Firefox address bar. Yess. \o/ [20:03] But yeah, GTK seems no worky for middle click. [21:18] > <@grayson-g:matrix.org> The only issue with this is I was using `try_aquire_for()` which was unimplemented, and to implement would need a non-blocking wait solution (unless I'm not thinking creatively enough 😉). [21:18] > I went back to implementing this with a condition variable and using `wait_for()` on it instead to it doesn't hang. Local tests pass, waiting to see what CI thinks about it. [21:18] `try_acquire_for` should be easy enough to implement, I think? [22:00] "> <@grayson-g:matrix.org> The..." <- Just seeing this. If it sleeps when waiting to acquire, that would need to spin up another thread, right? Maybe I'm not conceptualizing correctly.