[11:14] <alan_g> anpok: is this likely to be another gtk-mir problem? https://bugs.launchpad.net/miral/+bug/1627697
[11:58] <alf_> kdub: Is our IRC server down for you too, or is it just me?
[11:59] <kdub> hmm, launchpad is down for me, so i'd guess outage
[12:00] <alan_g> #launchpad says "Launchpad temporarily unavailable due to a network failure"
[12:00]  * alan_g decides to try again after lunch
[12:02] <RAOF> Firewall madness strikes again.
[13:14] <NeKit> http://pastebin.com/DtHEr0U8
[13:14] <NeKit> any idea what might be the reason for unity8 to fail? unity-system-compositor works though
[13:15] <NeKit> the device is MTK Helio X10
[13:21] <anpok> NeKit: kdub might have an diea..
[13:22] <anpok> alan_g: I will take a look when the keymapping bug is in a better state
[13:23] <kdub> NeKit, it seems to fail to map the buffer on the server side
[13:23] <kdub> and then seems to have fencing problems
[13:24] <kdub> maybe the usage bits go wrong somewhere
[13:24] <kdub> not sure though
[13:25] <NeKit> visually Ubuntu logo animation is playing fine though
[13:25] <NeKit> but nested compositor won't start due to buffer error
[13:26] <alan_g> anpok: thanks, I'm starting to feel that some spelunking tin gtk+ is needed.
[13:28] <om26er> Hi! How can I query screen resolution from Mir ?
[13:30] <anpok> om26er: as soon as you create a surface that is shown on screen you get surface_output_event
[13:30] <om26er> anpok, is there a commandline way to get that ?
[13:30] <om26er> or something pythonic ?
[13:30] <kdub> mirout
[13:31] <anpok> that even will tell you on which output you are displayed.. the via mir_connection_display_config you get access to the current setup...
[13:31] <anpok> *event
[13:31] <anpok> yes mirout
[13:32] <NeKit> kdub, might it be related to https://code-review.phablet.ubuntu.com/gitweb?p=aosp/platform/frameworks/native.git;a=commitdiff;h=90c5a47b7c7f00c04b4b681f4b81aea90b606b6f?
[13:33] <kdub> broken link
[13:35] <NeKit> kdub, https://code-review.phablet.ubuntu.com/gitweb?p=aosp/platform/frameworks/native.git;a=commitdiff;h=90c5a47b7c7f00c04b4b681f4b81aea90b606b6f
[13:36] <kdub> well, we don't really use the BufferQueue system in the ubuntu touch stack
[13:53] <NeKit> any steps that might help to debug buffer mapping then?
[14:05] <kdub> eh, I suppose I would start tinkering with mir::graphics::android::Buffer::write or read, and see if you can figure out a reason why its failing
[14:05] <kdub> maybe tinker with the allocation bits passed in to gralloc
[14:06] <NeKit> thanks
[14:23] <kgunn> alf_: hey, i'm back...but only here :)
[14:24] <kgunn> but  i was going to say, i added the core/kern snap to the drawing in order to
[14:24] <alf_> kgunn: (me too, only here...)
[14:24] <kgunn> show that those my have facilities needed by the u8-session snap
[14:24] <kgunn> to actually control the screen
[14:25] <kgunn> which i think is exactly what you were indicating
[14:25] <kgunn> was missing from the display control i/f that is there today
[14:27] <alf_> kgunn: that's one aspect, the other is actually allowing repowerd (or others) provide the dbus service over which apps can request keep-display-on
[14:27] <kgunn> alf_: yes, exactly
[14:28] <kgunn> alf_: so what may not be obvious, "an interface" (as in a single interface)
[14:28] <kgunn> can actually provide the slot/plug to the system/server side & the plug/slot to the client side
[14:28] <kgunn> alf_: mir interface is actually an example of this
[14:29] <kgunn> alf_: in the mir interface anything under "permanent slot" is what the mir server side is needing from the system
[14:29] <alf_> kgunn: looking...
[14:29] <kgunn> anything on the "connected slot" is what the mir server may need to do on the client side, and "connected plug" is what the client needs from the server
[14:30] <kgunn> alf_: ^
[14:30] <kgunn> hope that makes sense
[14:31] <alf_> kgunn: so, an interface can contain multiple slot/plug pairs?
[14:32] <kgunn> alf_: yes...well, specifically 2
[14:33] <kgunn> alf_: in my simple mind, i think of it as "top" pair and "bottom" pair architecturally
[14:42] <alf_> kgunn: thank, your explanation + reading the mir snap helps.
[14:47] <alf_> kgunn: my approach would be for the screen-inhibit-control interface to have a ConnectedSlot (allowing accepting dbus request) and ConnectedPlug (allowing sending dbus requests)
[14:47] <alf_> kgunn: but no PermanentSlot/Plug
[14:48] <kgunn> alf_: well, i think you've gotta drive that thru some testing....
[14:48] <kgunn> e.g. can u8 session do what it needs to do ?
[14:49] <kgunn> alf_:  when AlbertA and tedg ge the u8-session to the point where you can launch an app we'd need to try on an all-snaps system
[14:51] <alf_> kgunn: yes, I need to test, but my point (and I could be wrong) is that screen-inhibit-control interface shouldn't know about how repowerd in particular implements this functionality (hence no PermanentSlot/Plug)
[14:52] <kgunn> alf_: well...it's not that the plug/slot knows about implementation per se...it's just permissions
[14:53] <alf_> kgunn: it leaks implementation details, e.g., PermanentSlot contains the paths that repowerd needs to access to provide the display-on functionality.
[14:54] <alf_> kgunn: mir can get away with this because the interface is 'mir' not 'compositor'
[14:59] <kdub> hmm, login.ubuntu.com isn't working for me, which means no hangouts
[16:17] <alan_g> anpok: when you get headspace to look at gtk-mir, could you check all the miral bugs tagged with gtk-mir - AFAICT they are all in the toolkit
[16:20] <bschaefer> alan_g, do you want me to tag vs put [ gtk ] in the name for bugs?
[16:20]  * bschaefer wasnt really sure how you wanted to do the bug reports
[16:21] <alan_g> bschaefer: tags are easy to search
[16:21] <bschaefer> right, ill make sure to add those for future bugs
[16:22] <alan_g> But really once we're sure they're toolkit related they should be logged upstream
[16:22] <bschaefer> i agree
[16:22] <alan_g> I've  not got around to that either
[16:22] <bschaefer> (not sure where to log gtk mir issue?)
[16:22] <bschaefer> is there a launchpad page for it?
[16:23] <bschaefer> same with sdl2/sdl1.2 i suppose you *could* log it upstream for SDL2 (which is fine since mir lives in upstream SDL2)
[16:25] <kdub> 22 MP's up for review :/
[16:26] <bschaefer> kdub, partly my fault :|
[16:26]  * bschaefer made a bunch of sub MPs
[16:26] <bschaefer> but now depend on the ABI changes (which is blocked atm)
[16:27] <kdub> partly everyone's fault :)
[16:27] <bschaefer> :)
[16:27]  * bschaefer starts reviewing
[16:31] <dandrader> alan_g, how do I tell miral that no window should have focus? ie, I opened a indicator panel, so the foreground window should lose focus and it should not be given to any other window
[16:32] <dandrader> when indicator panel closes, focus return to foreground window
[16:32] <alan_g> select_active_window(Window{}) should do it
[16:32] <dandrader> alan_g, if I understood its code, it will give focus to the previous window
[16:33] <alan_g> Hmm. Let me look...
[16:34] <alan_g> select_active_window(Window{}) should do it.
[16:35] <dandrader> alan_g, right, that prev_window variable confused me....
[16:35] <alan_g> It needs to notify focus loss to the previous window
[16:38] <alan_g> bschaefer: anpok did point me where to log gtk bugs, butr I can't find it in my IRC log today
[16:39] <bschaefer> alan_g, :) i can poke anpok later
[16:39] <bschaefer> as if i can figure out if its miral (ill still report it for miral) then report it for gtk as well
[16:39] <bschaefer> just so i can mark it as a dup of that (so others can follow it)
[16:39] <alan_g> That sounds good
[16:58] <anpok> ... i am out for a bit .. but will continue for a few hours later tonight
[16:59] <anpok> bschaefer: bugzilla.gnome.org product:gtk+ component: Backend:Mir
[16:59] <bschaefer> anpok, sweet thanks
[16:59] <bschaefer> alan_g, ^
[17:00] <alan_g> 8)
[17:01]  * alan_g has lp:1625401 in gdb, with debug symbols
[17:02] <bschaefer> o nice
[17:02] <bschaefer> its not just X?
[17:02]  * bschaefer only saw it on miral on x
[17:03] <bschaefer> but doesnt mean it didnt happen on kms :)
[17:03] <bschaefer> o strange on mir 0.24... ive not seen this on mir_demo_server (wonder if its something strange happening specifically in miral?)
[17:04] <bschaefer> though ive not tried xmir on mir_demo_server
[17:04] <alan_g> I hope to find out
[17:08] <bschaefer> thats a good hope
[17:34] <alan_g> bschaefer: found it
[17:35] <bschaefer> alan_g, o nice, what was it?
[17:35] <alan_g> https://bugs.launchpad.net/mir/+bug/1625401/comments/3
[17:35] <bschaefer> o interesting
[17:35] <bschaefer> alan_g, just it just loop forever trying to find a not null session?
[17:36] <alan_g> Trying to find a session that's either null or doesn't have a null default_surface
[17:36] <bschaefer> interesting
[17:38] <alan_g> I wish I could reproduce more than twice a day. But I've already stretched EOD, so I'll finish off tomorrow.
[17:38] <bschaefer> yeah :( i was randomly hitting
[17:39] <bschaefer> alan_g, o also the reason we couldnt remove that API
[17:39] <bschaefer> is it would break ABI? (from my understanding?)
[17:39] <bschaefer> (the public client API) since it was released in 0.24
[17:40] <alan_g> No worse than changing the function to not work
[17:40] <bschaefer> but we cant break public client ABI?
[17:40] <alan_g> Both cases break clients that use it
[17:40] <bschaefer> (the C abi)
[17:41] <alan_g> the function
[17:41] <kdub> any other takers? https://code.launchpad.net/~kdub/mir/eglimage-from-mirbuffer-android/+merge/305868 https://code.launchpad.net/~kdub/mir/passthrough-ipc-plumbing/+merge/305698 https://code.launchpad.net/~kdub/mir/fix-1626503/+merge/306480 ?
[17:41] <bschaefer> kdub, ill attempt to review but a lot of the context is lost :)
[17:41] <bschaefer> alan_g, hmm right but ... i would love to remove it but if we are going to break client ABI ... shouldnt we just go ahead and break it for a bunch of things we want to remove?
[17:41] <kdub> bschaefer, thanks (and thanks to the other vogons who have reviewed those ones too)
[17:42] <bschaefer> alan_g, ill ask you tomorrow, dont want to question to much here :)
[17:42] <bschaefer> (since you're EOD)
[17:43] <alan_g> bschaefer: I've pushed an (untested) fix, if you have time to try it...
[17:43] <bschaefer> alan_g, yeah i can try to reproduce it all day
[17:43] <bschaefer> and let you know
[17:45] <alan_g> bschaefer: breaking the function affects exactly the same clients that removing it does
[17:45]  * alan_g has to go
[17:46] <bschaefer> alan_g|EOD, ...very true