[06:13] <duflu> RAOF: Can we kill max_simultaneous_outputs, or does it have a future?
[06:13] <RAOF> I believe I've already answered this :)
[06:13]  * duflu looks
[06:13] <RAOF> It's a *shrug*
[06:14] <RAOF> It's information that's easy to provide, but it's not easy for a client to use.
[06:14] <duflu> RAOF: I mean https://code.launchpad.net/~mir-team/mir/fix-1661163/+merge/316307
[06:15] <RAOF> Hm.
[06:16] <RAOF> The deprecation message is incorrect, but I'm not aghast at the function being deprecated.
[06:16] <duflu> I know, was just a suggestion
[06:16] <duflu> We could declare it deprecated and then decide to keep it
[06:54] <duflu> RAOF: OK then, a simpler question: Are 'cards' a dead concept?
[06:54] <RAOF> Yes
[06:54] <duflu> I thought so, but max_simultaneous_outputs depends on them
[06:54] <RAOF> In our current implementation, yes.
[06:54] <duflu> Then again, so does everything loosely
[06:56] <RAOF> Again, yes :)
[06:56] <RAOF> It's possible that cards will be exposed again in the client interface, but we've never ever exposed more than one.
[06:56] <RAOF> Which is why they're not useful.
[06:57] <RAOF> That said, prime support will suddenly mean that sometimes we *do* have more than one card.
[06:57] <RAOF> But the first go at that will not really expose that.
[06:59] <duflu> RAOF: Hmm.... seems my best option is to just improve that deprecation comment
[06:59] <duflu> Since the logic to implement it was deleted
[07:00] <RAOF> It'd be pretty easy to re-add that logic, but *shrug*.
[07:01] <duflu> RAOF: It was part of a larger code deletion (I just bisected it). Too hard
[07:01] <duflu> for now
[07:02] <RAOF> Oh, I mean you could easily re-add logic that would support it.
[07:04] <RAOF> But, again, shrug.
[07:04] <RAOF> Also, EOD!
[07:05] <duflu> Kay, bye
[10:33] <dandrader> AlbertA, around?
[10:35] <dandrader> alan_g, using the new "mir_window_spec_set_cursor_name() && mir_window_apply_spec()" API doesn't trigger mir::scene::SurfaceObserver::cursor_image_set_to as the deprecated API "mir_cursor_configuration_from_name() && mir_window_configure_cursor" does
[10:35] <dandrader> alan_g, What should I be listenting to on the server side now?
[10:37] <alan_g> dandrader: I would expect that to work. Possibly a Mir bug.
[10:38] <dandrader> alan_g, ok, will report then
[10:43] <dandrader> alan_g, https://bugs.launchpad.net/mir/+bug/1663197
[10:43] <alan_g> dandrader: ack
[14:33] <alan_g> A question to ponder: https://code.launchpad.net/~alan-griffiths/miral/miral-toolkit-dev/+merge/316827/comments/825816
[14:39] <elopio> kgunn_: AlbertA: hey, can you please check for my email in your inbox? I think you are sending me to the spam :'(
[14:56] <AlbertA> dandrader: here.. let me check the frontend
[14:56] <AlbertA> elopio: oh I was just waiting for kgunn to answer sorry :)
[15:07] <elopio> AlbertA: he seems to be missing in action. But anyway, the ideal was to have you both to talk about the work you have been doing.
[15:07] <elopio> AlbertA: can you join us on Friday next week?
[15:09] <AlbertA> elopio: I can , I believe kgunn_ is on vacation today
[15:09] <kgunn_> elopio: i'm here...busy
[15:09] <kgunn_> otp
[15:13] <kgunn_> ah...demos, thank you AlbertA
[15:29] <dandrader> AlbertA, turns out to be a bug in miral
[15:29] <dandrader> AlbertA, will try out your qtubuntu branch again once the fix is available
[15:30] <AlbertA> dandrader: cool thanks
[15:33] <elopio> AlbertA: awesome! I'll send you the invite, and more details next week.
[16:23] <alan_g> dandrader: confirmed a Mir bug - aiming to get fix into 26.1
[16:23] <dandrader> alan_g, ok