#ubuntu-mir 2013-12-09
 * alan_g rejoices - this week he can boot his laptop with USC. (Which means he can actually run his changes.)
<mlankhorst> hah :p
<racarr> Morning!
<alan_g> Afternoon!!
<racarr> Aww :(
<anpok> evil evening!
#ubuntu-mir 2013-12-10
<alan_g> Hi RAOF - you got home OK?
<RAOF> alan_g: Indeed I did.
<RAOF> Only delayed by a little bit.
<alan_g> Good
<alan_g> Where are we with the changes to support Mir nested mode on mesa?
<RAOF> alan_g: I've just realised why they make i965 explode in a heap with mesa 10.0, and am about to upload some packages to the archive.
 * alan_g didn't hear the explosions
<RAOF> They were localised.
<RAOF> Oh, I guess that I should check that nested actually works, too.
<alan_g> RAOF: that would help. (I think anpok was trying to use it yesterday - without success.)
<anpok> .. hm yes it failed when creating a pbuffer surface in the nested compositor
<anpok> i looked at building u-s-c with the partial chroot script of mir
<anpok> how do you build that for ubuntu touch?
<alan_g> anpok: I haven't, but it is small enough that I'd start by building on the device
 * alan_g worries that the evil script is going to start spreading
<anpok> hmm too cute to be evil
<RAOF> usc doesn't need to link to any of the hybris-y bits, does it?
<anpok> only qt5 core and qt5dbus is added
<RAOF> I think you *should* be able to use an honest-to-god armhf chroot.
<alan_g> Mir and dbus
<anpok> and mir/build/ make install into the chroot  works good
<anpok> but the cmake config files of qt5 are evil
<RAOF> Install qemu-usr-static and âmk-sbuild --arch=armhf trustyâ should get you something working.
<alan_g> anpok: do you need usc to test your nested changes? It would involve fewer variables to stick to the mir examples.
<RAOF> Unless you're actually working on usc you should be able to use mir_demo_server_shell; that's what I'm testing nested with.
<anpok> two instances of mir_demo_server_shell
<anpok> ah
<anpok> then i'll move usc back to the other end of the stack..
<RAOF> So, um, why is the Nested platform trying to create a 1,1 pbuffer surface?
<RAOF> Because that's never worked on the mesa Mir platform.
 * alan_g briefly wonders what a "1,1 pbuffer surface" is before tuning out...
<RAOF> Might make more sense as a 1Ã1 pbuffer surface?
<anpok> alan_g: offscreen EGL surface with width and height attributes 1,1
<alan_g> what does it need that for?
<anpok> i only debugged through release mode binaries and thought that the pbuffer allocation function was some empty fallback.. but that might just be a side effect of the release binary
<alan_g> greyback: how's this feel as a message passing API? (Obviously not hooked up to anything yet) https://code.launchpad.net/~alan-griffiths/mir/message-passing-api/+merge/198422
<greyback> alan_g: looking...
<greyback> alan_g:  surface_callback Callback function to be invoked when request completes = called when surface realized?
<alan_g> greyback: when the call it's passed to completes. (Unrealized creation or realization
<greyback> alan_g: I'm trying to decide if having Mir define messages to be of type "key:value" is a good idea. What do you think?
<alan_g> why would mir define messages that it treats as opaque?
<greyback> alan_g: true. That was my obvious counter-argument :)
<greyback> alan_g: but it would enforce a style between shell and client
<greyback> alan_g: yeah leave it
<kgunn> i thot the reason for a notion of msg was to have some versioning control to it ?
<alan_g> greyback: I originally outlined some structure to the messages, but after the feedback I got in London I decided that Mir should stay out of that
<alan_g> kgunn: the question is whether that is envelope or content
<alan_g> there should be versioning and structure - but Mir doesn't need to know
<kgunn> alan_g: got it...so the versioning is extra-mir
<kgunn> its really shell/papi responsibility
<kgunn> ?
<alan_g> kgunn: there's loads of stuff: protocol id, version, structure that Mir can ignore. (Even if we have a canonical example in "shellinator")
<greyback> kgunn: yep, shell&papi will define their own versioned messaging scheme
<kgunn> greyback: alan_g ...ok...was just thinking RAOF was promoting the idea mir would have a bit of awareness there...
<kgunn> personally...i'm a fan of fully opaque
<kgunn> just trying to keep an open mind
<kgunn> as people seemed to have traversed this ground with x
<greyback> yep, I think it best to keep it opaque
<alan_g> kgunn: greyback - that experience is good for the unity8 protocol. But IMO Mir can and should ignore it.
<alan_g> Anything Mir needs to know about the shell can tell it.
<kgunn> alan_g: greyback ...yep, it totally makes sense to me...just trying to elicit any pitfalls
<kgunn> racarr: ^
<racarr> Mornnning
<anpok> in london the discussion went in a direction about adding extensibility to mir to be able to keep those portocols opaque, but defined in a way that others could make use of them
<racarr> Right, that's animportant bit about having versioning/identified protocols
<tvoss> alan_g, greyback protobuf supports on the fly message generation and extraction, too. I would think that we should stick with one way of marshalling, with Mir being able to ignore messages (treat them as opaque)
<greyback> racarr: +1
<alan_g> anpok: their needs to be protocol negotiation and versioning - the question is whether Mir or a shell handles it. I see only problems in Mir doing so.
<alan_g> Of course, shellinator and unity8 are free to do something compatible.
<anpok> thought we ended with .. we might do that later.. (providing extensibility in some form)
<tvoss> alan_g, by protocol you mean payload versioning (up to the higher level shell from my pov) or would you also like to version to the framing (size + type) for example?
<alan_g> anpok: I thought about it since and decided that Mir isn't the "we" that controls the protocol negotiation/versioning/structure
<anpok> yup I agree in best case we get away without the need for control..
<greyback> tvoss: has protobuf good versioning support? Just thinking worse-case where we'd need a non-backward compatibile change
<alan_g> tvoss: I initially intended that, but after the discussion that led to in London I decided that Mir should do the simplest thing and leave it to the next layer in the stack
<tvoss> greyback, yup, it supports forward and backwards versioning
<greyback> tvoss: ok thanks, will look that up
<tvoss> greyback, ack, look at cap'n'proto, too
 * greyback loving that project name
 * tvoss too
<alan_g> The simplest thing Mir can do that will work is to shift bytes between processes. It doesn't care if the shell uses protobuf or cap'n'proto
<mlankhorst> set sail for epic fail
<alan_g> mlankhorst: you know where we're going?
<tvoss> alan_g, I tend to agree
 * alan_g wonders what tvoss tended to agree to
<mlankhorst> to the bottom!
<racarr> I can't parse this conversation anymore :p
<racarr> the joys of IRC
<racarr> I think the simplest thingMir can do that will work is omitIPC and require shells to export a protocol
<racarr> soI dont think that is what we are aiming for
<anpok>  hm try | sort | uniq
<racarr> aha
<anpok> racarr: i think i misunderstood you, what are we aiming for?
<racarr> anpok: Well, I just mean, I don't think "the simplest thing that Mir can do that will work"
<racarr> is always the right thing for the combined architecture of Unity8 and Mir
<anpok> understood ..
<alan_g> racarr: I think we may have different values for "work". But do you have any objection to this approach?
<racarr> alan_g: I think it shoves work to differing shells (and now papi/differing client implementations)
<racarr> that could easilybe solved at the mir level with a protocol description language and a code generator
<alan_g> Why should Mir be responsible for dictating a protocol description language?
 * alan_g thinks a PDL is a good idea, but where does it belong in the stack?
<racarr> alan_g: Because it's the 'lowest-common-denominator' for compatibility?
<racarr> I'm not sure ;)
<anpok> alan_g: in the shell creation framework/library?
<anpok> brb
<alan_g> anpok: racarr I'm concerned that we get into a tarpit of alternate ways to provide a PDL and don't deliver what unity8 (or the proxy - greyback) needs right now,
<racarr> alan_g: That's fair.
<racarr> I will try and finish my email on the subject today
<racarr> i'd like to talk to Mr.RAOF
<alan_g|EOD> racarr: ack
<robert_ancell> racarr, so I hear I can now run u8 on desktop... :)
<kgunn> robert_ancell: the rumors are true
<robert_ancell> kgunn, any idea when packages will hit the archive?
<kgunn> hmm.... robert_ancell nothing changed in mir, i think it was just unity-mir and platform-api...and all that's needed is in trunk
<kgunn> so a couple of days i'd guess
<kgunn> i'll fwd you the mail
<kgunn> if you need
<robert_ancell> I got the email
<robert_ancell> It seems qtubuntu it probably the big one
<robert_ancell> so it's in flight then?
<robert_ancell> also, racarr said "It will be necessary to run as root for now" - is there a plan to make this work non-root, or should I continue to add support to lightdm so we can run a u-s-c+u8 combo on desktop?
<kgunn> robert_ancell: waiting on RAOF to land some mesa patches to enable nested mir...then usc can be used
<kgunn> and spoke to mterry & greyback earlier this morning...there shoulnd't be need for anything else afaict
<robert_ancell> Oh, I see. The shell needs to be run as root until we can get it to run in u-s-c then?
<kgunn> exactly
<kgunn> and robert_ancell yes you are correct the qt5.2 is kind of a big thing...
<kgunn> not completely sure why 5.2 is a pre-req tho
<kgunn> from this morning i think 5.2 will be in archive mid Jan (?)
<kgunn> platform guys will know best
<racarr> robert_ancell: The basic deal with 5.2 as a prereq is qtubuntu only selects an opengl elsl context and selecting a desktop context produces strange issues
<racarr> but qt on the desktop is compiled with desktop gl
<robert_ancell> aha
<racarr> in 5.1, it emits shaders that dont work with GLES
<racarr> but in 5.2 it emits shaders that happen to work
<racarr> and things are worked around until qtubuntu is fixed
<racarr> :)
<robert_ancell> racarr, do the desktop drivers have problems with gles/egl?
<racarr> no should be fine
<racarr> something is rather weird in Qt with Desktop GL, v.GLES
<racarr> I can't claim to understand it
<robert_ancell> kgunn, is RAOF on leave?
<kgunn> robert_ancell: nope
<kgunn> robert_ancell: he was on a little early...and looked like he was on late yesterday....
<kgunn> he might be jet lagged :)
<robert_ancell> yeah, I thought so
<kgunn> robert_ancell: feel free to poke him continuously on mesa patches :)
#ubuntu-mir 2013-12-11
<robert_ancell> mterry, around?
<mterry> robert_ancell, hello
<robert_ancell> Can I get you to do a quick sanity check on a lightdm merge? Just pushing it now...
<robert_ancell> https://code.launchpad.net/~robert-ancell/lightdm/usc-module/+merge/198479
<mterry> robert_ancell, ok, looking
<robert_ancell> ta
<mterry> robert_ancell, why not use xmir for this?
<mterry> with a unity seat
<robert_ancell> mterry, this is so we can run Unity 8 + USC from a greeter, i.e. no X
<robert_ancell> you then have one USC per session
<robert_ancell> and can do full user switching etc
<mterry> robert_ancell, oh, huh.
<mterry> robert_ancell, why not run unity8 standalone then?
<robert_ancell> because then it has to be root to do the VT switching / graphics permissions
<mterry> robert_ancell, sorry, got distracted by something.  Coming back to this
<mterry> robert_ancell, I guess I don't know enough about how Mir works, but I would have thought standalone unity8 and USC would have the same problems
<mterry> robert_ancell, so the xlocal dropping ready signal seems unrelated.  But the rest of it makes sense.  Why is the usc class a display server?  For convenience of adopting its API?
<robert_ancell> mterry, it will be used as a display server in the U8+USC case, but yes, mostly a convenience
<robert_ancell> actually it is required to be a display server for that case
<robert_ancell> I figured it would be better to make the code common
<robert_ancell> yeah, the xlocal ready signal was just something I noticed was unused
<mterry> Well, seems fine.  Mostly just moving code around
<robert_ancell> yes
<mterry> I imagine the unity seat is nice and lean now
<robert_ancell> it is :)
<mterry> robert_ancell, I'm working on a bug I'm seeing in Touch, with lightdm/greeter/session interaction
<mterry> robert_ancell, can you look at a log real quick and maybe hit me with a cluebat?
<mterry> http://paste.ubuntu.com/6554125/
<robert_ancell> sure
<mterry> robert_ancell, in there, I've commented some lines
<mterry> robert_ancell, around line 89, why do we kill the user session?
<mterry> Doesn't seem to make sense.  Separately, I'm not sure 100% why the greeter is dying, but I think that's a mir crash
<robert_ancell> that is odd
<robert_ancell> mterry, A guess - it's reset_session in greeter.c killing the existing sessions which for some reason we still hold a reference to?
<robert_ancell> grepping through the source suggests that would make the logs in the same order
<robert_ancell> perhaps we have a reference to the old greeter for some reason
<robert_ancell> because obviously the new greeter shouldn't know about an existing session
<mterry> hm
<mterry> I can add more debugging logs and drill down
<mterry> Might be another of these 'mir does things instantly' bugs like with the other display/session bug
<mterry> What causes the "Could not unblank display" error?  I can't remember.  I know we used to see it often
<mterry> I'm seeing it now in the USC during greeter testing
<RAOF> On the device I'd be pointing fingers at powerd.
<RAOF> That seems like the scapegoat of choice :)
<kgunn> robert_ancell: cool...just found out you're gonna do something to usc to make xmir not req'd for the unity8 preview thanks!
<kgunn> i was worrying about that one
<robert_ancell> yeah, as discussed on a piece of paper in a hotel room :)
<robert_ancell> we just need Mir on Mir working...
 * robert_ancell looks at RAOF
