[10:01] <mlankhorst> huh
[10:02] <mlankhorst> why would unity8 give me a surface that has slightly more width than the screen?
[10:02] <mlankhorst> New size: 1366x742
[10:02] <mlankhorst> while the screen is 1360x768
[10:03] <mlankhorst> oh no, it's 1366 after all, wonder why it says 1360 then..
[10:03] <greyback> mlankhorst: a unity8 bug most likely. I'm aware of a bug where the surface height you end up with is 4 pixels too tall (for non-fullscreen surface)
[10:04] <mlankhorst> oh no, it might be some thing I need to workaround in xmir, bug in the resolution stuff
[10:33] <duflu_> mlankhorst: Interestingly Xorg also reports physical dimensions (xrandr) completely wrong. Mir does not
[10:33]  * duflu_ wanders off
[10:34] <mlankhorst> shrug :P
[10:36] <mlankhorst> I'm fighting with Xmir atm, getting some nice interactions where u8 resizes my newly created Xmir window and I currently don't handle that. I need to detect the case where Xmir runs in a window and handle xrandr differently there..
[10:58] <mlankhorst> can I detect the window is created with a different somehow? the resize event seems to be delayed..
[11:00] <greyback> mlankhorst: unity8's window sizing is a bit flawed right now. When clients requests surface, it is given fullscreen surface. Then when first frame is swapped, does unity8 resize surface to what is wants
[11:00] <greyback> so you always get a resize event shortly after surface creation
[11:00] <mlankhorst> ok, that would explain things..
[11:00] <greyback> known issue, I have code to fix it, I need to resurrect it and land it
[11:01] <mlankhorst> that would really help me. :P
[11:01] <greyback> mlankhorst: ok, let me do that today.
[11:03] <alan_g> greyback: are you now happy with my qtmir changes? (I tracked down my problems to PEBCAK)
[11:04] <greyback> alan_g: I am, just need to check one thing and then I can TA the new-migrate. Will then move onto the refactor, but from my initial look there was nothing controversial
[11:05] <alan_g> greyback: great
[11:09] <mlankhorst> greyback: but that could open another bug, until I call mir_surface_set_event_handler I can't process messages from the surface
[11:09] <mlankhorst> so if you fix it will it be race-free?
[11:10] <greyback> alan_g: can you answer that? ^^
[11:13] <greyback> mlankhorst: my understanding is when client calls mir_connection_create_surface with certain geometry defined in MirSurfaceParamters, the MirSurface returned should be checked again by the client to see the geometry it is given - as they may not be the same.
[11:13] <mlankhorst> yeah, unfortunately I don't see a call to do so..
[11:15] <greyback> mlankhorst: mir_surface_get_parameters should do it
[11:16] <alan_g> mlankhorst: what race are you concerned with?
[11:18] <alan_g> the size of the surface you have is available locally (as greyback says) and needs to be checked
[11:18] <mlankhorst> what call gives me the size then?
[11:20] <mlankhorst> oh right, the MirGraphicsRegion
[11:23] <mlankhorst> but that only works for cpu rendering, not gl
[11:26] <mlankhorst> oh nm, found it
[12:54] <greyback> alan_g: all approved, many thanks
[12:57] <alan_g> greyback: thank you.
[20:56] <rsalveti> kgunn: kdub: hey, have one question about mir and the input system and events, who knows more about that?
[20:56] <rsalveti> basically I want to understand what is the flow for the evdev events we get on our devices
[20:56] <kgunn> rsalveti: racarr and anpok
[20:56] <rsalveti> I know the shell is the one handling all the input, probably via mir
[20:56] <kdub> probably racarr in this timezone
[20:57] <rsalveti> cool, thanks
[20:57] <rsalveti> hm, no racarr around
[20:57] <kgunn> rsalveti: he's just gone for lunch...
[20:57] <rsalveti> cool, will ping him later then, thanks!