[00:41] <sophie-w> Spent last couple days on remote desktop. I switched to Arch for remote desktop testing, which lets me both install and build from source the latest stuff more easily. I've confirmed that gnome-remote-desktop does work with headless mutter, but not Sway + xdg-desktop-portal-wlr. This seems to be because Gnome implements `org.gnome.Mutter.ScreenCast` instead of the generic `org.freedesktop.portal.ScreenCast`. I think the latter is implemented
[00:41] <sophie-w> as a wrapper over the former on GNOME, but xdg-desktop-portal-wlr only implements the latter, and gnome-remote-desktop only uses the former. They look similar, so there are a number of options. For now I'm trying to modify gnome-remote-desktop to work.
[00:42] <sophie-w> Even with libvnc/librdp broken out, gnome-remote-desktop is still complex enough that I think our best bet of making a good experience is to either use it, or fork it. I think trying to build something from scratch would be a big time sink.
[07:37] <RAOF> Hm.
[07:38] <RAOF> My code breaks `renderer.set_viewport(area)` for `area != DisplayBuffer.view_area()`
[07:39] <RAOF> On the other hand, we only ever *call* `renderer.set_viewport(db.view_area())`.
[07:43] <RAOF> Hm. And under what circumstances would you actually *want* to call with `area != db.view_area()`?
[08:00] <alan_g[m]> I'm lacking context, but damage repainting? Partial screen capture?
[08:04] <RAOF> The result of calling `set_viewport` with an area not equal to the output dimensions is that your rendering is no longer 1:1 onscreen.
[08:04] <Saviq> Zoom?
[08:05] <RAOF> Yeah, it'd be one way of doing that.
[08:05] <RAOF> Iâ€¦ think.
[08:35] <alan_g[m]> OTOH, the only place we _currently_ use `set_viewport()` is in `DefaultDisplayBufferCompositor::composite()` where `area` is taken from `display_buffer.view_area()`
[08:36] <alan_g[m]> Oh, and in the `mrg::Renderer` constructor, where it does the same
 "OTOH, the only place we _current..." <- Right. I was wondering whether I should