<robert_ancell> no pressure
<RAOF> robert_ancell: Mostly working :)
<RAOF> robert_ancell: Or, at least, the non-Mir-on-Mir bit of Mesa is working again
<RAOF> kgunn: Why was xmir required for the unity8 preview in the first place?
<kgunn> RAOF: only if we took in usc as-is today...in order to run unity8 on mir-on-mir w/ usc
<kgunn> so a knock on effect
<RAOF> Ah, for the greeter?
<kgunn> yes...
<RAOF> Right.
<RAOF> Gah! What a super-useless error message: âsession_error("egldemo")â
<RAOF> Thanks, SessionMediatorReport!
<RAOF> (For those playing at home - current state of Mir-on-Mir-on-Mesa is âeverything seems to work, except that clients mysteriously fail to connectâ)
<duflu> RAOF: How do unthrottled frame rates of fullscreen clients compare (-n -f) ?
<RAOF> duflu: Between mir-on-mir and mir-on-hardware.
<duflu> RAOF: Yes
<RAOF> duflu: Unknown; clients fail to connect to the nested mir server.
<duflu> RAOF: OK. We'll get there. Will be interesting to see. In fact I think that's my job. I just don't have the right Mesa to test desktop nesting yet
<RAOF> duflu: Yeah. You'll have the right mesa just as soon as I can verify that the mesa I've got here *is* the right mesa :)
<RAOF> Well, modulo buildd time.
<RAOF> Oh, and a small Mir change.
<duflu> RAOF: That's fine. I have plenty of other stuff to get through before I'm back on that task
<RAOF> duflu: So, quick and dirty eglplasma FPS eyeballing suggests that running nested slightly *increases* framerate, and seems to reduce variance.
<duflu> RAOF: That's totally weird :)
<RAOF> Not at all.
<duflu> RAOF: Reduced variance is not weird. Only increased throughput
<duflu> RAOF: You know it outputs framerate to stdout?
<RAOF> Yes, that's what I was reading.
<RAOF> There's no way I could tell the difference between 1800fps and 1700fps otherwise.
<RAOF> It's also possible that there *isn't* a significant difference in throughput; I haven't actually computed averages.
<duflu> RAOF: Yeah, that's what I meant. We can't just say "it's over 60FPS so who cares?". It's all about percentage differences, which often interpolate to less capable machines where a small difference is more critical
<RAOF> Anyway, this now works, except for software buffers.
<duflu> All too often that extra 10% on a developer machine equates to no longer missing frame deadlines on a slower customer machine
<RAOF> I'm a bit surprised that nested gave different numbers at all, actually.
<duflu> Yeah all things working properly, throughput should be unaffected
<robert_ancell> bregma, https://code.launchpad.net/~robert-ancell/lightdm/mir-sessions2/+merge/198487 adds support for Mir sessions
<RAOF> duflu: Particularly because nested currently doesn't change the swapbuffers flow at all - it's client â immediate server in both cases.
 * duflu wonders if we're getting some extra N-buffering effect
<RAOF> Hm. The client receiving a 0Ã0 shm buffer isn't actually going to be a Mesa problem.
<RAOF> Which means that mesa works!
<RAOF> Which means that it's time to upload :)
<RAOF> Woot. Also works on radeon.
<RAOF> duflu: Oh, this mesa should also make running Mir under vmware work.
<duflu> RAOF: Very interesting
<RAOF> Assuming that our drm probing method doesn't discount them.
<duflu> RAOF: And qemu with the vmware graphics option? :)
<RAOF> Likewise; as long as it supports the newer vmware kernel module.
<RAOF> Hm. Mir team meeting today?
<duflu> Not sure. Hope not. I have nothing to talk about and need to duck out at lunch
<duflu> RAOF: proposed counts as "Fix Committed", no?
<RAOF> duflu: Yes, but if you're thinking of changing the bug status, I wouldn't bother; it'll be automatically marked as fix released soon enough.
<duflu> RAOF: Too late
<RAOF> Hm. The commit which broke nesting on Mesa seems to have been made to fix nesting on Android.
<duflu> ??
<RAOF> It switched the nested platform constructor from creating a context with EGL_NO_SURFACE to creating a dummy 1Ã1 pbuffer surface and creating the context on that.
<RAOF> Presumably because at least one of the Android EGL stacks didn't support EGL_KHR_surfaceless_context.
<RAOF> However: Mesa doesn't support pbuffer surfaces
<duflu> RAOF: So the new Mesa still can't nest using dev branch?
<duflu> Because of the dev branch...
<RAOF> Correct.
<duflu> Excellent. Yes, I suspected pbuffers were deprecated but wasn't sure so did not block that from landing... Was it mterry?
<RAOF> Yeah.
<duflu> Yeah I remember that commit. Sorry. At the time it appeared nesting was still very much under development. Which is only half true
<duflu> RAOF: Could you log a bug for that? tagged "nested" ?
<RAOF> I'd rather just fix it.
<duflu> That too
<RAOF> Once this branch builds you can have a merge to review :)
<duflu> Whee, more reciews
<duflu> And reviews
<duflu> Although if Mesa prevented it from working till now, no functionality is technically lost, yet :)
<RAOF> I guess I should really test this on android nested, shouldn't I.
<RAOF> Bah. Why doesn't bzr lp-propose properly target lp:mir/devel when I ask it to?
<RAOF> duflu: https://code.launchpad.net/~raof/mir/check-for-surfaceless/+merge/198510 if you want to play the nested game.
<duflu> RAOF: Looking at it
<duflu> RAOF: Did I miss something? Does C++ really force us to create constructors like that? Is there no other way?
<duflu> Last time the answer was "no" but I think it's worth asking again
<RAOF> No other way while retaining the constness, no.
<duflu> Dear C++: Be better :S
<duflu> At everything
<didrocks> RAOF: yeah lp-propose will still catch up to the "toppest branch" to what you target
<didrocks> RAOF: that's why everytime we deploy a stack, we have to reconfigure to set trunk target as "trunk" :/
<RAOF> We *could* factor out the surface construction into a function, which would make things look a bit better.
<didrocks> you shuold do the same for mir/devel I guess
<didrocks> should*
<RAOF> didrocks: What needs to happen? lp:mir/devel properly points at lp:~mir-team/mir/development-branch
<RAOF> duflu: You wouldn't happen to know on which android device(s) nesting is most likely to work, would you?
<duflu> RAOF: I had it working on N4 last week
<didrocks> RAOF: I've just run "bzr config -d lp:mir/devel public_branch=~mir-team/mir/development-branch"
<duflu> Without fuss
<didrocks> RAOF: if you try now, it should work
<didrocks> RAOF: it's a question of internal launchpad stacking branch
<anpok_> RAOF: worked on the nexus 10 too
<anpok_> where do i see which tests are executed or not executed through make test?
<RAOF> They're all executed; output goes to stdout IIRC.
<RAOF> There's also logs in Testing/..
<anpok_> hm why do I experience test failures when i run the binaries manually?
<RAOF> Because you need the environment set up by umockdev
<RAOF> (Running the binaries with âumockdev-run bin/unit-testsâ will work)
<anpok_> thx!
 * RAOF is hit *again* with the âfind_libhardware doesn't look in the chrootâ bug. Perhaps it's time to fix that.
<RAOF> What's the easiest way to test on the phone again?
<tvoss> Saviq, can you help RAOF ?
<Saviq> tvoss, RAOF, I can try, test what? (first time I've seen the find_libhardware thing)
 * RAOF would have turned up to the session at the sprint, but it was on before I knew it was on :)
<RAOF> Saviq: You probably have libhardware-dev installed system-wide; that masks the bug.
 * duflu would have gone to a couple of useful sessions, but each time mir-team was too busy in discussions and no one could escape
<Saviq> RAOF, nope, no libhardware-dev installed here
<RAOF> Saviq: I need to test nesting mir on android; our documentation for that is significantly out of date.
<RAOF> Saviq: Hm, odd. Building with ./cross-compile-chroot.sh?
<Saviq> RAOF, haven't built mir for a long time, but when I was - yes, cross :)
<duflu> RAOF: How old is your image?
<RAOF> duflu: Fresh as of now.
<RAOF> Newest in trusty-proposed.
<duflu> RAOF: BTW, umockdev-run still not joyful on saucy... bug 1259851
<ubot5> bug 1259851 in Mir ""umockdev-run bin/mir_unit_tests" fails with: sendmsg_all: cannot run glob: Invalid argument umockdev-run: unable to propagate signal 6 to child 9323: No such process" [Undecided,New] https://launchpad.net/bugs/1259851
<Saviq> RAOF, I'm also afraid I never touched nested mir - mterry and ricmm know most there, but obviously TZ is wrong there...
 * duflu retests trusty
<RAOF> duflu: Yeah, needs a umockdev SRU
<anpok_> i could test nested on n10 .. that what i did the last two days..
<duflu> Fun. Some trusty update has bricked my laptop. Almost
<duflu> ... and that's why I maintain saucy on my primary system
<duflu> anpok_: Very nice first code review
<RAOF> Bah. How can the phablet image not have strace installed? :)
<RAOF> anpok_: Yeah, I agree that we should have an actual shared âcheck EGL extensionsâ helper. I'll factor one out of our existing stuff.
<anpok_> i was unsure whether minor stuff like that was enough for "needs fixing" or .. dunno
<anpok_> guide me ..
<RAOF> I think that's a reasonable use of "needs fixing"
<duflu> Sometimes. Depends if we have time and have spent much time iterating the branch yet. In this case, it's fine
<RAOF> Cool, didn't break android.
<anpok_> should the integration/acceptance test run on the device
<RAOF> Yes, but it doesn't.
<RAOF> Oh, actually it will.
<anpok_> [ RUN      ] AndroidGPUDisplay.gpu_display_ok_with_gles
<anpok_> unknown file: Failure
<anpok_> C++ exception with description "could not select EGL config for use with framebuffer" thrown in the test body.
<anpok_> [  FAILED  ] AndroidGPUDisplay.gpu_display_ok_with_gles
<anpok_> but that happened with devel too
<anpok_> and that one [----------] 1 test from AndroidInternalClient
<anpok_> [ RUN      ] AndroidInternalClient.internal_client_creation_and_use
<anpok_> seems to hang.. or take longer?
<anpok_> i have to shutdown lightdm and unity for that?
<RAOF> Maybe? I wouldn't think so.
<duflu> anpok_: bug 1249019
<ubot5> bug 1249019 in Mir "Test failure: AndroidGPUDisplay.hwc_display_ok_with_gles" [Medium,Triaged] https://launchpad.net/bugs/1249019
<anpok_> how do i stop unity8? i thought kill would work..
<alan_g> anpok_: as phablet: "stop unity8"
<anpok_> hm unkown job unity8
<RAOF> anpok_: stop --user unity8
<alf_> anpok_: Are you logged in as user 'phablet'?
<alan_g> sudo -i -u phablet
<alan_g> stop unity8
<duflu> And if it can't find the "stop" command then: /sbin/stop unity 8
<duflu> /sbin/stop unity8
<anpok_> arg not properly logged in .. now it works
<anpok_> hm it works
<anpok_> but i get strange framerates
<anpok_> 7800 on non nested
<anpok_> 32 on nested demo shell
<anpok_> 7800 on non nested demo shell
<anpok_> both eglplasma
<anpok_> hm 32 is for root .. and 7800 for phablet user..
<anpok_> ah
 * duflu just needs to reinstall the world and can then confirm :)
<anpok_> 7800 happened when i was using the mir lbiraries from system..
<anpok_> and i also resized the buffer
<anpok_> ah cmake  default is no optimization
<RAOF> cmake defaults are almost all wrong. :(
<duflu> anpok_: The surface size is a huge factor in frame rate. You need to keep it unchanged if you're comparing frame rates
<RAOF> Particularly for eglplasma; that thing does *lots* of per-pixel computation.
<RAOF> Less so for egltriangle :)
<duflu> Hmm, yes, I did promise less trig-per-fragment and never got around to it
<RAOF> Nah, I wouldn't bother; it's useful that it pushes the GPU a bit.
<duflu> We could move the existing shader into the planned "hand warmer" app
<alan_g> duflu: in boston I found 6 levels of nesting made any app a hand-warmer
<duflu> Handy
<alan_g> ...and terrible frame rates
<duflu> alan_g: I had a good theoretical reason why the frame rates degraded. But as recently as this morning RAOF and I couldn't see why it would happen
<duflu> I had a reason many months ago which seemed to line up with your findings... Just can't remember
<alan_g> duflu: well, there have been a lot of optimizations since
<duflu> alan_g: We pass through to bypass now?
<alan_g> I don't know. We couldn't then
<RAOF> Bypass shouldn't make any difference to framerate on our current nested stack?
<duflu> RAOF: It definitely should. If bypass was critical before, it's still critical now.
<alan_g> RAOF: if we don't bypass then surely we copy the whole buffer for each nest
 * duflu hopes alan_g is kidding
<RAOF> Yeah, we copy the buffer for each nest; I guess if you nest enough that's going to kill GPU bandwidth enough for you to notice.
<RAOF> But that's only a 60Hz copy.
<duflu> A 60Hz copy will kill performance on plenty of systems. Obviously we'll need to eliminate that
<RAOF> Yes, indeed.
<RAOF> But for things which aren't bandwidth constrained - and I'd guess that eglplasma is not bandwidth constrained - a bunch of 60Hz copies isn't going to materially affect the results.
 * alan_g thinks that measurement is the key
<RAOF> Oh, certainly.
<duflu> RAOF: Not sure. Seems to depend on the GPU x framebuffer dimensions
<RAOF> The thing that we *don't* have with nested is spiralling IPC latency, because the relevant IPC is only client <-> immediate compositor. Once we land the generalised bypass/HWC stuff, though, IPC might be interesting.
<duflu> An "extra copy" was the reason why XMir never performed as well as X, despite the fact it should have been faster than X. Let's not get into the habit of accepting extra copies, or we may indefinitely lag behind existing X performance
<anpok_> hm for the nested hwc stuff client api needs to be changed too? or would nested behave like a client with a bag of buffers to post?
<RAOF> I'm not advocating that we accept extra copies.
<RAOF> Indeed the client API needs to change for the nested HWC stuff.
<duflu> anpok_: It's transparent. The client should never know
<duflu> Really?
<anpok_> duflu: the "can-you-compose-part"..
<alan_g> anpok_: the point is that that the client doesn't know
 * duflu doesn't remember that discussion
<anpok_> yeah it starts to blur away
<alan_g> anpok_: what "can-you-compose-part" was left at the end of discussions
<alan_g> We ended with "you will compose..."
<anpok_> alan_g: i thought only for the nested case.. yes
<alan_g> anpok_: you're talking about the revised composite loop discussion?
<anpok_> yes
<anpok_> but maybe that happened when my stomoach toldme that i am continental
<alan_g> We ended with unity8 doing its own thing and then passing a set of surfaces(?) to Mir wht the instruction "you will compose this"
<RAOF> alan_g: The nested compositor is a client; it has to know.
<RAOF> unity8 will pass that set of surfaces to it's Mir, which will pass that set of surfaces over the client API up to usc, which will composite.
<RAOF> s/'//g
<duflu> That doesn't sound right. We'd be explicitly preventing hardware composition/overlay/bypass... ?
<alan_g> RAOF: there's still no "can-you-compose-part"
<RAOF> alan_g: Correct.
<RAOF> alan_g: But there *is* a change in the client api, to allow passing the bag of buffers to composite up.
<RAOF> (Because usc is the only thing that can reasonably allocate hardware resources)
 * RAOF declares EOD, but may be around later to argue further :)
<anpok_> and here i need to dig deeper
 * alan_g thinks maybe we need to get into the same timezone for a proper argument
