[07:23] <anpok_> hi
[07:24] <anpok_> I am playing with xmir in silo-004.. and tried various options
[07:25] <anpok_> when using -egl or -egl_sync the buffer contents seem to be corrupted. -sw and no option work fine when -damage is used. Without -damage a mix of old and new buffer is sometime visible..
[07:53] <duflu> anpok_: Did it ever work better than that? The new xmir is still relatively "new"
[07:58] <duflu> Weird. Every IRC message and email I've sent today has been met with silence.
[07:58] <duflu> Is there anybody out there?
[07:59] <sturmflut2> Well, it's only 10 AM here in europe, on a monday. People are probably either asleep or in meetings.
[07:59] <ogra_> or both ;)
[07:59] <sturmflut2> ogra_: Didn't want it to phrase like that, but yes.
[08:00] <duflu> Actually I was sending messages mostly to people in this timezone (West Aust / Hong Kong / Tokyo)
[08:02] <anpok_> duflu: :)
[08:03] <anpok_> not sure .. at least there is one configuration inside the set that works fine
[08:04] <duflu> anpok_: I would not worry about it. In my testing XMir 2.0 has been only mildly mature. I would not expect it to have perfect visual correctness and damage handling yet
[08:59] <duflu> alf_, anpok_: If I need to propose a fix to egl-platform-mir.patch, where is the best place?
[08:59] <alf_> duflu: mesa package
[09:00] <alf_> duflu: I have found that all other repositories are out of sync with the package
[09:00] <anpok_> hm tjaalton recently had to make changes to the patch
[09:00] <duflu> It's been a while. I need to remember how to :)
[10:11] <alf_> greyback: Which component in unity8(?) knows when the screen is (un)locked? I need it to emit a dbus event on (un)locking.
[10:11] <alf_> greyback: (Hi!)
[10:11] <greyback> alf_: Hey!
[10:11]  * ogra_ thought there is already one ... mtp should use it 
[10:12] <greyback> alf_: it's a qml component: either Greeter/Greeter.qml or Components/Lockscreen.qml
[10:12] <greyback> what is it you want to do?
[10:16] <alf_> greyback: I want USC to somehow know if the screen is locked or not, so we can deal with inactitivity timeouts correctly. Basically, when the phone is locked touches shouldn't extend the inactivity timeout.
[10:16] <greyback> understood
[10:16] <greyback> Greeter is probably the place to be
[10:17] <greyback> qml doesn't have built-in support for dbus. We usually write a small C++ class with a method which fires the dbus signal. Then call that method from qml.
[10:18] <alf_> ogra_: if there is an existing dbus signal I can watch for, even better... but I haven't been able to find one
[10:18] <alf_> greyback: ack
[10:19] <greyback> alf_: something like DashCommunicator would be the simplest example I can point you to
[10:19] <ogra_> alf_, bzr branch lp:mtp ... if there is a dbus signal server.cpp should use it
[10:19] <greyback> that's in lp:unity8:/plugins/Unity/DashCommunicator
[10:19] <ogra_> (i dont think mtp implements its own thing here)
[10:19] <alf_> ogra_: thanks, I will take a look
[10:25] <alf_> greyback: ogra_: So, I see a 'com.canonical.Unity.Greeter' interface used by MTP, but I don't see unity8/greeter implementing this interface
[10:26] <ogra_> fun
[10:26] <ogra_> well, it works with mtp ... somehow ..
[12:24] <Chipaca> alf_: o/
[12:24] <Chipaca> alf_: does mir always load xkb?
[12:27] <alf_> Chipaca: Hi. It uses xkb libraries on the client side
[12:27] <Chipaca> alf_: yes. always?
[12:28] <alf_> Chipaca: yes (AFAIK)
[12:28] <Chipaca> ok
[13:20] <attente> hi, shouldn't mir be re-focusing a parent surface when one of its focused child surfaces is released?
[13:32] <renatu> hey guys I am using ubuntu 15.04 (r58) on arale, and I noticed that the screen never turns off while idle
[13:33] <renatu> how I can debug it?
[13:33] <anpok> this is known issue of unity-system-compositor
[13:33] <tsdgeos> me?
[13:33] <anpok> hm alf_ made a fix
[13:33] <tsdgeos> er
[13:33] <tsdgeos> ignore me
[13:34] <tsdgeos> i added an highlight on unity and get confused thinking people are pinging me
[13:34]  * tsdgeos hides in his cave
[13:34] <anpok> :)
[13:35] <renatu> anpok, nice thanks, will this fix land on OTA5?
[13:35] <anpok> renatu: iirc applications seem to try to remove display on requests that they never issued.. and that caused usc to restart the display off timeout
[13:35] <anpok> iirc ota5 is already closed?
[13:36] <renatu> seb128, ^^^
[13:37] <seb128> anpok, renatu, check on #ubuntu-ci-eng, there are still discussing very selected landing, but it's likely going to be for ota-6 now
[13:43] <seb128> anpok, is there any way to tell what application does that?
[14:28] <kgunn> camako: anpok what's the plan on mir0.14 wrt wily vs vivid+ being frozen ? e.g. are you gonna land in wily regardless? or dual land only ?
[14:29] <kgunn> i got no opinions, just asking
[14:54] <camako> kgunn, land on both. vivid+ will soon thaw.
[14:54] <kgunn> ack
[14:55] <anpok> kgunn: i was told I cannot dual land because of the attached source packages
[14:55] <anpok> so I picked wily since vivid+overlay was freezing already
[14:57] <kgunn> camako: ^
[14:57] <kgunn> anpok: ok, up to you and camako how you wanna do it...
[14:57] <kgunn> anpok: but you might wanna add
[14:57] <kgunn> https://code.launchpad.net/~afrantzis/unity-system-compositor/fix-1461476-display-off/+merge/264127
[14:57] <kgunn> to that silo
[14:58] <kgunn> camako: racarr also, just checking on the raw event stuff, i thot we needed some device introspect as a precondition?
[14:58] <kgunn> just seeing the introspect card is on backlog
[14:59] <kgunn> was there maybe a smaller task gonna be spun out of that ?
[14:59] <camako> anpok, kgunn, ack about it not being a dual landing, but we will land on both. vivid+ is thawing by EoD today.
[14:59] <camako> land on both == two silos
[15:02] <kgunn> :) camako i'm kind of wanting to bet you on the thaw
[15:02] <kgunn> but you might win...
[15:02] <kgunn> you never know
[15:03] <camako> kgunn, yeah I know it may not but the point is it's close (one or two days don't make much of a difference at this point)
[15:04] <camako> kgunn, I made a comment on the introspection card, but haven't been able to sync with racarr. Hopefully today
[15:05] <kgunn> camako: thanks... it'll be my favorite topic for a while :)
[16:54] <greyback_> racarr: What is meant by "device introspection" exactly?
[16:54] <racarr> greyback_: Yeah input device introspection
[16:55] <racarr> enumerate devices, query their properties, etc...
[16:56] <greyback_> racarr: ok, that makes sense. Just the name was vague, and introspection I consider to inspect inside something, not just read fundamental properties of it
[16:56] <racarr> yeah I see that
[16:57] <racarr> I think of it as introspection wrt to the fields
[16:57] <racarr> in the event
[16:57] <racarr> an in particular the raw event which will need more interpretation
[16:57] <racarr> but even as it stands like
[16:57] <racarr> some of our axes e.g. everything except
[16:57] <racarr> x/y can't be used because
[16:57] <racarr> they are device specific min max
[16:58] <racarr> so its like, hey what is this axes, what is this button
[16:58] <racarr> *shrug*
[16:59] <greyback_> racarr: devils advocate - who needs that?
[16:59] <anpok> shells
[16:59] <kgunn> racarr: so should it be better names as event-introspection ?
[16:59] <kgunn> if it's even named yet :)
[17:00] <greyback_> for unity8 drawing pointer, would not relative mouse move events be enough?
[17:00] <greyback_> i.e. mouse moved 1 unit to the left
[17:01] <greyback_> anpok: I'll need more than "shells" ;) Can you give me examples
[17:01] <racarr> greyback_: Yes thats what the raw events are
[17:01] <greyback_> shells can get device info via other libraries like udev
[17:01] <racarr> and the intersection with
[17:01] <greyback_> racarr: cool
[17:01] <racarr> introspection
[17:01] <racarr> is you get a bunch of
[17:02] <racarr> {Id: 7: axis 9: value 14}
[17:02] <anpok> greyback_: true..
[17:02] <racarr> which ones come from a mouse :)
[17:02] <racarr> um so yeah shells
[17:02] <racarr> can't strictly speaking use udev without
[17:02] <racarr> breaking our encapsulation of input
[17:02] <anpok> greyback_: I wanted to write that.. and then realized.. that with libudev you do not need to have permission to query the device
[17:02] <racarr> so then
[17:02] <racarr> input platforms don't work
[17:02] <racarr> e.g. someone writes a platform for a custom device or
[17:02] <racarr> a platform for networked input ala synergy
[17:03] <racarr> you can't assume that you can just query the device via other apis
[17:03] <racarr> and then there are also client consumers
[17:04] <greyback_> sure, but similarly we can't assume mir runs on linux, but we have
[17:04] <racarr> I think for example drawing apps
[17:04] <greyback_> I just don't want to see reinvention of the wheel
[17:05] <racarr> wan't to find a device thats a tablet and map it to a window...and maybe list the tools
[17:06] <greyback_> ok, fair example
[17:06] <racarr> it's
[17:06] <racarr> an unfortunately complex solution to relative pointer events
[17:06] <racarr> but I dont think much is required for that
[17:06] <racarr> if I can't find a good pat
[17:07] <racarr> moistly the difficulty is in carving through the InputReader
[17:07] <racarr> soon though...there's kind of
[17:07] <racarr> a fallback strategy of just throwing some relative info in the pointer event
[17:09] <racarr> MORE CAFE
[17:17] <racarr> mmm
[17:35] <racarr> AlbertA: In https://code.launchpad.net/~albaguirre/mir/tweak-failing-tests-ci-tsan/+merge/264463
[17:35] <racarr> + ASSERT_THAT(client_frames, Gt(compose_frames * 0.78f));
[17:36] <racarr> what does this mea
[17:36] <racarr> n
[17:36] <racarr> well or rather why 0.78 now instead of 0.8
[18:26] <kdub> racarr, iirc from the summary in the standup, changing that value didn't quite work either, and since its a timing-based test, might just be disabled
[18:27] <kdub> and... in the new buffer scheduling stuff, should be translated to a not-timing-based test
[18:33] <racarr> kdub: Ah. Sounds good to me :)
[18:33] <racarr> thanks
[18:51] <kdub> 'tis the time in the afternoon to switch to reviewing
[19:01] <attente> hi, i don't seem to be receiving a focus-in event for a surface when one of its focused child surfaces is released. is this unexpected or by-design?
[19:47] <racarr> just spent a while working on mir on x review....made progress now breaking for lunch...
[20:49] <greyback__> attente: bug. That's window management which requires much work still
[20:50] <attente> greyback__: ok, thanks
[20:51] <attente> greyback__: is there already a bug number for it? should i file one?
[20:51] <greyback__> attente: not that I know of. Please file
[21:24] <attente> greyback__: is there any other information i can get out of a MirSurfaceEvent other than the attribute and the value (through the client api)? ideally like a surface handle or identifier?
[21:25] <greyback__> attente: I'll let a Mir expert answer that. racarr?
[21:28] <attente> greyback__, racarr: actually, i spoke too soon, i guess i don't need it because i'm getting that info directly from the event handler callback for the surface
[21:37] <conyoo> gsettings get com.canonical.qtmir lifecycle-exempt-appids
[21:37] <conyoo> ['com.ubuntu.music']
[21:37]  * ahayzen ducks
[21:37] <conyoo> does this mean music app is not suspended?
[21:37] <ahayzen> while audio is playing yes.. for now ;-)
[21:37] <conyoo> nice :D
[21:37] <conyoo> so i can add terminal app?
[21:38] <ahayzen> hopefully it'll go soon
[21:38] <ahayzen> i don't know if settings that would allow other apps to not be suspended, try it!
[21:39] <conyoo> i have no idea how :>
[21:40] <conyoo> gsettings set com.canonical.qtmir lifecycle-exempt-appids what?
[21:51] <greyback__> conyoo: yes
[21:51] <greyback__> what -> "['com.ubuntu.music','com.ubuntu.terminal']"
[21:51] <greyback__> qith quotes
[21:51] <greyback__> with
[21:52] <conyoo> uuu thanks, greyback__  :D
[21:53] <conyoo> gsettings get com.canonical.qtmir lifecycle-exempt-appids
[21:53] <conyoo> ['com.ubuntu.music', 'com.ubuntu.terminal']
[21:53] <ahayzen> :-) greyback__ you'll be happy to hear that we are finally working on bg-playlists support with the media-hub guys at the moment, its slow progress but we'll get there soon hopefully :-)
[21:53] <conyoo> so is the key some vector, enum/
[21:53] <greyback__> ahayzen: wooo!
[21:54] <greyback__> conyoo: array of strings
[21:54] <conyoo> right
[21:55] <conyoo> yay! now i can use unity8 on the desktop :D
[21:56] <conyoo> Xmir sort of works :D i'm good