[08:19] -GitHub[m]:#mir-server- **[MirServer/mir]** AlanGriffiths added bug to [issue #2465](https://github.com/MirServer/mir/issues/2465): ABI breakage of libmircore.so.1 with v2.8.0 vs v1.8.2 [09:07] -GitHub[m]:#mir-server- **[MirServer/mir]** AlanGriffiths drafted [pull request #2466](https://github.com/MirServer/mir/pull/2466): Bump mircore soname [09:07] -GitHub[m]:#mir-server- [09:07] -GitHub[m]:#mir-server- > Fixes: #2465 [09:12] Good morning o/ [09:13] Saviq: Good morning, how are you this week? [09:14] All good, thanks. Weekend too short :) [09:14] You? [09:14] Much the same. Too much of it spent weeding [09:24] -GitHub[m]:#mir-server- **[MirServer/mir]** frank-dspeed opened [issue #2467](https://github.com/MirServer/mir/issues/2467): Bug: Starting mirserver with nvidia-470... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/f3d8ec881d5c765906a19c83e19a8bf4f3fabcaa) [09:29] -GitHub[m]:#mir-server- **[MirServer/mir]** frank-dspeed edited [issue #2467](https://github.com/MirServer/mir/issues/2467): Bug: Starting mirserver with nvidia-470 [09:32] -GitHub[m]:#mir-server- **[MirServer/mir]** frank-dspeed edited [issue #2467](https://github.com/MirServer/mir/issues/2467): Bug: Starting mirserver with nvidia-470 maybe also 515 as it turns out [09:32] -GitHub[m]:#mir-server- **[MirServer/mir]** frank-dspeed edited [issue #2467](https://github.com/MirServer/mir/issues/2467): Bug: Starting mirserver with nvidia-470 even 515 [10:43] Huh, why do we have a rebuild? [10:43] $ diff -qr /snap/ubuntu-frame_beta/2* [10:43] Files /snap/ubuntu-frame_beta/2294/meta/snap.yaml and /snap/ubuntu-frame_beta/2561/meta/snap.yaml differ [10:43] Files /snap/ubuntu-frame_beta/2294/snap/manifest.yaml and /snap/ubuntu-frame_beta/2561/snap/manifest.yaml differ [10:44] > Huh, why do we have a rebuild?... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/451addcc77702b78a2d1c176d42daa58fc25ab2c) [10:45] I refreshed the help text [10:47] Saviq: Ah, right [11:47] alan_g thanks for the review, will fix. I'm going to need a bit of assistance please: [11:47] https://github.com/MirServer/mir/pull/2464/files#diff-c5e7495f2b7719ad72c650438650bd4723471bf7034b7a4b2b9aea3e0de2b37bR66-R71 [11:48] I'm having trouble understanding how does `StreamLogger::out` end up pointing to nullptr… [11:58] It isn't, you are reusing the out parameter after moving from it [12:09] Oh so it's a name clash :duh: [12:45] alan_g did you wanted to add something here? [12:45] https://github.com/MirServer/mir/pull/2464/files/5191eb0ac8ac6d9e8cc1f5a9f3e5fbc82e29ae32#r895545035 [12:45] *want [13:02] "alan_g did you wanted to add..." <- https://github.com/MirServer/mir/pull/2464/files/5191eb0ac8ac6d9e8cc1f5a9f3e5fbc82e29ae32#r895545035 [13:02] Well, you said it was going away and it didn't [13:11] alan_g I'm likely, again, missing something obvious here, but I wanted for the stream to be owned by the StreamLogger, since it outlives where the stream is opened. What is the better choice here? [13:12] Just moving the fstream? [13:12] -GitHub[m]:#mir-server- **[MirServer/mir]** frank-dspeed edited [issue #2467](https://github.com/MirServer/mir/issues/2467): Proposal: Better handling for ubuntu with nativ drivers from nvidia 470 even 515 [13:13] Oh. Duh. [13:15] -GitHub[m]:#mir-server- **[MirServer/mir]** AlanGriffiths edited [issue #2467](https://github.com/MirServer/mir/issues/2467): Auto-selection of X11 platforms fails with Nvidia drivers (470 and 515) [13:30] alan_g ah but that would mean FileLogger can _only_ do `ofstream`s, and as is it can do other streams as well, WDYT? [13:30] (why I now renamed it `StreamLogger`…) [13:33] I can imagine using, say, `stringstream` during testing, so there is some arguement for generalizing it. But not sure it justifies the complexity [15:03] -GitHub[m]:#mir-server- **[MirServer/mir]** AlanGriffiths marked [pull request #2466](https://github.com/MirServer/mir/pull/2466): Bump mircore soname as ready for review [15:09] alan_g unless you have something in mind lined up for grayson-g, I thought he could start looking at the status screen feature for Frame? [15:10] (after he's done with the touch filters) [15:10] I was thinking he should progress some of the documentation work we have piled up. (With a bit more guidance) [15:12] FWIW I don't want for that to take more than a day of anyone's week, as that can get tiring quickly, and should be a team job [15:13] I will get the meta-documentation going as my next TODO so everyone can pitch in [15:32] Going to move my remote assistance efforts from gnome-remote-desktop to wayvnc: https://github.com/any1/wayvnc [15:32] Not as featureful as GRD (doesn't support RDP, probably other stuff as well), but might be simpler to get running [15:35] So no dice with GRD? [15:36] It does look like there will be little wayvnc-specific work here, so we could move to a more featureful solution in the future [15:37] RDP, vaapi/vdpau come to mind as things we should think of [15:38] GRD isn't unworkable, but I think it might be a pretty big sink of time. [15:39] And I'm starting to rethink my stance that we shouldn't build our own [15:39] And sounds like a lot of the plumbing is GNOME-specific [15:39] But if there's something else that can work for us then we should try that first [15:39] I'm for gettings something simple to work to gain experience if nothing else [15:39] Agreed [15:40] GRD might actually be the most generic thing, since some of the work will be hooking into D-Bus interfaces that either are or at least are similar to the XDG desktop portal ones [15:43] What would be ideal (from a certain perspective) is to build a remote desktop server that uses only the generic XDG desktop portal interfaces, and then have those interfaces implemented for Mir in a way that also works on Sway/wlroots, because then the the same remote desktop server would work everywhere [15:44] The downside of that though is that implementing the D-Bus interfaces and implementing a remote desktop server using them might be quite a bit more work than just implementing a remote desktop server that consumes Wayland protocols. [15:45] And add a lot more complexity to the system. With the latter approach (which is I think what waypipe uses), D-Bus need not be involved at all. [15:51] We will need the portals in the long run so we can support screen casting/recording from desktop apps - but +1 on starting simple [15:52] alan_g re: `std::unique_ptr`, that's unhappy b/c `mir::logging::~Logger` is protected. Think it worth reworking that, or better sticking with `std::shared_ptr`? [15:53] Saviq: Well the XDG ScreenCast portal already works with xdg-desktop-portal-wlr [15:53] Saviq: That's a pain (the deleter being part of the pointer type). [15:54] sophie-w: (Firefox screen sharing works) [15:55] alan_g[m]: The alternative is to make `~Logger` public. I see no downside [16:01] Out of the box wayvnc works with Mir for a single frame, then stalls (`--disable-input` option is needed, since we don't support virtual pointer yet) [16:13] "The alternative is to make `~..." <- Yeah, that decision comes from pre-c++-11 days, about time to review it ;) [16:35] OK, good night for today o/ [16:55] -GitHub[m]:#mir-server- **[MirServer/mir]** AlanGriffiths closed [issue #1316](https://github.com/MirServer/mir/issues/1316): Firefox/Wayland flickers badly [17:03] And goodnight from me 👋 [18:12] -GitHub[m]:#mir-server- **[MirServer/mir]** wmww opened [pull request #2468](https://github.com/MirServer/mir/pull/2468): Add --add-all-wayland-extensions option [18:12] -GitHub[m]:#mir-server- [18:12] -GitHub[m]:#mir-server- > Convenient for development and debugging, as well as running in contexts where all clients are fully trusted [19:36] -GitHub[m]:#mir-server- **[MirServer/mir]** wmww opened [pull request #2469](https://github.com/MirServer/mir/pull/2469): wlr-screencopy-v: send .damage event when required [19:36] -GitHub[m]:#mir-server- [19:36] -GitHub[m]:#mir-server- > The `.copy_with_damage` request still isn't implemented fully (it does not wait for there to be damage or report the damaged area of the screen), but with this change it works well enough for wayvnc to work (albeit with higher than needed CPU load)