<anpok_> we talked about usc not being able to do hardware overlays due to the way buffers got allocated
<alan_g> anpok_: this is all "future optimization" as for the time being unity8 is only passing a single buffer
<anpok_> and that we might be able to remember those buffers/surfaces?
<anpok_> ah ok
<anpok_> but then we dont use hwc
<alan_g> we will
<anpok_> but therfore we need to reidentifiy through one nested compositor that this is for the same surface we had in the last bag..
<anpok_> alan_g: just wanted to finish my thoughts - while being interrupted by wife .. -> need to hunt something for lunch
<duflu> OK, that kind of makes sense for the complicated case of some overlays and some non-overlays. But we should probably focus on not breaking the existing bypass in the simple one-fullscreen-surface case
<alan_g> duflu: I'm not convinced it isn't already broken in nesting
<alan_g> But otherwise +1
<duflu> alan_g: isn't? or is?
<duflu> I'm just saying make sure bypass still works before covering complicated partial overlays
<alan_g> duflu: has it ever worked in nested mode?
<duflu> alan_g: No idea. I haven't been able to test nesting on desktop yet. Just reinstalling trusty at present
<alan_g> duflu: me neither
<duflu> But it's definitely a requirement. The need for performance at least 90% that of X is still a need
<duflu> Ideally better
<alan_g> Agreed. I was just reacting to "not breaking" by saying we likely need to fix first.
<duflu> So if it's not implemented yet, who's working on finishing nesting?
<duflu> Anyone, or are we distracted?
<alan_g> No-one at the moment
<duflu> OK, well it's all just talk right now anyway. I'll soon get back to speed and implement some automation for gathering numbers
<alan_g> But RAOF has been landing stuff to make it work on mesa and kdub has been fixing some problems on different android stacks. It's only just getting to the "it runs" stage.
<duflu> Yeah I know. Which is fine with me, because it should become usable just as I'm ready to use it
<duflu> ... this week at least
<anpok_> ;32m[ RUN ] ServerDisconnect.client_detects_server_shutdown
<anpok_> unknown file: Failure
<anpok_> C++ exception with description "Timeout while waiting for child to change state" thrown in TearDown().
<anpok_> ;31m[ FAILED ] ServerDisconnect.client_detects_server_shutdown (60188 ms)
<anpok_> something like that happened on jenkins for roafs merge request
<anpok_> is that something that happens now and then .. (timeout in unit test..)
<alan_g> anpok_: something like that is happening for several requests
<alan_g> Looks like recently switched on tests are failing intermittently
<alan_g> alf_: are you working today?
<alf_> alan_g: yes
<alan_g> I was going to look at our new test failures - but not if you're already onto it?
<alf_> alan_g: I am currently working on screenshotting/casting, but I can take a look at the failures. Are these the ones mentioned above?
<alan_g> alf_: No I'll look - I just didn't want to duplicate effort
<alf_> alan_g: ok, thanks
<mterry> I need help with Mir + Qt integration.  Specifically, strategies for getting as far as possible into a process before causing Mir to wait due to screen-off  (i.e. I want greeter to load as much as possible before pushing buffer to Mir)
<mterry> Maybe use a different Qt backend, get everything prepped, then switch to Mir?  Is that even possible?
<mterry> Or use some Mir API to queue changes, but not actually push the buffer until I ask?
<mterry> greyback, ^ ?  Or do you know who best to ping?
<mterry> ricmm, ^
<kdub> 'getting as far as possible into a process'
<kdub> ?
<kdub> i also think our power model isn't flexible enough to handle USC in the mix as it stands today
<mterry> kdub, the way it works right now
<mterry> kdub, is that if you are in your session, and press the power button to lock...
<mterry> kdub, the greeter process is frozen by Mir quite early in its lifecycle and so after the user turns screen back on again, it takes a couple seconds for greeter to finish loading and display on screen
<mterry> kdub, I'd like to get that loading to happen while screen is off
<mterry> kdub, but right now, Mir is getting in the way
<kdub> yeah, a bit of a different problem than what I was talking about
<mterry> I believe Mir is freezing us in the runQMirServerWithClient call
<kdub> do we know which call is blocking?
<mterry> ^  I can get more details if needed, but maybe that is enough of a clue?
<mterry> That call is in unity-mir
<kdub> eh, doesn't mean much to me
<kdub> without digging
<mterry> Which eventually calls mir::run_mir
<mterry> kdub, ^ does that ring a bell?
<mterry> That's really all it does.  And connects to QApplication::quit
<mterry> Well, it also creates ShellServerConfiguration
<kdub> what's probably happening is
<mterry> Which might be blocking on some graphics call
<kdub> usc stops serving buffers out to the greeter (because its obscured from view)
<mterry> I don't think this is USC specific.  I saw the same thing with just standalone unity8.  When the screen is off, Mir freezes all clients
<kdub> we were talking about that last week
<kdub> and the plan was to improve our IPC a bit for that situation
 * kdub forgets who was looking at that though
<mterry> kdub, that doesn't mean much to me.  Does that mean you wouldn't freeze clients?
<mterry> kgunn, ^ do you remember who was looking into that?
 * kgunn reads
<kdub> kgunn, it was the discussion about the different 'channels' of ipc requests need
<kdub> circa wednesday?
<kdub> and how acquiring new buffers does not need to be serialized at the protocol level with display requests
<kgunn> kdub: mterry ....is this the long desire racarr topic of wanting to have a split queue on the server side....
<kgunn> in order to untangle unrelated events
<kgunn> e.g. some events you don't want serialized in with the rest
<kdub> yes
<kdub> in as far as I understand the problem mterry is describingc
<kdub> mterry, what i understand you to want is...
<kgunn> mterry: kdub ...if that is it, then its racarr ....we were thinking maybe january
<kgunn> see this bp
<kgunn> https://blueprints.launchpad.net/ubuntu/+spec/client-1404-mir-performance
<kgunn> kdub: yeah...i think your right...becuase this was exactly the point...seperating render queue fom things like power event queue
<kgunn> btw...i have this one weird dysgraphic tick...i often type "g" for "q"....so if you see gueue in a minute..just replace w queue in your head
<mterry> :)
<kgunn> its totlally weird....they;re not even close on keyboard or in alphabet....evidence i think in shapes
<mterry> kgunn, well, just so ya know, without that feature, locking delay might be enough of a regression to block landing split greeter.  Can still develop feature branch on side, but in terms of landing, there's probs a dependency there
<kgunn> mterry: ok....so its become more than just a nusance of that "stale" screen shot appearing
<kgunn> ?
<mterry> kgunn, yeah.  The stale screen shot is still a nit, but even with that one frame fixed, there'd still be a couple seconds delay as the greeter comes up because Mir is preventing startup
<kgunn> crap
<kgunn> mterry: anyway...when i do get hold of racarr...we'll try to bump this in priority (at least the split q part)
<kgunn> mterry: so to distill it into what you need...you need to be able to queue up rendering even tho the screen is off ?
<kdub> we won't be able to do that
<kdub> if the screen is off, more likely than not, the clocks are powered down :/
<mterry> kgunn, sorry, missed highlights.  Yeah, I want to queue up rendering
<mterry> kdub, if something is using cpu, I don't think we suspend everything
 * mterry has to jet
<kgunn> kdub: mterry ...well actually you're wanting to "pre-render" just before waking the screen right ?
<kdub> mterry, but we need the cpu, gpu, and bus clocks up to perform a render
<kdub> mterry, i guess once 'power on' comes over dbus from powerd, you're probably okay to do a render there
 * kdub writes iterator over SurfaceStack
<kgunn> kdub: did we get to the bottom of the exception in screen blank/unblank rapidly in succession ?
<kdub> kgunn, no
<kdub> kgunn, still around?
#ubuntu-mir 2013-12-12
 * duflu suspects we'll be landing things by hand again :/
<RAOF> Wow. I think I may have found a case where g++'s error message is better than clang's.
<RAOF> Huh. Tell a lie.
<RAOF> Bah!
<RAOF> C++11, why does âGLContext(GLContext const&) = delete;â delete all subclass' move constructors?
<RAOF> Ah, ok.
<RAOF> So, nested worked on android by accident *anyway*.
<RAOF> (It selects an EGLConfig supporting EGL_WINDOW_BIT and then proceeds to create a pbuffer surface with that config)
<RAOF> Man, we have *far* too many EGLContext wrappers.
<duflu> Code duplication... to be sure to be sure
<alf_> RAOF: kdub wanted to deduplicate, but it seems you got there first
<RAOF> Yup.
<anpok> duflu: i meant the methods of DefaultServerConfiguation are spread accross multiple cpp files
<duflu> anpok: It's not a class or a method. I think you're confusing default_configuration with DefaultServerConfiguration. They're unrelated
<anpok> oh .. too many files named default_configuration.cpp
<alf_> anpok: That's so that we can keep implementation details internal to the components that provide them. Each component implements part of the DefaultServerConfiguration in the default_configuration.cpp file located in its source directory.
<alan_g> duflu: did we figure out what causes the CI test failures?
<duflu> alan_g: No, haven't looked very deeply. They commenced failing again as soon as I said they were passing
<duflu> alan_g: Just got a full pass a second ago!
<alan_g> There's a lesson in that! ;)
<duflu> This is way too erratic and unreliable
<alan_g> +10
<tvoss> didrocks, can you help alan_g and duflu track down the test flakiness?^
<didrocks> tvoss: isn't that the CI team role or the QA team one?
<didrocks> tvoss: FYI, all known flaky tests are summarized in my last emails
<didrocks> if you see more failure, it's either:
<didrocks> - working with the other upstreams to get their new revealed flakyness fixed
<didrocks> - or fix a real bug
<didrocks> (too many bugs are excused as flakyness, where they are flaky behavior in reality)
<tvoss> didrocks, fair, just trying to identify a POC
<alan_g> didrocks: I was discussing it with ChrisGagnon yesterday - we're getting inconsistent (and not locally reproducible) results on the phone hardware that's just been switched on.
<didrocks> alan_g: will be interesting to have all debug infos for the other teams to fix it (can be autopilot, can be the app or can be a real issue)
<didrocks> anyway, I think it's QA/CI team that you want
<didrocks> to help identifying the cause
<alan_g> didrocks: I guess you've been too helpful to tvoss in the past. ;)
<didrocks> ahah, no, he still has credits on my help card :p just I think I won't be able to help reliably (especially with all the meetings I'm in)
<didrocks> and I think some people need to fulfill and own their role now ;)
 * duflu is paranoid and assumes he has not credits left
<duflu> Although I don't think we need didrocks help on this issue yet
<alan_g> greyback: are you subscribed to mir-devel and the "Shell communication channel: simple, half-assed or fully-arsed?" discussion
 * alan_g wonders why his keyboard just switched to US layout
<greyback> alan_g: I am. I see your thread, I'll add my 2cents shortly
<RAOF> EOD for me.
<alan_g> Goodbye RAOF, have a nice evening
<tvoss> RAOF, o/
 * duflu isn't sure using one's full arse is in fact better than half thereof
