[10:53] <alan_g> alf_: not urgent, but have a look when ready... kdub's fiddling with the cross-build script is finally working on CI for https://code.launchpad.net/~alan-griffiths/mir/add-glog-logging/+merge/153568
[11:00] <alf_> alan_g: great, I will take a look when I am done (or too tired to continue) chasing shared_ptr :/
[11:01] <alan_g> alf_: if you get stale with it let me know and I'll take a look.
[11:02] <alf_> alan_g: thanks, I will let you know
[12:32] <alf_> alan_g: This is what I found is going on http://people.canonical.com/~afrantzis/mir-cyclic-dependency.dia
[12:32] <alf_> alan_g: I have a solution but I need to check it a bit more (after lunch)
[12:33] <alan_g> alf_: I'll try to understand and be ready to review ;)
[12:34] <alf_> alan_g: in short, we need to ensure that InputManager drops its reference to ApplicationSession when the session is closed
[12:34] <alf_> alan_g: but perhaps this is an indication of deeper design issue
[12:37] <alan_g> alf_: That is my reaction too - but I need to think it through
[12:38]  * alan_g feels there's a role (and associated class) missing, but isn't quite sure what the role is.
[12:44] <kgunn> alf_: are you viewing the diagram via firefox? or some other app? (giving me fits)
[12:45] <alf_> kgunn: I am using dia
[12:45] <kgunn> thanks
[12:49] <alf_> kgunn: in case dia crashes for you, see https://bugs.launchpad.net/ubuntu/+source/dia/+bug/1102960
[12:49] <alf_> kgunn: there is a workaround in comment #11
[12:53] <alan_g> alf_: I'm pretty sure that InputManager isn't an InputFocusSelector (what it needs is the current focus, not to be informed of focus changes). Also the InputFocusSelector interface is broken (I'm sure I mentioned this during review).
[12:58] <alan_g> The missing role is an object that provides the InputManager with the current focus and monitors session and surface events within the shell.
[13:01] <alan_g> Rephrasing: The missing role is an object that the InputManager uses to dispatch events (to the current focus) and monitors session and surface events within the shell.
[13:02] <alan_g> alf_: ^ is that your thinking too?
[14:22] <alf_> alan_g: So in essence reverse the Input - Shell dependency and break the cycle?
[14:25] <alan_g> alf_: Well, it could be considered like that, but it is motivated by separating concerns.
[15:09] <hikiko> kdub, ping :)
[15:09] <kdub> hello hikiko
[15:20] <alf_> alan_g: So you were thinking something like input::Shell { send_input_event(...) = 0; set_input_focus_changed_callback(...) = 0;} input::InputManager(input::Shell) ?
[15:23] <alan_g> alf_: Something like shell::SessionInputFilter : input::InputFilter, shell::FocusMonitor
[15:31] <alf_> alan_g: I am trying to understand how each option will help us solve the dependency problem
[15:33] <alf_> alan_g: why does shell need shell::FocusMonitor?
[15:35] <alan_g> alf_: Well, maybe the names is bad. But as I see it the shell needs to notify *something* about changes to the focussed session and/or surface
[15:37] <alf_> alan_g: shouldn't that be expressed in terms of the "something", though?
[15:37] <alan_g> I called *something* "shell::FocusMonitor" because it is an interface the shell needs
[15:45] <hikiko> hello
[15:46] <hikiko> one question :)
[15:46] <alf_> hikiko: sure
[15:46] <hikiko> gbm can be used under X?
[15:46] <hikiko> I thought no but I am not sure :)
[15:46] <kdub> alf_, specifically, the scenario hikiko is wondering about is
[15:47] <kdub> an x server that owns the framebuffer, and mir operating as an x client (using sdl )
[15:47] <kdub> and she wants to make sure that the gbm buffer 'stuff' in mir won't be affected by the presence of an x server that owns the framebuffer
[15:53] <alf_> hikiko: kdub: it will be affected since in that case we don't priveleged access to the drm device (the X server has)
[15:55] <hikiko> so if I want to have an sdl platform (like we already have the gbm and the android) for the emulator, I need to implement the buffer classes you have in the other 2 platforms (I can't use the gbm and just create a new display) isn't it?
[15:57] <kdub> the issue sounds like its getting privilege to get at the gbm graphics buffers then
[16:01] <racarr> alf_: alan_g: The current focus implementation is a shortcut
[16:01] <racarr> alf_: alan_g: The way it should really work I think
[16:02] <racarr> and has to for all the pointer stuff is
[16:02] <racarr> the input manager maintains a session handle and window handle for all open
[16:02] <racarr> sessions/windows, and removes them when appropriate
[16:02] <racarr> via a listener interface
[16:02] <racarr> focus is a seperate callback/interface
[16:02] <racarr> that updates the property on one of the window handles
[16:05] <alan_g> racarr: I really think that the input manager should delegate that tracking to something that knows about the events that change focus.
[16:06] <smspillaz> racarr: morning :)
[16:06] <racarr> Morning :)
[16:07] <racarr> alan_g: Yeah I think once it gains this logic for managing the list of sessions handles, etc, it should become a new interface
[16:08] <racarr> well a new
[16:08] <racarr> object
[16:09] <alf_> hikiko: kdub: although if you just want to create some buffers to render to/use as textures it may be the case that no special priveleges are required (but I haven't tried)
[16:11] <alf_> hikiko: kdub: also, perhaps you can get SDL surfaces that are backed by drm buffers? (I have no idea)
[16:13] <racarr> alf_: alan_g|tea: What is this about input::Shell { send_input_event}, etc...
[16:13] <hikiko> I don't think that's possible... Does it have to be drm buffers? Does the client actually directly manipulate drm buffers?
[16:13] <racarr> shell::SessionInputFilter?
[16:13] <racarr> Don't really understand
[16:16] <alan_g> racarr: it all begins with alf_ finding an ownership cycle causing memory leaks
[16:17] <alan_g> http://people.canonical.com/~afrantzis/mir-cyclic-dependency.dia
[16:17] <alf_> hikiko: Yes, the client part of mir (for the desktop) uses drm buffers. If the server sdl backend doesn't send drm buffers, you will also need to write a new matching client backend. And I am not sure how Mesa will work with that...
[16:17] <alf_> hikiko: although the work racarr did recently should help
[16:17] <hikiko> well, I guess that mesa will just provide the opengl context
[16:18] <smspillaz> alf_: hikiko my understanding of working with wayland is that you should be able to allocate gbm buffers in an SDL based X11 compositor and send them to the client
[16:18] <smspillaz> and then just create the textures from those
[16:18] <smspillaz> shouldn't be any different than running directly on kms
[16:18] <hikiko> that's cool if possible
[16:18] <hikiko> I will try this first
[16:19] <alf_> alan_g: racarr: Hangout?
[16:19] <hikiko> thanks a lot all of you :)
[16:20] <alan_g> alf_: sure
[16:20] <hikiko> I have to go, my day is over! see you :)
[16:21] <alf_> racarr: alan_g: https://plus.google.com/hangouts/_/77e412bddebe0d5ea06c9d92750a3dfaaa736317?authuser=0&hl=en
[16:22] <smspillaz> alf_: If the mesa mir platform is anything like the wayland platform, I believe all that would be necessary is to allocate the buffers using the mir platform in mesa, and then calling into eglCreateImageKHR to bind it to a texture
[16:27] <kgunn> racarr: you joining? ^
[16:29] <Darxus> Anybody have an email address for sturmflut?  Or know if his changes to glmark2 to get it to run on mir are available (upstream?)?  I'm curious if they'd be a useful reference for porting it to wayland.
[16:30] <Darxus> I guess he wasn't the one that ported it.
[16:34] <smspillaz> Darxus: alf_ was the one who did the mir work for glmark2
[16:34] <smspillaz> actually alf_ wrote it iirc :)
[16:35] <smspillaz> Darxus: they're in a meeting though, give it 15 mins
[16:36] <alf_> Darxus: it should be relatively straightforward to port to wayland, you will need to implement the NativeState interface for wayland (e.g. see NativeStateMir, NativeStateX11 etc)
[16:38] <Darxus> smspillaz: Thanks, looks like things are pretty well documented, and upstream:  https://blueprints.launchpad.net/ubuntu/+spec/client-1303-mir-glmark2 https://code.launchpad.net/~glmark2-dev/glmark2/trunk  Looks like most of it is here:  http://bazaar.launchpad.net/~glmark2-dev/glmark2/trunk/revision/265
[16:38] <Darxus> alf_: Thanks.
[16:41] <kdub> hey rsalveti is lp:~rocket-scientists/aal+/trunk the latest version of hybris?
[17:34] <alf_> racarr: alan_g: kgunn: Last chance for hangout today
[17:35] <kgunn> alf_: you off on monday?
[17:35] <alf_> kgunn: no, but I guess Alan is (and the US?)
[17:35] <alan_g> alf_: kgunn I'll be off on Monday
[17:35] <kgunn> alf_:  oh yeah...Alan is i think too....US works
[17:37] <alf_> alan_g: kgunn: so do you want to hangout today or leave it for next week (perhaps have some more time to think about it, too)?
[17:38] <kgunn> alan_g: alf_ if racarr is m.i.a. i guess leave it till Tues.
[17:39] <alf_> kgunn: alan_g: fine with me
[17:40] <alan_g> alf_: ok
[17:40] <alf_> all: (-alan_g) Have a great weekend
[17:40] <alf_> alan_g: Have a great long weekend
[17:40] <alf_> :)
[17:40] <kgunn> alf_: :) hope you enjoy yours also
[17:41] <alan_g> alf_: I'll try (but my wife has chores planned)
[17:41] <racarr> Sorry was afk
[17:41] <alf_> lol
[17:41] <racarr> isn't
[17:41] <racarr> today off?
[17:41] <racarr> :)
[17:42] <racarr> we can catch up later.
[17:42] <alf_> alan_g: kgunn: racarr: ok, hangout take two?
[17:42] <racarr> Or that :) sure
[17:42] <kgunn> ok
[17:43]  * alan_g doesn't know what's happening
[17:43] <alf_> alan_g: kgunn: racarr: https://plus.google.com/hangouts/_/8ca1c200997596d270738b80ee77065cc715ad1e?authuser=0&hl=en
[17:43] <alf_> alan_g: racarr's perfect timing is what's happening :)
[18:04] <alf_> racarr: http://paste.ubuntu.com/5658848/
[22:50] <sturmflut> When will basic window management be in place? Apparently at the moment Mir doesn't even support two clients running at the same time, it just displays what the last client to be started draws onto its surface