[01:40] <robert_ancell> Has anyone been looking into Freon on ChromeOS?
[02:05] <duflu> robert_ancell: Not as far as I know. Seems probably irrelevant. It's a very lean single "platform" implementation of what Mir's "Mesa" platform is.
[02:05] <duflu> ... which I'm working on making even faster
[02:06] <robert_ancell> duflu, I'm interested in what they did for input devices / access permission to the drm device etc
[02:07] <duflu> robert_ancell: Are we not going to do it the way we did for X11? Or searching for a better option?
[02:07] <robert_ancell> I'm just interested in their solution. I don't think it has any effect on us
[02:08] <duflu> robert_ancell: Also remember ChromeOS/Android != Ubuntu
[02:08] <robert_ancell> They have a very limited use case so they can drasticly simplify.
[02:08] <duflu> Whatever they use we might not have, and vice-versa
[02:08] <robert_ancell> I didn't make that connection at all...
[02:08] <duflu> robert_ancell: In the same way that Android kernel != Ubuntu kernel
[02:09] <robert_ancell> I'm pretty sure their kernel has nothing to do with the Android one
[02:10] <duflu> robert_ancell: No, but you're assuming it's closer to Ubuntu than the Android one is. It might be equally distant in new ways (tm)
[02:10] <robert_ancell> I haven't made that assumption either
[02:12] <duflu> robert_ancell: Suffice to say Mir already has code that replaces what Freon does. And that DRM platform in Mir we call "Mesa" is excitingly more mature and capable than Mir's Android platform
[02:13] <duflu> Although we're always working on improving performance
[09:23] <alan_g> alf_: duflu anpok_ - anyone else going to look over this? https://code.launchpad.net/~albaguirre/mir/fix-1427976-take2/+merge/252031
[09:24] <duflu> alan_g: If so then not today
[09:25] <alf_> alan_g: I will, in a bit
[10:12] <alan_g> greyback: thanks for confirming U8 does what I suspected.
[10:12] <greyback> np
[10:13] <greyback> giving input focus to somethign which isn't visible to the user is just wrong IMO
[10:15] <alan_g> Me too. But someone put in the effort to do it and the rest of us let it land.
[10:35] <duflu> greyback: I thought so too. But now come to think of it, that's useful. We can just get the Scene (SurfaceStack) to check if the focussed surface is visible() next time it does a frame. And if not visible by then, revert to previously focussed
[10:35] <duflu> Give the surface a frame to become visible and if it's fast enough, it gets focus.
[10:36] <duflu> Although there's also the cookie stuff ...
[10:36]  * duflu -> dinner
[10:36] <greyback> duflu: with unity8, the surface only appears in the SurfaceStack (equivalent) when it has drawn a frame
[10:36] <greyback> is a surface a surface if nothing has been drawn?
[10:36] <greyback> I think no
[10:36] <duflu> greyback: Right, but you need to know "preferred focus" which might be a surface not yet visible
[10:37]  * duflu -> dinner really
[10:37] <greyback> duflu: sure, but that's a focus decision, which is more likely related to surface being user-visible than being created
[10:37] <greyback> ah, he's gone
[10:41] <alan_g> There are also scenarios (like activating menus) where it isn't essential for the surface to paint for it to affect the processing of input. (But there are other ways to handle that.)
[10:42] <greyback> right
[17:24] <alan_g> alf_: you've tracked down a couple of these in the past. I must be missing something - have you time to help? https://code.launchpad.net/~alan-griffiths/mir/is-NullWindowManager-better-than-GenericShell/+merge/252147/comments/626462
[22:35] <racarr> InputDispatcher->InputSender port is mostly working...some race appearing where the finished signal isn't percolating properly and then delivery starts to slow down (timeouts eventually make it work)