<duflu> And on that thought, good night
<mterry> kgunn, when might we see a new mir drop? (resending, because I think IRC timed out on me)
<seb128> mterry, one day you need to get a stable internet connection ;-)
<kgunn> mterry: i'd like to say next week
<seb128> mterry, or an IRC proxy
<mterry> seb128, naw, anything important is logged  :)
<seb128> ;-)
<mterry> kgunn, :(  ok
<kgunn> mterry: we've got wonky integration tests right now on the dev branch that alf is trying to sort thru
<kgunn> as soon as those stabilize we can update
<kgunn> mterry: is there a feature on dev you really need pulled thru ?
<mterry> kgunn, yeah, this is the bug racarr fixed at the sprint, blocking nested mode
<mterry> kgunn, I can wait
<mterry> kgunn, just wanted to see it land
<kgunn> mterry: well...me too
<kgunn> mterry:  i was ready to promote it this week...but we started seeing flaky ci
<kgunn> mterry: what's bothering me...we've been chasing for a few days...and its nothing easy...we're starting to think stuff like...toolchain deltas or low level arm diff between calxeda vs n4
<kgunn> calxeda being the big arm server where the build is done
<kgunn> so its native...but not to the same arm core
<kgunn> and its the classic...only the auto ci will fail...no local attempts fail
<mterry> kgunn, yikes
<mterry> greyback, so I've heard that scenegraph will make animating stuff in USC easier.  Is that because I'll be more easily able to use Qt stuff or what?
<greyback> mterry: essentially with QML, any application surface will be added to the QML context as an Item. So you can animate it with the usual QML animation system
<mterry> greyback, hmm, OK.  And the USC would be able to do the same with session surfaces
<greyback> mterry: as an example, see http://bazaar.launchpad.net/~gerboland/+junk/qpa-mirserver/view/head:/qml-demo-shell/qml-demo-shell.qml
<greyback> mterry: when a new surface appears, its x coordinate is animated in. When it is destroyed, it scales to zero.
<greyback> mterry: yep
<greyback> mterry:  to USC, the unity8 user session is just a surface
<mterry> greyback, awesome.  I want to play with that.  What is rough ETA for landing?
<alan_g> greyback: once you start using hardware overlays that won't be true
<greyback> alan_g: sure, once hardware overlays are happening, QML won't be drawing the surface (hardware will), but it will still manage the surface
<greyback> mterry: oh January, maybe later. It's in demo condition still. I'm still learning the ins and outs.
<alan_g> greyback: usc is in the path to hardware - so the unity8 session becomes a set of surface
<greyback> alan_g: sure, but unity8 will decide what surface(s) to be overlaid, send that to USC which will either hardware draw it, or fallback to GL. But that still requires unity8 to manage the surface properties
<mterry> greyback, OK, so not baked enough for me to try and use?
<greyback> mterry: let me send you some bits and pieces so you can play.
<kgunn> racarr: btw, i meant to tell you earlier... mterry was chatting with me yesterday and was indicating that
<kgunn> the whole seperate queue for differing events was going to be more critical sooner that later
<kgunn> because it wasn't just an annoyance of that stale frame showing on screen-on
<kgunn> mterry cmiiaw...but you're effectively  needing to render prior to the screen coming on
<kgunn> mterry: and i can't remember...was there some other reason it was going to be critical ?
<mterry> kgunn, just that it was an ugly enough regression when splitting the greeter that it would likely block landing
<mterry> kgunn, the problem being that Mir freezes the greeter early in its startup, so it can't queue up what the screen will look like for when the screen does come back on
<anpok_> hm my connection is getting bad again
<kdub> kgunn, ping
<kdub> if its not your eod
<kgunn> yo
<kgunn> kdub:
<kdub> i've wandered above mir in looking for that bug...
<kgunn> kdub: ok...do we need gerry to pick it up ?
<kdub> might be something I want to look at with him
<kdub> because I see in unity-mir the sequence coming off of dbus is on, off, on, on
<kdub> and the double on causes us problems
<kdub> and from powerd's perspective, i just see  on, off, on, off repeated
<kdub> i don't know what dbus can or cannot do with message ordering
<kgunn> greyback: you really on ?
<greyback> kgunn: yes, but only because I forgot to turn off IRC :)
<greyback> kgunn: what's up?
<kgunn> greyback: oh, sorry...but if you're tempted ^
<kgunn> what kdub is looking at....2 "on" msgs
<kgunn> causing screen to stay off
<kdub> greyback, could dbus send out of order messages?
<greyback> kdub: dbus guarantees order of messages
<greyback> well as long as there's 1 source & 1 destination
<kdub> could it send a message twice?
<greyback> kdub: so you get "on off on on" all over dbus? From powerd?
<kdub> yes, from powerd
<greyback> kdub: nope, never heard of that happening
<kdub> but looking through powerd, looks like it should never do that
<kdub> i'll keep poking around
<greyback> if you've no luck, mail me before you EOD, and I'll take it up in the morning
<kgunn> greyback: thank you
<kdub> alright, thanks
<greyback> kdub: it's strange as I thought this line in unity-mir would prevent it asking Mir for a double-on:
<greyback>         if (displayConfigOutput.power_mode != newPowerMode) {
<greyback> dbusscreen.cpp:69
<kdub> that would stop the blank/unblank, but not the compositor stop/start
<greyback> oh
<greyback> hmm
#ubuntu-mir 2013-12-13
<duflu> Free karma: https://code.launchpad.net/~vanvugt/mir/version-0.1.3/+merge/198507
<RAOF> Arse. My nested testing on android was not, in fact, testing nested.
<RAOF> Aww, yeah. *Now* I'm really testing nested, and it still works. Hurray!
<duflu> RAOF: Cool. Just in time. I got my script for instantly logging input latency going yesterday
<duflu> The only weird and surprising thing so far is that MirKeyEvent has half the latency of MirMotionEvent
<duflu> I guess it's much simpler
<RAOF> Good, and also still works on mesa.
<duflu> Five MPs waiting to land. Lay your bets on how many actually will
<RAOF> Hm. You know what this code doesn't have any of? Tests.
<RAOF> Hurray for tests finding logic errors!
<RAOF> Bah. g++, be better at flow analysis.
<RAOF> duflu: https://code.launchpad.net/~raof/mir/check-for-surfaceless/+merge/198510 should be now be landable, assuming that g++ remains well-behaved.
<duflu> RAOF: Thanks. Though I'm using N4 for nested testing right now
<RAOF> Cool; it works there too :P
<tvoss> greyback, Saviq meeting?
<tvoss> alf_, are you joining us on the hangout?
<alf_> tvoss: what hangout?
<anpok|afk> regarding the transparent nested surfaces..
<anpok> it kind of works..
<anpok> the client examples that we have dont seem to request per pixel translucent surfaces
<anpok> so I hacked around eglplasma to get a visible difference..
<anpok> is there already a good example that plays with transparency that I missed?
<anpok> and if not -- do we want one?
<RAOF> anpok: multiwin might do transparency?
<RAOF> If not, yeah, we'd want a quick example.
<alan_g> anpok: multiwin does use transparency
<alan_g> anpok: hacking extra options that demonstrate features into the examples is a valid pastime
<anpok> yeah.. maybe eglplasma was probably a bad example - I had to change the shader code too
#ubuntu-mir 2013-12-15
<Stskeeps> x
#ubuntu-mir 2014-12-08
<mlankhorst> racarr_: how are multiple touchpoints supported by mir currently?
<anpok> mlankhorst: the MirMotionEvent inside MirEvent stores an array of MirMotionPointer, this part is currently redone with the MirEvent-2.0 proposal..
<mlankhorst> anpok: yeah but I mean there can be multiple fingers then?
<anpok> yes
<mlankhorst> ok
<mlankhorst> what about touchpads?
<alan_g> greyback_: have your concerns been addressed here? https://code.launchpad.net/~mir-team/mir/allow-lock-surf-orientation/+merge/242984/comments/599192
<greyback_> alan_g: yeah, it's good for me
<alan_g> thanks
<mlankhorst> how do you get a ppa for phone?
<alf__> mzanetti: greyback_: What's the requirement for the cursor in terms of enabling it and disabling it on the phone? Do you want runtime control or will a flag to USC be enough (I guess the first)?
<mzanetti> alf__: I guess in the end we want runtime control in any case
 * greyback_ agrees, runtime would be ultimate goal
<mzanetti> but for a start any of those would be ok I guess... maybe Gerry has some more ideas
<alf__> greyback_: mzanetti: OK, I will start with a flag to USC to move more quickly and unblock you. We can move to something more elaborate later.
<attente_> RAOF: is that like a full-screen transparent input-only surface?
<racarr_> mlankhorst: Each pointer_coordinate in the MirEvent array is a touchpoint and each MirEvent for a given device will report the state of ALL touchpoints, uh
<racarr_> as mentioned its being redone, to take care of issues like
<racarr_> touchpads don't really work because you cant introspect various axes and see which are relative/absolute
<racarr_>  + all the touchpad emulation stuff is missing, e.g. two finger  scroll, etc
<mlankhorst> racarr_: yeah the thing I need
<mlankhorst> racarr_: will it use libinput?
<racarr_> mlankhorst: Yes.
<mlankhorst> yay
<racarr_> Work is underway to use libinput/android stack per device
<racarr_> :)
<RAOF> attente_: No, it's a surface that captures the mouse (and will capture most keys, too) on focus, among other things.
<attente_> RAOF: ah, cool. any idea when it will be available in mir?
<RAOF> attente_: Not really, sorry.
<RAOF> attente_: It's on the backlog, but not one of the current priorities.
<attente_> RAOF: ok, thanks
<attente_> RAOF: do you know if there's a way to set the z position of a surface through the client api for a multi-surface application?
<RAOF> Not currently.
<RAOF> I'm not sure if we'll expose that capability (as opposed to raising surfaces).
<attente_> oh ok. that's what i wanted actually, just to be able to bring a particular surface to the front
#ubuntu-mir 2014-12-09
<racarr_> Hmm if I was smart I would have first ported MirSurface and MirScreencast to MirBufferStream in an independent MP before adding the surfaceless buffer stream type....
<racarr_> and if I was really smart I would probably do that now even though it involves repeating some work
<racarr_> :(
<racarr_> lol
<racarr_> about EOD...
<racarr_> Morning duflu :)
<duflu> racarr_: Hmm, already?
<duflu> racarr_: Hello!
<greyback_> duflu_: hey, since I'm up rather late hacking on multimonitor, I'll definitely miss our catchup later on
<duflu_> greyback_: Fair enough. I do have a fun WM branch that is usable but it's not pretty enough to propose yet
<duflu_> Started down the slippery slope of "hey it's easy to implement all WM at once" without breaking it up
<greyback_> duflu_: ok, well we're still stuck with single surface apps just yet, so we need to fix that
<greyback_> and all those surface types need to be connected up in qt/gtk...
<duflu> greyback_: I'm working on surface states right now. The types work (parenting?) I have deferred to the rest of the team since my proposals were voted down
<greyback_> grand so
 * duflu looks up Irish vernacular
<greyback_> loosely translates to "fair enough"
<duflu> greyback_: grand so
<greyback_> :)
<duflu> greyback_: There's our catchup done. Go sleep
<mikodo> I would like to see Mir be developed with it's own feature of inversing the display.(Independant of X or Xmir with "Xcalib" or by using compositors like Compiz and Kwin).
<greyback_> duflu: brain still buzzing
<duflu> mikodo: That's actually trivial to do in a fragment shader. Only a little messy right now for Mir to switch shaders on the fly. But we'll improve that
<duflu> red = 1 - red; green = 1 - green ...
<mikodo> duflu, Thanks. I remain hopefull for iths
<duflu> mikodo: Although Unity8 replaces most of that so such features would have to be requested from each shell
<mikodo> duflu, Here's hoping for it ... Thanks
<duflu> mikodo: When and if I get to implementing dynamic shader switching I'll make that the first test case, for the Mir demo shell at least. You'd have to request it from Unity8 separately
<mikodo> duflu, hmm, where
<duflu> mikodo: https://bugs.launchpad.net/ubuntu/+source/unity8/+filebug
<mikodo> duflu, When should I ask
<greyback_> mikodo: right now, so we can keep it in mind, with other a11y features like zoom, high contrast, etc
<duflu> mikodo: Whenever you like. Worst case is they will say "never". But ideally it will get logged as an enhancement for future
<duflu> mikodo: greyback_ is the Unity8 man
<duflu> And needs sleep
<mikodo> duflu, Thank you. Alright.
<duflu> That's annoying. The only Nvidia low-profile fanless cards that fit in my system are still the old 210's
<duflu> Although a 610 with a fan will fit
<duflu> alf__: Also software cursor during zoom FTW (Super+mousewheel)
<alf__> duflu: indeed
<duflu> alf__: Between zoom and rotation it's easy to see the renderer/compositor needs to speak up when software cursors are needed
<seb128> hey there
<seb128> question for you ;-)
<seb128> how work does Mir support multimonitor atm, is there work planned for that already/if so where are the specs/details?
<seb128> things like geometry of the monitor, their respective position, having a primary monitor concept, etc
<seb128> equivalent to xrandr apis to change those
<alan_g> seb128: there is some basic support. See examples/example_display_configuration_policy.h but it is currently left to the shell to implement any logic around it
<seb128> alan_g, thanks
<seb128> alan_g, that file doesn't have a lot, it suggests that the option are mirror or side-by-side?
<seb128> I guess no way to do like in xrandr atm, define position, like one monitor on top of the other one?
<kdub> there is... "mirout"
<alan_g> seb128: something would have to implement a cleverer policy that the proof-of-concept examples there
<seb128> kdub, alan_g, are what is currently supported and what is planned documented somewhere?
<seb128> the cleverer policy is mir work? or shell/unity8 one?
<alan_g> libmirserver supports mirroring. There's an example that also supports sidebyside and single display to prove other options are possible.
<alan_g> We don't have any other options in our "backlog" AFAIK - but...
<anpok> alan_g: hm i think seb128 means free placement of outputs and resolution changes per output..
<anpok> during runtime ..
<kdub> we can do that
<kdub> on mesa
<seb128> it means that it should be working/we could write a configuration UI for unity8-desktop-next?
<seb128> like do the same current desktop do
<seb128> allow to move monitors on the left/right/top/bottom, change their resolution, define which one is primary, etc?
<seb128> mir supports it and client apis are there?
<seb128> kdub, ?
<alan_g> kdub: isn't http://unity.ubuntu.com/mir/group__mir__toolkit.html#ga89043c48c15e7a020619fdd80e6a46dc etc session local?
<alan_g> I mean  mir_connection_apply_display_config() applies to the current session, not to the desktop env
<kdub> alan_g, yes, iirc, it applies to the current session
<seb128> what's the difference between current session and desktop env?
<alan_g> seb128: the session belongs to a client application
<seb128> like unity8?
<alan_g> seb128: like camera
<seb128> hum, how that works?
<seb128> usually you configure your monitor setup as you wish your config to be and stay
<seb128> like external 24" on the left, laptop on the right
<seb128> and something apply that config on start
<seb128> and it stays until something change it
<seb128> what would be the client application in that case?
<alan_g> seb128: that's why I didn't think what kdub referred to met your need
<seb128> k, thanks
<seb128> where should I open a bug if I register one about my usecase
<kdub> right, I don't think it would either, now that I understand better, although we do have a lot of the plumbing, more modifying the policy
<seb128> mir? unity8? something else?
<seb128> kdub, willcooke asked me to register bugs for things we need from mir to have a full desktop, trying to do that ;-)
<alan_g> kgunn: where does this belong? ^^
<kgunn> just a sec, on a hangout...
<kgunn> camako: ^ you might read thru as well....
<camako> kgunn, I was
<kgunn> so i can see on desktop where there may be fixed physical screens with relative position, this makes sense, but with say phone/monitor it doesn't
<kgunn> surely we want the feature, question is...where does the logic/tracking reside & where does the policy decide
<kgunn> sort of feels like mir should prolly keep track of the positions for any sort of optimizatino or shared FB or some such could happen
<kgunn> but then shell would determine policy, e.g. i'm on a desktop or i'm on phone , a-la hypothesis generator from
<kgunn> https://docs.google.com/a/canonical.com/presentation/d/1K1oV4vMc-FduKUNYYO62zPUCU5WMb74zjer8KzYzhLg/edit#slide=id.p
<kgunn> greyback: mzanetti ^
<kgunn> in short, to support relative monitor placements in a converged world...
<greyback> sounds like htere's no one answer for all our convergence cases
<greyback> I guess some displays could be isolated from others, i.e. phone UI probably should not be part of the entire "virtual desktop", as it doesn't make a huge amount of sense to drag an app to the phone screen with a mouse
<kgunn> seb128: so is system-settings a client of mir in any way today ?
<seb128> kgunn, well, system settings is a standard app, I expect it to write some configuration on disk but it's not a service so it's not going to apply it, unity8 should probably be the one doing that
<greyback> perhaps Mir could tag some displays as being configurable, and some as not - shell could decide which display is and isn't configurable
<kgunn> seb128: yep...
<kgunn> greyback: when you say "configurable" you mean...can have a relative position to the other display ?
<seb128> greyback, well, on "docked phone" it could make sense to be able to turn the screen of the phone on or off, the same way you do it today for a docked laptop
<greyback> kgunn: yeah
<greyback> seb128: true.
<kgunn> it does make sense tho that mir would need to add "output" coordination...to render windows across screens, and mouse trajectory etc
<greyback> sounds like we want Mir to support multiple display collections. phone display would be set as member of a single collection, on it's own. Then multiple monitors could all belong to another collection. Displays in a collection can be configured relatively to eachother
<greyback> only a single collection can capture a mouse
<greyback> windows/applications cannot be shared across collections
<seb128> greyback, greyback, I get from that discussion that we don't have a blueprint/bug/googledoc discussing those needs yet?
<greyback> seb128: I'm not aware of any docs on the topic
<seb128> where should we start? with a bug report against mir?
<greyback> bug to start, but really we need to determine what is actually wanted
<greyback> scope is kinda big
<kgunn> seb128: yeah...and you're early :)
<seb128> yeah
<seb128> kgunn, well, willcooke asked us to register bugs for things that "desktop is going to need from mir"
<seb128> that's one of those
<seb128> we need to know what is missing to get a full desktop
<seb128> so we need to start listing those
<seb128> even if it's early to work on them
<kgunn> seb128: absolutely, no worries
 * willcooke likes being early