[09:13] <RAOF> * Break the `!view_area` case, and remove the tests,
[09:13] <RAOF> * Fix the `!view_area` case, or
[09:13] <RAOF> * Entirely remove the `set_viewport` API, as there's only one correct value to pass in
[09:14] <RAOF> * Right. I was wondering whether I should:
[09:14] <RAOF> * Break the `!view_area` case, and remove the tests,
[09:14] <RAOF> * Fix the `!view_area` case, or
[09:14] <RAOF> * Entirely remove the `set_viewport` API, as there's only one correct value to pass in
[09:14] <RAOF> * Right. I was wondering whether I should:
[09:14] <RAOF> * Break the `!view_area` case, and remove the tests,
[09:14] <RAOF> * Fix the `!view_area` case, or
[09:14] <RAOF> * Entirely remove the `set_viewport` API, as there's only one correct value to pass in
[09:14] <RAOF> * Right. I was wondering whether I should:
[09:14] <RAOF>  * Break the `!view_area` case, and remove the tests,
[09:14] <RAOF>  * Fix the `!view_area` case, or
[09:14] <RAOF>  * Entirely remove the `set_viewport` API, as there's only one correct value to pass in
[09:19] <Saviq> IMO option 1 is bad, recipe for falling into a pothole later on
[09:19] <Saviq> And since we can't find a use case for option 2 -- option 3 seems legit?
[09:20] <alan_g[m]> I'm tempted by 3, but would want to understand why the API is there first
[09:22] <alan_g[m]> Was it used by U8 or the "testing server"? And how?
[09:22] <alan_g[m]> WIll poke around in a bit...
[10:41] <alan_g[m]> OK, so far as I can tell the only use was in `DemoCompositor` (which used it for zoom)
[10:41] <alan_g[m]> So, I'm good with 3
[10:42] <alan_g[m]> alan_g[m]: https://github.com/MirServer/mir/commit/f05f4908d22531f2fbdb09ea7135b6ac1eae349f
[11:11] -GitHub[m]:#mir-server- **[MirServer/mir]** AlanGriffiths added Needs Info to [issue #2463](https://github.com/MirServer/mir/issues/2463): Some touch events are not being fired on Ubuntu-Core
[12:17] -GitHub[m]:#mir-server- **[MirServer/mir]** Saviq opened [pull request #2464](https://github.com/MirServer/mir/pull/2464): performance_test: record renderer and mode
[14:07] <Saviq> alan_g so another approach I was considering was a MultiLogger that you'd register one or more loggers with, is that what you had in mind?
[14:08] <Saviq> I suppose I went for smaller impact on public API again, but concede it's not as clear
[14:08] <alan_g[m]> Yes, that's [composite pattern](https://en.wikipedia.org/wiki/Composite_pattern)
[14:09] <alan_g[m]> (And I'd make it zero or more, not one or more)
[14:09] <Saviq> Right right, just you would rarelyâ€¦ owait, that's NullLogger :_
[14:13] <Saviq> alan_g as for the `unique_ptr<ofstream>`, it was for differentiating between the first time streaming failed (when I printed the error) and subsequent ones (when I wanted to stay silent)
[14:14] <Saviq> But with the composite pattern that will go away since the MultiLogger can drop the failing logger altogether
[14:14] <alan_g[m]> Wouldn't a `bool reported_bad_output{false}` express that better?
[14:16] <Saviq> That's what peer reviews are for ;P Thanks!
[14:18] <alan_g[m]> That's what I'm here for. ðŸ˜€
[14:21] <Saviq> Another thing I was considering we could do on the tail of that is to `EXPECT_EQ` renderers and modes (where fullscreen) through the chain of compositors.
[14:21] <Saviq> But wasn't sure if really worth itâ€¦
[14:22] <alan_g[m]> Definitely not worth adding to the first PR
[14:27] -GitHub[m]:#mir-server- **[MirServer/mir]** graysonguarino closed [issue #2457](https://github.com/MirServer/mir/issues/2457): Wayland platform display configuration racy
[14:29] <grayson-g[m]> alan_g: Is there an issue my time would best be spent looking at today? I'm not sure what the status is on the multitouch issue. If nothing directly with Mir, is there anything I should be researching?
[14:34] <alan_g[m]> grayson-g do you think there's enough done on the multitouch filtering? I'm a bit nervous that the special treatment of 0,0 gives us an explosion of test cases. (But didn't look too far into that)
[14:36] <grayson-g[m]> alan_g[m]: It seems like the two cases, multiple touches in the same frame at 0,0 and repeated down states not being double notified are handled. I can try to think of anything else worth being tested on it.
[14:36] <grayson-g[m]> s/handled/being properly filtered/
[14:37] <alan_g[m]> Could you run through all the tests of that code and see if they actually test that up, down and change events arrive as expected. I saw some tests that just checked that some events happened. I'm mostly concerned that the internal state (contact is down) ties up with the created events.
[14:38] <alan_g[m]> The other thing I noticed is that the event matchers are really poor at reporting what doesn't match. That would be worth improving
[14:39] <grayson-g[m]> alan_g[m]: By event matchers, are you referring to the logic that does the filtering? Are you saying to `mir::log_info()` the cases that filtering is occurring?
[14:40] <alan_g[m]> grayson-g[m]: No, `MATCHER(KeyDownEvent, "")` etc
[14:41] <alan_g[m]> I will try to find examples that provide output...
[14:49] <alan_g[m]> ...huh! I though we had some. (Maybe they were deleted with dead code.) The best I've found is `InputConfigElementsMatcher`
[14:50] <alan_g[m]> Looks a bit messy writing them like that. Maybe worth checking googletest docs to see if there is a better way
[14:52] <alan_g[m]> NB this would be a separate excercise to the filtering PR, but would aim to improve the reporting when tests fail
 "I will try to find examples that..." <- Here's a hacked up example:
[16:22] <alan_g[m]> MATCHER(KeyDownEvent, "")... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/5e76ee224d28e570aac98e7e507a69c337a308d4)
[16:23] <grayson-g[m]> > <@alan_g:matrix.org> MATCHER(KeyDownEvent, "")... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/30a733c0ba9550d29d30fc53776a0bfcd000c4ef)
[16:28] <alan_g[m]> It is back! (But with Polish in the footer): https://mir-server.io/doc/
[16:36] <Saviq> D'oh.
[17:03] <Saviq> Good weekend, all o/
[17:04] <sophie-w> Good weekend!
[17:05] <alan_g[m]> ðŸ‘‹
[17:06] -GitHub[m]:#mir-server- **[MirServer/wlcs]** AlanGriffiths closed [issue #24](https://github.com/MirServer/wlcs/issues/24): unknown file: Failure C++ exception with description "Failed to add signal write fd. Have you created too many main loops?" thrown in SetUp().
[17:08] <Saviq> > **[MirServer/wlcs]** AlanGriffiths closed [issue #24](https://github.com/MirServer/wlcs/issues/24): unknown file: Failure C++ exception with description "Failed to add signal write fd. Have you created too many main loops?" thrown in SetUp().
[17:08] <Saviq> _How_ did you arrive there? :D
[22:47] <sophie-w> D-Bus is... confusing