[05:00] <RAOF> Oh.
[05:00] <RAOF> / TODO support surface modifications
[05:01] <RAOF> Well, that's why m_surface->generate_renderables only ever returns one renderable, then.
[05:10] <RAOF> We should be handling set_streams calls before handing the request on to the shell.
[05:11] <RAOF> Yeeees!
[05:11] <RAOF> I win the subsurface award!
[05:17] <RAOF> Hm.
[05:17] <RAOF> Positioning is not quite right.
[05:17] <RAOF> SHIP IT ANYWAY!
[09:48] <greyback_> alan_g: hey, I was porting qtmir to the WindowManagement API (removing SessionListener) last night, and noticed that the WM has no notion of prompt sessions. Is that intentional?
[09:49] <greyback_> also, are you planning on removing mir::shell::Shell, as it duplicates much of WindowManager
[09:50] <alan_g> greyback_: I've "not needed" prompt sessions for any of the window management work I've done in Mir (yet)
[09:50] <alan_g> I've shown you this before: https://code.launchpad.net/~alan-griffiths/qtmir/window-management/+merge/274241
[09:51] <alan_g> It's been waiting on the simpler stuff to land
[09:52] <greyback_> alan_g: yep, you have. I just wanted to remove SessionListener and make more use of WM. Hopefully doesn't conflict too much
[09:54] <alan_g> greyback_: sure, all part of the same migration. are prompt sessions a blocker?
[09:54] <greyback_> alan_g: not at all. Just curious about the direction
[09:56] <alan_g> Well, for direction, I'd like to "internalize" Shell and "publish" BasicWindowManager - but the latter needs more work.
[09:57] <greyback_> ok
[11:17] <alan_g> greyback_: any more thoughts? https://code.launchpad.net/~alan-griffiths/qtmir/test-harness-for-MirWindowManager/+merge/274221
[11:18] <greyback_> alan_g: I don't think I had.
[11:19] <greyback_> approved
[11:25] <alan_g> thanks
[13:48]  * alan_g wishes he could mount an sd card with a useful filesystem
[14:04] <anpok> vogons: should we use the dso versioning guide also for loadable modules?
[14:05] <anpok> ... modules as in platforms.. /me doesnt see the need as the most part of the abi is not inside the set of symbols.. but the vtables..
[14:07] <alan_g> anpok: There's clearly a need for some versioning. I've not thought about whether the guide covers it.
[14:09] <anpok> i have to bump input platform abi right now.. so I would have to either go to '4' or 0.18.0
[14:12]  * alan_g decides to read what the guide says today....
[14:12] <anpok> :)
[14:12] <popey> robert_ancell: bug 1421575
[14:12] <ubot5`> bug 1421575 in xserver-xorg-video-intel (Ubuntu) "Desktop corruption when changing monitor config" [High,Triaged] https://launchpad.net/bugs/1421575
[14:15] <alan_g> anpok: so your only question is about "_4" vs "_0.18"?
[14:16] <anpok> yes
[14:17] <alan_g> "_0.18" makes sense to me
[14:17] <anpok> i mean the motivation for that naming for client comman and server .. and platform dso versioning does not seem to apply here. So I wasnt sure to use that naming for platforms
[14:17] <anpok> *common
[14:18] <alan_g> Well, the argument that having a name related to the release is easier to get right still applies
[14:19] <anpok> for the package and shared library name.. yes
[14:27] <alan_g> anpok: It would be more consistent with "horizontal_scroll_scale" to have "cursor_acceleration_bias".
[14:28] <anpok> right
[14:36] <alan_g> anpok: As it was merged and reverted you need to rebase this for it to have any effect: lp:~andreas-pokorny/mir/load-all-supported-input-platforms
[14:36] <anpok> oh right
[16:00] <alan_g> alf: have you looked into lp:1502782 at all?
[16:13] <alf> alan_g: no