<willcooke> but is late to this conversation
<willcooke> :)_
<seb128> hehe
<kgunn> seb128: likely would need a bug on design as well...like, what do we want to do on phone/tablet....
<kgunn> e.g. android made a real concrete decision to just mirror
<seb128> kgunn, bug on ubuntu-ux/mir/unity8 I guess
<kgunn> yeah
<seb128> well, android doesn't claim to support developer desktops yet
<kgunn> i think we should collectively design a phase 1 tho...
<seb128> they might revisit if/when they try to reach there
<kgunn> e.g. desktop we want parity, phone should at least mirror
<seb128> right
<kgunn> i could totally see on phone
<kgunn> having a glowing-edge or something where you can flick apps or some such
<kgunn> to magically appear on monitor
<kgunn> kind of special desktop extend mode...
<kgunn> or phone becomes a remote or vcr-button mode
<camako> ... yeah a lot more can be done on a phone, though... depending on how much we wanna do
<kgunn> camako: yeah...i heard a rumor you once had to work on such stuff :-P
<camako> heh.. I heard that rumor too.
<kgunn> camako: so i think we just found something for alf and alan to work on in the new year ;)
<camako> kgunn, yeah.. this is very murky though, we need arch/design input in terms of how far we want to go
<camako> do we want apps to be aware of these displays and change their behaviour, etc.. (the "remote control" use-case requires that)
<camako> anyways, let's start with a bug
<camako> :-)
<kgunn> camako: agree with murky statement, hence i'll take it on me to draft a spec for something like a phase1(desktop parity & reasonable expectations for phone), we can include ideas for future under a phase2
<camako> kgunn, sure
<racarr_> camako: Did you mean to update your review status on
<racarr_> add-more-event-getters?
<greyback> can anyone tell me how/where Mir decides to use clone mode for multimonitors?
<racarr_> greyback: I think you are looking for the DefaultDisplayConfigurationPolicy
<camako> racarr, I was hoping to see something logged for the aborts.
<racarr_> camako: oh ok
<greyback> racarr_: that's it, thanks
<racarr_> hmm wait
<racarr_> why have I
<racarr_> lol these statements were originally assert
<racarr_> and now they are aborts
<racarr_> preceded by log strings
<racarr_> that contain
<racarr_> assertions
<racarr_> :/
<racarr_> lol I guess they are ok in release builds though
 * alan_g would have been happy with #undef NDEBUG
<alan_g> camako: could you find time to review this today? https://code.launchpad.net/~alan-griffiths/mir/publish-server-examples-and-docs/+merge/244026
<camako> alan_g, yep I was working on it right now as a matter of fact
<alan_g> camako: then note that I've just updated it
<camako> alan_g, ok, I'll refresh
<racarr_> camako: What do you think the log messages should say? I can't think of anything useful
<racarr_> the only thing interesting afaics is the calling frame which we obviously dont have
<kdub> racarr_, would BlankingHwcControl be a better name?
 * kdub agrees that it could be better
<kdub> and the 1.4 impl would be PowerModeHwcControl
<racarr_> kdub: Yeah I think that does make more sense
<bschaefer> greyback, hey, any luck with those pixel formats + sdl?
<greyback> bschaefer: not had chance to give it a go yet, sorry
<bschaefer> greyback, no worries :), jsut wanted to double check
<mibofra> hi guys
<mibofra> does someone remeber me xD ?
<anpok> how could we forget
<mibofra> lol hi anpok
<mibofra> anyway, I'm again with utouch in chroot, another setup, on the latest rootfs. Now everything seems to not prompt errors, egl demos too (anyway only render_to_fb continue displays something )
<mibofra> but I've started another mir demo server and mir_stress
<mibofra> with mir_stress I get this: UMP: ump_arch_open() failed to open UMP device driver
<mibofra> (notice that I've /dev/mali and /dev/ump reachable)
<anpok> what do you mean by another?
<anpok> in parallel to an already running one?
<mibofra> anpok, deteled the other one and set up another
<anpok> deleted the server?
<mibofra> anpok, deteled all the rootfs and unrolled the latest
<mibofra> mounted in bind /dev and company
<mibofra> chrooted on ubuntu touch
<anpok> ah reading correctly helps
<anpok> mibofra: i can only guess (and I would start by looking at which operation failed through strace) AlbertA isnt here and kdub might have better ideas
<mibofra> anpok, ok
<kdub> mibofra, yeah, only one hwc-owning server should run at a time
<mibofra> kdub, and I've only one server in background xD
<mibofra> *ad noone in foreground
<kdub> for a total of 2 running servers in the system?
<kdub> also mibofra, does the server and basic clients work?
<kdub> if it does, perhaps the stress test is just covering a corner case that we have a problem with (and most usecases would still work)
<mibofra> kdub the matter is that now clients and demos run fine, but without displaying something, except form the standalone_render_to_fb
<kdub> try running the server with "--disable-overlays true"
<mibofra> ok
<mibofra> kdub, the same
#ubuntu-mir 2014-12-10
<racarr_> Buffer stream is supposedly done gonna let it sit for a day then do some self review/iteration though
<racarr_> don't want it to turn in to the 4500 line MR where everyone comes to hate me
<racarr_> :p
<racarr_> or rather It hink that may be what it is now
<racarr_> and want to turn it in to something else
<RAOF> Pfft!
<RAOF> :)-
<racarr_> deleting code is definitely the best way to spend last hour or so of work day
<duflu_> OK, now bzr diff is lying to me
<duflu> What the?! My whole fix got merged over without conflicts?
<duflu> That's a new and scary bzr bug
 * duflu longs for git
<mikodo> duflu, Thank you!  https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1400580
<ubot5> Launchpad bug 1400580 in Mir " Color Inverse on display. Toggle Negative Image" [Wishlist,Triaged]
<duflu> mikodo: No problem
<duflu> alf__: Could you have another look at nice-log?
<alf__> duflu: FYI, client-api-platform-operation-* branches updated
<alan_g> alf__: got a moment to review this? https://code.launchpad.net/~alan-griffiths/mir/publish-server-examples-and-docs/+merge/244026
<alf__> alan_g: sure
<alf__> duflu: oops, just a moment
<duflu> alf__: Thanks. Not sure if I'll have time to try and land them again today
<duflu> But anyone can do it
<alf__> duflu: np, thanks
 * alan_g looks to see who has... interesting: http://paste.ubuntu.com/9454116/
<alf__> aargh, merging back the trunk which contains the revert of the client-platform-* removes files from my branch!
<alf__> why bzr, why?
<duflu> alf__: Yeah I meant to warn you of that. Need to resubmit under a different name
<duflu> Because bzr is awesome
<duflu> But it was my mistake not testing x-compile
<duflu> alf__: I had the same thing happen (with less explanation) this morning. I had to download the diff from LP and patch it back in :S
<alf__> duflu: no worries, I should have checked x-compile to, but I forgot (I am used to CI checking it)
<alf__> s/to/too
<duflu> alf__: I *thought* building all platforms covered the Android code on desktop
<duflu> Must have been in #ifdef ANDROID
<alan_g> duflu: it builds the all production code, but the tests only for the first platform
<duflu> alan_g: Ah
<duflu> alan_g: We *could* build tests for both
<alan_g> duflu: there's stuff with different implementations that we'd need to split out
<alan_g> But we *should*
 * alan_g can't be motivated to log a bug
<alan_g> alf__: any opinion on mir_demo_server[_basic|_example|]?
<alf__> alan_g: +1 for "mir_demo_server"
<alan_g> I'll roll that into the update then. :)
<alan_g> alf__: pushed
<greyback> alf__: hey, on a displayconfiguration change, is there any chance existing DisplayBuffers are all destroyed and re-created?
<alf__> greyback: they are
<greyback> alf__: ok, explains things on my end
<greyback> thanks
<alf__> greyback: Do you know which channel I should use to get the latest phone image? vivid-proposed?
<greyback> alf__: yes, that's it
<alf__> greyback: ta
<greyback> np
<mlankhorst> racarr_: how's mirevent 2.0 coming along?
<kgunn> seb128: did you file a bug the other day on relative screen position ?
<kgunn> i was just chatting with alf__ and it seems we already have this :)
 * kgunn is also curious about racarr_'s answer re mirevent2.0....as is anpok
<alan_g> Have we defined any version macros that users can use to conditionally compile server code?
<racarr_> mlankhorst: The new accessors landed but we hav to port everything and make a release before we can rip out hte old event and start making more detailed changes
<racarr_> e.g. mir event-2.0 is there now but
<racarr_> equivalent to mir event 1.0 still basically
<seb128> kgunn, not yet
<seb128> kgunn, I had to call it a day yesterday and was not working today, going to do that tomorrow
<kgunn> racarr_: so anpok should start to conform to the new mirevents structures for the libinput work ?....i mean since they're in there
<kgunn> seb128: ack...so i think tomorrow your morning, just chat with alf__
<kgunn> before bugging
<racarr_> kgunn: Not yet, he still outputs the old mir event structures and clients see the new one (or the old one)
<racarr_> I think we talked about it yesterday and are on the same page
<racarr_> unless this is something else...
<racarr_> :)
<kgunn> could be, just trying to help things along
<racarr_> no worries. I am wondering if I should speed up any bits to help
<racarr_> libinput
<seb128> kgunn__, k, thank you
<anpok> re
<anpok> racarr_: ah ok, wasnt sure about outputting the old one..
<anpok> thought the new ones were just around the corner
<mlankhorst> racarr_: ok
<racarr_> anpok: Well...I dunno...like I said the new ones are there for clients
<racarr_> but even if something was mped to port every client now
<racarr_> it would be what, 2 weeks at least before we could drop the old code
<racarr_> and right now the old event is used over the wire
<racarr_> :/
<racarr_> for accessing MirEvent though you should
<anpok> hm for input .. we still have the mapping ..
<racarr_> use the new mir_input_event*
<racarr_> stuff
<anpok> yeah
<anpok> mapping to droidinput structures..
<racarr_> mm
<kdub> anpok, racarr_ any more thoughts on the namespace stuff from yesterday?
<kdub> iirc, we were thinking about changing mir::input to mir::event because "input" is somewhat vague
<racarr_> aha thats not what I was thinking ;)
<racarr_> I was thinking that mir::input is fine as it is because its understood to mean input devices
<racarr_> and that if we put everything related to events
<racarr_> in the same namespace
<racarr_> we lose that meaning
<racarr_> so if you wantt o have stuff related to MirEvent, but don't want it in the mir:: namespace
<racarr_> maybe it belongs in a mir::events:: namespace
<racarr_> or something
<racarr_> but certainly for example, an input device prober, or the input dispatcher, etc
<racarr_> I think those make more sense in mir::input::
<kdub> okay, I see the distinction, although from the graphics side of the fence... all looks like input to me :)
<racarr_> kdub: You are right a generalization could be made I just think its more confusing than helpful
<racarr_> e.g. mir::output::logging, mir::output::graphics
<racarr_> wouldn't be helpful ;)
<racarr_> lol
<kdub> right, but mir::hid or mir::events might be
<kdub> anyways, so dropping the namespace stuff... I guess we're still looking for what to do with the 3 EventSink interfaces
<racarr_> kdub: I dunno...sorry ill think about it in a  sec...furiously debugging
<AlbertA> does anyone know why we don't have a mir_surface_spec_set_output_id? we have a set_fullscreen_on_output....
<kdub> AlbertA, just a fuzzy memory, but iirc, something having to do with helping more mesa bypass happen
<AlbertA> ok...I'm just wondering so I can migrate the examples....
<AlbertA> to the new spec api
<AlbertA> since eglapp uses the output id parameter to place a non-fullscreen surface
<AlbertA> in a specific output id
<AlbertA> if the user sets up that option
<racarr_> Interesting
<racarr_> I thought output_id was equivalent
<racarr_> to fullscreen on output
<racarr_> and didnt know the other behavior was allowed
<AlbertA> so perhaps we just want to deprecate that behavior?
<AlbertA> although reading the windowing spec
<AlbertA> the system needs to support restoring the previous client context....
<AlbertA> which may include being in a certain monitor and non-fullscreen
<AlbertA> but I guess that can just be done in the server side
<racarr_> I think thats opaque
<racarr_> to the client
<racarr_> yeah
<racarr_> ikf there is any client involvement
<racarr_> its through an opaque
<racarr_> cookie
<racarr_> im not sure apps are even allowed to use fullscreen_on_output
<racarr_> afaik the approved use case is: xmir
<racarr_> and nested
<kdub> and eglspinner?
<kdub> maybe what that means is that USC allows clients to do that (returns true), but U8 does not (returns false)
<racarr_> ah probably
<AlbertA> ok, I think I have my answer :) change eglapp....:)
<anpok> kdub: no further thoughts so far
<mibofra> kdub, nothing I've checked and I've the same problems/errors of the last time. But I think, also wayland on the framebuffer library works well xD . Is there an option to force mir to use only the framebuffer (as /dev/graphics/fb0)?
<mibofra> *or the rendering method of the render_to_fb demo
<kdub> "--disable-overlays true" (argv) or "MIR_SERVER_DISABLE_OVERLAYS=true" (env) forces the render_to_fb demo rendering method
<mibofra> let's try (again
<mibofra> )
<mibofra> MIR_SERVER_DISABLE_OVERLAYS=true , well, It's visible that it's an env specification xD
<mibofra> kdub as usually segfault on egl demo, and nothing displayed on the screen for others
<mibofra> just a thing, I launch the compositor in this way:
<mibofra> unity-system-compositor --file '/run/mir_socket' --from-dm-fd 0 --to-dm-fd 1 --disable-overlays true
<kdub> try mir_demo_server_shell
<mibofra> the same result
<kdub> any kernel or logcat error msgs?
<mibofra> kdub, http://paste.ubuntu.com/9467210/ from dmesg, but I think is not really useful
<kdub> nah, so thats okay
<kdub> http://bazaar.launchpad.net/~mir-team/mir/development-branch/view/head:/doc/android_new_device_bringup.md
<kdub> has some more suggestions... one day it'll make it to unity.ubuntu.com/mir
<mibofra> kdub, from logcat: http://paste.ubuntu.com/9467244/
<kdub> and try the mir_integration_tests
<mibofra> ok
<mibofra> well, kdub it doesn't accept the filters, anyway the integration test segfault after [ RUN      ] StaleFrames.are_dropped_when_restarting_compositor and fail at http://paste.ubuntu.com/9467332/
<kdub> how does this one do?: mir_integration_tests --gtest-filter="TestClientIPCRender.test_accelerated_render_double"
<mibofra> kdub, it returns the help of mir_integration_tests
<kdub> oh, sorry, --gtest_filter
<mibofra> kdub, http://paste.ubuntu.com/9467365/
<kdub> mibofra, so, the render_overlays one won't output anything for hwc 1.0, but the server should still work (and the render_to_fb works, so thats good)
<mibofra> kdub, anyway on the android_new_device_bringup.md there is also --gtest-filter instead of --gtest_filter
<kdub> right, should be updated
<mibofra> kdub, http://paste.ubuntu.com/9467658/ , line 55
<mibofra> is normal that the compositor stops before the drawing?
<kdub> mibofra, no, its strange
<kdub> I guess if that integration test is working, and the render_to_fb works, the driver components are working... something else is going on
<mibofra> kdub, does the compositor need some tty?
<mibofra> like the tty1?
<kdub> no, it doesnt
<mibofra> ok
 * kdub hasnt seen StaleFrames be the failing test for a new device before
