[01:25] <RAOF> Pfft. That was a bit of a gnarly one.
[04:49] <RAOF> You know, it really would be nice if Qt creator didn't crash each time my RANDR config changed.
[07:06] <duflu> Confusing.... "0.1.9" is the latest download available ... by date :)  https://launchpad.net/mir/+download
[08:31] <alan_g> alf_: anpok duflu - anyone about to vote or shall I just approve it? https://code.launchpad.net/~alan-griffiths/mir/spike-nested-server-test-fixture/+merge/224637
[08:32] <duflu> alan_g: Code? What's that?
[08:32]  * duflu looks away
[08:33]  * alan_g thinks this is a new duflu - not sure if I like it. ;)
[08:43] <mpt> Hi, can anyone remember why we started talking about “surface roles” instead of “surface types”? The Mir code still refers to “types”, correct?
[09:20] <duflu> mpt: Correct. I implemented "types" and "states" based on the old design docs a year or so ago. The word "role" then appeared in newer design docs, but the Mir code still refers to types and states.
[09:21] <duflu> There's another new noun too... I forget
[09:23]  * duflu votes for "types and states"
[09:24] <duflu> Although the enumeration values used in code don't need to match perfectly so long as the mapping is clear
[09:53] <mpt> thanks duflu
[10:17] <doko> alan_g, tvoss: so the phone team did choose to do this transition this way, why do the mir people insist now on a different way?
[10:17] <doko> alan_g, btw, your nick name is not up to date in the directory
[10:19] <alan_g> doko: the mir team are being asked to approve a change that hasn't been adequately explained to them. Why were they not involved in a decision that affects them?
[10:20] <doko> alan_g, what is missing from https://bugs.launchpad.net/mir/+bug/1329089/comments/5 ?
[10:20] <doko> alan_g, I would assume three weeks is enough for raising questions
[10:21] <alan_g> doko: it was proposed two working days ago. Not three weeks
[10:22] <tvoss> alan_g, the bug is way older than that, though
[10:29] <alan_g> The bug comment says "Don't use versioned build dependencies for g++-4.x at all (preferred)" and the MP introduces versioned dependencies - how does one follow from the other?
[10:52] <alan_g> tvoss: regardless of the merits of the chosen approach duflu does have a point about the changelog
[10:52] <tvoss> alan_g, sure, happy to change that
[10:54] <alan_g> tvoss: that should resolve both the "Needs Fixings" you've got. ;)
[15:32] <alf_> mterry: dandrader: I saw that we updated the scene code in unity-system-compositor devel-mir-next. The issue there is that because we are creating the SceneElements on our own (instead of letting the scene do the work), we are missing on the new visibility tracking (occludded/exposed events) mechanism.
[15:33] <dandrader> alf_, yes
[15:33] <alf_> mterry: dandrader: Last week I suggested that we drop the scene reimplementation and just hide all sessions that are not needed. Was this considered, or was it too risky to do now?
[15:34] <dandrader> alf_, fell free to do whatever you think is best. I just did it because no one else in mir team had time to do it and I had to unblock the qt comp work. My idea in that patch was to keep the exact same behavior as before
[15:34] <dandrader> alf_,  thus ignoring the visibility as that method simply won't return elements that are not to be rendered
[15:35] <alf_> dandrader: ok, if there is nothing blocking a potential change, I will take a look, thanks
[15:35] <dandrader> alf_, which I guess yields the same result as returning elements with visible=false?
[15:37] <dandrader> alf_,  and if I recall correclty, mterry wanted to keep this scene infrastructure for some future use....
[15:38] <mterry> dandrader, alf_: no, it should be fine to try hiding the sessions
[15:43] <dandrader> alan_g, is I call surface->configure(mir_surface_attrib_focus, mir_surface_focused), is there any logic in mir that might override this and set the focus back to unfocused?
[15:43] <dandrader> s/is I/if I
[15:44] <alan_g> dandrader: you mean as a result of your call or as a result of anything?
[15:45] <dandrader> alan_g, well, both. :)
[15:46] <racarr> dandrader: SurfaceConfigurator could...
[15:46] <racarr> which it looks like you guys are implementing in unity-mir and hooking up to a Qt signal um
[15:46] <racarr> youc an check the return value of surface->configure to see
[15:47] <racarr> ifyou succeed in setting it to focused (and then perhaps its changed latter)
[15:47] <alan_g> dandrader: yes. E.g. the surface is destroyed by the client
[15:47] <racarr> or if it never gets set to focused (i.e.t he surface configurator intercepts it and changes to unfocus)
[15:49] <dandrader> racarr, right, we do have a surfaceconfigurator that seems to just return whatever it gets
[15:49] <dandrader> will take a closer look at this guy to see if there's any missing piece
[15:51] <dandrader> racarr, is SurfaceConfigurator::attribute_set just like a signal that tells what has happened or does it expect any action to be taken in the implementation?
[15:51] <racarr> dandrader: It returns the value which should actually be set
[15:51] <racarr> so its like a value filter or something
[15:51] <racarr> dandrader: i.e. for the shell to say
[15:51] <racarr> haha no this surface cant be maximized dont be silly
[15:51] <racarr> etc
[15:51] <dandrader> racarr, Isn't that SurfaceConfigurator::select_attribute_value ?
[15:52] <racarr> OH sorry
[15:52] <racarr> Yes I believe attribute_set is just a signal
[15:56] <dandrader> racarr, hmmm, looking at ms::BasicSurface::configure it looks like configuring the focus attribute doens't actually do anything?
[15:56] <alf_> racarr: dandrader: We have a FocusSetter class that can change the focus in reaction to new sessions etc in SessionManager. Is unity-mir overriding this?
[15:56] <dandrader> racarr, I mean, it doesn't call an internal set_focus() or anything....
[15:57] <dandrader> it just notifies the observer
[15:58] <dandrader> alf_, I took a quick look at FocusSetter but it seemed to deal with session focus which seemed to be a concept distinct from surface focus...
[15:58] <racarr> dandrader: Ah sorry didnt understand what you were doing. yes that is true
[15:59] <racarr> FocusSetter is the only way to "set focus" and the attribute is something it sets.
[16:00] <racarr> It sets focus to the default surface for a session
[16:00] <racarr> but I guess we can/should have focus(surface)
[16:01] <dandrader> racarr, all I wanna do is calling surface->configure(mir_surface_attrib_focus, mir_surface_focused) and have the client be told that so that it can update this stuff UI accordingly
[16:01] <alf_> mterry: how do you try unity-system-compositor + greeter + multiple sessions (e.g. if I make changes how do I test I haven't broken it?)
[16:02] <racarr> dandrader: I'm not 100% surethats right, because it shouldn't be "focused"
[16:02] <racarr> for example unless it has
[16:02] <mterry> alf_, uh... that was much easier back with a split greeter
[16:02] <racarr> the keyboard input target
[16:02] <racarr> itspossible, that the_surface_configurator
[16:02] <dandrader> racarr,  because in the qtcompositor world the focus concept lives in the qml scene of unity8, so I wanna use surface->configure(mir_surface_attrib_focus,...) as a way of exposing that info to the client. so effectively I just want  the IPC done
[16:02] <racarr> could becomethenew...focus mechanism
[16:03] <mterry> alf_, it's tricky because USC gets its ideas of which session should be focused from lightdm
[16:03] <alf_> dandrader: racarr: use a NullFocusSetter?
[16:03] <racarr> Yep
[16:03] <dandrader> racarr, in qt comp, every client surface is represented by a qml item, which has a focused property
[16:03] <mterry> alf_, so really unless you fake something up, you'll need an actual split greeter
[16:03] <racarr> dandrader: Yes I see I forgot the input targeter,etc werent relevant
[16:04] <racarr> I think Alf is right use a NullFocusSetter so no one will interfere with you setting the attributes otherwise
[16:04] <mterry> alf_, but you can test the spinner / primary session swapping by killing unity8 and confirming that it brings up a spinner again
[16:04] <mterry> alf_, and creating new demo clients to connect to USC and confirm that they don't display
[16:04] <racarr> or implement the_focus_setter with an impl that just calls surface->configure
[16:04] <dandrader> racarr, but still surface->configure(mir_surface_attrib_focus is effectively a noop in BasicSurface... no IPC gets done
[16:05] <racarr> err...I dont think thats true because we have a test
[16:05] <racarr> lemme look
[16:06] <alf_> mterry: that would be a good starting point, but I would like to also put the greeter in the equation when testing (isn't that the reason behind current and next sessions in usc?)
[16:06] <dandrader> racarr, or is there a surface observer that gets notified and does the IPC?
[16:06] <mterry> alf_, yes it is the reason
[16:07] <mterry> alf_, but the split greeter branch was ripped out of trunk and not replaced with anything that works against current trunk right now
[16:07] <mterry> (I've been too busy with RTM stuff to rework it in the short term)
[16:07] <racarr> dandrader: yeah thats it, src/server/scene/surface_event_source.cpp
[16:07] <racarr> lol...its a little...nonobvious from the code
[16:08] <alf_> mterry: makes sense... what does RTM use ATM? (yay, acronym madness!)
[16:08] <mterry> alf_, right now it uses an integrated greeter, just some qml that the unity8 process draws
[16:09] <dandrader> racarr, ahhh, ok. thanks for the info!
[16:09] <racarr> np, sorry to be a little confusing lol
[16:11] <alf_> mterry: ok, so that works for now because we only have one session on the phone?
[16:11] <mterry> alf_, right.  No multi-user support yet
[16:14] <alf_> mterry: ok, so if, for example, I used translucent sessions to visually check that two sessions (current, next) are rendered, would that be a decent test  of the expected behavior?
[16:15] <mterry> alf_, yeah, sure.  But the trick is fooling USC into thinking what the next session should be
[16:16] <mterry> alf_, maybe just hard-code the name for testing purposes
[16:16] <davmor2> kgunn: Manta is having display issues.  If I unplug it and the screen blanks I get a brief flash of grey and then it is just black
[16:16] <alf_> mterry: Sounds good, thanks. Hopefully I will find some time this week to give it a go. Thanks!
[16:18] <davmor2> kgunn: we are wondering if this would be similar to the issue that people on nexus 5 are seeing
[16:18] <kgunn> what image davmor2
[16:19] <kgunn> i've been playing with manta last nigth &
[16:19] <kgunn> this morning
[16:19] <davmor2> kgunn: 106/107 for today
[16:19] <kgunn> havent seen this
[16:19] <kgunn> lemme check my image
[16:19] <kgunn> #
[16:19] <davmor2> kgunn: needs to be unplugged
[16:19] <kgunn> davmor2: mmm...lemme see
[16:19] <davmor2> kgunn: if you have the usb lead in it works fine
[16:20] <davmor2> kgunn: once you are in the broken state you can actually plug the usb lead into the dev press the power button and it wakes fine
[16:20] <kgunn> davmor2: ok, i see it...freaking weird
[16:20] <kgunn> AlbertA: ^
[16:20] <kgunn> check this out...
[16:20] <kgunn> why would usb connection effect screen unblank & contents
[16:21] <kgunn> e.g. the screen does come on, but contents missing
[16:21] <kgunn> davmor2: and its seems inconsistent
[16:21] <kgunn> sometimes it works
[16:23] <davmor2> kgunn: happens reliably here if there is no usb lead in.  I also noticed that it sometimes happens on the music scope if you play a track from the scope and then pause it but that is flakey at best
[16:24] <kgunn> davmor2: huh...it definitely happens more than not, but its not 100% i can get back to lock screen every now and then w/o usb in
[16:25] <AlbertA> kgunn: davmor2: only in manta?
[16:25] <kgunn> probably 1/3 of the time lock screen....2/3's grey/black
[16:25] <davmor2> kgunn: I wonder if it is because of the gfx chipset and it being a tablet so it does deep sleep properly.  That would mean that adb was causing a wake on the system and then screen pops into life maybe?  long shot
[16:25] <kgunn> davmor2: mmm...maybe
[16:26] <kgunn> does feel kernelish
[16:26] <davmor2> AlbertA: yeap only manta possible bq/meizu and maybe nexus 5
[16:27] <kgunn> davmor2: i've been playing ever since you pung....it seems to be rare on time-outs (vs very common on button hit)
[16:27] <AlbertA> davmor2: ok flashing #107... yeah it maybe related to suspend...
[16:31] <davmor2> AlbertA, kgunn: So Flo is fine I've been trying it most of the afternoon
[16:31] <davmor2> mako: was tested for promotion it is fine
[16:32] <kgunn> dang it kdub driving a uhaul...he would find this interesting
[16:32] <davmor2> kgunn: Shall I file a bug against mir for this initially?
[16:32] <AlbertA> davmor2: against unity-system-compositor
[16:32] <davmor2> AlbertA: will do
[16:41] <davmor2> https://bugs.launchpad.net/ubuntu/+source/unity-system-compositor/+bug/1336411
[17:16] <AlbertA> davmor2: kgunn: https://code.launchpad.net/~albaguirre/unity-system-compositor/fix-1336411/+merge/225209
[17:16] <AlbertA> davmor2: the blank issue in manta was due to suspend indeed
[17:17] <davmor2> AlbertA: yeah
[17:17] <AlbertA> davmor2: so as soon as I get a review, I'll propose to land
[17:30] <AlbertA> can somebody take a look at: https://code.launchpad.net/~albaguirre/unity-system-compositor/fix-1336411/+merge/225209
[17:43] <kgunn> rsalveti: or mterry ^ ? we're down a kdub today who might normally review
[17:44] <mterry> I am about to head to a dentist appt, but can do later today
[18:04] <olli> AlbertA, how do I take a screenshot on the device?
[18:04]  * olli can't google it and doesn't remember how to do it
[18:05] <racarr> phablet-screenshot exists if thats what you mean
[18:05] <racarr> AlbertA: Im checkingit out...
[18:06] <olli> racarr, thx
[18:06] <olli> I was searching in the ubuntu- name space
[18:07] <racarr> :)
[18:09] <racarr> AlbertA: So the basic point is what was "acquire-sys-state"
[18:09] <davmor2> AlbertA: okay back from tea.  Is there a package I can install and test and I'll happily do that for you
[18:09] <racarr> which I am guessing is like...acquire a powerd we are awakecookie or something
[18:09] <racarr> needs to be called
[18:09] <racarr> before display->configure?
[18:10] <AlbertA> racarr: right before attempting to power on the display
[18:10] <AlbertA> nexus10 doesn't like it...
[18:10] <AlbertA> otherwise
[18:10] <racarr> ok makes sense to me lol
[18:10] <racarr> youc an get in to a similar state on nexus 4 actually or at least you used to be ableto
[18:10] <racarr> *thinks*
[18:11] <racarr> eh
[18:11] <racarr> similar but unrelated
[18:11] <racarr> there was a point where to run mir without unity8 you had to run
[18:11] <racarr> powerd-cli active:p becausenothing else
[18:11] <racarr> waskeeping the system out of suspend state
[18:11] <racarr> andthen powering the displays would fail of course.
[18:11] <racarr> anyway lgtm
[18:12] <AlbertA> racarr: heh :)
[18:12] <olli> AlbertA, racarr phablet-screenshot seems to be looking for a local socket, wasn't there a convenience script I could run on the dekstop and which would get me a screenshot from the device
[18:12] <olli> without having to login etc
[18:12] <AlbertA> racarr: thankfully those days are gone
[18:12] <AlbertA> olli: yeah that should let you do it from the desktop
[18:12] <AlbertA> olli: it has been updated though
[18:13] <AlbertA> olli: but it's a utopic package
[18:13] <AlbertA> olli: so if you are not in utopic, you won't get the updated scripts I suppose
[18:16] <davmor2> olli: you need to change /usr/bin/phablet-screenshot from /run/mir_socket to /var/run/mir_socket iirc then it works
[18:23] <AlbertA> racarr: thanks!
[18:23] <AlbertA> kgunn: can you top approve? https://code.launchpad.net/~albaguirre/unity-system-compositor/fix-1336411/+merge/225209
[18:27] <davmor2> AlbertA: if there is a package I can install to test that fix give me  a ping and I'll happily test it in the morning nearly my EOD unfortunately
[18:29] <AlbertA> davmor2: sure, I'll ping you thanks@
[18:42] <kgunn> AlbertA: done
[18:47] <kgunn> AlbertA: we should throw that in with camako's mir040 landing request
[18:47] <AlbertA> kgunn: oh...I just put a new row
[18:47] <AlbertA> in ci train
[18:48] <kgunn> AlbertA: actually...that's fine
[18:48] <kgunn> we can do it seperate
[18:48] <kgunn> camako probably wants to finally get mir landed, no need to add 1 more complication ;)
[20:55] <dandrader> racarr, don't you think we're missing this? http://paste.ubuntu.com/7733309/
[21:15] <racarr> dandrader: Looks like it.
[21:16] <dandrader> racarr, ok, I'll report a bug
[21:23] <dandrader> https://bugs.launchpad.net/mir/+bug/1336548
[21:23] <racarr> dandrader: Thanks ill make a test andpropose a branch unless you are already on it
[21:24] <dandrader> racarr, I don't have a branch. just have that patch. that's why I reported the bug (making the test is the hardest part) :)
[21:29] <racarr> dandrader: :) Thanks.
[21:29] <racarr> will propose fix asap
[21:29] <dandrader> racarr, thanks!
[21:37] <dandrader> racarr, we are also missing a mir_surface_get_focus(), or mir_surface_get_focus_state() :(
[21:37] <dandrader> on the client API side
[21:39] <dandrader> same for the visibility attribute
[22:34] <racarr> dandrader: Also true -.- though it does show up in the attrib change events
[22:34] <racarr> will...mp an mp for that as well
[22:35] <dandrader> racarr, yes
[22:35] <dandrader> racarr, reported a bug for it as well https://bugs.launchpad.net/bugs/1336553
[22:37] <racarr> Was out picking up more green tea! To the emacs machine.
[22:37] <racarr> Thanks for writing it up in bugs.
[23:00] <RAOF> Yay bugs!