<mibofra> kdub, I had an idea
<mibofra> kdub, it uses /dev/ump as part of the driver (egl) no?
<kdub> perhaps, that's abstracted to mir and different on each chipset
<mibofra> I've fusered /dev/ump to see if there was something using it, and I've found something with lsof
<mibofra> I've found Binder_1 , kdub
<mibofra> maybe it interferences in a way?
<kdub> not sure
<mibofra> kdub, other process too are using ump
<RAOF> AlbertA: Requests for output_id that _weren't_ fullscreen were denied.
<mibofra> kdub, _render_to_fb access in another way, I think is not only problem of setting --disable-overlays true, because it doesn't solve the problem on the other mir servers (demo or not)
<RAOF> AlbertA: mir_surface_spec didn't change that, it just meant that you couldn't make a request that we'd automatically deny :)
<AlbertA> RAOF: ack
<mibofra> hi AlbertA, hi RAOF
<AlbertA> hi there
<racarr_> RAOF: Linux is about choice and MirSurfaceSpec is ruining it.
<racarr_> :p
<racarr_> Good morning
<RAOF> Ok. Naming problem.
<RAOF> I've got an interface, currently called Dispatchable, which has âget pollable fdâ and dispatch() operations.
<RAOF> I need to name an interface for something that has a create_dispatchable_for_me() operation.
<AlbertA> RAOF: DispatchableFactory? :)
<RAOF> Yeah, possible, but you only ever want to produce one Dispatchable from it.
<RAOF> The interface is more create_a_dispatchable_that_will_dispatch_me()
<RAOF> And it very rarely makes sense to have more than one of those.
<racarr_> DispatchableProgenitor
<racarr_> hmm
<racarr_> Sorry what is a dispatachable?
<racarr_> or rather what does dispatch() do
<racarr_> for whom
<RAOF> dispatch() does whatever should be done when there's something ready.
#ubuntu-mir 2014-12-11
<racarr_> I dunno...I dont understand enough about the problem to think of anything better than DispatchableFactory I guess
<racarr_> arranger/provider/source etc none really seem to add anything
<RAOF> I think I'm going for Dispatcher vs Dispatchable.
<racarr_> mm. Despite it being a subject of some debate I'm in to -er suffixes ;)
<racarr_> I've still never understood the point of this
<racarr_> auto foo(int bar) -> return_type
<racarr_> pattern
<RAOF> As far as I'm aware it's only vaguely interesting when you're doing crazy stuff.
<RAOF> *Or* when you don't want to have to specify namespaces.
<RAOF> (As the -> return_type is implicitly namespaced by whatever scope foo is in)
<RAOF> I don't know why we use it, because I don't think we ever use either of those properties.
<RAOF> AFAIK we just use it as a confusing alternate syntax :)
<racarr_> I wish we wouldn't
<racarr_> do things like that :/
<racarr_> lol
<RAOF> Yeah, we might want to put it in the style guide.
<racarr_> Seems you are right and that all the uses come around....
<racarr_> yeah mostly crazy stuff...when the return type is templated
<racarr_> or dependent on template parameters I guess
<racarr_> like auto foo (T a, T b) -> decltype(a + b)
<racarr_> is apparently
<racarr_> a thing
<RAOF> Right.
<RAOF> :)
<racarr_> approaching EOD :)
<racarr_> p.s. buffer stream done but I want to manualyl test screencast, etc
<racarr_> which...I didn't quite get too today
<RAOF> Woot!
<RAOF> Please subscribe me to that when you submit it.
<RAOF> I'd like to see what my suggestion hath wrought.
<RAOF> âª Let the moonlight / take the lid / off your dreams â«
<racarr_> :)
<RAOF> Hm.
<RAOF> std::shared_ptr<std::shared_ptr<std::vector<std::shared_ptr<>>>> is appearing in my code.
<duflu> RAOF: That looks suboptimal
<duflu> For human readers
<duflu> Although part of the problem is just verbosity in the language. sp<sp<vector<sp>> would be slightly better
<RAOF> There will come a time when I don't have to merge trunk into the platform probing branches more than once a day.
<duflu> RAOF: Been there. Sometimes on the same branch every day for many months :P
<RAOF> duflu: If you can work out some way to use rpath that *doesn't* involve having somewhat-fragile code in libmirserver/libmirclient (or something they link to) go ahead :)
<duflu> RAOF: One last request: Sanity check again that our parallel version installs won't break
<duflu> We don't want to regress on that one
<RAOF> Already done so.
<duflu> Jolly good. Enjoy your evening
<alan_g> duflu: alf__ should we commit lp:~vanvugt/mir/fix-1401365 directly to help clear CI?
<duflu> alan_g: I would think so
<alan_g> OK, I'll do it
<duflu> Ta
<alf__> alan_g: duflu: There is also https://bugs.launchpad.net/mir/+bug/1401364
<ubot5> Launchpad bug 1401364 in Mir "CI test failure in multiple tests" [High,In progress]
<alf__> alan_g: duflu: It's not clear if the leak is an effect or the cause. Like duflu, I can't reproduce it locally.
<duflu> Yay. Kind of hard to bisect if only Jenkins can reproduce it
<alan_g> alf__: yes. But you'd grabbed it so I wasn't duplicating effort (yet)
<alf__> alan_g: Do you know if adding noexcept to a method is an ABI break?
<alan_g> Hmm.
<alan_g> ABI isn't directly mentioned in the standard. But it IIRC noexcept isn't part of the type (i.e. one can assign function pointers) so the implication is "no".
<alan_g> alf__: @lp:1401364 it looks as though the "leak" is irrelevant - we get leaks in the forked processes because we call exit() to prevent them continuing to run the tests.
<alan_g> alf__: @lp:1401364 looking at the tests that fail it is suggestive that the exit code from the client is based on the valgrind error, when it should be the the exit code we return from the client. (There was some magic incantation about this - maybe that is what broke...)
<alf__> alan_g: Locally, when running the tests I don't get any "definitely lost" leaks, even though the forked processes still call exit() the same way
<alan_g> alf__: FWIW I find the same.
<mlankhorst> can I mix mir_surface_get_current_buffer with eglSwapBuffers?
<mlankhorst> on android
<alf__> mlankhorst: I think so. Better ask kdub later in the day.
<alf__> mlankhorst: to make sure
<mlankhorst> ok
<mlankhorst> i'm trying to get rid of the glitching on android
<alan_g> alf__: I can reproduce using valgrind --error-exitcode=1 --trace-children=yes --leak-check=full --show-leak-kinds=definite --errors-for-leak-kinds=definite bin/mir_acceptance_tests --gtest_filter=ClientLibraryErrors*:ClientLibraryThread*
<alf__> alan_g: Nice! In particular it seems that ClientLibraryErrorsDeathTest* messes up things somehow
<alan_g> alf__: I'm happy toback off now and let you investigate. Or should I did deeper?
<alf__> alan_g: I have a lead to follow now. If I get stuck I will let you know, thanks.
<alan_g> yw
<mlankhorst> alf__: but on android should eglSwapBuffers in a mir application block?
<alf__> mlankhorst: eglSwapBuffers with a mir EGLSurface needs to contact the server, so it can block until the server gives it another frame back
<Saviq> hey all, we've been getting random usc crashes on vivid, it's starting to look android-input-related: bug #1401488
<ubot5> bug 1401488 in unity-system-compositor (Ubuntu) "unity-system-compositor assert failure: *** Error in `unity-system-compositor': corrupted double-linked list: 0xaa817808 ***" [Undecided,New] https://launchpad.net/bugs/1401488
<mlankhorst> alf__: yeah, but I was still getting some glitches, do I need additional sync on android if I move my swapbuffers to a separate thread?
<alan_g> Saviq: it looks corrupt heap related. The fact that android-input is allocating memory at the time doesn't make it the cause (or exonerate it).
 * alan_g tries to remember how to run USC under valgrind
<Saviq> alan_g, if it matters, it always happened for me when interacting with the screen
<Saviq> and yeah, it's not easily reproducible, it's not rare, but totally random
<alan_g> USC won't be doing much memory management when you're not interacting with the screen
<Saviq> alf__, hey, so I have the desktop-next iso working under VMWare, can I somehow control the screen size?
<alf__> Saviq: I don't know if the KMS driver exports any other modes besides the default one. Could you try the mirout utility to see if there are other modes available?
<Saviq> alf__, hmm "could not connect to a display server", should I run as root or something?
<Saviq> alf__, ah, got it, connected to usc
<Saviq> alf__, yeah, there's plenty modes
<alf__> Saviq: can you pastebin them please
 * Saviq tries
<alf__> alan_g: https://code.launchpad.net/~afrantzis/mir/fix-1401364-death-test-leaks/+merge/244414
<Saviq> alf__, http://paste.ubuntu.com/9475199/
<alan_g> alf__: looking
<alf__> Saviq: so VMware tells us that the recommended/native mode is 800x600@60 so we choose that. I don't know what would happen if we chose a different mode (i.e., if the modes are actually supported).
<Saviq> alf__, ah, I can change the resolution in the VM settings, /me tries
<alf__> Saviq: one thing to try is to run mir_demo_server_shell and use mir_demo_client_display_config to change the mode to see if it can actually be changed.
<alf__> Saviq: this won't help with USC but it will let us know if the modes are actually supported
<Saviq> alf__, I'll try and have a look
<alan_g> alf__: I don't see any change in behaviour
<Saviq> alf__, FWIW, changing the VM settings didn't change much
<alf__> alan_g: What did you try? When running the command you pasted before without the fix I get leaks in ClientLibraryThread* tests. With the fix I don't. (Leaks in ClientLibraryErrorDeathTest are normal and expected for the forked processes).
<alan_g> alf__: exactly that
<alan_g> And I still see the test failures
<alan_g> And yes I do have the changes and saw the recompile
<alf__> alan_g: Is this a clean build of the proposed branch, or did you apply the changes to an older branch?
<alan_g> Just merged it to an existing copy of trunk
<tsdgeos> guys, what is responsible of calling frame_posted in the client? is it eglSwapBuffers? if so in which part of mir does it "hook" that call?
<alf__> alan_g: Hmm, not sure what's going on then. I built again from scratch (clean trunk no existing build directory, merged fix branch, cmake .. -Duse_debflags=true), it works with the fix and it breaks if I revert the fix.
<alf__> alan_g: Let's see what CI thinks of it.
<alan_g> alf__: I'm approacing lunch  - I'll wait and see what CI does.
<alan_g> alf__: FWIW I left a clean build running over lunch - and still see the failures. Weird
<alf__> alan_g: indeed... and s-jenkins isn't accessible to get an early peek at how the CI build is going
 * alan_g broke his tablet by trying to debug USC (and now it goes into a reboot loop)
<kdub> alan_g, you can ubuntu-device-flash --bootstrap from the bootloader screen
<alan_g> kdub: yeah. I know. But I'd rather be able to boot to a command line and revert config edits
<greyback_> alan_g: hey, could I get you to merge qtmir trunk into your refactor-after-migrate-to-mir-Server-API branch?
<alan_g> greyback_: you could
<greyback_> alan_g: branch is not under a team, but your username
<alan_g> greyback_: pushed
<greyback_> alan_g: thank you
<mibofra> kdub, hi. So I've arrived at the conclusion that the compositor stops after a while the server is running.
<mibofra> (I think the _render_to_fb demo uses another mechanism as it works fine)
<kdub> well, the render_to_fb is a subsystem
<mibofra> kdub, ok, but has it got its compositor?
<kdub> not the same one as the server
<mibofra> kdub, so it starts it internally in another way than the other servers
<mibofra> or I can't explain that the same thing woks in a case and in the others no.
<kdub> right, maybe a backtrace from where it hangs or crashes would help
<racarr_> greyback_: Just checked out lp:qtmir to build it and getting problems about no FindGMock...have you run in to this? Did we miss some files or something?
<mibofra> kdub, installing the debug symbols packages
<mibofra> kdub, anyway really I don't get errors on the server with gdb when the compositor stop
<kdub> right, it could be hung
<racarr_> Anyone have a branch of qtmir that works with lp:mir?
<mibofra> kdub, do you want a strace of the server?
<kdub> mibofra, maybe not, unless you see something interesting
<mibofra> not really
<mibofra> kdub, any ideas?
<mibofra> kdub, if you have any idea or remember some particular debug process to see why the compositor stops, let me now
<mibofra> *know
<mibofra> I'm here
#ubuntu-mir 2014-12-12
<greyback__> racarr_: hey, install cmake-extras - it has the gmock module that qtmir uses
<racarr_> o
<racarr_> greyback__: Does that have the EnableCoverageReport stuff that I proposed in another mp too?
<greyback__> racarr_: yes
<racarr_> Ah :)
<racarr_> cool
<racarr_> greyback__: Thanks :)
<greyback__> no worries
<duflu> Should it be possible that clang generates code that yields SIGILL??!
<duflu> Oh, apparently clang does emit this invalid instruction intentionally sometimes. Wonder why gcc works
<alan_g> targetting the wrong processor?
<Kaleo> hey guys
<duflu> alan_g: No, it's the right architecture. But apparently clang sometimes uses invalid instructions like an abort()
<duflu> Kaleo: Hello
<Kaleo> is there any difference in MIR's rendering or behaviour whether the phone is plugged on USB or not/charging or not?
<duflu> Kaleo: Not explicitly in Mir but the driver could (and likely would) use a lower power mode on battery alone
<Kaleo> right
<duflu> Kaleo: You see such things?
<Kaleo> duflu, one thing I notice for example
<Kaleo> duflu, is that the lock screen's background sometimes takes time to be displayed
<Kaleo> duflu, probably for the texture to be uploaded or rendered
<Kaleo> duflu, only on battery
<duflu> Kaleo: Yeah lower power mode is noticeably slow
<duflu> It gets worse... if you're careful with your efficiency then the phone thinks it's in low power mode and can clock down too much, causing stuttering
<Kaleo> duflu, interesting
<duflu> It drives graphics people crazy
<Kaleo> duflu, can you think of any reliable way to trigger that mode?
<duflu> Kaleo: No, it's driven by how little you stress the GPU
<Kaleo> duflu, does the low power mode impact CPU perf as well?
<duflu> Kaleo: I think so..?
<Kaleo> k
<Kaleo> duflu, I believe this all relates to https://bugs.launchpad.net/camera-app/+bug/1398436
<ubot5> Launchpad bug 1398436 in camera-app "Preview frozen after unlocking" [Critical,In progress]
<duflu> Kaleo: There could be other bugs at play in our code, always. I'm reminded of this talk where I think John Carmack discusses the same issue driving him crazy: https://www.youtube.com/watch?v=nqzpAbK9qFk
<Kaleo> duflu, ok
<Kaleo> duflu, concretely what happens is that after locking and unlocking the phone the camera app's rendering is not happening for a few seconds
<duflu> Kaleo: Oooh, you don't have framedropping (eglSwapInterval(0)) do you?
<Kaleo> duflu, I don't have anything outside of the pristine RTM image
<duflu> Kaleo: If a client has set eglSwapInterval(0) (which I think is unlikely) then we do have buffer scheduling bugs that will appear as a freeze
<duflu> (fixed in Mir 0.10)
<Kaleo> duflu, is MIR 0.10 in vivid?
<duflu> Kaleo: No, it's future
<Kaleo> duflu, ok
<Kaleo> duflu, I don't recall the app setting eglSwapInterval(0)
<duflu> Kaleo: There is one additional bug that will trigger such a freeze, but it's only known to happen in cases that the phone won't trigger
<duflu> Still, I expect both to be fixed in 0.10
<duflu> Kaleo: I'll grep the camera-app source in case
<Kaleo> duflu, done that, no match
<Kaleo> duflu, but there is something more
<duflu> Kaleo: Also, we only know that Android overlays are highly unstable with eglSwapInterval(0). This does not guarantee they're always going to be stable with the default eglSwapInterval(1), just moreso
<Kaleo> duflu, for the duration of the freeze, the app is not notified it is focused/active (Qt.application.active is still false)
<Kaleo> duflu, even though the process has been correctly resumed
<duflu> Kaleo: To absolutely verify it's not another overlays bug, try running with env MIR_SERVER_DISABLE_OVERLAYS=true
<Kaleo> duflu, ok, trying that
<duflu> ... for USC
<duflu> Kaleo: And then I must go for the week ...
<Kaleo> USC?
<duflu> Kaleo: Only unity-system-compositor will use the hardware overlays
<duflu> So the environment needs setting for that
<Kaleo> duflu, I can set it in /etc/environment no?
<duflu> Kaleo: Yes, but make sure it sticks after rebooting (/proc/<pid>/env)
<Kaleo> duflu, yep
<duflu> Kaleo: Please also double-check the whole stack of projects to ensure nothing is triggering eglSwapInterval(0)
<Kaleo> duflu, I grepped it all and only qtubuntu sets it
<Kaleo> duflu, if an env var is set
<duflu> ... or creating a GL context with zero
<Kaleo> otherwise it defaults to 0
<Kaleo> duflu, bug still happens with MIR_SERVER_DISABLE_OVERLAYS=true
<duflu> Interesting
<duflu> Kaleo: I think the clock-down power management stuff is a big offender but that will only cause you to miss a frame or two in my experience
<Kaleo> k
 * duflu forgets what the kernel features are that stop it from happening. It's something Linux has inherited from Android recently-ish but is not yet widely used
<Kaleo> duflu, note the rest of unity8 behaves normally during the freeze
<Kaleo> duflu, everything is fluid and responsive
<duflu> Kaleo: I'm out of ideas
<Kaleo> duflu, ok
<duflu> and the work week
<Kaleo> duflu, thank you
<duflu> No worries...
#ubuntu-mir 2014-12-14
<mibofra> kdub, hi
<mibofra> I don't know if it will be useful, but I obtain this with unity-system-compositor as server, on egltriangle client http://paste.ubuntu.com/9516997/
<mibofra> on unity-system-compositor the compositor doesn't stop
<mibofra> anyway, [1418572657.681595] (II) graphics:     [EGL_FRAMEBUFFER_TARGET_ANDROID] : 1 this line
<mibofra> a strange thing, if 1 represents the /dev/graphics/fbX where 1 is the number of the device, why it's on 1 and not on 0 (fb0)?
<mibofra> *is it on
<mibofra> but maybe I'm wrong
<mibofra> kdub, are you here?
<mibofra> AlbertA, hi
<anpok> hm maybe tomorrow
<anpok> in which context do you get the exception log?
<anpok> is there a communication error and the egltriangle client gets disconnected due to that?
<mibofra> anpok, unity-system-compositor and egltriangel demo client
<mibofra> I get the log on the server
<mibofra> *on unity-system-compositor
<anpok> mibofra: but the client still works then?
<mibofra> anpok, no
<mibofra> anpok, only the mir_demo_standalone_render_to_fb works (and I've tried with weston that works with fbdev-backend backend)
<mibofra> (just for curiosity)
<anpok> ah ok.. so this is the thing to debug..
<anpok> either something strange happens on the client and causes the communication failure or on the server..
<anpok> you could enable more client or server reports to see whats going on.
<mibofra> anpok, we have been arrived with kdub to the conclusion that the compositor it's launched in another way by the mir_demo_standalone_render_to_fb
<mibofra> that works
<mibofra> I'm curios to see what happens adding to that demo a server infrastructure and using it instead of the other demo servers
#ubuntu-mir 2015-12-07
<alan_g> alf_: your question answered? https://code.launchpad.net/~albaguirre/mir/fix-1522581/+merge/279533
<alf_> alan_g: yes, (top-)approved
<kenvandine> greyback, any news on mouse settings support?
<greyback> kenvandine: hey, the next mir release (mir0.18) will have the backend-support enabled. USC then needs to add api to fix that
<kenvandine> greyback, is the USC work on target to land in ota-9?  i've heard we need it for ota-9
<greyback> kenvandine: https://trello.com/c/pxiVCDT0/238-create-client-input-configuration-api-analogous-to-display
<greyback> it's in the active sprint backlog for the mir team
<greyback> we need to get it pushed up the priority list
<kenvandine> greyback, thx
<kenvandine> i've been told we need it for ota-9, but with the holiday break we are running out of time quickly
<kenvandine> greyback, i can't see that card
<greyback> kenvandine: you should have access now
<kenvandine> thx
<kenvandine> greyback, and it's still going to be using gsettings keys right?
<greyback> kenvandine: to do it quickly, probably yeah. Will get proper Mir APIs eventually
<kenvandine> ok
<kenvandine> any unity8 tasks need to be done?
<greyback> yeah, gsettings work will happen in unity8.
<anpok> greyback: for doing it quickly there is a dbus api already
<anpok> I added that right after the london sprint... and it will be wired to the backedn with 0.18
<greyback> anpok: ah yes, I forgot that. Thanks
<anpok> so it is already available on the image
<anpok> but just no backend..
#ubuntu-mir 2015-12-08
<jgdx> greyback, hey, able to chat today?
<greyback> jgdx: yeah, in a meeting atm, will ping you after
<jgdx> greyback, okay.
<anpok> hmm https://github.com/NVIDIA/libglvnd
<greyback> jgdx: ok, am free now. Can we hangout?
<jgdx> greyback, yeah, https://plus.google.com/hangouts/_/canonical.com/system-settings
<jgdx> greyback, you'll let me know how I'll get a hold of the mir pointer? Or is that documented somewhere?
<greyback> jgdx: this should work: http://pastebin.ubuntu.com/13825584/
<jgdx> greyback, thx
<RAOF> anpok: Yeah, that's been slowly stewing for *ages*.
<RAOF> (libglvnd)
#ubuntu-mir 2015-12-09
<duflu> RAOF: Is this up your alley? https://bugs.launchpad.net/mir/+bug/1524161
<ubot5> Ubuntu bug 1524161 in Mir "[ FAILED ] ClientSurfaceEvents.surface_receives_output_event_on_creation " [Undecided,New]
<RAOF> duflu: Sure, let me look at it.
<RAOF> Good, good. Of course I can't cause that locally...
<RAOF> Oh!
<RAOF> duflu: Ah, yes. This is because Alan is wrong about not needing std::future<void> there :)
<duflu> You mean the thing that's about to land... :)
<RAOF> Well, that isn't, because CI correctly failed the autolanding?
<duflu> Oh, right
<duflu> anpok_: Did you notice (or did I imagine) that the touchscreen event rate on mako dropped from 96Hz to 60Hz in xenial (devel-proposed)?
<duflu> It's not a bad thing though. Keeps latency down.
<duflu> Maybe Google did it in the kernel
<duflu> Assuming we've upgraded
<duflu> Still the 59Hz trick provides visibly much lower latency
<anpok_> no I havent noticed that
<anpok_> but we did switch to monotonic timestamps
<anpok_> which means we are accounting touch events with the time stamp they occured on..
<anpok_> this removes the time the server takes to catch up with the device..
<duflu> anpok_: No I sanity checked and tried Mir 0.17 too. It also runs at 60Hz on xenial instead of the old 96Hz
<duflu> So the change happened in the OS and not Mir
<duflu> At least aliasing (and reprocessing) are both reduced now we're mapping 60Hz->59Hz vs the old 96Hz->59Hz
<duflu> anpok_: Also the mako kernel is now from Sep 3 2015
<anpok_> well thats the old kernel + new bluetooth stack
<duflu> *shrug*
<anpok_> hm that happened in september already hmm
<duflu> Yeah still 3.4.0
<duflu> anpok_: It's a xenial (devel-proposed) image so possibly not in production
<anpok_> hm mtk drivers really hated the image changes.. and caused a month full of ci problems
<jgdx> greyback, hey, who do I talk to about keyboard layouts?
<greyback> jgdx: anpok_ probably to start with
<jgdx> greyback, thanks
<jgdx> anpok_, let me know when you're back? I have some questions re: layout managing, specifically how to configure layouts, if it's through mir or with xkbcommon directly?
<jgdx> and if mir, then I can't really find the api bits for it
<jgdx> anpok_, aah, never mind. It's xkb_mapper's XKBMapper.set_rules I assume?
<anpok_> jgdx: yes there
<jgdx> anpok_, and how do I get there from a mirconnection? /cc greyback
<anpok_> jgdx: why would you want to get there?
<anpok_> it is part of the input event processing
<anpok_> ah
<anpok_> you want to configure it yourself
<anpok_> sorry did not read the backlog entirely
<anpok_> jgdx: do you want to configure a clients keymap within the shell. or the shells own keymap from within the shell.. or the clients own keymap as a regular client?
<anpok_> s/clients/client
<jgdx> anpok_, yes
<jgdx> :p
<jgdx> whatever the keyboard indicator does today, I want to replicate
<anpok_> then you just have to send a keymap event with the xkb_rules to the focused client
<anpok_> just kann surface->set_keymap(xkb_rule_names_thing);
<anpok_> *call
<anpok_> jgdx: let me guess.. the keyboard indicator is a client?
<anpok_> greyback: or is it part of unity8?
<jgdx> anpok_, it's not
<jgdx> â¦ a part of unity8, but it may be a client? Not sure of the definitions in the x world
<anpok_> jgdx: ok, then you need to find a way to access the currently focused session and the focused surface.. and just set the keymap..
<anpok_> or set the keymap for each surface of session.. not sure what behvior is preferred..
<jgdx> anpok_, will setting the keymap for the shell set it for all surfaces?
<greyback> anpok_: we've nothing implemented in unity8 for keymap support
<greyback> I don't even know who is responsible for mapping the actual keys
<greyback> afaict, all shell can do is send event to app telling it what keymapping it should perform
<anpok_> jgdx, greyback: the current keymap is stored client side per surface, we only gurantee that we forward proper scancodes and alreayd interpreted modifier states.. so to control which keymap a client uses a shell just has to set the keymap through the Surface interface
<jgdx> greyback, could you communicate that ^ to your meeting tomorrow? :)
<anpok_> greyback: all the indicator would need is access to the currently focused surface or session..
<jgdx> if not, I will
<greyback> jgdx: ack
<jgdx> anpok_, configuration will be done via System Settings for now, the indicator hasn't been considered yet
<anpok_> oh
<greyback> jgdx: making an indicator for this is far more work than unity8 doing it internally.
<kenvandine> greyback, is the stake holders meeting you mentioned thursday the 17th?
<jgdx> greyback, right, I think an indicator is future, not for pd1
<kenvandine> if the work isn't even prioritized by then, there's really no chance any of it will land for ota9
<greyback> kenvandine: am afraid so
<kenvandine> damn
<kenvandine> greyback, ok, bfiller said he'd attend it
<jgdx> anpok_, the indicator does pr window but also global keymap configuration, btw
<jgdx> I think the default is global, which is what we want to do
<greyback> anpok_: when an app creates a surface, what is the default keymap?
<greyback> anpok_: the API only has a setter, no getter
<anpok_> greyback: the universal default keymap ... en_us ..
<anpok_> greyback: sounds like feature request? set the keymap on creation..
<anpok_> hm I believe RAOF made an MP to allow that to work before any user input would be received
<Saviq> kdub, are you aware we've qtmir in flight in silo 22 already?
<Saviq> kdub, also, according to https://requests.ci-train.ubuntu.com/#/ticket/725 qtmir-gles needs a rebuild in your silo, there's a new commit in lp:qtmir/gles that has to deal with new Qt
<Saviq> kdub, it also says mir needs a rebuild, you can see in https://ci-train.ubuntu.com/job/ubuntu-landing-021-0-status/lastBuild/console why it thinks you need the rebuild
<kdub> Saviq, will investigate shortly
<kdub> thanks for the heads up
<ondra> kdub let me know if you need more help
<kdub> ondra, i'm into the device, should be good for the first round
<kdub> thanks !
<ondra> kdub ok, you need to reboot it, and reboot, you are on computer connected to it, so should give you more freedom
<kdub> ondra, I need to reboot it now? or if i need to reboot it?
<ondra> kdub if you need to reboot it:)
<ondra> kdub you are in full control :)
<RAOF> anpok: Indeed; any events you send to a surface *during* its construction are received immediately(ish).
<anpok> hey!
<anpok> always odd when I see you leave and return on the same day :)
<bschaefer> i think that means its time to EOD anpok :)
<RAOF> :)
#ubuntu-mir 2015-12-11
<duflu> RAOF (I know you're away right now): Is this also your domain? - https://bugs.launchpad.net/mir/+bug/1499229
<ubot5> Ubuntu bug 1499229 in Mir "[regression] [testsfail] failure in CI on ThreadedDispatcherSignalTest.keeps_dispatching_after_signal_interruption" [High,Triaged]
<RAOF> duflu: Yeah, it is.
<maikeul> Hello, I have a very basic question regarding running Xmir on an ubuntu phone (meizu), the connection is rejected by the server and I just cannot find a log or indications on how to allow this.
<anpok> maikeul: you have to add a parameter --desktop_file_hint= iirc that tells unity8 which application it is dealing with
<anpok> it otherwise tries to figure out the app id.. and that will fail
<maikeul> ha thanks i will investigate this, i did not understood it was required
<maikeul> undertand sorry
<anpok> hm people at #ubuntu-unity shoud know more details
<maikeul> thanks a lot
<anpok> the parameter needs just one valid .desktop file..
<maikeul> i'll just investigate this and eventually ask on the unity channel, thanks, so far i still get rejected
<anpok> what parameter do you supply for mirSocket?
<anpok> oh logs say rejcted..
<anpok> nm, then it is the right one already..
<maikeul> the one in /var/run
<sturmflut> Does anybody know if GTK has a Mir backend? I think I read about it being patched for Mir, but that was a long time ago.
<anpok> gtk3 has
<anpok> yes and it is upstream
<anpok> but on ubuntu-touch devices there are problems with the supported pixel formats.. none match the ones that cairo currently supports.. (I believe the backend currently tries to use software rendering)
<anpok> or the opposite and that turns out to be a problem.. I havent looked in detail
<sturmflut> anpok: Thanks for the detailed reply!
<mcphail> sturmflut: if you get this working, can you let me know?
<anpok> sturmflut: oh things have changed:
<anpok> https://git.gnome.org/browse/gtk+/commit/gdk/mir/gdkmirwindowimpl.c?id=af5792f14126382705b2de328e4266f03ad1f824
<maikeul> is there a repo/ppa where to get the latest builds for Xmir ?
<bregma> maikeul, the latest version should be available in the vivid+overlay PPA, which should be in the sources on your device already
<bregma> maikeul, just be aware there is no official support for running X11 apps directly on your phone
#ubuntu-mir 2015-12-12
<robin-hero> Hey all, Could somebody take a look at my bug report: https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1519235
<ubot5> Ubuntu bug 1519235 in mir (Ubuntu) "Nexus 4 - HDMI-Slimport adapter can't charge the phone and display the screen at the same time." [Undecided,Confirmed]
<robin-hero> I attached a log, but not sure this is the necessary :)
#ubuntu-mir 2015-12-13
<robjh> hi all. I'm trying to run a program called egltriangle that i found here: http://bazaar.launchpad.net/~mir-team/mir/development-branch/files/head:/examples/       ive got it to compile without errors, the program's output surgests that it should work but i cant get it to output to the display. im using a meizu MX4. is it doing this because im not on a real pc?
<robjh> I'll ask on the forum later on I guess
<RAOF> robjh: What errors are you getting? You need to do some stupid wrangling to make it show up in Unity8, but if you stop lightdm and start your own Mir server it should show up on the MX4 (we use it as a basic smoke-test).
#ubuntu-mir 2016-12-12
<RAOF> Urgh.
<RAOF> MirWaitHandle continues to be our worst client-side architectural mistake
<RAOF> Gah.
<RAOF> Can we make mir_buffer_stream_set_scale go away?
<robert_ancell> anpok, was debian/patches/0001-libinput-add-orientation-and-size-of-touch-point-and.patch from libinput ever upstreamed? I can't find a reference to it on https://bugs.freedesktop.org/buglist.cgi?component=libinput&list_id=601451&product=Wayland&resolution=---
<Pharaoh_Atem> I wish it was upstreamed
<Pharaoh_Atem> the inability for that to be upstreamed has made it difficult to build Mir on Fedora
#ubuntu-mir 2016-12-13
<robert_ancell> Pharaoh_Atem, yes, that was what I was thinking :(
<Pharaoh_Atem> robert_ancell: I have a rediffed version of the patch (http://copr-dist-git.fedorainfracloud.org/cgit/ngompa/Mir/libinput.git/tree/libinput-1.5.0-touch-point-orientation.patch), but there's literally no way I can ever *hope* to consider getting Mir in Fedora proper while patches are required in libinput and mesa
<Pharaoh_Atem> robert_ancell: though I suspect the Mesa people aren't particularly happy with the idea that Mir turns Mesa GPLv3
<Pharaoh_Atem> which might explain why the platform support patch hasn't made it in
<robert_ancell> Pharaoh_Atem, what's the GPLv3 issue?
<Pharaoh_Atem> the community doesn't particularly care for copyleft licenses at all
<Pharaoh_Atem> Wayland is licensed under the same terms as Mesa and Xorg (X11 Expat license)
<Pharaoh_Atem> they're more in the "copyfree" (or as I call it, "pushover") camp
<Pharaoh_Atem> robert_ancell: that particular community is made up of Linux, BSD, Windows, and various other platform people
<Pharaoh_Atem> with the exception of Linux, all of them prefer permissive licensing
<robert_ancell> Pharaoh_Atem, but how is Mir affecting the Mesa license?
<Pharaoh_Atem> in order for Mir to function, Mesa must have a platform module built into it
<Pharaoh_Atem> which links the Mir libraries
<Pharaoh_Atem> thus, Mesa, when compiled with Mir support, goes from X11/MIT to GPLv3
<robert_ancell> Pharaoh_Atem, the Mir client library is LGPL, so that shouldn't be an issue
<RAOF> No; it goes to LGPLv3
<RAOF> Or, rather, it remains X11/MIT as long as you don't statically link libmirclient in.
<Pharaoh_Atem> ah, so the mesa client libs are LGPLv3 then?
<RAOF> libmirclient is LGPLv3.
<RAOF> Anything you need for writing clients (or drivers) is LGPL; if you want to write a server, those libraries are GPL.
<Pharaoh_Atem> hmm
<RAOF> The reason why the platform support patch hasn't made it in is that we need to blow it up in the immediate future.
<Pharaoh_Atem> blow it up?
<RAOF> Change the API.
<RAOF> Change the types you hand to EGL.
<Pharaoh_Atem> is that happening soon?
<RAOF> Yes.
<RAOF> The Mir plumbing required to do that has either landed or is in a reveiewable MP, I think.
<RAOF> The final step is to publish that API and migrate the platform patch.
<RAOF> (And, obviously, to migrate all the downstreams. Yay!)
<Pharaoh_Atem> well, the downstreams aren't exactly plentiful, so that's not nearly as big of an issue
<RAOF> Right. *Particularly* when the patch isn't upstream.
 * RAOF is also somewhat glad he never quite got around to implementing EGL_KHR_platform_mir support, so we can update that spec before it's released.
<RAOF> Incidentally, thanks for doing the Fedora packaging work.
<Pharaoh_Atem> unfortunately, it's all broken
<Pharaoh_Atem> Mesa in Fedora is now at v13
<Pharaoh_Atem> and that patch is not trivial to rebase
<Pharaoh_Atem> RAOF: it seems like *technically* it's possible to use Mir without the mesa patch
<Pharaoh_Atem> so the *bare minimum* for me being willing to put Mir through review in Fedora would be to get the libinput patch upstreamed
<Pharaoh_Atem> as it won't compile without it
<RAOF> It is. You can't run GL clients, but you can run GL shells and software-rendered clients.
<Pharaoh_Atem> eugh
<Pharaoh_Atem> not a great experience then
<RAOF> Yes.
<RAOF> EGL unavoidaby requires platform-integration for different display servers.
<RAOF> (At least until someone proposes and implements a vendor-neutralish EGL with platform integration bits, like Android).
<Pharaoh_Atem> well, that would require the big Linux companies and the big GL consumers to come together to agree on something
<Pharaoh_Atem> we can't have that! </sarcasm>
<RAOF> Heh. glvnd now exists, vulkan has a mostly-sensible ICD system.
<RAOF> Things are getting better :)
<Pharaoh_Atem> glvnd *barely* made it into Fedora 25
<Pharaoh_Atem> so we have that fully enabled
<Pharaoh_Atem> well, technically, it made it to Fedora 23+
<Pharaoh_Atem> but we're starting to use it with Fedora 25
<RAOF> And in another 10 years or so maybe we can remove the previous Linux OpenGL ABI!
<Pharaoh_Atem> yeah, no
<Pharaoh_Atem> you're asking for way too much
<Pharaoh_Atem> even Apple and Microsoft haven't done that
<RAOF> Yeah, I know it's not going to happen.
<Pharaoh_Atem> my main interest in Mir has been to see if I can accomplish what many of my predecessors say is impossible: get Unity working properly on Fedora, without downgrading half the world
<Pharaoh_Atem> and since Unity 7 is on life support, I've looked toward Unity 8
<RAOF> Unity8 should be helpful there, as it mostly doesn't rely on GNOME patches.
<RAOF> (And Qt is friendlier to downstream platform integration)
<Pharaoh_Atem> yes
<Pharaoh_Atem> it helps that since I'm more of a KDE guy myself, I'm more familiar with that stack
<RAOF> Although I also think that much of our Qt stuff is upstream.
<RAOF> Although not qtmir, because it's a fast moving target.
<Pharaoh_Atem> it is, but it's disabled in Fedora since we don't have the scaffolding for it
<Pharaoh_Atem> i.e. Mir itself
<Pharaoh_Atem> and various unity libraries
<RAOF> Heh
<Pharaoh_Atem> well, we recently brought back libunity and libappindicator, since Plasma 5 now uses them
<Pharaoh_Atem> I've never been happy with how those projects are managed, though
<Pharaoh_Atem> we're forced to yank tarballs from the ubuntu archive because the lp projects are dead wastelands with no updated releases ever made
<RAOF> Embrace the rolling release + CI pipeline!
<RAOF> It Is Life
<Pharaoh_Atem> well, that would require things like mir's gmock tests to actually work
<RAOF> (Or, more seriously, is hostile to downstreams)
<Pharaoh_Atem> right
<Pharaoh_Atem> I've always had a bit of lethargy for working with Launchpad-hosted projects, because they tend to do this to me
<Pharaoh_Atem> irony of ironies, my very first package in Fedora is of a piece of software hosted on Launchpad
<RAOF> There was a time when our projects would do actual releases, but not now. Mir is an outlier in that we *do* do releases.
<RAOF> (Because we don't have a stable C++ ABI, so updating Mir requires rebuilding the world, so we don't do that every commit âº)
<RAOF> On the plus side, you *should* be able to take a random trunk commit and have it work properly.
<Pharaoh_Atem> nope
<Pharaoh_Atem> I won't trust that until I can run gmock tests
<RAOF> What's broken there? We don't patch googletest.
<Pharaoh_Atem> unfortunately, for some reason I cannot fathom, Mir's CMake script can't detect gmock and gtest
<RAOF> Does fedora just lack the latest gtest?
<RAOF> Huh. Maybe you install it in an odd place?
<Pharaoh_Atem> https://apps.fedoraproject.org/packages/gtest
<Pharaoh_Atem> https://apps.fedoraproject.org/packages/gmock
<RAOF> Alternatively, maybe you don't install the sources and expect projects to link to prebuilt libraries?
<Pharaoh_Atem> for gmock, it's sources
<Pharaoh_Atem> for gtest, it's libraries
<Pharaoh_Atem> https://apps.fedoraproject.org/packages/gmock/sources/spec/
<Pharaoh_Atem> https://apps.fedoraproject.org/packages/gtest/sources/spec/
<RAOF> Well, we have googletest 1.8.0 in zesty. But we don't require it.
<RAOF> Right. Our gtest detection won't work unless you've got the gtest sources unpacked somewhere.
<RAOF> (As is recommended by upstream)
<Pharaoh_Atem> upstream dropped that recommendation when they fully moved over to cmake
<Pharaoh_Atem> the apt guys told me the same thing...
 * RAOF heads out.
<Pharaoh_Atem> RAOF: https://github.com/Debian/apt/commit/99ba7cc1901c761c97d67775f23858b86594f2ba
<anpok_> Pharaoh_Atem: it was proposed but not yet added because a way to calibrate/scale the reported touch contact size unit into something meaningful was missing..
#ubuntu-mir 2016-12-14
<dandrader> alan_g, in mir_prompt_session_new_fds_for_prompt_providers() I get a list of fd integers
<dandrader> alan_g, how do I get a filepath from them so I can it them in mir_connect()?
<dandrader> s/it them/use them
<alan_g> dandrader: there's no filepath - just an FD. mir_connect can take an "fd://<fd>" connection string to use an FD
<dandrader> is the  "fd://<fd>" some standard format or is it a mir thing?
<alan_g> Probably a Mir thing
<alan_g> bbiab
<alan_g> greyback: any chance of quick feedback? I'd like to roll this into MirAL 1.0 and progress that later today.
<alan_g> https://code.launchpad.net/~alan-griffiths/miral/miral-hosted/+merge/313211
<greyback> alan_g: what do you mean by "hosted" here?
<alan_g> greyback: on another desktop - e.g. Unity7 or Unity8
<alan_g> Basically, you can now click on the miral-shell icon in U8
<greyback> I see. Name wasn't obvious to me
<alan_g> greyback: do you have a better one?
<greyback> alan_g: thus far, no
<greyback> nested?
<alan_g> That hasn't been greeted with comprehension either
<alan_g> "guest" has also been tried
<alan_g> camako has been trying to get rid of "nested" for years
<alan_g> "miral-app"?
<greyback> I like that
<alan_g> OK, renaming is easy
<alan_g> greyback: renamed
<greyback> ac
<greyback> alan_g: just 1 small thing, otherwise good
<alan_g> greyback: thanks
#ubuntu-mir 2016-12-15
<kgunn> o/
<kgunn> camako: AlbertA hey so been chatting with mfeatherston, he's on a freescale chip with vivante drivers
<kgunn> and it's an ubuntu-core all-snaps
<kgunn> image
<kgunn> ....and his driver choices are closed/prop x, wayland, or android
<camako> nice
<kgunn> so wondering...
<kgunn> could he just pack the android drivers along with libhybris into a mir-kiosk snap and get it rolling?
<kgunn> or is libhybris going to have baked in system path assumptions that will not be happy with the snappy world?
<kgunn> kdub: ^ ah you might know this...
<camako> kgunn, has libhybris never been used in snappy?
<kgunn> if you're on and not changing diapers :)
<kgunn> camako: nope....at least i don't think
<kgunn> camako: we've not yet had a need to put snaps on an android driver stack
<kgunn> so this would be a first...
<camako> kgunn, I don't really know without trying it out
<kgunn> i was kinda wondering camako if there is an device where we could do this...
<kgunn> like m10 i don't think has an image from the foundation team yet
<kgunn> mfeatherston: curious...did you roll your own image?
<mfeatherston> yes
<kgunn> aha
<mfeatherston> https://github.com/embeddedarm/ubuntu-core if you're curious
<kgunn> mfeatherston: so you've put the gfx drivers in for the propritary x version i suppose?
<mfeatherston> Yes, we support yocto which uses their proprietary x11 drivers.
<mfeatherston> We have android running too with their drivers
<kgunn> hey, i need to run actually...but mfeatherston i am really interested in your effort
<kgunn> camako: kdub can we think about how we might test out and build some instructions for running mir-kiosk on android drivers?
<kgunn> i think we knew there'd eventually be a need...just need to figure out how to do it
<mfeatherston> kgunn, I'll be working on this the next few weeks at least so I'm sure I'll be around.  Thanks for your help!
<camako> kgunn, sure
<kgunn> like i suppose we could use dragonboard?
<kgunn> as a vehicle
<kgunn> just to prove the hybris/android thing
<kgunn> ok...gotta run
<camako> kgunn, yes we can talk more about it
<kdub> yeah, can probably make some option work
<kdub> android platform compiled against glibc, or the mir patches on top of the wayland stack would get freedreno going i think
<kdub> been on the backburner for a long time
<mfeatherston> freescale provides binary wayland drivers too if that would be simpler for this case as well.
#ubuntu-mir 2016-12-18
<peat-psuwit> Hello. Currently I'm trying to eliminate screen corruption in Fairphone 2.
<peat-psuwit> The problem is that when eglCreateWindowSurface is called, underlying EGL driver will change ANativeWindow's pixel format from RGBX (if that's what is choosen) to RGB.
<peat-psuwit> This seems to cause corruption, because before that, everything concerns that the surface is in RGBX, but now only ANativeWindow (which is implemented by EGLNativeSurfaceInterpreter class) knows about this.
<peat-psuwit> Is there any mechanism to communicate pixel format changes to anything, especially to server?
