#ubuntu-mir 2013-07-22
<robert_ancell> duflu, bug 1203207 is the Main Inclusion Request for mir
<ubot5> bug 1203207 in mir (Ubuntu) "[MIR] mir" [Undecided,New] https://launchpad.net/bugs/1203207
<duflu> robert_ancell: Oh. Very confusing acronym
<robert_ancell> yes
 * duflu begins to struggle with a new keyboard. Very slow
<RAOF> Oh, why the new keyboard?
<duflu> RAOF: Because I've been using the old one to death... for 10+ years.
<duflu> That said, I'm now back on it. I think I need a different new keyboard
<RAOF> Fair suck of the sav.
<duflu> Is that a Rudd'ism?
<RAOF> I'm pretty sure it's not?
<RAOF> Isn't that a stereotypical Strayaism?
<duflu> Maybe. But I never heard any like that before Rudd
<robert_ancell> RAOF, were you making a .symbols file for libmirserver as well as libmirclient?
<RAOF> robert_ancell: No?
<RAOF> Would you like me to be?
<robert_ancell> RAOF, ok, just wanted to check. I'm going to look at enabling that
<robert_ancell> RAOF, do you have a branch for the client .symbols file?
<RAOF> Not on Launchpad, no.
<robert_ancell> go on...
<robert_ancell> you know you (I) want you to
<RAOF> I can push it up, but it doesn't work, because something's exporting a bunch of C++ drivel we don't want exported.
 * RAOF does so.
<robert_ancell> not working is my specialty
<robert_ancell> thomi, is there a reason why jenkins polls the MPs and can't just have a hook on the bzr repo to know when new ones come in?
 * robert_ancell gets somewhat impatient with Jenkins
<thomi> robert_ancell: you probably know bzr better than I do, but I don't think you can do that
<thomi> robert_ancell: my understanding is that a MP really has nothing to do with bzr
<robert_ancell> yeah, I guess
<thomi> robert_ancell: if launchpad had that functionality we could
<thomi> but... no one is landing new launchpad functionality :)
<robert_ancell> poll faster dammit! :)
<thomi> robert_ancell: it should be pretty fast
<thomi> robert_ancell: what makes you think that it's slow?
<robert_ancell> I'm pretty impatient
<robert_ancell> I just want the server to double check my results in minutes and push :)
<robert_ancell> RAOF, woah, big old pile-o-patches to mesa :)
<RAOF> Yup.
<RAOF> 'tis what has been consuming my time :)
<thomi> robert_ancell: it may be that what you're actually waiting on is the build time, rather than the poll time
<RAOF> robert_ancell: Enjoy lp:~raof/mir/mirclient-symbols
<robert_ancell> RAOF, ta
<duflu> RAOF: If you never start/use X, Mir only needs the Mesa stuff upstreamed to work, right?
<RAOF> duflu: Correct.
<duflu> That will be nice to be able to build/run Mir without any PPAs
<thomi> RAOF_: any ideas where I get the swrast video driver from? I'm trying to use xvfb for something, and it's complaingin at me
<duflu> thomi: It's part of Mesa.... libgl1-mesa-dri:amd64: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
<RAOF_> duflu is correct.
<tvoss> good morning :)
<tvoss> RAOF, good morning :)
<RAOF> tvoss: Aloha.
<duflu> tvoss: Morning (v2)
<tvoss> duflu, good morning :)
<duflu> Woo, another Perth Canonicaler
<tvoss> RAOF, hah, debian rules for the intel driver enables both sna and uxa and --with-default-accel=uxa
<RAOF> tvoss: Not as of http://bazaar.launchpad.net/~mir-team/mir/xf86-video-intel-fixup/revision/196 ?
<duflu> So, does SNA win at runtime?
<RAOF> Maybe it just needs a rebuild?
<duflu> Oh, of course not, if default==UXA
<tvoss> RAOF, yeah, I'm looking at the source package from the system-compositor-testing ppa
<RAOF> tvoss: The recipe https://code.launchpad.net/~mir-team/+recipe/xf86-video-intel-xmir should nest xf86-video-intel-fixup as the packaging. But it looks like the last autobuild failed to upload, so I've prodded a rebuild.
<tvoss> RAOF, ack, thanks
<alf__> duflu: @distinguish-locked-buffers, could you please briefly explain why need to differentiate between the two kinds of consumers?
<duflu> alf__: Because bypass requires that you can and will have two compositor buffers acquired at once, and each acquire gives you a new one. A snapshot on the other hand is always shared and never "progresses" the buffer queue
<alf__> duflu: For normal (non-bypass) usage though, we need to be able to (potentially) share compositor buffers. For example, if a window is between two outputs.
<alf__> duflu: and it has to be rendered on both
<duflu> alf__: Yes I will be covering the shared case... and will adapt as multimonitor evolves
<tvoss_> RAOF, where did you copy the package to? does not show up on system-compositor-testing
<RAOF> Haven't copied the package at all; just triggered a build from the recipe in mir-team/staging
<tvoss_> RAOF, hmmm, upload failed
<duflu> alf__: I'm not entirely comfortable implicitly guaranteeing that successive compositor_acquires will return the same buffer multiple times. I think you should either try to call it only once, or flag the intended use or required buffer number
<duflu> That would be safer, and clearer
<RAOF> tvoss_: Oh, of course. No change on the xf86-video-intel-vladmir branch means no change in version number. Should be fixed by tweaking the recipe, which I've done and hit the "build" button for.
<tvoss_> RAOF, thx
<tvoss_> RAOF, got some time for a chat?
<RAOF> duflu, alf__: Your talk reminds me that I'll need to discuss some buffer issues regarding GLX passthrough, once I've finished upstreaminginginginginging.
<RAOF> tvoss_: In a little bit? I'd like to finish all this upstream pushing first.
<tvoss_> RAOF, yeah, sure :)
<tvoss_> RAOF, just ping me
<duflu> alf__: compositor_acquire(int age) ?
<alf__> duflu: How do you think we should deal with the "surface rendered on multiple output" scenario? The current strategy (as implemented by the MultiAcquisitionBackBufferStrategy) tries to minimize having out of sync information on different screens, while keeping performance reasonable. I am sure there are other mechanisms, but we should think about the conflicting constraints and prioritize/compromise. See https://code.launchpad.net/~afrantzis/m
<duflu> alf__: I think the compositor should either guarantee one compositor_acquire per surface per frame, or it should include extra info to tell the buffer stream if it can/should recycle the previous one
<duflu> Maybe pass a serial/frame number into acquire
<duflu> alf__: In fact, compositor_acquire(int frameno) would eliminate the need for a separate snapshot_acquire
<alf__> duflu: we don't currently have the concept of a single frame across all outputs, since we render each output in its own thread, following different timings.
<duflu> alf__: Yes, good point.
<tvoss_> RAOF, seems like the recipe finished successfully
<duflu> alf__: What's the motivation for spreading composition across multiple threads?
<duflu> Just trying to be a little faster?
<duflu> ... because it might break down when we have to manage whole-display transformations/effects
<duflu> Not sure
<alf__> duflu: Main point is consistently rendering at each output's refresh rate
<duflu> alf__: Right. Be fast to ensure you can keep up. Makes some sense
<RAOF> Well, also because you can't ensure that there aren't beats in the two refresh ticks.
<alf__> duflu: it's not just about performance... RAOF got there first ^^^ :)
<duflu> What's a "beat"?
<RAOF> http://en.wikipedia.org/wiki/Beat_%28acoustics%29
<duflu> Oh, right, a (heart) beat to throttle the client
<duflu> Actually, no, I don't see how that's related
<RAOF> If you've got two ticks (a and b) with slightly different frequencies - as you likely will with two different vblank signals - then there'll be times when there is an arbitrarily small gap between a tick from a and a tick from b.
<RAOF> So if you try and render both in the same thread you'll find that for any non-zero frame render time you'll be missing frames some of the time.
<alf__> duflu: RAOF: and also even if vsync rate is exactly the same, the starting offset of the vsync cycle is not guaranteed to be the same on different outputs. For example, one output's vsync may happend in the middle of the vsync cycle of another output (v0+8ms)
<duflu> OK, I don't fully need to understand the reasoning on that right now. I'm not seeking to make composition single threaded... It's just nice to know why it's not
<duflu> And regardless, performance will be higher and support for multiple GPUs closer to reality with multiple threads
<RAOF> tvoss_: Finished the frantic upstreaming; can we chat post ZoÃ«-bath?
<tvoss_> RAOF, for sure :)
<tvoss_> RAOF, saw your mails on the xorg-devel list
<freeflying> do we still have 2 cursors issue with staging mir ppa?
<tvoss> freeflying, yup
<freeflying> tvoss: sounds cool, will give it try
<tvoss> freeflying, you might want to use the system-compositor-testing ppa, though
<tvoss> freeflying, staging revs too fast right now
<freeflying> tvoss: my laptop has a built-in touch screen, so concern of the 2 cursors issue :)
<tvoss> freeflying, I don't think anyone has tested that :) but: all input handling is done by X anyways
<tvoss> RAOF, can I just copy over the intel driver from staging to testing?
<RAOF> tvoss_: Yes.
<tvoss_> RAOF, okay, just installed from staging, running fine with SNA enabled by default
<tvoss_> RAOF, to verify: copy with binaries is correct?
<RAOF> Correct.
<tvoss_> same series, too?
<RAOF> Yes.
<tvoss_> RAOF, copied
<RAOF> Cool.
<freeflying> tvoss_: 2 cursors issue is still in system-compositor-testing with my laptop
<tvoss_> freeflying, right :) we abuse it right now as a watermark
<tvoss_> freeflying, if you feel adventerous, I can give you a deb that removes the second cursor
<freeflying>  tvoss_ yes plz :)
<kgunn> didrocks: is everything in order ? (i should say "at the moment" :)
<didrocks> kgunn: we still have this ati issue, right? Is it worked on?
<didrocks> kgunn: on the MIR, see my answer and please run the "check-mir" command on them :)
<didrocks> kgunn: finally, we need to find people to maintain all those new rdepends in main
<kgunn> didrocks: uh-oh...thought we clear those...bug# ?
<didrocks> kgunn: seems we didn't (it didn't move): bug #1203070
<ubot5> bug 1203070 in Mir "unity-system-compositor doesn't start on some ati card (with opensource driver)" [High,Confirmed] https://launchpad.net/bugs/1203070
<didrocks> and I can confirm this morning's test is still failing
<kgunn> bregma: do you or any of your team have a machine with ati locally ?
<kgunn> wrt https://bugs.launchpad.net/mir/+bug/1203070
<ubot5> Launchpad bug 1203070 in Mir "unity-system-compositor doesn't start on some ati card (with opensource driver)" [High,Confirmed]
<kgunn> just wondering for easier debug
<bregma> kgunn, not me, and I don;t think any of my team since we had to borrow one to track a problem a few months ago (but I'll check, just in case)
<kgunn> otherwise...can bschaefer work with robotfuel today ?
<kgunn> bregma: thanks
<bregma> actually, I lie, there is a machine in my house with an ATI card but it's still running 10.04 and I doubt I could upgrade it without political difficulty :)
<robotfuel> kgunn: I asked which card it was in the bug, I have xmir working on ati cards that I've tested.
<robotfuel> didrocks: ^
<kgunn> bregma: :D
<kgunn> tell "her" its for a good cause :))
<didrocks> robotfuel: did you see what I wrote in the description? RAOF already did a first pass
<mlankhorst> meh my nv50 is failing entirely :P
<kgunn> bregma: well....seems maybe its a specific card
<kgunn> mlankhorst: bah!...or not
<didrocks> answered anyway ;)
<didrocks> kgunn: tell me once you finished the MIR btw + found maintainers for the rdepends we are not upstream for
<kgunn> didrocks: rdepends == who's gonna own xorg/mesa patches right ?...can we assume its RAOF for now?...i will work to get another name & will be explicit when/if this changes
<kgunn> that ok ?
<didrocks> kgunn: I meant the other one, you added (and rightly) opened a MIR against those
<didrocks> the new MIR build-dependencies
<didrocks> Mir
<didrocks> that we have to MIR (just adding complexity :p)
<kgunn> didrocks: ah glog, glmath
<didrocks> kgunn: exactly
<didrocks> kgunn: we need a team subscribed to the bug
<didrocks> who will fix those if we have/critical issues in ubuntu
<didrocks> (as it's supported by canonical)
<didrocks> liburcu, systemtapâ¦
<kgunn> olli__: ^
<kgunn> its like system "stuff"
<didrocks> libgflags needs a MIR as well
<didrocks> but wasn't opened: https://bugs.launchpad.net/ubuntu/+source/google-glog/+bug/1151844
<ubot5> Launchpad bug 1151844 in google-glog (Ubuntu) "[MIR] google-glog" [Undecided,Fix committed]
<didrocks> as seems gflag had a +1 from mterry :p
<tvoss> didrocks, I think we had a gflags MIR before
<didrocks> tvoss: yeah, it's that one
<tvoss> didrocks, ah okay
<didrocks> tvoss: it was merged in the google-glog one
<didrocks> just didn't read through the ack :p
<kgunn> tvoss_: i'm running your one off fine....but pts giving me guff at the moment....complaining about php (which i know i had previously....arrggg)
<tvoss_> kgunn, okay, the one you have does not clean the list of damaged regions :) and you should see increased cpu usage by usc
<racarr> First GPU hang of the week woo
<racarr> what is the shell class that listens to surface configuration requests from the client and I guess approves/dissaproves them
<racarr> I cant think of anything other than the super unsatisfying like
<racarr> SurfaceConfigurator, or things like that that tell you
<racarr> nothing
<kdub> SurfaceRequestGatekeeper
<racarr> kdub: closer maybe but I still dont like it somehow
<racarr> maybe the_surface_attribute_selector()
<racarr> Value SurfaceAttributeSelector::select_value(Surface, Attribute, RequestedValue)
<kdub> still pretty vague :)
<kdub> sounds like you're trying to name it 'what does this do for mir' when it might be a class that describes something mir does for hte shell?
<racarr> mm
<kdub> racarr, also keep in mind that we'll need something similar to that class for surfaces and connections, i think
<kdub> (thinking of denying framebuffer reconfiguraiton requests)
<racarr> kdub: This chain of thought reminds me of an earlier thought I had
<racarr> if the shell needs something like that for
<racarr> every setter on msh::Surface
<racarr> then perhaps the shell should be implementing
<racarr> msh::Surface
<kdub> oh indeed :)
<kdub> i thought thats where we're heading
<kgunn> racarr: yeah, i think mterry had been thinking for greeter like shell (internal mir client)...but after a chat with robert
<racarr> kdub: Eh 50/50 ;)
<kdub> or rather, it sholud get a msh::Surface-like interface
<kgunn> racarr: it seems like mterry is going to just be able to be a regular client
<kdub> we will probably want to keep a 'switchboard' class inbetween
<racarr> kgunn: Ok. Great :)
<racarr> kdub: right.
<kgunn> racarr: yeah...so even if its confusing...bottom line...less work for you i think :)
<kdub> directing the signals between 'shell cares' and 'shell doesn't care' to the 'new class' we're takling about and the rest of the mir system respectively
<racarr> kgunn: I think I get it now. I think I had just misinterpreted something earlier and thought this had already happened
<racarr> kgunn: Went through gerry with the major shell items left/dandrader about OSK I think there are only 2 that are blocking for the next while so im hoping to get proposals today
<kgunn> racarr: awesome ! thanks...those are our collective #1's on the shell-mir integration....its great to see it coming together
<xjunior> hey, switch back to X for a while should be just comment out unity from 10-unity-system-compositor.conf, right?
<kgunn> xjunior: yep...http://unity.ubuntu.com/mir/debug_for_xmir.html
<xjunior> kgunn: XMir is a little slow lately, and I would need X for a few days. Uncommenting that is just crashing when initializing lightdm
<xjunior> it initializes, then gives me a popup saying it's going to start in low graphics mode
<kgunn> xjunior: hmmm - honestly i have never heard of that causing an issue for anyone....
<smspillaz> behold your first non-toolit non-demo client http://i.imgur.com/9Heamzv.jpg
<smspillaz> *toolkit
<kgunn> might wanna file a bug and share your logs
<xjunior> kgunn: is there an automated way of doing it?
<kgunn> xjunior: not really...
<kgunn> xjunior: i gotta run...
<xjunior> so, X starts to fail with the following:
<xjunior> "LoadModule: "dri2""
<xjunior> "Module "dri2" already built-in
<xjunior> "
<xjunior> then unloads a bunch of methods and crashes
<xjunior> boom, that's it
<xjunior> it works with XMir, though
<kgunn> bregma: robert_ancell  https://bugs.launchpad.net/mir/+bug/1203070
<ubot5> Launchpad bug 1203070 in Mir "unity-system-compositor doesn't start on some ati card (with opensource driver)" [Critical,Confirmed]
<xjunior> kgunn: is thet for me?
<kgunn> xjunior: no sorry :)
<xjunior> no worries ;) I wish it was
<xjunior> I have a intel card, btw
<kgunn> too many conversations :)
<tvoss> xjunior, I'm working on the slowness issue
<xjunior> that's fine :) It means people are testing it a lot
<kdub> smspillaz,  cool
<racarr> smspillaz: Oh yay it works
<kgunn> bregma: invited you just if you wanted to join...totally optional
<tvoss> smspillaz, ping
<smspillaz> racarr: I told raof I made a bet with you that I would get the mir client finished and working (my definition of working: I can navigate to play a video, hence I can conveniently leave out keyboard input) before my project supervisor starts reviewing the wayland stuff
<smspillaz> so I made a bet with you
<smspillaz> mmkay
<xjunior> tvoss: that's nice. What's the actual issue?
<tvoss> xjunior, I'm deep in debugging the damage extension right now, but it's caused by some weird interaction in xmir-window.c
<smspillaz> tvoss: pong
<tvoss> I'm currently compiling an xserver that reverts http://cgit.freedesktop.org/xorg/xserver/commit/?id=8d7b7a0d71e0b89321b3341b781bc8845386def6 which caused hassle elsewhere, too
<tvoss> xjunior, https://gerrit.chromium.org/gerrit/#/c/474/1/x11-base/xorg-server/files/1.9.3-no-damage-report.patch
<tvoss> smspillaz, hey there :) how goes?
<tvoss> smspillaz, nice work on the xbmc stuff :) did you get it to work with Mir, yet?
<xjunior> tvoss: nice!! is there an URL where I can see the xmir-window.c file?
<xjunior> more for curiosity than anything
<tvoss> xjunior, I'm working with the source package from the system compositor testing ppa
<smspillaz> tvoss: see the image I just posted :p
<smspillaz> no input yet but that's pretty easy, just need to copypasta
<smspillaz> the xkbcommon stuff
<tvoss> smspillaz, sorry, not in my scrollback :)
<bschaefer> smspillaz, awesome :), also hello!
<smspillaz> tvoss: http://i.imgur.com/9Heamzv.jpg suprise!
 * tvoss wonders if he can pledge for a second edge
<xjunior> are you getting a ubuntu edge?
<tvoss> yup
<racarr> tvoss: You should switch to marketing
<tvoss> racarr, why is that?
<racarr> "Pledge for a second edge"
<racarr> it rhymes and everything
<tvoss> yeah, now that you say it:)
<xjunior> Really loved the design. The price is a little salty to get it in Brazil (it would get additional 90% taxes)
<racarr> you just have to imagine an athlete saying it over a gingle
<racarr> and then drinking a bottle of gatorade
<tvoss> smspillaz, \o/
<smspillaz> tvoss: though to be fair xbmc is pretty easy to port
<smspillaz> once you avert your eyes
<smspillaz> to the #define kludge
<smspillaz> that is CWinEvents
<smspillaz> and then also all of the
<smspillaz> IInterfaces
<tvoss> okay, wuick logout
<racarr> I came up with a way to implement the latest input workaround purely in unity/platform API rather than having to make a new kind of event filter in Mir!
<racarr> the audience can hold
<racarr> their applause
<smspillaz> tvoss: the mir client api is a little odd to work with at the moment, but it was better than the dlopen'ing some function that uses varargs because the client interfaces are autogenerated and can't be looked up at runtime
<smspillaz> (in wayland)
<tvoss> smspillaz, odd in what respect?
<smspillaz> tvoss: its a bit hard to explain all in one session
<tvoss> smspillaz, yup, feel free to file some bugs
<smspillaz> tvoss: trust me, its better than that : https://github.com/smspillaz/xbmc/blob/5903875e5904c9174be6d9a82a6638817628f2be/xbmc/windowing/WaylandProtocol.h
<tvoss> smspillaz, heh :)
<tvoss> xjunior, running a test-case now, might take some time :)
<xjunior> cool man, hope you get it :)
<xjunior> do you do some sort of automated performance test?
<tvoss> xjunior, it's not performance, somewhere an update gets lost
<xjunior> gotcha
<tvoss> anyway, time for bed :)
<tvoss> I'm on it, will give you an update tomorrow
<kdub> robert_ancell, ping
<robert_ancell> kdub, hello
<robert_ancell> RAOF, some good feedback on the X patches!
<robert_ancell> RAOF, Is lightdm 1.7.2-0ubuntu2 stuck in the -proposed queue?
<robert_ancell> 1.7.6-0ubuntu2 rather
<RAOF_> robert_ancell: Maybe?
<RAOF_> robert_ancell: Not that I can see?
<robert_ancell> RAOF, https://launchpad.net/ubuntu/+source/lightdm says it's been in proposed for 8 hours
<RAOF> robert_ancell: It's probably blocked waiting on autopilot tests?
<robert_ancell> RAOF, it doesn't have any..
<RAOF> ...
<racarr> test_shell_control_of_surface_configuration.cpp
<RAOF> It might cause a retrigger of _other_ autopilot tests?
<racarr> acceptance test files are hard to name
<thomi> I'm no expert, but I believe that it'll wait in proposed until the entire stack is known to be good
<thomi> which means *all* the tests passing, for all projects
<thomi> this is done to avoid half-broken stacks being pushed to distro
<thomi> but this is all Didiers stuff, so I could well be wrong
<RAOF> That seems unnecessarily brutal?
<thomi> RAOF: not really
<bschaefer> thomi, that could be true, as there is a failing test in power pc thats blocking a release atm :(
<thomi> RAOF: once you release into distro, *everyone* gets it
<thomi> RAOF: and if you break the desktop, hordes of angry geeks on horseback surround your house
<RAOF> I mean, you should be able to be more granualar; a failing unity test shouldn't block everything
#ubuntu-mir 2013-07-23
<thomi> RAOF: maybe. Unity has binary deps on lots of other things though, so you often can't release libdee (for example), unless you release the rest of the stack at the same time
<RAOF> Oh, that totally makes sense.
<robert_ancell> RAOF, do you know who I can talk to about lightdm still being in proposed? The one in main has a serious bug
<RAOF> robert_ancell: Probably most people in #ubuntu-release?
<robert_ancell> RAOF, ta
<RAOF> I'd expect a random archive admin to know.
<mlankhorst> RAOF: oh btw can lts-raring and mesa in raring be promoted to -updates? :P
<duflu> robert_ancell: Could you do me a favour?
<robert_ancell> duflu, sure
<duflu> robert_ancell: Change the "development focus" to 0.9.11 on https://launchpad.net/compiz
<duflu> ?
<robert_ancell> duflu, done
<duflu> robert_ancell: Thanks
<Sarvatt> mlankhorst: that was extra annoying, finding out it was in -proposed after recommending it to people instead of edgers :)
<Sarvatt> mlankhorst: but infinity was talking about making daily builds work so "any day now"
<olli> RAOF, hey
<RAOF> olli: Yo!
<olli> just wanted to say thanks for proposing all the patches over the weekend
<olli> :)
<olli> seems like the intel one got the most traction so far
<RAOF> Well, the most reaction at least :)
<olli> RAOF, true
<olli> so, it seems like we have missed all major upstream releases (at least Mesa and X iirc)
<olli> not sure if "missed" is the right term
 * duflu wanders off to lunch
<olli> enjoy duflu
<olli> RAOF, how will we ship these in 13.10 then?
<RAOF> By patching?
<RAOF> Same way we did XI2-multitouch?
<olli> heh, the amount of "?" indicates I was asking a stupid question ;)
<olli> will you have to maintain 2 versions of the patches then, one for Mesa/X/... at 13.10 and one for the respective latest version
<olli> will that be a big delta, if at all?
<RAOF> Depends on how things change underneath.
<RAOF> The patch as-of 13.10 though probably won't need _too_ much support that isn't simple backporting.
<tvoss> RAOF, ping
<RAOF> tvoss: Yo.
<tvoss> RAOF, good morning :) got some time in your voip lair?
<RAOF> Sure.
<RAOF> My new, improved, VoIP lair!
<tvoss> RAOF, \o/ let me grab coffee
<tvoss> RAOF, can you open a hangout and add me to it, would like to join on the ipad
<didrocks> kgunn: just to reash, I'm not thrilled to drop 50% of our testing, and just having one machine with "a workaround" to get Mir starting
<didrocks> rehash
<didrocks> RAOF: hey, you confirm that the ati issue isn't due to lxc, but a real issue, right?
<RAOF> didrocks: Yeah, looked like it.
<didrocks> RAOF: if you need access to the machine, we can provide you that
 * didrocks is seeing that we diminish more and more on Mir quality side "just" to ship in universe
<tvoss_> didrocks, how many machines can we provision in the lab to start mir?
<didrocks> tvoss_: 2 right now
<tvoss_> didrocks, why not more? it is my understanding that we have 2 ati, 2 intel and 2 nvidia machines
<didrocks> tvoss_: we have that since yesterday
<tvoss_> didrocks, what gpu is running in the two machines?
<didrocks> tvoss_: we just need to provision the nvidia
<didrocks> one intel, one ati
<didrocks> tvoss_: the 3 others are for raring
<tvoss_> didrocks, why do we need them for raring?
<didrocks> tvoss_: because we support our users?
<didrocks> so we do have SRUs everyday
<tvoss_> didrocks, sure, but I thought we could just reprovision them with a different Ubuntu version?
<didrocks> tvoss_: no, we need kernel == container
<didrocks> tvoss_: the machines are the same anyway, between the ati, intel and nvidia FYI
<tvoss_> didrocks, okay, I was told some time back that we have he/le ati, he/le nvidia, he/le intel
<didrocks> maybe you are not mentionning the same machines then
<didrocks> because the 3 others arrived this week
<didrocks> and we only have 3 until then
<tvoss_> didrocks, that might well be
<tvoss_> didrocks, so which machine is causing issues? the ati one?
<didrocks> yep
<tvoss_> didrocks, intel and nvidia come up cleanly?
<didrocks> tvoss_: well, nvidia is on raring (one of the 3 we had)
<didrocks> we need to wire up the other one
<didrocks> on intel, it was failing as well
<didrocks> and we needed my workaround
<didrocks> the sleep :/
<didrocks> I got a "we never see it"
<didrocks> then, when I gave the description, starting to see devs telling they saw it
<didrocks> and "just" reboot :/
<didrocks> we need to change that behavior
<tvoss_> didrocks, as far as I know we do not see those issues in the cert lab
<didrocks> tvoss_: so, we are inventing the issues?
<didrocks> "not seen here" -> then, when opening "oh btw, I saw it some times"
<didrocks> regular rules
<tvoss_> didrocks, of course not, I'm just trying to track down the issue
<tvoss_> didrocks, can I get access to the ati machine?
<didrocks> tvoss_: see the bug report, RAOF already dived to it
<didrocks> tvoss_: yeah, once daily are finished, I can give you access
<tvoss_> didrocks, ack, can you paste the bugreport again?
<tvoss_> didrocks, my backlog is a bit fucked up after numerous reboots
<didrocks> tvoss_: bug #1203070
<ubot5> bug 1203070 in Mir "unity-system-compositor doesn't start on some ati card (with opensource driver)" [Critical,Confirmed] https://launchpad.net/bugs/1203070
<didrocks> Chris told: "it's failed to create the hw cursor buffer, and I don't believe that there are any more relevant logs
<didrocks> available."
<tvoss_> mlankhorst, ping
<mlankhorst> pong!
<tvoss_> mlankhorst, hey there :) we are trying to solve an issue with Mir failing to create a hardware cursor buffer on ati.
<tvoss_> mlankhorst, I wonder if you are aware of any known ati issue in that area?
<mlankhorst> erm cursor usually has special requirements for buffer
<tvoss_> mlankhorst, okay, the call succeeds in general, we only have an issue on one specific card. Is there any way to get something like a last error from gbm?
<mlankhorst> use the debugger(TM)
<tvoss_> mlankhorst, woot, thanks for the enlightenment ;)
<mlankhorst> it's what it's for :P
<duflu> alf__: How do you guarantee that only one compositor buffer is consumed per 16ms in the multimonitor stuff? Is it still partial releases?
<duflu> ... or yet to be figured out?
<alf__> duflu: there is no guarantee for that atm
<duflu> alf__: OK, I thought I might be too early. When you have an idea, please let me know
<alf__> duflu: hmm, sorry, there is a partial guarantee
<duflu> alf__: Saved resources?
<duflu> alf__: I would suggest enforcing that compositor_acquire only happens for real on one monitor (which must also have the highest refresh rate of all monitors)
<duflu> Probably #0. And recycle till that monitor refreshes again
<alf__> duflu: about partial release... essentially the first release of a buffer marks its end as a preferred buffer for next acquisitions. Since under normal operation this happens once per ~16ms, the consumed once per 16ms is enforced.
<alf__> duflu: (more or less)
<duflu> alf__: I know but that won't be true under bypass, so I'm hunting for a more robust guarantee
<duflu> Under bypass, two compositors are held and one consumed, per 16ms
<alf__> duflu: Couldn't we just have a differently constructed BufferStream for bypass, that doesn't enforce the MultiAcquisition policies?
<duflu> alf__: Yes. However I suspect that will cause the client to get buffers at Nmonitors*60Hz
<duflu> Which is fine for me with one monitor right now. Not fine for working with multimonitor
<RAOF> Dear POSIX: signals are hateful, and
<RAOF> I hate you.
<hikiko> hi
<hikiko> question
<duflu> alf__... So before it becomes a problem I would like to see some more explicit distinction between buffer recycling and guaranteed buffer advancement
<alf__> duflu: I haven't really thought about this yet, but perhaps using a combination of a different back buffer strategy in BufferStream plus a different CompositingStrategy (note, renamed to DisplayBufferCompositor in proposed MP), which we need anyway, perhaps we could reach the needed behavior. Hopefully we won't need to have a single behavior that works for both normal and bypass, if that means making compromises for both.
<hikiko> alf__, I tried to use the mir buffers as you said but I am not sure if you can fill the ipc package using those buffers
<alf__> hikiko: what method are you referring to?
<hikiko> fill_ipc_package in platform alf__
<alf__> hikiko: well, the plan is to relay this request to the native platform to do this for you
<RAOF> Who thought that having read() able to return EINTR at any point and *partially* consume the buffer was a good idea? >:(
<duflu> RAOF: Before threads were invented/common...
<duflu> Though arguably, retrying I/O is less error prone than expecting programmers to do threads reliably
<RAOF> And who didn't want to make libc go to the effort to *not* consume the buffer in that case?
<RAOF> Yeah, but you can't retry IO. You need to keep track of how much was actually read, and then try to read the rest.
<RAOF> Because *that's* totally not going to be done badly, and couldn't be sensibly implemented in the goddamned system library.
<hikiko> I don't create a native and a nested platform at the same time alf__ either native or nested
<RAOF> Not that this is *necessarily* the cause of output delay, just that I hate noticing things that are going to explode when a SIGIO comes in at an inopportune time.
<alf__> hikiko: the nested platform should create and use an instance of a specially configured native platform, see second paragraph of mir-on-mir mir-devel email reply
<hikiko> ok
<hikiko> I forgot to re-add this :p
<hikiko> sorry :)
<deathcrawler> Current Ubuntu Phone images uses Mir directly?
<mlankhorst> RAOF: sigh
<mlankhorst> I'm getting reports about mir now..
<mlankhorst> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1201028
<ubot5> Launchpad bug 1201028 in xorg-server (Ubuntu) "Xorg crashed with SIGABRT in raise()" [Undecided,New]
<RAOF> mlankhorst: I don't know what you're talking about officer. Mir couldn't cause *any* problems at all. See, we've corraled him in a PPA where he's kept safe from the masses!
<mlankhorst> the bugs get filed against xorg-server though, what should I do with them?
<mlankhorst> I just want them not be against xorg-server for now, i don't care if I close it as invalid or reassign to mir :P
<duflu> That's odd. There should be no automatic reports when users (like that one) are using a PPA
<RAOF> mlankhorst: Feel to reassign to the xmir project. duflu set that one up :)
<mlankhorst> link?
 * duflu assigned it
<duflu> mlankhorst: Launchpad project "xmir"
<mlankhorst> https://bugs.launchpad.net/ubuntu/+source/xorg-server?field.searchtext=mir&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=
<mlankhorst> but I'll reassign all then
<duflu> Oh, I was reassigning. But OK
<alf__> deathcrawler: not yet (it still uses surfaceflinger) but we are getting close to switching
<tvoss_> RAOF, disabling sigio event reporting in X is great, works fine here ;)
<deathcrawler> alf__: Thanks
<duflu> Oh dear. My diff is now over 4kloc to trunk. This is a worry
<RAOF> tvoss_: Oh, disabling sigio events avoids the bug?
<tvoss_> RAOF, nope
<tvoss_> didrocks, alf__ https://code.launchpad.net/~thomas-voss/mir/fix_process_waitpid_approach_to_correctly_setup_tracing/+merge/176367
<alf__> tvoss_: looking
<alf__> tvoss_: what does the waitpid (pid, NULL, 0) call do after PTRACE_ATTACH?
<tvoss_> alf__, it waits for the child process to be stopped as a result to the parent attaching. that should help us avoid a lot of races
<ogra_> LOL
<ogra_> http://www.indiegogo.com/projects/support-ubuntu-edge-enthusiast
<ogra_> awesome
<ogra_> oops, i'm not in -touch, sorry
<tvoss_> ogra_, still great :)
<alf__> tvoss_: is this because of  WUNTRACED   also  return  if  a  child has stopped (but not traced via ptrace(2)).  Status for
<alf__>                    traced children which have stopped is provided even if this option is  not  speciâ
<alf__>                    fied.
<tvoss_> alf__, yes, partly and PTRACE_ATTACH really is what we want to do here
<alf__> tvoss_: I guess my question is what guarantees that we have that waitpid(..., 0) is notified about the stopped child (normally waitpid() only gets termination events).
<tvoss_> alf__, that's the usual flow of ptrace_attach and then waitpid
<alf__> tvoss_: ok, I am not familiar with it, and the manpages are not very clear, but if it works then great :)
<tvoss_> alf__, tests pass and I haven't seen any flakyness locally
<mlankhorst> oh darn, I had the mir ppa enabled still..
<mlankhorst> might have been why my nv50 was still not working after fixing all the card bugs :>
<kgunn> mlankhorst: are you free to help with ati debug wrt this "unable to provision hw cursor" ?...we have a QA machine on which this is consistently failing 100%, didrocks can help provide access
<kgunn> its blocking mir entering universe
<kgunn> robotfuel: ^ let's see if mlankhorst can help
<mlankhorst> kgunn: sure ;P
<mlankhorst> what kind of hw btw
<hikiko> question: do we have an env variable for the platform already? I'd like to see if my native platform is gbm or android at runtime without ifdef and maybe getenv is an option..
<kgunn> mlankhorst: https://bugs.launchpad.net/mir/+bug/1203070
<ubot5> Launchpad bug 1203070 in Mir "unity-system-compositor doesn't start on some ati card (with opensource driver)" [Critical,Confirmed]
<kgunn> "cedar"
<kgunn> tvoss_: ^
<tvoss_> kgunn, yup
<mlankhorst> mmm lets see
<mlankhorst> kgunn: that's only starting with unity-system-compositor from ppa:mir-team/unity-system-compositor right?
<kgunn> mlankhorst: well, this may be a didrocks build, via his daily ppa (not necessarily exactly system-compositor-testing)
<mlankhorst> mm lets try anyway..
<didrocks> kgunn: mlankhorst: to ensure to run the same version, use those from ppa:ubuntu-unity/daily-build-next
<mlankhorst> ok, upgrading
<tvoss_> mzanetti, ping
<mzanetti> tvoss_: pong
<tvoss_> mzanetti, soemthing weird going on here: https://jenkins.qa.ubuntu.com/job/mir-android-saucy-i386-build/1415/console
<mzanetti> tvoss_: hmm... seems to be the same as last time
<mzanetti> tvoss_: I wonder why this is build on ps-android-sandybridge. That seems wrong
<mzanetti> tvoss_: as that's the machine where the devices for testing are attached
<mzanetti> tvoss_: yeah. this definitely seems wrong to me. who sets up Mir jobs usually?
<kgunn> hikiko: should be easy to add...i would think you could check if gralloc is present
<tvoss_> mzanetti, same happens for clang: https://jenkins.qa.ubuntu.com/job/mir-clang-saucy-amd64-build/1300/console
<tvoss_> mzanetti, not sure, thomi perhaps?
<tvoss_> alf__, ^ can you help here?
<mzanetti> tvoss_: hmm... not sure why the one on kinnara fails. that should work.
<mzanetti> tvoss_: I contacted fginther. he's in a phone call right now. when he's free again we'll try to resolve it asap
<hikiko> yes I've added kgunn I just wonder if we already used one because I couldn't find any
<alf__> hikiko: why do you need to get the native platform type?
<hikiko> because my nested platform has a pointer to the native platform in order to call native functions when necessary
<hikiko> and I have to initialize that pointer to a new GBM or a new Android platform
<hikiko> (the pointer is mg::Platform)
<tvoss_> hikiko, I thought the idea is that the nested platform does not need to know those details?
<hikiko> it won't know
<hikiko> then it will use the mg::Platform functions
<hikiko> but at some point I have to initialize the mg::Platform
<tvoss_> hikiko, isn't it like auto platform = mg::NestedPlatform()?
<alf__> hikiko: you can do it that the same way we get the platform currently, by exposing a symbol in the native platform library (e.g. create_native_platform_nested(...))
<hikiko> I call create_platform_nested() :s
<hikiko> but even the current create_platform
<hikiko> returns a GBMPlatform in GBM case
<hikiko> and an Android in case of android
<hikiko>     return std::make_shared<mgg::GBMPlatform>(report, vt);
<hikiko> you specify that your pointer is mgg::GBMPlatform
<mlankhorst> kgunn: hm tons of fun spam in dmesg......
<alf__> hikiko: Isn't that what you need? The native platform knows what to do when you call create_native_platform_*(...). It creates an appropriate mg::Platform pointer and sends it back to you.
<mlankhorst> kgunn: http://paste.debian.net/18047/
<mlankhorst> though no idea why....
<hikiko> yes but in create_platform* you specify what type of platform this is
<hikiko> you can't have a mg::Platform pointer without initialize it with new GBM or new Android
<kgunn> mlankhorst: do we need to contact radeon guys?
<mlankhorst> but I guess that's what causes your issue here
<hikiko> you either have to do ifdef "GBM"...
<mlankhorst> kgunn: I think so..
<hikiko> or get the platform at runtime
<hikiko> using getenv for example
<kgunn> mlankhorst: do you have a contact ? (i'm supposing you already have :)
<mlankhorst> kgunn: that was with drm-next + drm-fixes of today :P
<hikiko> create_platform returns a different pointer in gbm and in android case
<mlankhorst> I guess #radeon would work, brb buying some food
<kgunn> ta
<alf__> hikiko: that's what create_native_platform_nested() will do also, no difference in the mechanism, just in the way the native platform is set up internally
<mlankhorst> that was a merge of drm-next + drm-fixes, dno how representive that is :P
<mlankhorst> hm i should probably try with a cleaner kernel later just in case
<hikiko> alf__, I am talking about the create_platform_nested implementation
<hikiko> mmm
<hikiko> I mean that
<hikiko> even if create_native_platform_mnested
<hikiko> lives in GBMPlatform
<hikiko> it has to return a GBMPlatform pointer
<hikiko> ah :) sec
<hikiko> lol ok :) mg::Platform lala = create_native... yeah... got it... :P
<hikiko> <-tired :p ok, ignore :)
<hikiko> thanx!
<hikiko> I wrote the func and forgot to use it 2 times today :p
<tvoss_> greyback, ping
<greyback> tvoss_: pong
<mlankhorst> kgunn: ugh, was lacking pm firmware
<kgunn> mlankhorst: pm == power management ?? (e.g. pmic )
<mlankhorst> yeah
<kgunn> mlankhorst: oh...yeah...so hw mouse would be like one of the first hw accelerators i suppose
<kgunn> in terms of sw trying to use it
<mlankhorst> indeed
<mlankhorst> so I guess you should check dmesg, just in case
<kgunn> mlankhorst: so, where does that lie in the field of responsibility ?....is that a ubuntu saucy foundational problem ?...or?
<mlankhorst> kgunn: heck check dmesg on that machine, then you know for sure
<kgunn> mlankhorst: mmm, but X worked ?
<kgunn> gotta run
<mlankhorst> x can fallback to unaccelerated
<kgunn> brb
<kgunn> mlankhorst: ok...back, so "we" mir team need to add in fallback for sw cursor for xmir/radeon ?
<kgunn> bschaefer is this something you could look pre-australian time ? ^
<kgunn> didrocks can give bschaefer access to machine if needed
<bschaefer> kgunn, whats going on? The sw cursor thing?
<kgunn> bschaefer: yeah
<kgunn> https://bugs.launchpad.net/mir/+bug/1203070
<ubot5> Launchpad bug 1203070 in Mir "unity-system-compositor doesn't start on some ati card (with opensource driver)" [Critical,Confirmed]
<kgunn> basically we know the problem....we need to create a solution & test it
<bschaefer> kgunn, possibly, i've a few other things ive to work on :)
<didrocks> kgunn: sure, tell me once you need the access so that I can prepare
<kgunn> bschaefer: no prob...if you're helping robotfuel keep doing that
<kgunn> no pointing in switching just for the sake of it
<bschaefer> kgunn, no, i do unity-maintenance under bregma and i've some new ibus changes I need to get landed
<kgunn> greyback: curious...you said unity8 now (w/ some caveats/bugs) runs on mir....do the instructions on the wiki need to change ?
<kgunn> or does it all just magically stay relevant ?
<bschaefer> kgunn, if I can finish that up quickly I could possibly take a look :)
<greyback> kgunn: which instructions? Let me check through them
<kgunn> bschaefer: ah...ibus...yeah...kinda critical :)
<kgunn> greyback: https://wiki.ubuntu.com/Touch/Testing/Mir
<bschaefer> kgunn, yeah, as some would like the new version landed, but that SW fallback cursor is also critcal!
<greyback> kgunn: hmm, so that URL to s-jenkins is an internal url only, so no community people will be able to use it.
 * bschaefer goes to work fast
<greyback> kgunn: other bits could be updated, yes. I'll add it to my list
<kgunn> greyback: doh...good point
<kgunn> np...in due time
<greyback> kgunn: ack
<kgunn> greyback: crap...can you shoot me the link to your sketchpad of "todo's" closed it before saving link
<greyback> kgunn: sure: http://studio.sketchpad.cc/UFFAX8fxc2
<kgunn> greyback: one more interrupt, does "Use actual surfaces instead of screenshots for window management" actually address my "cut corners" blueprint ?
<greyback> kgunn: I don't think so. That proposal is for shell to animate the actual application surface, not a screenshot of the application (as we're doing right now)
<greyback> kgunn: nothing to do with single-surfac shell
<kgunn> greyback: got it...texture source for the single surf...not actual compositing...
<kgunn> didrocks: can you paste the dmesg output from the ati-trouble machine into the bug ? https://bugs.launchpad.net/mir/+bug/1203070
<ubot5> Launchpad bug 1203070 in Mir "unity-system-compositor doesn't start on some ati card (with opensource driver)" [Critical,Confirmed]
<tvoss_> mlankhorst, ping
<didrocks> kgunn: I just pasted the relevant time log: https://bugs.launchpad.net/mir/+bug/1203070/comments/5
<ubot5> Launchpad bug 1203070 in Mir "unity-system-compositor doesn't start on some ati card (with opensource driver)" [Critical,Confirmed]
<didrocks> (the lightdm segfault)
<kgunn> didrocks: ??....lankhorst indicated the pm firmware not being installed as the reason for hw mouse failing....this is somewhere after that
<mlankhorst> kgunn: pong, might be related, maybe not
<didrocks> kgunn: I don't see any logs for it, does he know what we should install? (even on the image by default)
<mlankhorst> can i start unity-system-compoistor alone
<didrocks> mlankhorst: it seems lightdm is setting up an environment for it
<didrocks> so stopping/start lightdm
<mlankhorst> without lightdmm...
<didrocks> would be a question for kgunn and robert_ancell I guess :)
<kgunn> mlankhorst: sure.. (in xmir config i assume you mean)
<kgunn> which should just kick of mir
<kgunn> tvoss_: ^ sanity
<kgunn> but obvioulsy...no mir clients (as xmir has failed by that point)
<tvoss_> kgunn, ENOCONTEXT
<kgunn> tvoss_: could one, after a failure to boot in xmir, kick off the u-s-c process manually
<tvoss_> kgunn, hmmm, no, you need lightdm and the env for that ...
<kgunn> tvoss_: is the need for lightdm because we cannot have a "clientless" mir ?
 * didrocks wasn't on crack then :)
<tvoss_> kgunn, of course not, it's because the usc needs t obe passed some file descriptors
<tvoss_> kgunn, and a vt to operate upon
<kgunn> tvoss_: ack
 * kgunn was insane...
<mlankhorst> gone
<bschaefer> kgunn, ping
<kgunn> bschaefer: yo
<bschaefer> kgunn, hey, so ive some time now, but I don't have an ATI card :(
<bschaefer> i've a large desktop I can install ubuntu on but it'll take a bit of time
<kgunn> bschaefer: yeah....it'd be best to get access to didrocks machine
<kgunn> but he's not on
<kgunn> at least for the moment
<bschaefer> dang and now hes gone...
<bschaefer> kgunn, well I should have mentioned this acouple hours ago :)
<kgunn> he might show back up
<bschaefer> yeah, Ill try poking some QA people in the meantime
<kgunn> cool
<kgunn> tvoss_: robotfuel: do you know if there is someone else who might be able to provide us access besides didrocks to the ati machine failing to boot ??
<tvoss_> kgunn, not sure, sil2100 might be able to help
<robotfuel> I don't have access to the ati machine yet, jibel might?
<robotfuel> kgunn: ^
<kgunn> jibel: could you help us ?
<bschaefer> kgunn, I think I found one
<kgunn> sweet!
<kgunn> bschaefer: i'm gonna break for lunch...
<bschaefer> kgunn, cool, enjoy your lunch!
<tvoss_> xjunior, hey there :)
<tvoss_> xjunior, still busy debugging
<xjunior> tvoss_: nice man :) good luck with that!!
<xjunior> I believe it's a hard piece of code to debug
<bschaefer> kgunn, yup, got access to a ati machine, thanks for the suggestion :)
<tvoss_> xjunior, it is, raof is looking into it, too
<xjunior> fortunately it's not Xorg :P
<xjunior> I still can't get into Xorg, btw. I believe it's a intel driver issue. It's crashing and I remember it was updated a few days ago
<tvoss_> xjunior, did you pin the ppa?
<xjunior> yeap
<bschaefer> xjunior, something like this: https://bugs.launchpad.net/xmir/+bug/1203776
<ubot5> Launchpad bug 1203776 in xserver-xorg-video-intel (Ubuntu) "X crashes w/ latest xserver intel driver from System Compositor Testing PPA" [Undecided,Confirmed]
<tvoss_> xjunior, just to make sure: you have got the system-compositor-testing ppa?
 * bschaefer was getting an intel crash on normal X as well this morning
<racarr> I am trying to process the scene graph discussion email
<xjunior> tvoss_: yea yeah, absolutely
<xjunior> I guess that's what's happening to me :)
<racarr> and I think what Alan is describing, and what I've started to see we need through some of the pain in resolving races like in session-transactions
<racarr> is not actually a scene graph in...any particular sense
<racarr> one of it's responsibilities (it's interface to the compositor) coincides with some of the responsibility of a scene graph
<xjunior> That's exactly the situation I have here, tvoss_. I +1'd that bug
<tvoss_> xjunior, thx
<racarr> but it contains assosciations like session->surface, etc, which aren't actually 'scene' assosciations
<racarr> I guess I feel like the problem we are trying to solve, is that we have dataa and state distributed over the system so we want to integrate it in to a single multi index store
<racarr> and not
<racarr> we need a "scene graph"
<racarr> *trails off in to mumbling*
<racarr> I am just thinking outloud :)
<bschaefer> racarr, so your trying to come up with a data structure that can store all of the session/surfaces while having random access while having some sort of graph structure?
 * bschaefer could have read that wrong
 * bschaefer looks up scene graph...
<bschaefer> which looks just like a B-Tree
<bschaefer> but a bit crazier...
<racarr> bschaefer: Hmm, thats probably part of the data structure. but I think finding a data structure once we know exactly what we need wont be so bad
<racarr> I guess to me the thing is, state is distributed all over the system
<racarr> i.e. the input state is held in some data structure that basically builds an input view of the surface stack
<bschaefer> right, reading scene graph wiki was kind of funny: The definition of a scene graph is fuzzy
<racarr> the shell bit with the session assosciation, and shell state lives in the shell, and acts as sort of another view/controller to the surface stack
<bschaefer> isn't input in a different thread as well?
<racarr> likewise, the compositor gets a view of the surface stack, and treats it like a scene graph
<racarr> Right
<racarr> so with all the state in different bits
<racarr> synchronization gets
<racarr> increasingly difficult
<bschaefer> geez, thats going to be hard to get that all sync...
<bschaefer> yeah
<racarr> and, another thing is pretty much all state
<racarr> changing in mir
<racarr> needs to support some pattern like
<racarr> notify the shell of this and potentially allow it to interfere, etc.
<racarr> and without one authoratative source of...what is what when
<racarr> this becomes kind of difficult and we've ended up with this weird pattern where the shell will do things like subclass one of our factory objects
<bschaefer> you'll get lost...and out of order :(
<racarr> and interfere and then call up to the base class
<racarr> yeah
<racarr> so that's what I am thinking about :p
<bschaefer> that is an interesting problem to solve...
<racarr> and we have always called this a scene graph, because at a very high level
<racarr> a bunch of components manipulate it, then the compositor visits it to render the scene
<racarr> well, at one very high level XD
<bschaefer> yeah, that sounds like a fun problem that almost seems like it needs to be broken down a bit haha
<racarr> but I think, "scene graph" doesn't actually capture the problem we are trying to solve
<racarr> yeah
<tvoss_> racarr, what you are describing is the mvc, isn't it?
<bschaefer> well, i don't a single data structure can capture that...scene graph is pretty high level thats just a bunch of other graphs/trees
<bschaefer> s/dont/dont think
<racarr> tvoss_: Well...it's some kind of MVC right! But it has a very particular structure
<racarr> and has to provide a few seperate views
<racarr> and I think part of what it needs to do is
<tvoss_> racarr, right, but mvc can account for that ;)
<tvoss_> racarr, gerry is merely pointing out that we can leverage an existing implementatoin quite easily. and I do strongly agree with that
<racarr> support some system of
<tvoss_> most likely, the glue layer I'm mentioning in the mail will allow for querying the views (compositor, input, focus) that you have in mind
<racarr> transactional/atomic operations
<racarr> mm
<racarr> but I guess I am saying that is the real problem at hand
<racarr> and if we knew these interfaces
<racarr> the data structure is entirely trivial
<racarr> maybe Qt through OpenSceneGraph can help us on the rendering end
<racarr> but that's closer to a view on this structure in the compositor not the structure itself I think
<racarr> right I mean this is our central data store, not our "rendering pass optimizer"
<racarr> I honestly still dont understand what it would mean though, using the qt scene graph
<racarr> does it mean ms::Surface implements QSceneGraphItem?
<racarr> Are we talking about just reusing their data structure? or using the renderer too?
<racarr> I don't think it understands that each display element has its own opengl context that its children are drawn in
<racarr> so I don't understand how that can be integrated with the compositor exactly
<racarr>  / at all.
<racarr> Sorry :) I don't mean to be negative
<racarr> but I literally don't know what the first step towards doing this would be
<kgunn> racarr: what is the first "it's" in "one of it's responsibilities (it's interface to the compositor) coincides with some of the responsibility of a scene graph"
<kgunn> i/f to compositor ?
<bschaefer> kgunn, hey, been rebooting this machine for a while now and xmir starts up each time :(
<bschaefer> using : 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Caicos PRO [Radeon HD 7450]
 * bschaefer keeps rebooting
<kgunn> bschaefer: hmmm....didrock's was a Cedar series...which i think is Radeon HD 5000 series of gpu
<bschaefer> kgunn, right, i should go check my desktop really quick...as if its a cedar series it might be worth getting xmir installed on it
<kgunn> bschaefer: also..
<kgunn> just thinking
<kgunn> it wasn't so much the fact it was cedar series....
<kgunn> the current theory of suscpicion was that
<bschaefer> the power management?
<kgunn> didrock's machine didn't have pm firmware installed
<kgunn> right
<bschaefer> yeah, hmm I wonder if I can uninstall that...
<kgunn> so when the gfx driver tried to use hw cursor it couldn't
<kgunn> ...and then got pissed
<bschaefer> but you would think things would fail softly...
<bschaefer> instead of bringing everything down
<kgunn>  (that's U.S. pissed not U.K. pissed)
 * bschaefer is from U.S
 * bschaefer just learned there was a difference
<bschaefer> kgunn, would you happen to know how to remove pm firmware?
<kgunn> oh...thot you were in canada...and you never know which they favor with speech :) z==zee vs zed
<kgunn> bschaefer: no ide
<kgunn> idea
<bschaefer> kgunn, haha yeah, from Seattle :)
<bschaefer> close
<bschaefer> kgunn, alright, well ill look into if thats even possible to remove, and if removing it should yield a working desktop or not
<kgunn> bschaefer: kernel folk might know....
<bschaefer> kgunn, would you happen to know a channel for that? When/if i get stuck at lease...
<racarr> kgunn: This data structure that we are debating in the email thread
<racarr> if I understood your question
<racarr> that point was just supposed to say that while it mimicks a scene graph in one scenario
<kgunn> bschaefer: took a guess...lots of people in #ubuntu-kernel
<racarr> I dont think that's the right way to come at it
<bschaefer> kgunn, great guess :), thanks!
<kgunn> racarr: ack
<kgunn> bschaefer: high five!
<racarr> I mean in the most literal sense
 * bschaefer high fives back
<racarr> it could be called a graph of the scene
<racarr> but it could also be called a list haha
<racarr> so I am trying to find the right direction to zoom in on it from
<kgunn> bschaefer: hmm, could it disabling the "APM" option referred to here be the trick http://how-to.wikia.com/wiki/How_to_configure_the_Linux_kernel/Power_management_options_(ACPI,_APM)
 * bschaefer takes a look
<bschaefer> possibly, I was thinking I could move the firmware/driver out of its dir in the kernel somewhere
<kgunn> bschaefer: maybe...something easier first...
<kgunn> duh
<kgunn> why not change the xorg conf to just rely on sw cursor
<bschaefer> hmm so right now its relying on the hw cursor?
 * bschaefer looks at the xorg conf
<kgunn> bschaefer: so i guess any xorg driver actually reads the xorg conf file....
<kgunn> http://linux.die.net/man/4/radeon
<kgunn> ?
 * kgunn realizes how little he knows
<bschaefer> kgunn, as do I :), im looking at turning some things off in the BIOS at first possibly that'll cause the firmware to not load?
<bschaefer> kgunn, also the machine im on doesn't even have an xorg conf file
<bschaefer> but I did fine a bunch of binary in the kernel that looked like it was dealing with power...but I have a feeling moving those will cause other problem s:)
<bschaefer> kgunn, how did we come to the conclusion the we were missing pm firmware?
<kgunn> mlankhorst saw dmesg's go by saying so
<kgunn> bschaefer, but i think you should be able to simply add a xorg conf file with over-riding values for options
<bschaefer> right, i need to look at those man pages :)
<bschaefer> lots of things to read :)
<kgunn> i only think this because of sna wiki (https://wiki.ubuntu.com/X/Testing/IntelSNA) where it talks about downloading their pre-formed version for sna
<bschaefer> yeah you can add an xorg conf file... im just wondering why there wasnt one...
<bschaefer> im also trying to wrap my head around why not having a pm firmware loaded would cause the hw cursor to not work
<kgunn> on the pm part...hw cursor is actually a seperate piece of silicon, that requires to be "powered" up at some point, so something probably inside the hw mouse driver
<kgunn> queried pm, it failed, so he failed..."sorry i ain't got no power"
<bschaefer> that does make more sense, im waiting on this machine to do something
<bschaefer> kgunn, sorry, seem to have broken to machine, hopefully I can get it up soon :)
<kgunn> bschaefer: thanks for the effort
<bschaefer> the machine*
<kgunn> and the update
<kgunn> :D
<bschaefer> np, I guess you can't just disable all PM  and expect it to turn on :)
<bschaefer> also forcing a SW wont help much atm, as im trying to reproduce the problem atm :)
<bschaefer> alright, have the machine back...
<xjunior> tvoss_: hey man, did have success
<tvoss_> xjunior, how?
<xjunior> any news on debugging the slowness on XMir
<tvoss_> xjunior, ah, that was a question?
<xjunior> yeah :) sorry
<xjunior> I ate some words apparently
<tvoss_> xjunior, no worries :) know the symptoms
<tvoss_> so I have an instrumented build of X now, will give that a spin tomorrow. Its 11pm here :)
<xjunior> oh, gotcha :) Europe?
<tvoss_> xjunior, yup, Germany
<xjunior> nice :) have friends there
<kgunn> robert_ancell: so looks like the ati bug is the last hurdle (at least for universe)
<xjunior> Alright, good luck tomorrow. Hope you solve it.
<kgunn> robert_ancell: so some debug mlankhorst did that didrocks machine didn't have pm firmware installed...
<mterry> robert_ancell, you asked about u8-greeter and running as mir server?
<kgunn> so when hw cursor tried to init...it failed....and xmir didn't fall back to sw cursor
<mterry> robert_ancell, I was thinking we wouldn't need to run as mir server anymore
<kgunn> whereas standalone x does (or that is the assumption)
<kgunn> robert_ancell: so bschaefer is in the midst of trying to "simulate" that problem...since didrocks is sleeping :) and we can't get to the machine
<bschaefer> yeah, and so far xmir is working, sooo trying to remove pm firmware...but just got the broken machine back...
<robert_ancell> mterry, I'm just getting LightDM to support Mir sessions/greeter with VT switching since we don't have nested Mir support yet. Just wondering if I can run the u8 greeter for now like that or support has been dropped
<kgunn> robert_ancell: so i'm hoping this is either a bug or missing feature we have to fall back to sw cursor
<robert_ancell> kgunn, who let didrocks go to sleep? ;)
<kgunn> i know... right ?
<robert_ancell> kgunn, yeah, wonder if it's just never been noticed because everything does the fallback
<robert_ancell> seems like it should be fixed in the driver depending on how widespread it is
<kgunn> robert_ancell: yeah...its one of those bugs that might have been lurking...also, just in case...didrock card was  a Cedar (5000 series)
<kgunn> just in case....as in bschaefer is toying around on a 7000 series
<bschaefer> it would be strange that a specific ATI card was doing this vs PM ... but what do i know haha
<kgunn> robert_ancell: if you, duflu or RAOF have a 5000 series it might be worth it just to enable swcursor in xorg.conf and test it
<bschaefer> they are under different classes though...
<robert_ancell> kgunn, I just have the one intel/nvidia card
<kgunn> it would at least help in confirm/deny
<mterry> robert_ancell, my branch is still using an internal mir-server
<bschaefer> im on a Caicos PRO
<kgunn> that this whole issue is related to swcursor
<mterry> robert_ancell, i.e. I haven't made it a pure client yet
<robert_ancell> mterry, cool, can you keep it like that for testing purposes until we have the whole stack ready?
<robert_ancell> or support both?
<kgunn> mterry: now has 3 optional configs he needs to support :))
<mterry> :)
<mterry> robert_ancell, uh, I can keep my current split as is, yeah.  Let me know when you don't care about mir-server mode anymore
<robert_ancell> mterry, will do :)
<kgunn> robert_ancell: also...would you mind dispositioning the MIR feedback ? i think your best to speak to it
<kgunn> robert_ancell: one note...for all the "need to assign a bug owner"
 * robert_ancell looks up dispositioning
<kgunn> olli chose mir-team for the moment :)
<robert_ancell> kgunn, that works for now
<kgunn> yeah...he promised to seek another victim...oops i mean owner
<robert_ancell> wiktionary says "Present participle of disposition.". Now I have to remember what a present participle is :)
<kdub> EventSink hitch-hikes through a lot of constructors
<kgunn> :)
<kgunn> robert_ancell: whenever RAOF or duflu come on, just check if they've got a cedar/5000 series ati card to try (w sw cursor).....since that bugs our #1 right now
<robert_ancell> kgunn, ok
<robert_ancell> mterry, oh, how did you remove the u-s-c task from the mir MIR?
<mterry> robert_ancell, there's a little red minus symbol next to the tasks
<robert_ancell> mterry, huh, I totally missed that
<mterry> robert_ancell, way nicer than marking invalid in terms of bug spam
<robert_ancell> yes
<robert_ancell> mterry, in the MIRs you refer to needing a dev team subscribed to bug reports. Is that the "bug supervisor" in https://bugs.launchpad.net/mir?
<mterry> robert_ancell, yeah, but for the ubuntu package side, not the upstream one
<mterry> so ubuntu/+source/mir
<robert_ancell> mterry, k
<mterry> I guess that's mir-team
<robert_ancell> mterry, so, Unity doesn't seem to have a subscriber https://bugs.launchpad.net/ubuntu/+source/unity
<mterry> robert_ancell, that would be good to add too
<mterry> robert_ancell, we didn't use to *require* it, only strongly suggest it
<mterry> robert_ancell, but no one did it, so we are bumping up our language
<robert_ancell> mterry, yeah, I'm trying to find *any* project that has a team subscribed to bug email
<racarr> kdub: It's not strong coupling, all the classes are just really good friends and having a party.
<racarr> :p
<mterry> robert_ancell, most of the gnome desktop ones have a team subscribed
<robert_ancell> the dialog for this is really bad. The list of teams is not sorted alphabetically
<robert_ancell> and you can't seem to tell who is subscribed by looking at the project page
<kdub> racarr, haha
<robert_ancell> RAOF, did you see the traceback about cedar/5000 series ATI cards
<RAOF> robert_ancell: I did, yes.
<robert_ancell> RAOF, got any?
<RAOF> I do not.
<RAOF> I've got a 4535 or somesuch, and a 7870 that I don't have a desktop box to put into.
<bschaefer> RAOF, i've been trying to reproduce it as well, on a 7450
<bschaefer> but xmir is working perfectly
<bschaefer> RAOF, it was mentioned that this could be due to the power management firmware missing, but it doesn't seem to be easy to just remove that to test if thats the problem...
<RAOF> bschaefer: I don't know about that - on 3.11 kernels you need more firmware than we've got in linux-firmware to *load* radeon.ko, but (a) we're running a 3.10 kernel, and (b) Mir would fail in a different way if that were the case.
<bschaefer> yeah... hmm I wonder if its the radeon family (as the 5000 is in the evergreen series) drivers then...
<bschaefer> RAOF, shouldn't mir attempt to play nice when it can't load the HW cursor?
<RAOF> Maybe? It currently doesn't, though.
<bschaefer> well you would assume if this happens: std::exception::what: failed to create gbm buffer
<bschaefer> no other gbm buffers are going to work...
<RAOF> You know what? I should look in the xf86-video-ati source and see whether they have any specific hacks for that card & the hw cursor.
<RAOF> Unfortunately, not. The hw cursor bo is super-specific - failing to allocate it doesn't mean that you'll fail to allocate anything else.
<bschaefer> o hmm thats interesting
<bschaefer> well im sure you've seen the list family for the ATI cards but: http://xorg.freedesktop.org/wiki/RadeonFeature/
<bschaefer> as the card im using is under Nothern Islands...idk if that even matters though vs the driver is self for each card
<RAOF> Isn't a 7450 SI? Stupid damned marketing department.
<bschaefer> it should be, looking at the number but the machine im on gives me:
<bschaefer> 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Caicos PRO [Radeon HD 7450]
<bschaefer> which Caicos is a NI card...possibly the  PRO is throwing it off...
<bschaefer> but looking here as well: http://wiki.gentoo.org/wiki/Radeon#Feature_support
<bschaefer> and it  has the 7450 under NI
<RAOF> Yeah, it the radeon page is probably right.
<bschaefer> hmm my desktop that i've not used in a while had an evergreen card
<RAOF> I just hate that the card marketing generation is not the same as the card chip generation.
<bschaefer> a redwood one
 * bschaefer starts downloading13.10
<RAOF> I've got an evergreen (although I can't quite remember the specific model) too, but that worked fine last time I tried it.
 * RAOF will be slow for the next hour or so, as he's minding ZoÃ«.
<bschaefer> well it'll take  a bit for me to get my desktop up with xmir.. 1-2 hours...
<bschaefer> it'll be strange if its just specific to CEDAR
<bschaefer> but then again this could be normal, as I haven't done video card stuff much before :)
<bschaefer> hopefully duflu will come on a reproduce the problem
<bschaefer> and*
<RAOF> Hey, is there any way to get a buffer ID that crosses the IPC boundary? I want to check that the buffer I most recently submitted from XMir is *really* the buffer that Mir's displaying.
<olli_> bregma, can you pls ping the relevant armhf issues to slangasek?
<olli_> or robert_ancell ^
<kgunn> RAOF: ok....any guesses on why robotfuel might see openarena values higher on Xmir vs X ?
<kgunn> kgunn: the results are still strange with the monitor attached x is 44.47  frames per second average and xmir is 136.97
<kgunn> is it because there's no governing ?
<kgunn> e.g. no more vsync on the bottom of x (moved to the bottom of mir)
<kgunn> robotfuel might take a trained eye....but do you see any tearing ?
<RAOF> vsync would be my immediate guess
<robert_ancell> kdub, around?
<kdub> yep
<RAOF> XMir clients are *not* throttled to vsync
<robert_ancell> kdub, I've just forwarded you an email regarding armhf tests and android. Perhaps you can help understand what lp:mir expects and what is happening
<kdub> sure
<kgunn> robotfuel: does it also provide time to complete ?....and is that different on x vs xmir ? (ignoring the fps for moment)
<kgunn> RAOF: right...so clients can go nuts and swap buffers as they like...which means, the truly displayed frames is much less than that
<kgunn> or "allegedly" is much less than that :)
#ubuntu-mir 2013-07-24
<robotfuel> kgunn: it doesn't save that information in the logs
<robotfuel> kgunn: I will rerun the tests to get that info, it goes to stdout
<robotfuel> kgunn: I don't notice any tearing, but open arena is always moving it would be hard to see
<robotfuel> kgunn: I'll watch again and get back to you. brb
<robotfuel> kgunn: openarena runs too fast to tell if it's tearing
<Sarvatt> run non xmir openarena with vblank_mode=0 openarena?
<robotfuel> xorg had a segfault on intel with xmir http://10.97.2.10:8080/job/utah-xmir-troubleshooting/ws/results/Xorg.0.log
<tvoss_> RAOF, ping
<sgx1> hi. now there're two mir PPAs, which one to use? installing_prebuilt_mir_on_pc.md suggests using system-compositor-testing ppa. but i find packages in Mir staging ppa are newer.
<tvoss_> sgx1, yup, but staging revs too fast and system-compositor-testing is the save alternative so far :)
<tvoss_> sgx1, we cherry-pick over to system-compositor-testing on a regular basis
<RAOF> tvoss_: Pong.
<robert_ancell> RAOF, duflu, alf__, hikiko, racarr, kdub, kgunn, meeting time!
<robert_ancell> thomi too!
<hikiko> hi
<hikiko> joining in a sec robert_ancell
<kgunn> kdub: you around?
<tvoss_> didrocks, ping
<didrocks> tvoss_: pong
<tvoss_> didrocks, got a branch for you to test on the ati machine :)
<didrocks> tvoss_: yeah! there are two ways: building it locally (but I don't have any i386 machines ready)
<didrocks> tvoss_: or pushing that to the ppa manually
<didrocks> I'm in favor of #2
<tvoss_> didrocks, so what do you need from me? just the branch?
<didrocks> tvoss_: yep, the branch is fine
<tvoss_> didrocks, lp: ~thomas-voss/mir/default-to-null-input-by-default
<didrocks> tvoss_: branching, pushing, building
<didrocks> then will rerun
<tvoss_> didrocks, ack
<tvoss_> didrocks, status?
<tvoss_> didrocks, I need to step out at 10 my time (in ~55 minute) to run some errands
<didrocks> tvoss_: well, it's building in the ppa right now
<didrocks> tvoss_: and as there is an ABI break, regarding to latest version, I have to rebuild u-s-c as well
<didrocks> so waiting for mir to publish first
<tvoss_> didrocks, ack ... which ppa are you using?
<didrocks> tvoss_: daily-build-next
<tvoss_> didrocks, ack and thx
<didrocks> yw ;)
<didrocks> will keep you posted
<tvoss_> didrocks, stepping out now, back in ~1 hour
<didrocks> tvoss_: ok, u-s-c is building now
<tvoss_> didrocks, ack
<dholbach> good morning
<mlankhorst> didrocks: ping
<didrocks> mlankhorst: pong
<mlankhorst> didrocks: on that non-working machine, could you post the full logs from /var/log/lightdm and full dmesg?
<didrocks> mlankhorst: I are running a rerun from tvoss first
<didrocks> mlankhorst: so wait for it I would say ;)
<didrocks> currently running, so shold have results soon
<mlankhorst> yeah my own test machine fails with std::exception::what: Failed to set the current VT mode
 * mlankhorst doesn't have plymouth or splash enabled, might be why
<mlankhorst> hm seems to be https://bugs.launchpad.net/mir/+bug/1195509
<ubot5> Launchpad bug 1195509 in Unity System Compositor "System compositor fails to start - Failed to set the current VT mode: Input/output error (5)" [Critical,Triaged]
<didrocks> mlankhorst: do you start it from lightdm?
<mlankhorst> yeah
<didrocks> weird
<mlankhorst> does lightdm switch to the console before letting unity-system-compositor configure it?
<mlankhorst> and can I use strace on ust somehow, to figure this one out
<didrocks> mlankhorst: I can answer on the second one
<didrocks> mlankhorst: /etc/lightdm/lightdm.conf.d/
<didrocks> you have a file shipped by usc
<didrocks> you can put a command
<didrocks> like: system-compositor=strace unity-system-compositor
<mlankhorst> yeah
<mlankhorst> hm of course that works..
<mlankhorst> didrocks: who spawns the xserver, unity-system-compositor or lightdm?
<didrocks> mlankhorst: ligthdm AFAIK
<didrocks> but I can be wrong
<mlankhorst> hm seems to be a plymouth race :P
<tvoss> didrocks, ping
<didrocks> tvoss: wb!
<didrocks> tvoss: so passed \o/
<didrocks> tvoss: please file a MP ;)
<didrocks> (I'm still rerunning to ensure we don't get any race, but should be good)
<tvoss> didrocks, \o/
<tvoss> RAOF, any more insight? any handover tasks I should look into?
<mlankhorst> looks like it's still failing locally, I'll try to figure out why :p
<RAOF> tvoss: I'm still hooking up exposing the buffer id to the client. Once that's done, I'll instrument everything and give it a run.
<tvoss> RAOF, awesome, thank you :)
<tvoss> greyback, ping
<tvoss> alf__, didrocks https://code.launchpad.net/~thomas-voss/mir/default-to-null-input-by-default/+merge/176638
<greyback> tvoss: pong
<alf__> tvoss: what's the driving force behind default-to-null-input-by-default ?
<tvoss> alf__, first: it saves us a bunch of wakeups per second in the system compositor scenario. Second: it solves issues with booting up on certain ATI HW where creating a bo for the hw cursor results in an exception
<alf__> tvoss: can't the system compositor turn this off, instead of making it the default?
<tvoss> alf__, possible, too
<didrocks> tvoss: should I rebuild Mir without your patch and be ready to take the new system-compositor in?
<didrocks> tvoss: ran 4 times, with full test suit and pass
<mlankhorst> I think I understand the bug, but not the fix yet :P
<tvoss> mlankhorst, which one exactly? the ati one?
<mlankhorst> https://bugs.launchpad.net/mir/+bug/1195509
<ubot5> Launchpad bug 1195509 in Unity System Compositor "System compositor fails to start - Failed to set the current VT mode: Input/output error (5)" [Critical,Triaged]
<tvoss> mlankhorst, \o/ I have been looking at that, too
<tvoss> didrocks, yup, but might take me some time, an hour or so
<didrocks> tvoss: ok, I can rebuild Mir meanwhile
<didrocks> to not loose time
<didrocks> tvoss: or will you have Mir changes?
<didrocks> (to expose an API or so onâ¦)
<mlankhorst> tvoss: well it's a dumb bug
<tvoss> didrocks, most likely no mir changes, at least I hope so
<didrocks> tvoss: ok, let me do a preventive build then :)
<RAOF> mlankhorst: Something involving plymouth is a dumb bug? Say it ain't so!
<mlankhorst> I don't get why plymouth is killed by lightdm *after* xserver started..
<mlankhorst> or mir
<didrocks> mlankhorst: I think for smooth transitioning? (just a guess)
<mlankhorst> anyway the io comes from the TTY having hung up
<RAOF> No, that shouldn't be it.
<mlankhorst> I'm guessing it is being opened too early, while plymouth still has control over it
<RAOF> mlankhorst: How's that mir-plymouth branch goin? :)
<mlankhorst> RAOF: blocking on the same thing as I want to block Xmir for, the separate thread is ugly
<RAOF> mlankhorst: Indeed it is; bug tvoss about that :)
<mlankhorst> but I did a control WARN_ON(1), and I did get that unity-system-compositor had a WARN_ONn hung_up_tty_ioctl+0x27/0x50
<mlankhorst> so it looks like this is the issue here
<tvoss> mlankhorst, RAOF happy to adjust the separate thread, but can we fix the bug without me on the critical path?
<mlankhorst> tvoss: erm sure, just postpone opening the fd or patch lightdm some more
<tvoss> mlankhorst, cool
<mlankhorst> I can do the latter
<RAOF> tvoss: Yeah, it's fixable. It's just that there wouldn't be an opportunity for this bug to exist if we weren't doing the stupidly fragile plymouth dance.
<tvoss> RAOF, help me understand, what is the fragile plymouth dance? :)
<mlankhorst> tty handover from plymouth
<RAOF> Plymouth starts, grabs the display. We then ask plymouth to die but hide its dying, and then X starts up, grabs the display, and takes the contents of the framebuffer.
<mlankhorst> well it looks like a workaround here might be to use VT_SETACTIVE instead of VT_ACTIVATE
<mlankhorst> erm VT_SETACTIVATE *
 * duflu goes to find food
 * tvoss loves those subtle differences for VT_* ;)
<tvoss> duflu, good luck
 * duflu rolls eyes at those identifiers
<mlankhorst> we'd snatch the terminal away from plymouth, if it's still active :P
<tvoss> RAOF, so in an ideal world, plymouth would just be a mir client, right?
<RAOF> Correct!
<mlankhorst> meh lets see if it works..
<RAOF> mlankhorst: Can we just nuke the whole VT subsystem?
<tvoss> RAOF, would disconnecting from the controlling tty for Mir help here?
<mlankhorst> lets see if this works...
<mlankhorst> tvoss: when touching the modes of the controlling tty, you want to not be attached to the tty?
<tvoss> mlankhorst, random idea :)
<mlankhorst> I guess not touching the tty at all could work though :p
 * tvoss mutters something about process group leaders and setsid
<tvoss> alf__, I set the status of https://code.launchpad.net/~thomas-voss/mir/fix_process_waitpid_approach_to_correctly_setup_tracing/+merge/176367
<tvoss> back to needs review
<tvoss> I'm quite sure I can fix the heisenbug :)
<mlankhorst> tvoss: actually it might need setsid for this to work correctly..
<mlankhorst> is unity-system-compositor run as root?
<tvoss> mlankhorst, I think so
<alf__> tvoss: as you like, I figured that since this MP was not related to the problem that cause the failure, we might as well merge it
<RAOF> mlankhorst: Yes, u-s-c is run as root.
<mlankhorst> blergh, looks like we need to do setpgid, setsid, before opening console
<mlankhorst> after that when /dev/tty is opened it automatically becomes ours, or in the worst case we need to claim it for ourselves
<tvoss> alf__, fair point, I will repropose under a different name
<mlankhorst> I now know more about job control than I cared for :p
<RAOF> tvoss: I'm off to bed; I've not yet managed to run a fully instrumented stack, so I'm not sure what I'll find.
<tvoss> RAOF, ack, thanks
<mlankhorst> meh got a fix, I think
<mlankhorst> http://paste.debian.net/18230/
<mlankhorst> the TIOCSCTTY needs to be uncommented if the setsid is not enough..
<mlankhorst> but it's kind of rude since it means snatching the tty away from someone else :p
<tvoss> mlankhorst, well, that's the consequence of our plymouth dance, right? :)
<mlankhorst> I guess so, what is the sleep for btw
<mlankhorst> it seems to work fine without
<tvoss> mlankhorst, didrocks was seeing some races iirc :) didrocks ^?
<mlankhorst> apart from some gpu stall everything works fine I guess
<mlankhorst> and the stall might be related to changes in my own tree
<mlankhorst> meh the remainder seems to be related to my card being flaky
<tvoss> mlankhorst, \o/
<tvoss> mlankhorst, wanna come up with an mp?
<mlankhorst> what branch is base?
<tvoss> mlankhorst, trunk, bzr branch lp:mir
<mlankhorst> ok
<mlankhorst> lets see if this works
<tvoss> alf__, didrocks https://code.launchpad.net/~thomas-voss/mir/fix_process_waitpid_approach_to_correctly_setup_tracing/+merge/176367
<mlankhorst> hm, I need a better git-bzr
<tvoss> mzanetti, could you retrigger CI for https://code.launchpad.net/~thomas-voss/mir/fix_process_waitpid_approach_to_correctly_setup_tracing/+merge/176367
<tvoss> ?
<tvoss> didrocks, you around?
<mzanetti> tvoss: sure. If you want I can give you permissions to retrigger jobs
<tvoss> mzanetti, I have, still need to setup my vpn :)
<tvoss> again :)
<mzanetti> tvoss: actually, in this case its enough to re-set the MR to "Approved" and Jenkins will pick it up again
<tvoss> mzanetti, top-state?
<mzanetti> tvoss: yeah
<didrocks> tvoss: back now
<tvoss> didrocks, https://code.launchpad.net/~thomas-voss/mir/fix_process_waitpid_approach_to_correctly_setup_tracing/+merge/176367
<tvoss> didrocks, that's not the usc adjustment
<didrocks> ok, looking for the additional commit
<didrocks> tvoss: ok, a little bit complex. What I would suggest is that we get the ATI fix first, then, having that running (with the workaround) a couple of day, and then, removing the sleep workaround, thoughts?
<tvoss> didrocks, not sure I do get you :) the mr I pasted is not connected to the ati issue ;)
<didrocks> tvoss: right, what I meant is:
<didrocks> let's not try to remove the race workaround for now
<didrocks> your fix is to avoid this issue, right? ^
<tvoss> didrocks, where do you see that I remove it?
<tvoss> nope :)
<mlankhorst> look I don't think that this is ready for universe if it requires a sleep workaround..
<tvoss> didrocks, mlankhorst might have a fix for the sleep workaround
<didrocks> tvoss: ah, I thought the waitpid would help that case as well, but maybe not enough context in the diff and it would be better than I download the whole file :)
<didrocks> ah good ;)
<tvoss> didrocks, yeah, this should fix the armhf races
<didrocks> but I would suggest that we keep the sleep for a couple of days (even if we have the fix)
<didrocks> to get things flowing
<didrocks> and then, trying to removing it and testing several rounds
<tvoss> didrocks, for disabling the input: can we pass additional command-line arguments to usc via lightdm?
<didrocks> tvoss: it seems to be possible, you just can't use shell expansion or && for instance
<didrocks> but command --option seems to work
<didrocks> (as "strace unity-system-compositor" worked)
<tvoss> didrocks, okay, then you can just pass --enable-input=false to usc :)
<didrocks> tvoss: this is already implemented?
<tvoss> didrocks, yup
<didrocks> hum, grep isn't my friend
<tvoss> didrocks, usc uses mir's DefaultServerConfiguration, which in turn respects that command-line option
<didrocks> ah ok ;)
<tvoss> didrocks, you need to fgrep in mir
<didrocks> yeah, makes sense
<tvoss> src/server/default_server_configuration.cpp
<didrocks> indeed, saw it :)
<didrocks> tvoss: https://code.launchpad.net/~didrocks/unity-system-compositor/fix-for-ati/+merge/176674
<didrocks> I'll then rebuild once in trunk and ensure with multiple test runs it's reliable
<mlankhorst> and again that needs fixing too :P
<mlankhorst> https://code.launchpad.net/~mlankhorst/mir/setsid/+merge/176676
<tvoss> didrocks, mind filing a bug against usc to make sure that we reenable hw pointer functioanlity shortly?
<didrocks> tvoss: sure
<tvoss> didrocks, thx
<mlankhorst> I don't think papering around it is a good thing though, that bug should be fixed first
<didrocks> mlankhorst: we have deadlines as well, we can't be idealistic when working on time constraints
<didrocks> as long as bugs are logged in, I don't think we should hold off
<didrocks> if we know that the workaround is reliably working
<mlankhorst> yeah but you want to land a random git snapshot of mesa, some xorg patches and some other stuff and then put mir in universe?
<didrocks> mlankhorst: mir will be in main I guess
<didrocks> to be able to build xorg
<didrocks> as it's a build-dep, right?
<mlankhorst> yes
<didrocks> so Mir in main, but not enabled by default
<didrocks> just a technology snapshot to get people trying it
<mlankhorst> and if it's in main it means I have to support it, including the mir bits. So open bugs that are not understood become a lot more important to me then..
<robotfuel> Does anyone know how I change the resolution in xmir? xrandr doesn't work
<didrocks> mlankhorst: you're welcome to give a hand to properly resolving them promptly consequently
<didrocks> tvoss: https://bugs.launchpad.net/mir/+bug/1204505
<ubot5> Launchpad bug 1204505 in Mir "unity-system-compositor needs to have hw pointer functionality enabled back" [Undecided,New]
<tvoss> didrocks, thx
<didrocks> tvoss: not sure how you want to prioritize it
<tvoss> didrocks, not sure yet, put it high, please
<didrocks> doing so
<robotfuel> Sarvatt: I tried openarena with vblank_mode=0 in xmir, it still was a lot faster than x
<tvoss> bregma, ping
<bregma> tvoss, hi
<kgunn> tvoss: thank for all your help overnight!
<tvoss> bregma, I looked into the acceptance tests, input-related ones specifically, and came up with an MP
<tvoss> https://code.launchpad.net/~thomas-voss/mir/fix_process_waitpid_approach_to_correctly_setup_tracing/+merge/176367
<kgunn> robotfuel: if that weird "better on xmir than x" only happening on ati gpu ? or e.g. on my intel i did not see this...i saw a 10% drop
<tvoss> bregma, it contains a pipe-based cross-process sync appraoch and adds a timeout to wait_for_termination
<robotfuel> kgunn: yes this is only ati
<kgunn> robotfuel: wondering if its related to ati video driver
<bregma> tvoss, will it handle the case where a server child process is waiting for a client child process and the client child process exits without sending a synch message?
 * kgunn wonders if intel is vsync'ing properly...and ati is unhinge from vsync
<robotfuel> kgunn: we also can't to xmir benchmarks at 800x600 until this bug is fixed https://bugs.launchpad.net/mir/+bug/1196239
<ubot5> Launchpad bug 1196239 in Mir "Cannot change display resolution" [Critical,Triaged]
<robotfuel> kgunn: we can get the default resolution for the monitor though
<tvoss> robotfuel, that's fine for now
<kgunn> robotfuel: hmmm & that bug is only on ati as well correct ?...again, i get different #s on my intel when i run 600x800 vs native res, meaning...my intel numbers all look sane
<robotfuel> kgunn: it might be, intel isn't working for me right now, it has the driver bug
<robotfuel> kgunn: can you delete xserver-xorg-video-intel package version 2:2.21.9+xmir5870-1~saucy1 from the mir-team/system-compositor-testing ppa?
<robotfuel> kgunn: the 0~saucy1 driver is suppose to work
<kgunn> robotfuel: lemme see
<kgunn> tvoss: so, robotfuel asked for me to roll back intel driver to 0~saucy1....but before i venture off, do you know why raof manually updated it ? do you have some context ? (is this for sna ?)
<tvoss> kgunn, I actually copied it over, it's the driver with sna enabled
<tvoss> robotfuel, are you sure that you have the ppa pinned? the driver is working perfectly fine here
<kgunn> robotfuel: confirmed...its working on mine for past few days as well
<kgunn> i was tvoss guinea pig & just left it installed
<robotfuel> tvoss: kgunn  https://bugs.launchpad.net/xmir/+bug/1203776 a lot of people have a problem with the 1~saucy driver
<ubot5> Launchpad bug 1203776 in XMir "X crashes w/ latest xserver intel driver from System Compositor Testing PPA" [Undecided,New]
<tvoss> robotfuel, are we sure that those people did pin the ppa correctly?
<tvoss> robotfuel, can you try the intel driver from staging real quick on the machine?
<robotfuel> tvoss: I'll try the one from the staging ppa, RAOF's looked at the bug and verified it.
<tvoss> robotfuel, ack and thx
<didrocks> tvoss: ok, unity-system-compositor starts and hang (remember that it's with Mir trunk rebuilt from the last couple of hours)
<didrocks> tvoss: dm_connection_start
<didrocks> Failed to read header
<tvoss> didrocks, dm_connection talks to lightdm
<tvoss> robotfuel, if your issue is fixed with the intel driver, I will copy it over to the testing-ppa
<tvoss> kgunn, ^
<didrocks> tvoss: new xorg-server in distroâ¦
<didrocks> I bet that's it
 * didrocks looks at the version
<tvoss> argh
<robotfuel> tvoss: didrocks http://10.97.2.10:8080/job/utah-xmir-troubleshooting/3/artifact/results/dpkg-list.log has the versions of everything installed when the xorg crash happens
<didrocks> tvoss: yeah, I bet it's the xorg issue
<didrocks> tvoss: I'll just apt-get source the old one
<tvoss> didrocks, for the dm_connection thingy?
<didrocks> and update with it
<didrocks> tvoss: yeah, it's a consequence
<didrocks> xorg doesn't have -mir option
<tvoss> didrocks, ack
<tvoss> didrocks, ah ...
<didrocks> so, /me apt-get source, fake a bump changelog and reupload to daily-buid-next ppa
<didrocks> mlankhorst: would be nice to coordinate with us and not make the whole thing more painful :p
<kgunn> didrocks: so we're not dead yet, once  you update daily-build-next ppa we get another shot at tvoss "disable input" for the ati bug?
<didrocks> kgunn: right
<didrocks> kgunn: I have faith, his fix in mir directly worked with multiple runs
<didrocks> kgunn: I think if the option in unity-system-compositor is correctly wired up, it shouldn't make a difference and should pass as well
<kgunn> didrocks: that's good news...
<kgunn> thanks
<xjunior> Morning edge people
<didrocks> mlankhorst: actually, it was doko on that oneâ¦
<tvoss> robotfuel, did you install the driver, yet?
<robotfuel> tvoss: no not yet, I'll do it now.
<tvoss> robotfuel, ack
<greyback> alf__: ping
<robotfuel> tvoss: FYI the drivers in the latest drivers staging ppa failed to build https://launchpad.net/~mir-team/+archive/staging/+packages
<alf__> greyback: pong
<greyback> alf__: hey, the snapshot API is working great, thank you
<alf__> greyback: Great news! Thanks for letting me know.
<greyback> alf__: I've one question however. I grab a snapshot just after the application surface is created, which is a touch too early as I guess the application hasn't drawn to it yet (i.e. I get black snapshot). Would there be a way to detect if an app has actually drawn to it's surface
<greyback> alf__: this is nothing at all major (for now I just delay snapshot with a timer), but would be nice for later
<tvoss> greyback, I think we should postpone that discussion until we have cleaned the scenegraph-conglomerat within mir
<robotfuel> tvoss: the lastest successful build from the staging ppa is already installed on the system. It doesn't work
<alf__> greyback: We have such a mechanism internally, but I don't think it is exposed in any way to the shell.
<greyback> alf__: I see. I'll keep it in mind. I might log a bug for it. Thanks!
<alf__> greyback: np
<robotfuel> tvoss: I have some other intel systems that didn't have an xorg crash
<robotfuel> tvoss: I am retrying to see if it's a race condition.
<tvoss> robotfuel, ack
<robotfuel> kgunn: resolution changes do work on intel, not on radeon. :)
<kgunn> robotfuel: i am so frustrated with the ati...
<kgunn> :-/
<tvoss> didrocks, status?
<didrocks> tvoss: 3 runs until now, it's all green
<robotfuel> tvoss: the xmir crash on intel is race condition
<didrocks> tvoss: I'm waiting for the 4th to finish
<tvoss> robotfuel, where?
<didrocks> to send an email :)
<tvoss> didrocks, ack and thx
<didrocks> tvoss: yw! thanks to you!
<robotfuel> tvoss: https://bugs.launchpad.net/xmir/+bug/1203776
<ubot5> Launchpad bug 1203776 in XMir "X crashes w/ latest xserver intel driver from System Compositor Testing PPA" [Undecided,New]
<tvoss> robotfuel, no, I meant where in the code ;)
<robotfuel> tvoss: I haven't looked in to it.
<tvoss> robotfuel, okay, thx
<qengho> Hi all. I maintain Chromium browser, and I received a pointer from upstream to a doc about their efforts to abstract some of the display interface.  We may find it interesting. https://sites.google.com/a/chromium.org/dev/developers/design-documents/ozone
<tvoss> qengho, hey there :)
<qengho> tvoss: yo.
<tvoss> qengho, I recently read it, quite interesting :)
<hikiko_> alf__, revno 881 works better: I see the mouse pointer but I can't move it
<qengho> tvoss: Thanks.
<tvoss> qengho, thanks for keeping us posted
<tvoss> bregma, ping
<bregma> tvoss, pong
<tvoss> bregma, so my local testing reveals some issues under valgrind, still trying to digest all of the information
<bregma> ....
<tvoss> bregma, thought I would handover, as your mail suggested to me that you are looking into the issue, too
<bregma> sure
<kdub> kgunn, ping
<kgunn> kdub: pong
<racarr> lol...whoops
<racarr> I just found a unit-test file which is missing from cMakeLists.txt
<racarr> after spending 5 minutes like oh god how does this compile
<racarr> do I even understand C++
<racarr> what is happening
<racarr> etc
<kdub> haha
<racarr> (missing from CMakeLists in trunk)
<racarr> for who knows how long
<racarr> because the API it uses is quite old
<racarr> thats ok though its a lame test
<racarr> *makes new branch*
<racarr> I wonder if I should write a failing test that all our test files are built :p
<racarr> omg
<racarr> more dead files
<racarr> this is embarassing -.-
<kdub> which tests?
<racarr> kdub: test_android_input_registrar
<racarr> and mock_input_configuration.h which it includes
<kdub> what
<racarr> its been this way for at least
<racarr> 3 months
<racarr> because Ir emember I rebuilt the input configuration
<racarr> when I still lived at my old place
<racarr> we could use bzr blame but it's almost certainly my fault so
<racarr> :p
<kdub> ah, i thought you said another registrar test that I was sure was working lately :)
<racarr> I hate using droidinput::Vector
<racarr> s/hate/have a strong distaste
<racarr> https://code.launchpad.net/~robertcarr/mir/support-monitor-input-channels/+merge/176775 whee
<racarr> good news, unity is done
<racarr> *closes eyes and begins to sleep*
<racarr> :p
<kdub> racarr, droidinput::Vector can't be as bad as writing new classes that support android::sp :)
<racarr> kdub: Ah, android::sp
<racarr> you know the input stack still isnt the most beautiful code
<racarr> but we have come a long way since
<racarr> android::sp in DefaultServerConfiguration
<racarr> XD
<kdub> oh yeah, much better now :)
<kdub> mir on the whole is much better
<kdub> remember back in the day, when we wrapped std::thread/mutex/chrono with boost? :)
<racarr> kdub: Oh god
<racarr> that led to the most fucked up compiler errors.
<racarr> I just remember, coming on to the Mir team, in the past I had been a perpetual C++ skeptic but I was like
<racarr> ok well I guess if they are doing C++ carefully and the right way it seems pretty good and well lets try it
<racarr> then I ran in to some stuff from the std::thread stuff and mir::std and I was just like
<racarr> oh god....
<racarr> Back soon
<olli> robert_ancell, ping
<robert_ancell> olli, hello
<olli> hey robert_ancell
<olli> quick q, I am trying to understand the new dashboard gema announced recently
<olli> from there it looks like we are building u-s-c without running any tests
<olli> http://91.189.93.67/staging/merger/unity-system-compositor/
<olli> kgunn, ^
<robert_ancell> olli, u-s-c doesn't have any tests currently
<olli> robert_ancell, how come, I thought anything mir has tons of tests
<olli> that's what I keep getting told at least
<olli> :)
<robert_ancell> olli, not u-s-c. :(
<olli> how do we intend to land that in distro if it doesn't have tests
<olli> robert_ancell, ^
<olli> brb
<robert_ancell> olli, it doesn't have much code over top of existing Mir so it is quite well tested. We will have integration tests that ensure that the whole stack works together. But yes, it should have some local tests too
<racarr> because of the structure we use kind of like...
<racarr> 1. Mir component. 2. default implementation in tree for demo-server and system-compositor
<racarr> 3. another implementation for unity
<racarr> I agree USC is really pretty well tested
<racarr> even if it has no in tree tests
<olli> robert_ancell, what's the plan to get tests in place
<robert_ancell> olli, file bugs and prioritize them
<olli> that's a reaction to my ping but apparently not a long standing plan
<robert_ancell> kernel panic, please repeat anything directed at me since " robert_ancell, what's the plan to get tests in place"
<olli> <robert_ancell> olli, file bugs and prioritize them
<olli> <olli> that's a reaction to my ping but apparently not a long standing plan
<robert_ancell> olli, the long plan is the same as Mir - new functionality needs new tests. At the moment we have very little functionalty
<robert_ancell> racarr, regarding https://code.launchpad.net/~robertcarr/mir/session-transactions/+merge/175669 alan is away
<robert_ancell> this week
<robert_ancell> So, get a second opinion or you have to wait if you need his response
<racarr> robert_ancell: Hoping for a second opinion :)
<racarr> not in the, need someone to approve it sense, but in the actually trying to figure out if its a good idea sense
<kgunn> thomi: question about http://10.97.2.10:8080/job/mir-saucy-amd64-ci/
<kgunn> am i reading that right...are the number of tests dramatically dropping?
<kgunn> or did they migrate...http://10.97.2.10:8080/job/mir-vm-ci-build/
<kgunn> ?
 * thomi looks
<thomi> kgunn: that graph seems odd - I'm sure we don't have 50000 tests :-/
<thomi> kgunn: looks like the results are being repeated a bunch of times: http://10.97.2.10:8080/job/mir-saucy-amd64-ci/216/testReport/%28root%29/SurfaceCreation/
<robert_ancell> 23 outstanding MPs! We need to land some code here
<robert_ancell> kdub, can you check if you're happy with https://code.launchpad.net/~afrantzis/mir/rectangle-closed-open/+merge/176348
<kdub> robert_ancell, sure
<kdub> i think i am, just wanted to get the input take on the matter
<robert_ancell> kdub, also, if you've fixed the issues duflu pointed out https://code.launchpad.net/~kdub/mir/add-pf-query/+merge/176451 can land
<racarr> greyback: https://code.launchpad.net/~robertcarr/mir/support-monitor-input-channels/+merge/176775
<racarr> a present for you
<greyback> racarr: aww geee, you shouldn't have!
<racarr> greyback: Don't worry, I left a bag of coal in the Qt scene graph thread so it's balanced
<greyback> racarr: :)
<racarr> the impl is a little different than how it was on SF but I think as long as
<racarr> you are using the surface InputRegioni
<racarr> int he same way the trap windows were used before
<racarr> it should work
<racarr> I even read some QML code
<greyback> racarr: goodness, you have been busy
<racarr> greyback: Nah. it's just a carefully crafted illusion
<racarr> *kicks up feet*
<racarr> Happy to see your video last night before I went to sleep :)
<racarr> did you guys get my email to scene graph thread because I didnt get my own email
<racarr> but normally do...
<greyback> racarr: it looks like it does all I need. I'll try integrating it tomorrow. Note I'm on holiday Friday, so tomorrow is gonna be busy for me
<racarr> if it's simple, i.e. surface needs to become a monitor surface and X needs to be hooked up to Y and bla and bla
<racarr> I have some time
<racarr> well not tonight probably anyway
<racarr> but if you cant finish it tomorrow, maybe send me a brain dump if it makes sense andI can try and run with it
<greyback> racarr: yep, got it. I didn't read it as rough-edged
<greyback> sure
<greyback> it's what I'll attempt first thing. As right now, cannot actually interact with apps!
<racarr> pft
<racarr> greyback: So we just got it working and now already first thing feature bloat
<greyback> racarr: XD
<kdub> ooo android 4.3
<racarr> kdub: Oooo
<kdub> yay, looks like the HAL layer is the same
<kdub> for graphics
<kdub> racarr, time to start merging their new input stack!
<kdub> :P
<racarr> kdub: I was about 3 second ahead of you there
<racarr> kdub: "Improved window buffer allocation results in a faster image buffer allocation for your apps, reducing the time taken to start rendering when you create a window."
<racarr> that ones for you ;)
<kdub> where did you see that?
<racarr> kdub: http://developer.android.com/about/versions/jelly-bean.html?43
<racarr> Video encoding from a surface
<racarr> Starting in Android 4.3 you can use a surface as the input to a video encoder. For example, you can now direct a stream from an OpenGL ES surface to the encoder, rather than having to copy between buffers.
<racarr> "On-screen GPU profiling
<racarr> "
<racarr> only new SF stuff
<kdub> yeah, seems like all new SF stuff
<racarr> well
<racarr> and drivers are
<racarr> open gles 3 now?!
<kdub> probably just an option though?
<kdub> lots of new bluetooth hals though
<RAOF> Why does xmir suddenly infinite loop in xf86DeleteDriver now that I'm trying to debug?!
<kdub> thank goodness we're not a bluetooth server
<racarr> kdub: yeah they just say the nexus devices have
<racarr> opengles3
<racarr> I cant even think of one clever thing you could do with mir and opengles3 XD
<racarr> Im sure its good for clients
#ubuntu-mir 2013-07-25
<kdub> racarr, yeah i mean, there are some good things, but our renderer just does the simple stuff at the moment
<kdub> wobbly windows would benefit
<racarr> haha right
<racarr> it has the
<racarr> map buffer object stuff which is kind of cool
<racarr> from opengl 4
<kdub> yeah, its a cool improvement
<kdub> sometimes i forget that opengl can do animations, and its not just an api for passing buffers into
<racarr> I read some paper once about some technique with using like two mapped vbo arrays and fences
<racarr> in order to do animations in this zero copy fashion (I mean, it still ahs to make it to the GPU depending on your architecture)
<racarr> but it was basically double buffering the vertex data, so neither the animator, or the GPU ever has to block
<racarr> and then I think using some nvidia fence extension
<racarr> I don't remember the details :p
<smspillaz> racarr: opengles3 has uniform buffer objects and transform feedback
<racarr> mm
<smspillaz> which is just great
<racarr> I don't think transform feedback is super interesting to mir though really
<smspillaz> racarr: actually the even cooler one
<smspillaz> racarr: its interesting if you want to like
<smspillaz> do wobbly windows
<smspillaz> in hardware
<racarr> ubu could be useful for some kind of optimizations </speculation>
<racarr> well
<racarr> right
<racarr> lol
<smspillaz> racarr: whats more interesting is opengl 4.4
<smspillaz> with stuff like
<smspillaz> bindless textures
<smspillaz> and
<racarr> haha
<racarr> thats what I was going to say
<racarr> (bindless textures)
<racarr> thats some cool stuff
<smspillaz> bind groups
<RAOF> Grr.
<smspillaz> or whatever it was called
<smspillaz> RAOF: y u mad
<RAOF> racarr: What's the least I can do to get stderr from mir_demo_server_shell to display?
<racarr> RAOF: 2>&1 > foo.txt
<thomi> racarr: any progress on the mir_stress bug thingy?
<RAOF> racarr: No, I mean "what's the least I can do to make mir_demo_server_shell not eat stderr?" Because I'm running it from ssh, so I can totally see anything that actually makes it to the tty.
<racarr> thomi: No, I haven't found the second bug yet
<racarr> I forgot it and let it escape my todo though so thanks :)
<racarr> RAOF: err
<racarr> I didnt know it ate stderr
<racarr> I redirect stderr to a file all the time
<racarr> at least I think Id o
<smspillaz> RAOF: gdb breakpoint on close () and see where it calls close(2) ? :p
<racarr> I really dont think its
<racarr> supposed to do that
<RAOF> Hm. Ok.
<racarr> RAOF: OH HEY! While I remember I keep on meaning to ask you about something that I am meaning to take on friday/next week
<racarr> DPMS support
<RAOF> racarr: Oh, cool.
<racarr> my understanding, is: expose turning CRTC on /off from mir::graphics, expose over IPC, expose component that lets shell approve/dissaprove these requests
<racarr> add component in U-S-C to be friends with X
<racarr> then implement a bunch of hooks on
<racarr> XMirDisplay
<racarr> or whatever
<racarr> it's called
<racarr> by a bunch of hooks I mean like 2
<RAOF> Do we want to expose it over IPC?
<racarr> does that make sense? What is up with backlight, I looked aroudn xf86-video-intel a little bit and the backlight code seemed a little strange at first glance using
<racarr>  /sys files or something
<racarr> RAOF: Hmm, well how else will X request it of USC
<racarr> you mean USC should provide a
<racarr> non mir interface perhaps
<racarr> ?
<RAOF> By USC implementing its own interface.
<RAOF> This, incidentally, is a reason why having the protocol being extensible would be really useful. :)
<racarr> the_frontend_communicator() override
<racarr> ;)
<racarr> ok I understand
<racarr> hmm
<RAOF> Oh, and backlight is indeed a twisty maze of vendor hate.
<racarr> I'm not sure in regards to over IPC / USC has it's own protocol
<racarr> I...remember I leaned towards the mir protocol when Iw as thinking last week
<racarr> but I think thats just because it wasnt clear to me what the protocol should be otherwise (DBus to X)
<racarr> it's also. not entirely absurd that maybe this is reasonable client API.
<RAOF> It should be over the mir socket, but it shouldn't be in the Mir protocol that we expose to clients.
<RAOF> Hm. Under what circumstances is it reasonable for a client to ask the display server to turn off the displays?
<racarr> Maybe it makes sense for certain kinds of presentation or media apps
<RAOF> You mean to ask the display server to *not* turn off the display, right?
<racarr> or a coniguration app
<racarr> RAOF: Well maybe not! I dunno i.e. a video player which has a distraction free setting can automatically turn off your displays when you are streaming to your TV
<RAOF> Eh, maybe?
<racarr> or like, when you present, you want your laptop display off, on, or in presentation mode, so presentation apps on other platforms often include what basically amounts to a monitor configuration panel
<racarr> yeah I dunno, maybe :p
<racarr> I think both of these are kind of borderline absurd, but I was just trying to generate
<racarr> ideas
<kgunn> thomi: thanks for the response - so, if i want to quick glance at all the unity tests reported on for mir.....what do i look at ?
<kgunn> prep'ing for iom sprint
<thomi> kgunn: without runing he tests yourself you mean? like, on a dashboard somewhere?
<racarr> RAOF: I thought about you last night because one of my friends is studying to be an actuary so he started talking to me about a series of probability problems he was doing
<RAOF> Oh?
<racarr> so then, he started explaining how to solve them with multidimensional integrals, etc, and my thought was that like, from a constructive perspective
<racarr> integrals seem to be the wrong abstraction to build
<racarr> probability on top of
<racarr> because why do you even need
<racarr> infinite sets?
<racarr> a few minutes in to arguing this point I feel as if I had a flash of empathy with your previous advisor XD
<thomi> kgunn: that's the correct job, but for some reason older builds reported waaaay too many tests. Newer builds look good though, for e.g.: http://10.97.2.10:8080/job/mir-saucy-amd64-ci/336/testReport/
<racarr> RAOF: Anyway that's how I invented my new theory of probability and started to wonder if the whole aesthetic of mathematical philosophy was misgrounded.
<racarr> but...lol...back to DPMS, um, so...not the mir protocol?
<RAOF> :)
<racarr> not the mir protocol but over the mir socket sounds difficult
<thomi> kgunn: not sure if that answers your question or not
<RAOF> Yeah, needing uncomputable numbers sounds like a silly thing for probability :)
<RAOF> racarr: It can probably be in the protocol.
<RAOF> racarr: I'd quite like it to be less difficult for protocol extensions to exist, though.
<racarr> I'll think about that
<racarr> I am trying to think about something inbetween
<racarr> non extensible protocol
<racarr> and everything is a ClientMessage
<racarr> and yeah thats exactly what I mean! You don't need all that for probability, so maybe by dealing with it in the continuum and then using limits to reduce it back to a finite state system you are actually
<racarr> developing a less...'reusable' theory of probability
<racarr> haha
<RAOF> I think we could actually manage it by making the frontend replacable.
<racarr> http://en.wikipedia.org/wiki/Circle-ellipse_problem
<racarr> I wonder if mathematicians had understood ideas from software engineering if math would have been architected differently ;)
<racarr> Hmm well
<racarr> the frontend is replaceable right?
<racarr> It's ust all or nothing
<RAOF> Hm, *or* passing in a ProtocolExtension to the frontend, so when it discovers a message it doesn't know about it delegates.
<racarr> its probably possible to use
<racarr> template trickery, so that adding a new message is as easy as putting it in the wire protocol
<racarr> and providing an impl on SessionMediator
<racarr> or something
<racarr> um
<RAOF> Yeah, something like that would be good.
<kgunn> thomi: excellent!....that does answer it
<racarr> It worries me a little at first response
<RAOF> It's insane that the first thing that anyone does when trying to solve discrete problems is go "hm, is this sufficiently well approximated by an uncountably infinite set full of uncomputable numbers?"
<racarr> does it complicate our wire versioning situation, etc...
<kgunn> weird about those repeated reportings
<thomi> yeah
<racarr> RAOF: Haha, right, and that's what I mean by the misguided aesthetic
<racarr> because before incompleteness results, people thought mathematics was just one single
<racarr> totally complete and consistent system
<racarr> so why not do that
<racarr> so that was seen as like
<racarr> elegant
<RAOF> Protocol versioning: hm, maybe?
<RAOF> The problem would come in when calls migrate from extension to core or visa-versa, right?
<RAOF> We'd also need extensions to be versioned.
<smspillaz> whatever you do
<smspillaz> don't autogenerate
<smspillaz> bindings from the protocol
<kdub> hah :)
<smspillaz> at least, don't make them inline
<smspillaz> the crap I had to do in order to dlopen wayland-client and use it
<smspillaz> was not fun
<racarr> RAOF: Well, or just when, one mir supports protocol version 7 with unity extension version 8 that was backported to ubuntu 15.04 but the version in 15.10 supports protocol version 7 with unity version 9 + unity fixes version 2 and the 16.04 daily...
<racarr> haha :p
<racarr> we want to avoid that I think
<smspillaz> the way wayland does it is ok
<smspillaz> basically, if the client doesnt support some protocol
<smspillaz> then the server doesnt send it events that match that protocl
<smspillaz> and ignores requests from that protocol
<smspillaz> (version)
<racarr> Mm
<racarr> the thing is, these methods aren't in the client library I guess or they would be int he real protocol
<racarr> our client library doesn't present an abstraction of like
<racarr> message
<racarr> in the same way wayland does
<racarr> maybe it should *shrug*
<RAOF> You just need similar extension support in the client library.
<RAOF> "just" âº
<racarr> right but I think to model that extension support
<racarr> the client library first has to like
<racarr> talk in terms of messages/protocol or something
<racarr> which it entirely hides now
<RAOF> Right. It could, however, export some of that, without exposing it to the C layer.
<RAOF> mir_extension_register(mir_my_extension)
<RAOF> mir_extension_foo_get() returns an opaque pointer to the C++ implementation bits needed to do the dispatch?
<racarr> are all the combinations
<racarr> of extensions sorted in to
<racarr> 1 set of extensions used by USC
<racarr> cients
<racarr> 2. 1 set of extensions used by unity clients
<racarr> in this case maybe its just libmirclient-system libmirclient-client, or its just libmiclient that has all of 1 but there are permissions and
<racarr> platform-api exposes the rest
<racarr> or....
<racarr> why do I use "or...." in place of "."
<racarr> Off to berkeley!
<racarr> You can follow live (with 168 hour delay) at http://archive.org/details/StuAllenAndMarsHotel2013-07-17.flac16
<racarr> :p
<RAOF> With 168 hour delay?
<RAOF> That's some serious "live" :)
<RAOF> Have fun in Berkeley!
<smspillaz> have fun racarr :)
<RAOF> Yes!
 * RAOF wins.
<RAOF> Nothing wrong with xmir, Mir really is displaying frame N-1.
<duflu> RAOF: \o/
<duflu>  /o\
<duflu> RAOF: If the surface has swapinterval=0 then Mir will use triple buffering on it
<RAOF> It's not; this is simple double buffering.
<duflu> Oh
<duflu> RAOF: So the client says here's one new frame and the compositor still could delay indefinitely?
<RAOF> The client says "here's one new frame" and the compositor says "thanks, I'll composite frame N-1 for you"
<duflu> RAOF: Heh. Actually that's something I just rewrote and we're arguing in email. More work to come
<RAOF> ...
<RAOF> Client sub buffer{3}
<RAOF> Client acquired buffer{4}
<RAOF> Compositor acquired buffer{3}
<RAOF> Compositing buffer{3}
<RAOF> Client sub buffer{4}
<RAOF> Compositor released buffer{3}
<RAOF> ...
 * duflu admires typing speed ;)
<RAOF> ...
<RAOF> Client acquired buffer{3}
<RAOF> Client sub buffer{3}
<RAOF> Compositor acquired buffer{4}
<RAOF> Compositing buffer{4}
<RAOF> Compositor released buffer{4}
<RAOF> Client acquired buffer{4}
<RAOF> Client sub buffer{4}
<RAOF> Compositor acquired buffer{3}
<RAOF> Compositing buffer{3}
<RAOF> Compositor released buffer{3}
<RAOF> ...
<RAOF> At some point in this log we start compositing the N-1'th buffer submitted by the client, rather than the last one.
<duflu> RAOF: Yes, it's cos the compositor chooses the front of the queue (oldest frame) even when there might be newer ones ready behind it
<duflu> That's related to my current work
<RAOF> This is actually a bit worse than that; the compositor is compositing using the buffer that the client currently owns.
<RAOF> Oh, no it's not. Carry on.
<duflu> RAOF: Also related. I now make that impossible
<RAOF> Sweet.
<duflu> Although there's a risk that you block the compositor, which needs to be eliminated
<RAOF> Yes
<duflu> RAOF: That's why I was confused. The lag should be impossible if nbuffers=2, unless the compositor is showing a buffer currently held by the client
<duflu> Hmm, maybe there's a third possibility
<duflu> RAOF: I will reconsider the issues you describe today and maybe give you a branch to try... ?
<RAOF> That would be excellent.
<robert_ancell> RAOF, we need a way to counter u-s-c being installed, but X not supporting Mir. LightDM can't easily tell this without trying to run X with -mir and reading the stderr error messages, so perhaps we can do it better. Can we make the patched X package provide something like xorg-server-xmir and then have u-s-c depend on that?
<RAOF> robert_ancell: Yes.
<RAOF> robert_ancell: We could even go so far as to split libxmir.so into xserver-xorg-xmir, so the core server doesn't gain Mir dependencies.
<robert_ancell> RAOF, that would be even better!
<robert_ancell> RAOF, but the core package still needs the patch to have -mir etc right? Do we assume if you have xserver-xorg-xmir then the core package matches that?
<robert_ancell> This is a Universe blocker (apparently) so we need to get it fixed asap
<RAOF> Ah, ok.
<RAOF> Good. That's what I'll do after lunch, then!
<robert_ancell> cool
<duflu> robert_ancell: Skype? Hangout?
<robert_ancell> duflu, hangout is best
<duflu> Not for my earphone comfort :)
<duflu> Woo, a day of fixing conflicts :/
<robert_ancell> RAOF, does the N-1 you mention in bug 1199450 accumulate over time? i.e. so you end up with N-M
<ubot5> bug 1199450 in XMir "[xmir] Inputs slowing, last event of a stream of events greatly delayed" [Critical,Triaged] https://launchpad.net/bugs/1199450
<RAOF> robert_ancell: No, because there are only 2 buffers.
<robert_ancell> ok, that's better :)
<RAOF> Possibly if we were triple-buffering then you could get 2 buffers behind?
<RAOF> Not really.
<duflu> That's weird. bzr is giving lots of conflicts that really are not
<RAOF> Although I guess that *most* people have something change on the screen reasonably frequently.
<duflu> RAOF: Keep glxgears running in the corner :)
<RAOF> But if you have just an xterm on the screen you'll forever be one-character behind.
<duflu> Alternatively, keep a browser open with lots of ads. That's always a big contributor
<robert_ancell> RAOF, any update on the X packaging?
<RAOF> robert_ancell: Is now in mir-team/staging.
<robert_ancell> RAOF, cool, what depends should I add to u-s-c, or have you already done that ;)
<RAOF> Not yet.
<robert_ancell> ok, I'll leave it with you then
<RAOF> K.
<RAOF> Ah. New xserver upload in saucy-proposed :/
<RAOF> robert_ancell: https://code.launchpad.net/~raof/unity-system-compositor/debconfify/+merge/176858 enjoy.
<robert_ancell> RAOF, odd branch name :)
<RAOF> It accidentaly got pushed to the last branch I proposed ;)
<robert_ancell> RAOF, I just realised strictly we don't need XMir to use the system compositor, but for current practical use case the dependency solves a bigger problem than this might cause
<RAOF> Indeed, that was my thought too.
<RAOF> Since there's currently nothing *but* XMir that can run in unity-system-compositorâ¦ âº
<robert_ancell> yep
<robert_ancell> we'll blow that bridge up when we come to it
<RAOF> Eh, when we get there we'll just drop the dep.
<tvoss> good morning :)
<RAOF> Hey ho.
<tvoss> RAOF, hey there, how goes?
<tvoss> RAOF, hey, did you see that the intel driver failed compiling in the staging ppa?
<RAOF> Hm, no I didn't.
<RAOF> I need to fix unrelated things in it anyway :)
<tvoss> RAOF, ack
<RAOF> tvoss: So, duflu was going to ping me with a branch that probably doesn't exhibit this behaviour.
<tvoss> RAOF, okay, could you point me to the places in the code where you put the terminal outputs?
<RAOF> tvoss: http://paste.ubuntu.com/5910065/ enjoy.
<didrocks> RAOF: robert_ancell: excellent! this will be in today's build (I just rerun u-s-c)
<didrocks> RAOF: robert_ancell: on a longer term, we can have a virtual package as well
<RAOF> didrocks: On a longer term we'll want to just drop it; the system compositor doesn't really depend on anything being run inside it, any more than the Xserver depends on Unity.
<didrocks> RAOF: hum, but something run X -mir, right?
<RAOF> lightdm does, yes.
<didrocks> but u-s-c add the -mir parameter? :)
<RAOF> Actually, that's probably where the dependency should be, now that you mention it :)
<didrocks> or it's lightdm?
<RAOF> It's lightdm.
<didrocks> ahâ¦
<didrocks> yeah, would be logical, not sure robert will be thrilled about it though :p
<didrocks> anyway, we can figure about it later, the urgent part is covered
<tvoss> greyback, ping
<robert_ancell> RAOF, didrocks, but the problem is lightdm doesn't depend on u-s-c, because it runs fine without it
<robert_ancell> it only depends on it when it's configured to use it, and that configuration is in the u-s-c package
<robert_ancell> if we move that out to somewhere else, e.g. ubuntu-desktop then that would be the right place for the dependency
<tvoss> alf__, ping
<alf__> tvoss: pong
<dholbach> good morning
<duflu> RAOF: Try this out. Let me know if the lag is now fixed;  lp:~vanvugt/mir/switch
<duflu> Morning dholbach
<RAOF> duflu: Ta.
<dholbach> hey duflu
<dholbach> how are you all doing?
 * dholbach hugs duflu, RAOF and the rest of the gang
<RAOF> Hey duflu!
<RAOF> Or even - hey dholbach!
<dholbach> :)
<tvoss> dholbach, berlin calling @fb?
<dholbach> tvoss, yep :)
<greyback> tvoss: pong
<tvoss> didrocks, ping
<didrocks> tvoss: pong
<didrocks> on 3G
<tvoss> didrocks, ack
<robert_ancell> hikiko, can you do an earlier 1-1?
<hikiko> sure robert_ancell
<hikiko> do you want me to join now?
<RAOF> duflu: Looks like that doesn't have the delay problem.
<RAOF> duflu: It looks like it's triple buffering, though?
<RAOF> tvoss: ^^^
<duflu> RAOF: Good start, but can you be sure? And yes, I default to triple because bypass will need it
<duflu> Also, frame-dropping is suboptimal without triple
<RAOF> duflu: Well, no I can't be sure.
<duflu> Alright, but still, good
<RAOF> But the workload which reliably caused the problem no longer causes the problem.
<tvoss> RAOF, could you quickly run phoronix-test-suite run pts/gaming-free with duflu's branch?
<duflu> tvoss: It's just buffering changes. Bypass is not in that branch. You know that?
<RAOF> tvoss: I've been using the openarena timedemo to test; I can do phoronix-test-suite too, if you like.
<tvoss> RAOF, would be cool, that was my test-case
<tvoss> RAOF, also: pbuilder create complains about W: Failure trying to run: chroot /var/cache/pbuilder/build/28791/. mount -t proc proc /proc
<tvoss> W: See /var/cache/pbuilder/build/28791/./debootstrap/debootstrap.log for details
<tvoss> E: debootstrap failed
<tvoss> W: Aborting with an error
<tvoss> I have had that issue a million times, but never remember how to solve it
 * RAOF uses sbuild
<RAOF> Sorry!
<tvoss> duflu, yup, know that. Just want to make sure that we put heavy load onto the system
<duflu> OK. It's a little unusual for other people to load test a branch that's not even ready to propose :)
<alf__> RAOF: Can you test the input delay with the current trunk with triple buffer enabled (change 2->3 src/server/compositor/swapper_factory.cpp line 47). It would be good to know if this is solved by triple buffering, or some other change in duflu's branch.
<RAOF> alf__: Sure.
<duflu> alf__: I expect triple will make it worse. I did an explicit fix for the lag bug today
<tvoss> duflu, on the current design?
<duflu> tvoss: Either. The higher the number of buffers, the worse the lag will be. The fix was not the number of buffers, but was to drop frames when more than one was queued for composition
<tvoss> duflu, ack, mind pinging me the branch?
<duflu> tvoss: r937 onward: https://code.launchpad.net/~vanvugt/mir/switch
<tvoss> duflu, can we backport that to trunk right now?
<duflu> tvoss: Possibly. Alf should have the know-how
<tvoss> alf__, ^?
<duflu> It's easy to drop excess frames. But you just have to remember to change how you throttle synchronous clients at the same time
<alf__> duflu: tvoss: RAOF: ...but this changes our compositor to drop frames always. Is XMir sending frames that it then wants to cancel/override with new ones instead of having a steady sequential stream?
<tvoss> alf__, duflu sounds like that should be controllable with a policy
<RAOF> xmir doesn't expect frame dropping.
<RAOF> If we're *getting* frame dropping then Mir's behaving unexpectedly.
<RAOF> Man, pts/gaming-free takes *some time* to download.
<alf__> RAOF: We are not dropping frames normally. However the proposed solution involves dropping all frames but the latest, if understood it correctly. So if the compositor's queue contains CBA with C being the latest, with the proposed change mir drops B,A and gets directly to C. I don't know what's causing the problem really, but this feels like dealing with the symptom.
<tvoss> alf__, the trigger is this bug: https://bugs.launchpad.net/mir/+bug/1199450
<ubot5> Launchpad bug 1199450 in XMir "[xmir] Inputs slowing, last event of a stream of events greatly delayed" [Critical,Triaged]
<RAOF> alf__: I'm not sure how the compositor's queue ever gets more than one buffer in it?
<RAOF> alf__: Because we're double buffering by default, and the client always has a buffer...
<RAOF> And a buffer that the client has can't be in the compositor's queue.
<RAOF> So, by my understanding, there can be at most one buffer in the compositor queue.
<duflu> RAOF: Yeah like I said yesterday - the bug should be impossible with nbuffers=2 in theory
<RAOF> But in practise it's quite easy to trigger :)
<duflu> Oh universe, how you deceive us all
<duflu> RAOF: Impossible if nbuffers=2 and they're being alternated fairly/evenly ;)
<duflu> I wonder if I will get to cook real food or spend another evening hacking :/
 * duflu finds middle ground and makes evening coffee
 * RAOF finishes dinner and goes to clean up.
<RAOF> Night all!
<tvoss> RAOF, night all :) talk to you tomorrow
<alf__> RAOF: duflu: I think there can be two buffers if the client is slow. Good night :)
<tvoss> alf__, can we easily switch to triple buffering on current trunk?
<duflu> Last I checked, it was a trivial 1 character change
<duflu> Night RAOF
<alf__> tvoss: yes, but we need to prove that this will help
<tvoss> alf__, happy to do so ... just show me where
<duflu> I think it would/should make it worse
<tvoss> duflu, alf__ I'm happy to be the guinea pig here
<duflu> tvoss: alf__ did... scroll back
<alf__> tvoss: change 2->3 src/server/compositor/swapper_factory.cpp line 47
<tvoss> alf__, thanks
<tvoss> duflu, alf__ the good thing is: it is not subtle, but totally visible ;)
 * tvoss is in love with sbuild
<hikiko_> alf__, ping!
<alf__> hikiko: pong
<didrocks> tvoss: kgunn: FYI, I'm recopying the latest changes from RAOF to the daily-build-next ppa, we really need to be in distro ASAPâ¦
<hikiko> hi alf__ I was wondering about the internal clients
<hikiko> and the internal display
<didrocks> tvoss: kgunn: argh, his build failed on i386
<tvoss> didrocks, ack, you referring to the xorg driver?
<didrocks> (one test)
<didrocks> tvoss: yeah, he changed the dep for mir
<hikiko> I guess these should be initialized and live in the native platform, correct?
<didrocks> but didn't copy in daily-build-next
<didrocks> so we can't install mir anymore now in it
<didrocks> tvoss: but anyway, one test failed from his xorg upload
<tvoss> didrocks, hold on, cannot follow
<tvoss> didrocks, did you just restart the build?
<didrocks> tvoss: yeah
<tvoss> didrocks, why is that? do you suspect a flaky builder?
<didrocks> it seems to be a flacky xorg tests
<didrocks> didn't fail on other archs
<didrocks> and the diff is meaningless
<didrocks> regarding to that failure
<didrocks> then, if it pass, I'll copy to daily-build-next ppa
<didrocks> as it's broken right now
<didrocks> (u-s-c depends on a package that doesn't existâ¦)
<tvoss> didrocks, ack ...
<tvoss> didrocks, I'm testing the intel driver from staging manually now
<tvoss> back in a few ... hopefully
<alf__> hikiko: it could be that you can use the one returned by the native one, but I haven't really checked the details
<alf__> hikiko: native one => native platform
<tvoss_> alf__, okay, does not make it better with triple buffering
<tvoss_> alf__, but it exposes some serious flickering
<tvoss_> alf__, or better, occasional serious flcikering/hiccups
<tvoss_> duflu, to test your branch: build and install, then rebuild of usc?
<duflu> tvoss_: No sure about the context but it is a drop-in replacement for lp:mir
<tvoss_> duflu, ack
<duflu> And now it's late again
<tvoss_> duflu, just sign off dude :)
<duflu> Well, I had coffee instead of dinner. That was my first mistake
<duflu> Going now
<hikiko> alf__: that's what I thought I just wanted to check that my logic is correct
<hikiko> thank you
<tvoss_> didrocks, seems like the i386 build made it through :)
<didrocks> tvoss_: yeah, just waiting a little bit before copying
<tvoss_> didrocks, ack
<tvoss> didrocks, ping
<didrocks> tvoss: pong
<tvoss> alf__, did you have a chance to look into the buffer issue?
<tvoss> alf__, the buffers are overtaking each other sometimes
<tvoss> mlankhorst, ping
<mlankhorst> pong
<tvoss> mlankhorst, hey there, we see an issue on ati with the following error message: [  2417.963] (II) UnloadModule: "radeon"
<tvoss> <didrocks> [  2417.963] (EE) Screen(s) found, but none have a usable configuration.
<mlankhorst> i'd need a full log for a picture.. plus dmesg if possible
<tvoss> didrocks, ^
<mlankhorst> and I'm just guessing it's a hybrid..
<didrocks> mlankhorst: do you have access to the VPN?
<didrocks> mlankhorst: would be easier to get what you want, you can poke that way
<mlankhorst> meh lets see how to set that up again..
<jibel> mlankhorst, dmesg http://paste.ubuntu.com/5911197/ , Xorg.log http://paste.ubuntu.com/5911199/
<mlankhorst> [  2417.963] (EE) RADEON(0): [drm] failed to set drm interface version.
<mlankhorst> shouldn't do that on xmir
<tvoss> what about fbdevhw
<mlankhorst> [  2417.963] (EE) Failed to load module "fbdevhw" (module does not exist, 0)
<mlankhorst> eg harmless
<mlankhorst> and it would have been disabled by xmir
<tvoss> mlankhorst, what means shouldn't to that on xmir?
<mlankhorst> the call that's failing shouldn't have been called at all..
<tvoss> mlankhorst, ah, thanks :)
<didrocks> tvoss: I think we have 2 issues
<didrocks> tvoss: this call not be done
<didrocks> tvoss: lightdm not retrying without the -mir option
<tvoss> mlankhorst, can you gain any further insight from the pastebin'd logs?
<mlankhorst> as I said, drm interface version call is failing, and that one should not be called at all with xorgMir..
<tvoss> mlankhorst, okay, so we have the wrong driver in there
<mlankhorst> meh what's the machine?
<tvoss> didrocks, ^?
<didrocks> tvoss: I checked, we have the same version than in the staging ppa
<didrocks> tvoss: and it's the one installed
<didrocks> is there any other one?
<mlankhorst> so then it's calling drmSetInterfaceVersion in the ddx when it shouldn't..
<tvoss> didrocks, seems like the ati driver from the staging ppa wasn't rebuild against the new xorg
<tvoss> mlankhorst, ^, could that cause issues?
<didrocks> tvoss: seeing the diff of xorg since yesterday, that doesn't cause an ABI break, right?
<didrocks> tvoss: https://launchpadlibrarian.net/145833378/xorg-server_2%3A1.14.2-0ubuntu2%2Bxmir1_2%3A1.14.2-0ubuntu2%2Bxmir1.1.diff.gz
<mlankhorst> tvoss: I already said what the issue is
<mlankhorst> drmSetInterfaceVersion is called, and it shouldn't, you have the source so you should be able to say why..
<tvoss> mlankhorst, I wonder why it ever worked then?
<mlankhorst> there's no guarantee it did, tbh..
<tvoss> mlankhorst, well, we have seen phoronix test suite running on ati
<mlankhorst> sigh, have you tried removing the call or not
<didrocks> tvoss: kgunn: on the "we stay in a broken (no ui) session story": https://bugs.launchpad.net/mir/+bug/1204936
<ubot5> Launchpad bug 1204936 in Mir "if unity-system-compositor exits too early, lightdm should retry starting xorg without -mir" [Undecided,New]
<didrocks> tvoss: kgunn: and bug #1204939
<ubot5> bug 1204939 in Mir "Mir doesn't start on ATI test machine" [Undecided,New] https://launchpad.net/bugs/1204939
<kgunn> didrocks: ack
<didrocks1> tvoss: do you see anything weird in terms of versions: https://jenkins.qa.ubuntu.com/job/autopilot-saucy-daily_release/label=autopilot-ati/618/artifact/results/sysinfo/dpkg-l.postsetup
<tvoss> didrocks, can you do me a favor and try to install the system-compositor-testing ppa on the machine?
<didrocks> tvoss: will be able to do that later on, I have an appointment, maybe sil2100 can help you? he should have access
<tvoss> sil2100, ping
<tvoss> didrocks, okay, no weird versions around
<sil2100> tvoss: let me backlog and see what's what
<tvoss> sil2100, ack
<sil2100> tvoss: on what machine do you need it installed? ati?
<tvoss> sil2100, ack
<tvoss> sil2100, is there a monitor connected to the machine, or a kvm switch?
<sil2100> tvoss: I only log there through ssh ;) That's all the access I have
<tvoss> sil2100, where does the machine physically live?
<sil2100> tvoss: not sure now, I would guess it's in Lexington? Let's ask the QA guys, one moment
<sil2100> tvoss: yes, I was right, they're in the QA lab in Boston
<sil2100> tvoss: so the QA guys should be able to physically access it and perform debugging
<tvoss> sil2100, how is the machine called?
<sil2100> tvoss: I know it by the name of dx-autopilot-ati
<thomi> morning
<racarr> I don't know what was up with feeling sick all night but feel excellent now :) almost done with surface configuration notification
<thomi> racarr: how's that mir_stress bug?
<racarr> thomi: The same...need to finish unblocking shell stuff first :)
<racarr> OSK incoming :D
<racarr> the osk needs to be able to hide/show over IPC
<racarr> so do we add mir_surface_hide/mir_surface_show?
<racarr> Is it a surface state
<racarr> if it is, how is it different than minimized
<racarr> (or the same question if it isn't)
<racarr> http://www.kickstarter.com/projects/cradle-of-mir/the-cradle-of-mir-at-burning-man-2013-russian-team we are so popular
<racarr> :p
<racarr> Hide is the same as minimize
<racarr> but show is not the same as restored
<kdub> racarr, haha@ the kickstarter
<kdub> downloading mir over bzr takes longer and longer as we get more revs
<kdub> maybe i should upgrade my internet connection plan to accomodate :)
<racarr> kdub: One day people will tell my story "He ventured to the desert to seek the cradle of mir. Witnesses report that after 3 days of meditation he stood and simply announced 'I have seen the scene graph', only to wander in to the desert and never be heard from again"
<racarr> :p
<racarr> hmm
<racarr> I think I should have done the SurfaceConfigurator, with two methods...
<racarr> i.e. configure_surface(surface, attrib, ref value)
<racarr> and surface_configured(surface, attrib, value)
<racarr> (ref requested_value in configure_surface) perhaps
<racarr> I am thinking about, how the shell can implement the policy of minimized windows get hidden
<racarr> and there is one place where the shell wants to say like, this window wants to be minimized, thats ok, or this window wants to be an overlay but thats prohibited
<racarr> but this isn't where you want to actually implement your behavior (i.e. minimize the window at some point)
<racarr> I think I dunno, it seems like you want to apply the behavior after you have actually called
<racarr> msh::Surface::configure
<racarr> Neither of these seem correct...so I start wondering if the shell should implement msh::Surface::configure
#ubuntu-mir 2013-07-26
<RAOF> duflu: Oh, I've realised that one of my problems with DRI bypass is actually a generic problem with nested bypass, so I'm interested in how you've solved it
<RAOF> The problem is - what happens if you need to unbypass? You've only got one buffer from the server you're running against, and you've handed it out to the bypass-client. So now you need to wait for it to swap_buffers before you can unbypass, but there's no mechanism to make it swap_buffers (and can't be in general).
<duflu> RAOF: My first prototype worked that way but then I realized the same problem. The client could hold it indefinitely.
<RAOF> So how did you solve that?
<duflu> The current approach is to make client buffers (sometimes) scanout capable and give them directly to the server as required
<robert_ancell> RAOF, on the phone, when unity8/mir runs as the user it's logged in as - does it have enough permissions to get input directly? Or do we have to go via the system compositor?
<RAOF> robert_ancell: If we want to have any form of user-switching then input needs to go via the system-compositor.
<robert_ancell> RAOF, but we're not doing that for XMir right?
<duflu> RAOF: There will be some smarts required to limit which clients get scanout capable buffers, and maybe event change it at runtime. But right now I just have all clients given scanout capable buffers. And sometimes they will be scanned out (bypass), sometimes not (composited)
<RAOF> Right. Which is why user switching under XMir is currently a terribly bad idea.
<RAOF> Also, we run XMir as root.
<robert_ancell> yes
<robert_ancell> I just got support to run Mir sessions and VT switch between them, but that's probably a no-go
<RAOF> And the design for 13.10 is that we trust XMir to acquire/release input when its session gets switched to/from.
<RAOF> As long as the Mir sessions can acquire/release input on VT switch, and unity-system-compositor can acquire/release input on VT switch that should work.
<robert_ancell> I think you need to be root to watch for VT switches
<RAOF> Indeed you do.
<RAOF> Anything we run on a VT needs to do so as root.
<robert_ancell> Is there any way to authorize certain processes to run on a VT?
<RAOF> Anything we run under unity-system-compositor *can* run unprivileged, as long as it gets input through u-s-c.
<robert_ancell> yeah
<RAOF> I'm not sure that's enough.
<RAOF> Because (if you're running on a VT) you need to be able to access /dev/input/* to get input.
<robert_ancell> yeah, and that's root right?
<RAOF> Indeed
<RAOF> And if your *user* can access /dev/input/*, then they can just open it, switch away, and they snoop all input.
 * RAOF notices it's 2pm and goes for lunch.
<robert_ancell> yes, you would have to limit it to just the shell to be useful
<RAOF> Which is pretty similar to "just run the shell as root"
<RAOF> duflu: Ah. That doesn't help me, then (and won't work for the nested-compositor case)
<RAOF> duflu: We should probably work out how to do it properly :)
 * duflu does lunch too
<tvoss> good morning :)
<RAOF> Aloha
<tvoss> robert_ancell, RAOF did we have any luck with the ati machine?
<RAOF> tvoss: I thought that got all resolved?
<tvoss> RAOF, not sure :) I hope it it is
<robert_ancell> tvoss, RAOF that's bug 1204939 and we don't have a solution
<ubot5> bug 1204939 in Mir "Mir doesn't start on ATI test machine" [Undecided,New] https://launchpad.net/bugs/1204939
<robert_ancell> RAOF, duflu can you have a look at that one and triage it please?
<tvoss> RAOF, we saw  [  2417.963] (II) UnloadModule: "radeon"
<tvoss> <didrocks> [  2417.963] (EE) Screen(s) found, but none have a usable configuration.
<tvoss> RAOF, from the next ppa that didrocks wanted to test
<RAOF> So the problem is that XMir hasn't been loaded at all.
<robert_ancell> RAOF, did the packaging changes mess things up?
<duflu> OK, title improved but needs much more attention to be "triaged"
<RAOF> robert_ancell: Possibly? I would have thought the server would die if it couldn't load xmir.so
<tvoss> didrocks, good morning
<didrocks> hey tvoss
<tvoss> RAOF, any ideas why the new packaging might fail?
<RAOF> tvoss: Not off the top of my head.
<tvoss> didrocks, do we have access to the machine? would like to track this issue down
<didrocks> tvoss: the machines are currently running the tests for daily release
<didrocks> as having those in the image is the priority, no access to the machine now
<RAOF> didrocks: Do we have a dump of /var/log anywhere?
<didrocks> RAOF: you can have that if you uncompress the archive from yesterday
<didrocks> I'll give you a pointer in 5
<RAOF> Ta
<robert_ancell> didrocks, you'll be in IOM right?
<didrocks> robert_ancell: right
<didrocks> RAOF: http://10.97.4.138/otto/saucy-i386-20130725-1116/archive/ubuntu_13.10_saucy_salamander_alpha_i386_20130725.1374764535.otto
<didrocks> RAOF: this is a tar file
<robert_ancell> didrocks, tvoss, see you guys there
<didrocks> you have a delta/ directory
<didrocks> robert_ancell: see you there as well dude! :)
<didrocks> in the delta, it's a bump of all what was modified
<didrocks> so you should have var/log and so old
<RAOF> Well, that is of moderate size!
<didrocks> so on*
<didrocks> RAOF: don't install that many packages :p
<didrocks> (it's really just a delta, with mir installed on top of it)
<RAOF> didrocks: It looks to me like xmir worked as expected on that test run - it's the failsafe session that failed to start.
<didrocks> RAOF: why failsafe was executed?
<didrocks> shouldn't we have u-s-c running?
<RAOF> lightdm.log shows that u-s-c started up fine, XMir started up fine, then upstart asked lightdm to terminate, which it did, cleanly.
<RAOF> (upstart sent SIGTERM ~20s after lightdm came up)
<didrocks> RAOF: the session even didn't start
<didrocks> (user session)
<RAOF> [+1.88s] DEBUG: Session 1085 running command /usr/sbin/lightdm-session gnome-session --session=ubuntu
<RAOF> Then: [+22.80s] DEBUG: Got signal 15 from process 1
<didrocks> RAOF: right, the question is why the session was killed?
<didrocks> as nothing changed and the same package versions are working reliably on intel
<didrocks> with session starting
<didrocks> unity spawn
<didrocks> RAOF: it seems that the acceleration test maybe doesn't work (what is tested before starting unity)
<didrocks> so can't start unity -> required component
<didrocks> -> exit
<RAOF> Plausibly - ~/.cache/upstart/unity7.log contains a lot of âunity7 stop/pre-start, process 1216â
<didrocks> RAOF: my guess is that acceleration doesn't work
<RAOF> There's no evidence of that in the Xorg.0.log, but it's possible.
<RAOF> But in gnome-session.log - compiz (core) - Info: Unity is not supported by your hardware. Enabling software rendering instead (slow).
<didrocks> yeah, seems like a good hint
<duflu> Hey that's what I was getting after updating last night :/
<tvoss> argh, gdb in an armhf chroot is pure pain
<tvoss> didrocks, what does the unity test script check?
<didrocks> tvoss: if hardware acceleration is available and multiple other things
<didrocks> tvoss: it's in nux sources, tools/
<didrocks> but maybe duflu debugged it as he saw it
<tvoss> didrocks, is there a log of it? I think I saw something in /tmp
<didrocks> tvoss: just returning 0 or 1 if supported/unsupported
<duflu> didrocks: No, I ignored the bug because it was on raring (which I assume we don't care about)
<tvoss> didrocks, hmmm, not what I would call overly chatty :)
<duflu> Though interestingly, the fix was to downgrade the latest lightdm update
<didrocks> you can launch it with -p to have more logs, but you need access for that on the machine
<didrocks> but as duflu gets it
<didrocks> maybe he can run it to get more infos?
<didrocks> duflu: interesting, that is a potential issue, right, latest lightdm
<duflu> didrocks: Also, on this raring machine I am not using USC. It's plain old X. Just that the staging PPA gave me a dud update
<dholbach> good morning
<tvoss> didrocks, can we downgrade lightdm on the machine for testing purposes?
<didrocks> tvoss: it's possible, will take timeâ¦ time I don't have today TBH
<didrocks> tvoss: i'm already on pressure to deliver something I didn't know that was planned for IoM as top priority
<didrocks> tvoss: I pushed it back for the last 2 week mainly because of Mir alreadyâ¦
<tvoss> didrocks, ack
<didrocks> sil2100/jibel should be able to help though to do that
<tvoss> didrocks, ack
 * RAOF is sad that you can't build X with clang â¹
<duflu> That's odd. I'm getting small amounts of graphics corruption since getting a new intel driver from staging
<tvoss> duflu, likewise
<tvoss> RAOF, duflu is there any way that I can try the staging ppa xserver and intel driver?
<duflu> tvoss: Is that a trick question? You mean with the other PPA? Maybe just download the deb(s)
<tvoss> duflu, nope, not a trick question
<tvoss> didrocks, or can I try to switch to next for intel?
<didrocks> tvoss: daily-build-next -> intel
<didrocks> it's working from what the tests says
<tvoss> didrocks, okay, will give it a spin now
<didrocks> tvoss: keep me posted ;)
<tvoss> sil2100, hey there
<sil2100> Morning!
<didrocks> hey sil2100!
<tvoss> didrocks, apt-get dist-upgrade removes unity-common? is that okay?
<didrocks> yep ;)
<tvoss> didrocks, in progress
<tvoss> alf__, ping
<tvoss> okay
<tvoss> no hw accel on unity
<tvoss> didrocks, tried daily-build-next with intel, comes up but no hw-accel, flickering screen
<didrocks> tvoss: interesting that times out on tests are so big that they pass thenâ¦
<didrocks> tvoss: ok, so clearly either an issue with latest Xorg or lightdm
<tvoss> didrocks, you sure?
<tvoss> I will reenable the system-compositor-testing ppa now
<tvoss> and compile usc and mir from current trunk
<tvoss> that's what you essentially do, correct?
<didrocks> tvoss: duflu mention that revering lightdm helped
<didrocks> tvoss: yeah, you have latest usc and mir normally
<tvoss> didrocks, ack, I will stick with the older xorg and intel driver in the testing ppa then
<tvoss> duflu, which version of lightdm did you downgrade to?
<duflu> tvoss: 1.7.5bzr1634raring0
<duflu> The broken one was 1636
<tvoss> duflu, ack and thx
<tvoss> duflu, did you experience flickering, too?
<duflu> tvoss: No... But then this raring machine is using plain X, not Mir
<tvoss> duflu, ack
<duflu> ... so that I can start new Mir servers concurrently
<tvoss> hmmm, compiling mir trunk fails with unit-tests requiring eglCreateImageKHR
<tvoss> I thought we had fixed that
<duflu> back in 30
<tvoss> duflu, ack
<tvoss> sil2100, any luck with the unity-test script?
<tvoss_> sil2100, ping
<tvoss_> RAOF, ping
<sil2100> tvoss_: still waiting for the machine to be free ;/ We might consider killing some jobs if this is urgent
<tvoss_> sil2100, nope, no worries
<tvoss_> any eta?
<sil2100> Let me see how far the stupid unity testing is
<tvoss_> sil2100, ack
<sil2100> tvoss_: I would say around 30 minutes, since unity testing is finishing and then just some smaller jobs are queued up
<tvoss_> sil2100, ack and thx
<sil2100> jibel: can we somehow block the autopilot-saucy-daily_release job not to accept any new requests for a moment?
<jibel> sil2100, stop the slave on the machine
<jibel> sil2100, sudo stop jenkins-slave on ait
<jibel> ati
<jibel> sil2100, but wait until the current runs are  finished
<jibel> as it will interrupt them
<RAOF> tvoss_: Pong
<tvoss_> RAOF, hey there :) I'm trying to bisect and track down why daily-build-next gives me a fucked up xmir stack
<tvoss_> RAOF, starting with system-compositor-testing ppa, what would be next? installing mir and usc from staging?
<RAOF> Hm. Wouldn't you install from daily-build-next?
<RAOF> You're trying to work out the component that's broken in daily-build-next, right?
<sil2100> jibel: thanks!
<tvoss_> RAOF, yeah, the problem is: daily build next is completely unusable for me on intel
<RAOF> tvoss_: And you want to find which component of daily-build-next is broken for you, so you'd install components one-by-one from there, right?
<tvoss_> RAOF, ack
<tvoss_> RAOF, I was wondering whether I could update X and xorg-video-intel before getting the new mir from daily-next
<RAOF> You could, yes.
<tvoss_> RAOF, okay
<tvoss_> RAOF, that would work although the packaging added the xorg-xmir package?
<RAOF> You'd need to ensure that xserver-xorg-xmir is installed, but apart from that, yes.
<tvoss_> okay
<RAOF> Hurray! Pixman is less annoying that I thought!
<RAOF> Although âthe docs are the sourceâ remains a less than optimal state.
<tvoss_> RAOF, ?
<RAOF> Oh, RegionUnion and RegionSubtract don't mind if the destination Region is the same as one of the arguments.
<RAOF> Although it's not obvious that this is the case.
<tvoss_> RAOF, ah
<Walther> Any news on when mir will be enabled by default to alpha/beta?
<tvoss> Walther, on it :)
<tvoss_> alf__, ping
<Walther> tvoss_: Huh? Last I checked it required adding a ppa, required open drivers instead of binary blobs for gpu, etc
<Walther> I mean, I'm running saucy already
<Walther> and tried manually installin mir once with catastrophic results, went back to "regular plain saucy"
<tvoss_> Walther, yup, we are working on getting Mir and XMir into the archive right now. For binary driver support: That's not something we are targetting for 13.10, so it will be Mir/XMir on open source drivers, falling back to vanilla X on closed-source drivers
<Walther> hm, ok
<Walther> (I just happen to have a too new GPU that doesn't really have passable support in open drivers :/ )
<Walther> on work computer, not an issue though
<tvoss_> Walther, that's unfortunate
<Walther> 7970, last time i tried, just doesn't want to cooperate on anything else than bin
<tvoss_> didrocks_busy, I was able to come up with a somewhat usable solution from staging ppa
<Walther> But yeah, thanks to all for doing your job, will join testing when I can
<tvoss_> Walther, thanks :) looking forward to finally being able to support you
<Walther> hehe
<Walther> Also, how's the status of native apps other than demos going?
<Walther> as in, the fallbacking to X when needed, and actual mir-supporting apps
<tvoss_> didrocks_busy, okay, taking the intel driver from the system compositor testing ppa gets rid of the weird glitches
<didrocks_busy> tvoss_: so, there are more fixes that were in the pipes?
<tvoss_> didrocks_busy, I have got lightdm from system-comp testing, intel driver from system-comp testing, everything else from staging, with usc build manually
<didrocks_busy> tvoss_: do you know the diff between u-s-c in daily-build-next and in the staging ppa,
<didrocks_busy> ?
<didrocks_busy> did you try to revert lightdm as well to distro? maybe it's lightdm from staging "fixing" it
<hikiko> hi, question: what exactly is the crtc? I got an exception on trunk: "Output has no associated crtc
<hikiko> and I was getting another flipping related one before
<ogra_> a CRT is a tube monitor ... i would guess the last C means connector
<hikiko> oh. it
<hikiko> thanks ogra_ :) I didn't realize it :)
<tvoss> mlankhorst, ping
<mlankhorst> pong, but not a work day for me
<tvoss_> mlankhorst, okay: I'm seeing a driver needs flags 0, nested not support in Xorg.0.log
<tvoss_> that's for kms with the latest intel from daily-build-next
<mlankhorst> it's not mir enabled, then..
<mlankhorst> and if it is it'll have to wait till monday, gone
<tvoss_> mlankhorst, thx
<mterry> What's the state-of-art for flashing a device with a unity-mir image?  Still to flash a special saucy-preinstalled-phablet-armhf.zip ?
<kgunn> bregma: is brandon around today?
<bregma> he should be, but he's on left coast time so he will probably start his day within an hour or so
<kgunn> bregma: duh! he just told me seattle yesterday...(gray hair moment)
<bregma> kgunn, it looks like the all-important https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1203207 may also be blocked on some issues, I'm going to file bugs for those and tag them entering-saucy
<ubot5> Launchpad bug 1203207 in mir (Ubuntu) "[MIR] mir" [Undecided,New]
<bregma> kgunn, if you could get that intel bug tagged, that would be great
<kgunn> bregma: on it...yeah...sorry
<kgunn> bregma: there now https://bugs.launchpad.net/mir/+bug/1205383
<ubot5> Launchpad bug 1205383 in Mir "Xmir intel vladmir head broken" [Critical,Triaged]
<bregma> kgunn, thanks
<bschaefer> kgunn, hey, i've a couple things to finish then I can help look into which rev has causing the ati issue
<kgunn> bschaefer: thank you
<kgunn> since you had a local card...you might be able to use that....i think you might have been on -testing ppa
<bschaefer> kgunn, np! I've a desktop with an ATI card, in the evergreen family but I should get the info for didrocks ati machine
<kgunn> excellent!
<bschaefer> kgunn, yeah, also would you happen to know how to point a local built mir to get lightdm load it?
<bschaefer> so I can start reverting trunk mir to figure out what rev caused the problems :)
<xjunior> tvoss_: hey dude, good morning/afternoon/whatever-is-there :)
<tvoss_> xjunior, otp, with you in a few
<kgunn> bschaefer: honestly...i think if you build is....it tries to use your usr bins first
<kgunn> at least i'm pretty sure...cause i fell victim one time, it wouldn't work from ppa
<bschaefer> kgunn, alright, Ill have to dig around to how to make lightdm point to my buiild ;)
<kgunn> but only i was broken...and yeah..oops
<kgunn> old binary in my usr dir
<bschaefer> right, hmm well I ll need staging, worst case I can  move it into /bin but that is reall the worst case
<kgunn> bschaefer: might ask tvoss when he's off the phone
<bschaefer> kgunn, sounds good, thanks!
<smintheu> hi everybody
<smintheu> trying to get mir to work on saucy
<smintheu> ran into a problem that has been reported before, but i haven't found a solution yet
<smintheu> here is my /var/log/lightdm/unity-system-compositor.log
<smintheu> ERROR: /build/buildd/mir-0.0.6bzr848saucy0/src/server/graphics/gbm/gbm_cursor.cpp(46): Throw in function mir::graphics::gbm::GBMCursor::GBMBOWrapper::GBMBOWrapper(mir::graphics::gbm::GBMPlatform&)
<smintheu> Dynamic exception type: boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >
<smintheu> std::exception::what: failed to create gbm buffer
<smintheu> any ideas?
<tvoss_> smintheu, are you running on ati?
<smintheu> nvidia if i'm not mistaken
<smintheu> lspci -v | grep "VGA compatible"
<smintheu> 01:00.0 VGA compatible controller: NVIDIA Corporation G84GLM [Quadro FX 570M] (rev a1) (prog-if 00 [VGA controller])
<tvoss_> smintheu, how did you install? from the testing ppa?
<smintheu> yes
<smintheu> I saw on launchpad that other people encountered this, and that it was supposedly fixed as of yesterday
<smintheu> https://bugs.launchpad.net/mir/+bug/1203070
<ubot5> Launchpad bug 1203070 in Unity System Compositor "unity-system-compositor doesn't start on some ati card (with opensource driver)" [Critical,Fix released]
<smintheu> if I understood correctly, it's supposed to be fixed
<smintheu> but I still have the same problem
<tvoss_> smintheu, the testing ppa is behind as we are busy landing in distro
<tvoss_> smintheu, can you wait until next week?
<smintheu> tvoss, sure, just playing around a bit
<smintheu> tvoss, I'll give it another try next week
<smintheu> tvoss, by landing in distro you mean that mir/xmir is going to become default in the daily builds?
<kgunn> smintheu: that's the idea
<smintheu> kgunn: cool. I'll give it a try again next week
<smintheu> tvoss, kgunn: thanks for your help
<tvoss_> smintheu, yw :)
<bschaefer> tvoss_, sweet, confirmed it fixes the cursor issue :)
<bschaefer> even though I assume it was already :)
<tvoss_> bschaefer, yup
<tvoss_> bschaefer, what are you running now?
<tvoss_> which version exactly, which ppa?
<bschaefer> tvoss_, I running testing, but compiled u-s-c my self
<bschaefer> im*
<bschaefer> though I had to remove the *.sleep  part
<tvoss_> bschaefer, fair
<tvoss_> bschaefer, interesting bit is actually daily-build-next
<bschaefer> tvoss_, o the sleep binary is in that ppa?
<tvoss_> bschaefer, it's a wrapper script
<bschaefer> or rather what so interesting part of that ppa?
<bschaefer> tvoss_, o well that makes more sense
<bschaefer> o that should have the the cursor fix...hmm I wonder if I should be testing this ati card with that
<tvoss_> bschaefer, if you can it to work, you are my hero
<bschaefer> tvoss_, well I think thats what Im looking at today :)
 * bschaefer installs ppa
<tvoss_> bschaefer, first purge the testing ppa
<bschaefer> tvoss_, thanks, almost didn't do that...
<kgunn> bschaefer: wanna stay in here ?
<bschaefer> kgunn, sounds good
<kgunn> cool
<kgunn> robotfuel: we moved :)
<bschaefer> so i just realized chris == robotfuel...
<kgunn> ha
<bschaefer> haha
<tvoss_> bschaefer, did you install the next ppa?
<bschaefer> tvoss_, doing that right now! just got down purging and updating
<tvoss_> bschaefer, ah :)
<bschaefer> now upgrade with the new ppa...hopefully things don't go tooo bad
<bschaefer> tvoss_, but looking at the ppa, theres no mir there?
<bschaefer> and after purging the testing ppa, should I be compiling mir my self?
<bschaefer> opps, I guess theres more then 1 page!
 * bschaefer is not use to that many packages in a ppa
<bschaefer> tvoss_, hmm working here
<tvoss_> wtf? no flickering?
<tvoss_> bschaefer, did you remove the pinning file for the testing ppa?
<bschaefer> tvoss_, shoot
<bschaefer> tvoss_, sorry! got your hopes up...
 * bschaefer upgrades again
<kgunn> how many times has each of us done that
<bschaefer> :), now I don't feel as bad haha
<bschaefer> kgunn, so am i expecting a crash or flickering?
<tvoss_> bschaefer, unity not coming up
<bschaefer> tvoss_, alright, that doesn't sound good :(, is mir still running in the background with the xserver?
<bschaefer> or is it the server as well?
<tvoss_> ?
<tvoss_> usc will be running, but xmir won't start
<bschaefer> err, so do you mean unity it self just crashes
<bschaefer> oo alright, when I hear unity doesn't run im thinking only compiz/unity
<tvoss_> ack
<bschaefer> hmm i just get a "no signal" from my monitor now ... thats somewhat strange
<tvoss_> can you ssh to the machine?
<bschaefer> tvoss_, well I should have gotten the ip first, but yeah i can guess a few
<bschaefer> should be 1-6...
<bschaefer> dang, forgot to install openssh...hmm thats going to be fun
<bschaefer> openssh-server
<tvoss_> bschaefer failsafe mode is yourr friend
<bschaefer> thanks, installing now, but the error I got was strange
 * bschaefer looks at the longs
<bschaefer> logs*
<bschaefer> (EE) no screen founds
<bschaefer> but that could be attempting failsafeX
<tvoss_> bschaefer, please get the xserver-xmir deb from the mir staging ppa manually and install it manually
<kgunn> This is a very general message telling you that something went wrong and there is no screen left which the server can successfully drive. Usually you'll see another error message describing what went wrong in more detail:
<kgunn> EE no screen found ^ from xorg
<bschaefer> kgunn, right, thats correct
<bschaefer> tvoss_, hmm getting the deb manually from the staging ppa?
<bschaefer> you mean add the ppa, and only install that package?
<tvoss_> bschaefer, cancel that
<bschaefer> alright, well the screen part is still true, but I can ssh into it now
<tvoss_> bschaefer, can you check if xserver-xorg-xmir is installed?
<bschaefer> dm_connection_start
<bschaefer> Failed to read header
<bschaefer> from lightdm log
<bschaefer> tvoss_, yeah let me check
<bschaefer> tvoss_,   Installed: 2:1.14.2-0ubuntu2+xmir1.1
<tvoss_> ack
<tvoss_> bschaefer, can you pastebin Xorg.0.log?
<bschaefer> tvoss_, yup!
<bschaefer> tvoss_,   Installed: 2:1.14.2-0ubuntu2+xmir1.1
<bschaefer> opps
<bschaefer> http://paste.ubuntu.com/5916056/
<bschaefer> tvoss_, ^
<kgunn> it wants exa ?
<kgunn> thot that was an intel thing
<bschaefer> on my Xorg failsafe attempt it has: [    33.829] (WW) Warning, couldn't open module vbe
<bschaefer> instead of exa...
<bschaefer> kgunn, it looks like it sees it doesn't exist
<bschaefer> kgunn, err, actually ati has XAA/EXA
<bschaefer> http://dri.freedesktop.org/wiki/ATIRadeon/
 * bschaefer wonders if XAA would workd
<bschaefer> work*
<tvoss_> bschaefer, try xaa please
<bschaefer> was just trying
<tvoss_> bschaefer, kgunn the interesting line is https://www.google.de/search?client=ubuntu&channel=fs&q=Driver+needs+flags+0,+incompatible+with+nested,+deleting.&ie=utf-8&oe=utf-8&gws_rd=cr&ei=adryUZCXL8SBtAa9v4CQDQ#safe=off&client=ubuntu&hs=i1p&channel=fs&sclient=psy-ab&q=%22Driver+needs+flags+0%2C+incompatible+with+nested%2C+deleting.%22&oq=%22Driver+needs+flags+0%2C+incompatible+with+nested%2C+deleting.%22&gs_l=serp.3...7152.7609.0.78
<tvoss_> 45.2.2.0.0.0.0.78.147.2.2.0....0...1c.1.22.psy-ab..2.0.0.Umv3IgNixhE&pbx=1&bav=on.2,or.r_cp.r_qf.&bvm=bv.49784469,d.Yms&fp=2582c0630cd1accc&biw=1316&bih=680
<tvoss_> bschaefer, kgunn even Driver needs flags 0, incompatible with nested, deleting.
<bschaefer> hmm it didn't seem to like my xconf file...
 * bschaefer tries again
<bschaefer> tvoss_, hmm but my xmir isn't even crashing, I don't think it gets that far
<bschaefer> it does...
<bschaefer> tvoss_, nevermind I see what you were looking at now :)
<bschaefer> tvoss_, hmm its loading my xorg.conf but its still looking for exa and not xaa
<tvoss_> bschaefer, kgunn hold on, looking at the source package from the next ppa, there is a conditional for xmir, translating into an XMIR preprocess define
<tvoss_> bschaefer, kgunn looking at the ati and intel source package, there is nowhere a define of the preprocessor macro
<kgunn> hmm
<tvoss_> bschaefer, kgunn xorg-xserver has an xserver-xorg.h.in that will get configured and finally (hopefully) contains the define
<bschaefer> wait so theres a define in the ppa thats replacing what?
<tvoss_> however, the header is nowhere included in the drivers
<tvoss_> bschaefer, kgunn so in total: I think we don't compile the x drivers for XMIR with nested support
 * bschaefer re calls RAOF mentioning to always include a header similar to that
<kgunn> little confused....who added the define ? is that upstream ?
 * bschaefer greps 
<bschaefer> tvoss_, well that would cause some problems...
<kgunn> bschaefer: yep....recal that too
<kgunn> header hell
<bschaefer> preprocessor hell :)
<tvoss_> okay guys, I'm eoding now
<tvoss_> please keep me posted here on irc, will pick up tomorrow morning
<bschaefer> tvoss_, alrright, have a good night sleep!
<bschaefer> yup!
<kgunn> good night tvoss_ see you on sunday!
<kgunn> thanks for the prodding :)
<bschaefer> kgunn, tvoss_ #include <xorg-config.h>
 * bschaefer doesn't know if this is whats missing though
<kgunn> bschaefer: hmm, digging..but it'd be in xorg patches from RAOF in his git branch i think
<kgunn> and as tvoss indicated it should be some sort of xmir macro
<bschaefer> so we are missing thi preprocessor define in the ati/intel source packages
<bschaefer> that should fix everything haha...
<kgunn> so it seems...so would need a recompile of those
<bschaefer> yeeah, but first dig through RAOFs git branches for some defines
<bschaefer> kgunn, do you have a link?
<kgunn> bschaefer: i would think in here....https://github.com/RAOF/xserver
<bschaefer> kgunn, cool, I just wasn't sure of what RAOF git account was, but I guess its RAOF :)
<bschaefer> thanks!
<kgunn> hmmm...don't see a mir ref in that header tho...(am i looking in the right one)
<bschaefer> kgunn, does that xserver encompass all of intel/ati? or are those in a separate branch?
<kgunn> bschaefer: seperate branches...same convention i think
<bschaefer> kgunn, hmm alright, cause tvoss_ mentioned it was in the ati/intel source packages
<kgunn> ...oop, no...they're in bzr
<kgunn> http://unity.ubuntu.com/mir/building_source_for_pc.html
<bschaefer> well thats also a good place to check :)
<chjunior> kgunn, are you guys talking about https://bugs.launchpad.net/xmir/+bug/1203776 ?
<ubot5> Launchpad bug 1203776 in XMir "X crashes w/ latest xserver intel driver from System Compositor Testing PPA" [Critical,Triaged]
<kgunn> chjunior: yes...basically
<kgunn> suffering too many damn channels
<chjunior> kgunn, cool :) is there a work around?
<kgunn> but i think there's some current thinking the sna not ready for prime time
<bschaefer> chjunior, ChrisTownsend mentions you can downgrade your intel driver
<chjunior> bschaefer, how can I do that exactly?
<kgunn> so in xorg.conf set  "AccelMethod"  "uxa"
<bschaefer> chjunior, you can do what kgunn is mentioning  (which was just tested)
<bschaefer> or reading this comment: https://bugs.launchpad.net/xmir/+bug/1203776/comments/36
<ubot5> Launchpad bug 1203776 in XMir "X crashes w/ latest xserver intel driver from System Compositor Testing PPA" [Critical,Triaged]
<chjunior> bschaefer, does that prevent future updates?
<bschaefer> chjunior, i would think the next time you upgrade it would upgrade it, but im not sure :(
<chjunior> E: Version '2.21.9+xmir5870-0~saucy1' for 'xserver-xorg-video-intel' was not found
<bschaefer> chjunior, :(, hmm it might have been bumped hmm, you could try what kgunn was mentioning :)
<bschaefer> chjunior, in /etc/X11/xorg.conf
<chjunior> yeah, I hate messing up with xorg.conf
<bschaefer> yeeaah
<chjunior> I'm a happier person since the last time I did it
<bschaefer> :)
<bschaefer> chjunior, you tried? sudo apt-get install xserver-xorg-video-intel=2:2.21.6-0ubuntu4
<bschaefer> you'll lose mir though :(
<chjunior> yeah
<chjunior> that's why I did the other one
<chjunior> If you want to keep mir: "=2.21.9+xmir5870-0~saucy1"
<bschaefer> :(, that was the last version, as currently we are on: 2:2.21.9+xmir5870-1~saucy1
<chjunior> yeah, and seem like there's no older version in there
<xjunior> kgunn, bschaefer: switching to uxa worked
<kgunn> xjunior: thanks data point 2 of success :)
<bschaefer> xjunior, awesome :), we'll have to figure out what sna doesn't work
<xjunior> bschaefer, kgunn: thank you guys. I have the bug here, I can help you out with anything
<xjunior> just let me know which logs/procedures you need
<bschaefer> xjunior, thanks :)
<bschaefer> kgunn, so looking at this ati branch
<bschaefer> if XMIR is not defined, we don't include a lot of things
<bschaefer> but i don't see it defined here though
<bschaefer> sooo something else must be defining it...
<mlankhorst> bschaefer: xorg-server ought to define it
<bschaefer> mlankhorst, well that make sense...
 * bschaefer looks through there
<bschaefer> configure.ac:1146:	PKG_CHECK_MODULES([XMIR], [mirclient], [XMIR=yes], [XMIR=no]), soo possibly we aren't enabling XMIR in daily next?
<bschaefer> kgunn, ^
<bschaefer> in RAOF xserver git branch
<bschaefer> malthanks for the info :)
<bschaefer> thanks*
<bschaefer> http://paste.ubuntu.com/5916291/
<bschaefer> so something is failing in here, thats setting it to false...
<bschaefer> opps copied a bit to much...
<kgunn> bschaefer: so its just a build/packaging bug ?
<bschaefer> kgunn, im not sure, as I want to confirm they are missing from main possibly...
<bschaefer> kgunn, but possibly!
<xjunior> bschaefer, kgunn: from the package diff, in the ppa, yes
<xjunior> the change was to default to sna instead of uxa
<bschaefer> xjunior, we are talking about this problem with a different ppa :), sna was just enabled ( IIRC)
<xjunior> sorry
<bschaefer> xjunior, no worries :)
<kgunn> xjunior: we've got a couple of moving pieces we're chasing...1 bug w/ sna....and another bug with what seems to be xmir preproc missing somehow (that bschaefer is talking about)
<xjunior> kgunn, gotcha ;)
<bschaefer> kgunn, should we push something to change things back to uxa, until we figure out what sna is not working atm?
<bschaefer> kgunn, not a signal mention of mir in xserver-xorg-video-ati-7.1.0
<kgunn> bschaefer: yeah...we probably should...
<bschaefer> from the daily-next ppa
<bschaefer> kgunn, so now why does xserver not think we should inculde xmir... hmm
<mlankhorst> to the build logs..
<bschaefer> yup, was about to try to just build xserver on my machine, but i suppose logs that exist already would be helpful :)
 * bschaefer gets an XMIR = YES here
<kgunn> bschaefer: ok....not sure what the hell...i swear i didn't see this earlier....
<kgunn> https://github.com/RAOF/xserver/blob/04b01054c2f0eb020b588c976cb4c6a3fb8d867e/include/xorg-server.h.in
<kgunn> XMIR undef in this one ^
<kgunn> for nested
<bschaefer> hmm strange: https://github.com/RAOF/xserver/blob/04b01054c2f0eb020b588c976cb4c6a3fb8d867e/include/xorg-server.h.in
<bschaefer> opps
<bschaefer> haha just copied that sorry!
<bschaefer> kgunn, yeah I saw that...
<bschaefer> but hmm
<Sarvatt> its a .in, changes based on build options
<bschaefer> kgunn, cause xorg-server read as: checking for XMIR... yes
<bschaefer> soo XMIR is getting undefed somewhere else...
<bschaefer> unless the ati/intel bits aren't using the right xorg from the ppa?
<mlankhorst> or they were built before xorg-server was built in the ppa.
<Sarvatt> try no change rebuilding the drivers that probably built before xserver with xmir did?
<bschaefer> possibly, how could we test this? Rebuild those packages?
<bschaefer> and it looks like xorg-server was built on 25th, and ati was on the 18th
<bschaefer> but intel was on the 25th as well
<bschaefer> https://launchpad.net/~ubuntu-unity/+archive/daily-build-next/+packages?batch=75&direction=backwards&start=300
<kgunn> bschaefer: yeah...just pull from bzr build local should work right ?
<kgunn> to prove it
<bschaefer> kgunn, hmm well im just wondering why the apt-get source on the ati/intel doesn't give use anything mentioning xmir... i mean the source should
<bschaefer> mention the xmir stuff either way right? (Even before its built?)
 * kgunn wants to say true...but digging first
<Sarvatt> forgot the deb-src line?
<bschaefer> possibly, its almost like we aren't using RAOFs version...
<kgunn> bschaefer: that's what i was going to dig on....
<kgunn> i wonder...
<bschaefer> kgunn, hmm let me double check the intel version...
<bschaefer> kgunn, cause I just realized I might have pull the wrong source...
<kgunn> :)
<bschaefer> kgunn, well I did pull the wrong one, but its still wrong on the right one :)
<kgunn> well...these bugs definitely make you neurotic
<bschaefer> yeeaah
<kgunn> check, double check...then check again
<bschaefer> yeah, well its still true! whew...
<kgunn> bschaefer: so you gotta intel_xmir.h with #if XMIR
<bschaefer> kgunn, well  thats only included if XMIR right?
<kgunn> now...that header, "asks" if that predefine exists and then acts on it
<kgunn> oops/now/no
<bschaefer> kgunn, right, but it has be defined, and XMIR doesn't exist in the apt-get source ati/intel
<kgunn> right
<bschaefer> kgunn, im trying to do a dget on the packge to see if the deb-src is correct...but gpg is not liking who signed it (or rather the like of...)
<kgunn> ok...getting convinced...i think the drivers just need to be rebuilt
<bschaefer> kgunn, yeah...how would we go about doing this :)
<Sarvatt> looked into it a bit and its more likely the refactoring the intel dev did when RAOF switched the branch to his 2.21.12 one broke SNA to be honest, the one in the ppa did build with mir support..
<Sarvatt> the one in daily-staging is versioned 2.21.9 but its really a 2.21.12 git snapshot from http://cgit.freedesktop.org/~ickle/xf86-video-intel/log/?h=xmir
<Sarvatt> (can see that in configure.ac)
<kdub> maybe once ff is over i'll restructure some android display code...
<bschaefer> Sarvatt, hmm well doing a dget on that package Im picking up xmir stuff
<bschaefer> but not when doing a apt-get source...
<bregma> bschaefer, that's because you don;t have the deb-src lines set up correctly:  trust the dget
<Sarvatt> bschaefer: it needs to be using https://code.launchpad.net/~mir-team/mir/xf86-video-intel-fixup instead of https://code.launchpad.net/~mir-team/mir/xf86-video-intel-vladmir which it just switched to yesterday and probably never got tested..
<bregma> Sarvatt, are you saying there's a change somewhere that needs to get reverted?
<Sarvatt> or 3 days ago rather
<Sarvatt> well it switched from 2.21.9 that had been tested with SNA I imagine for a long time to a branch that is a much newer git snapshot where the intel guys changed the xmir stuff around on 7/23, i'm just guessing thats where the problem started?
<kgunn> Sarvatt: yep...i think you're right
<kgunn> we went to head...untested
<Sarvatt> i have no context here but i'm just seeing an obvious thing
<bregma> bschaefer, do you feel confident about bisecting that delta when you get back from lunch?
<bschaefer> bregma, well ill trust dget for now onwn
<bschaefer> Sarvatt, awesome, thanks for looking into that!
<bschaefer> bregma, how would one bisect the delta from the branches?
<bschaefer> bregma, shouldn't we just have to point to the new one?
<bschaefer> or take the ickles changes and merge them with RAOFs?
<bregma> bschaefer, I would think the easiest thing is to revert to the old branch, but I'm thinking there was a reason why the newer one was used
<bschaefer> bregma, hmm well looking at the rev, ins't the old branch the one we are using?
<bschaefer> ie. https://code.launchpad.net/~mir-team/mir/xf86-video-intel-vladmir
<bschaefer> which I thought was the old one, but we should be using this one: https://code.launchpad.net/~mir-team/mir/xf86-video-intel-fixup
<bregma> <Sarvatt> bschaefer: it needs to be using https://code.launchpad.net/~mir-team/mir/xf86-video-intel-fixup instead of https://code.launchpad.net/~mir-team/mir/xf86-video-intel-vladmir which it just switched to yesterday and probably never got tested..
<bschaefer> bregma, well... yeah that would make the fixup the old one
 * bschaefer checks the diff of the 2
<bregma> Ya know what, I'd feel more comfortable if RAOF could explain why the change was made, and in the mean time drop back to the xf86-video-intel-fixup version -- can you try that and test to see if it solves the problem?
 * bregma does not want bschaefer to be working over the weekend
<bschaefer> bregma, haha, yeah that does sound like a good approach
<bschaefer> i've still got to make sure this ibus stuff is working as well
<bregma> ibus will wait patiently until next week, we want mir to land as soon as possible
<bschaefer> right, ill focus on this
<bschaefer> hmm but I don't think this explain the ati problem :(
<bschaefer> explains*
<bregma> oh
<bregma> :(
<bschaefer> cause moving back to uxa from sna fixes this intel problem
<bschaefer> but hmm I don't think this is going to fix the daily build problem
 * bschaefer looks into it anyway
<bschaefer> at lease we know something strange is going on with the packaging...
 * bregma thinks SNA is something that requires a MAU for the token ring
#ubuntu-mir 2013-07-27
<kgunn> having intel fixed is less broken than right now
<kgunn> some effort on bisecting ati would be good tho
<bschaefer> yeah, im not sure what branch it would be pointed out... i've also not tested nouveau, but im guessing its the same...
<bschaefer> bregma, kgunn hmm so strange, I used the intel-fixup branch, with the testing ppa and it fixed my normal X problm
<bschaefer> but xmir failed with the no screen found error :(
<bschaefer> and I wasn't even on the daily build ppa
<bschaefer> daily next ppa
<bregma> not sure I understand...  you mean the intel driver now works fine without xmir but xmir does not work?
<bschaefer> bregma, yeaah
<bschaefer> bregma, though I could need to move to the daily next ppa
 * bregma feels his head spinning with too many PPAs
<bschaefer> bregma, also https://code.launchpad.net/~mir-team/mir/xf86-video-intel-fixup
<bschaefer> doesn't mention xmir either
<bschaefer> soo its not getting warpped...
<bschaefer> wrapped*
<bschaefer> which would explain why it didn't work
<bschaefer> it would also explain why RAOF wasn't using it
<bschaefer> possibly...
<bregma> facts...  we need facts
<bschaefer> bregma, kgunn i've got a fun idea. So since when I dget I see xmir all over the place how about I try to install that version on my ati
<bschaefer> and if it fixes it, then its a packaging error
<bregma> yep
 * bschaefer goes to test that
<bschaefer> :(, seems to still fail
 * bschaefer also wonders why fdev fails as well
<bschaefer> fbdev*
<tvoss_> RAOF, ping
<smintheu> hi all - I heard mir/xmir are landing in the daily builds this coming week
<smintheu> anybody have an idea when, exactly, and if there are going to be builds with mir and others without?
#ubuntu-mir 2014-07-21
<duflu> camako: I'm kind of hoping we can add more fixes and performance improvements to RTM yet. You can see them targeted for a "0.5.1": https://launchpad.net/mir/+milestone/0.5.1
<duflu> (it's the same set as is tagged rtm14)
<camako> duflu, sounds good.. Though #1345533 is about hwc which tends to be device specific.
<duflu> camako: *shrug* I don't have one of them to test with
<camako> duflu, me neither :-)...
<camako> duflu, also I wasn't sure about #1316867 since it has to do with DRM and rtm is android...
<duflu> camako: Oh, yes. Worth having in a stable branch but not relevant to Android
<duflu> Kinda.. It's relevant to all platforms. Just starting with DRM
<duflu> But that one in 0.6 in time for utopic is enough
<camako> duflu, also it has to do with the fatal_error branch which is causing controversy... :-)
<camako> duflu, #1240909 would be nice but would like to see a solution in devel first.. Don't wanna hold up rtm for it... We can always backport...
<duflu> camako: Well if you think there will be a 0.5.2 then no problem. Otherwise double buffering offers potentially the biggest performance improvement yet to land, so it's worth trying to get in ASAP
<duflu> I mean the biggest improvement in responsiveness
<camako> duflu, yeah +1 on the responsiveness!
<camako> ... #1343074 has already been committed.
<duflu> Because Ubuntu touch is 8-buffered (3 in the client + 3 in the nested server + 2 in the native server). The double branch will get that down to 6-ish
<duflu> Minus 1 to calculate best case input lag. It's still not great
<duflu> Hmm, could even be more. I'm not familiar with the Android page flipping we use
<duflu> Actually, I confused the numbers. Lag is 2 + 2 + 1 = 5 right now.  The double branch gets that down to 1+1+1 = 3
<duflu> Almost halved
<duflu> Delay between client and screen will be at least 32ms less
<camako> It's pretty significant.. No doubt..
<duflu> And hopefully there are other unrelated improvements coming soon
<duflu> Actually, I think we might be weeks away from out-performing Android on the same hardware
<duflu> Just got to tweak some things
<camako> duflu, @ releasing 0.5.2 and even beyond, I fully expect that to happen.... until the device receives a final image which is weeks away.
<camako> the rtm device that is
<alan_g> any more review comments for this? https://code.launchpad.net/~mir-team/mir/cursor-spike-phase-7-name-some-cursors/+merge/225242
<alf_> duflu: @double, Could you elaborate on 115+ if (used_buffers > min_buffers() && max_buffers > 1), I am not sure I get the intent.
<duflu> alf_: That's when the minimum requirement drops (framedropping turned off). That code pre-dates the same check now present in the framedropping toggle.
<duflu> Might be redundant now
<duflu> But still good to keep
<alf_> duflu: wait, I think I may have completely misunderstood the MP... isn't this MP's goal to change the queue size depending on client demand? Or does it only change the queue when changing between non-framedropping and framedropping?
<duflu> alf_: That is now the only indicator of demand
<duflu> ... which is pretty new yes
<alf_> duflu: so it just switches between a fixed size of 2 buffers for non-framedropping and 3 buffers when allow_framedropping(true) ?
<duflu> alf_: Yes. Much simpler than earlier versions
<alf_> duflu: Simpler, yes, but is it sufficient? The fixed 2 buffer queue reduces latency, but it also uncoditionally drops all the benefits triple buffering brings (like the ability to deal with frames occasional missing the frame time limit)
<duflu> alf_: Yes, it is sufficient in all testing so far. There is an argument to make it configurable sure
<duflu> alf_: Forgive me for preparing to go offline soon
<alf_> duflu: Enjoy!
<alan_g> camako: we've three MPs for 0.5 failing "mysteriously" in CI - is this something you're looking into?
 * alan_g hopes to make 0.5 "someone else's problem"
<camako> alan_g, yea I saw that... Sure I can look into it.
<camako> alan_g, or more like ask fginther who recently prepared the jenkins config for 0.5
<alan_g> camako: you can also try cihelp on #ubuntu-ci-eng (which will probably end up at fginther too)
<ogra_> did you guys test the latest Mir and sysstem-compositor uploads on manta ? seems it is unbootable ...
<ogra_> http://paste.ubuntu.com/7829641/
<ogra_> I/hwcomposer( 2071): Using 2560x1600 60Hz resolution for 'fb0' from modes list
<ogra_> I/hwcomposer( 2071): unblank ioctl failed (display already unblanked)
<ogra_> W/libEGL  ( 2071): eglTerminate() called w/ 1 objects remaining
<ogra_> E/libEGL  ( 2071): validate_display:263 error 3001 (EGL_NOT_INITIALIZED)
<davmor2> kgunn: you about?  Manta is broken since the landing of 0.5.0 by the look of it.  It gets to the google logo and no further.
<kgunn> davmor2: i'm here, hmmm, is that news? i experienced that last week during our testing and i was told that was due to something else
<kgunn> davmor2: it was on irc, i think i recall someone saying it had to do with telephony stuff (?)
<alf_> kgunn: good to hear it's not just me, I though I had broken the device
<davmor2> kgunn: it works fine in 136 pre 0.5.0 and then breaks in 137 http://paste.ubuntu.com/7829641/ and http://davmor2.co.uk/~davmor2/syslog  is the only info I have from it which seems according to ogra_ to point to egl
<davmor2> kgunn: I only got back today so hit it testing something else.
<davmor2> kgunn: also wouldn't the flo play up too if it was the telephony stack?
<ogra_> kgunn, seems hammerhead broke at the same time ... i think they use the same driver
<ogra_> (at least thats what rsalveti claimed (the brokeness))
<kgunn> ogra_: not the same driver....in fact N7==N4 on driver
<rsalveti> not the same driver, but could be broken the same way
<ogra_> ok
<rsalveti> bug 1345533 for hammerhead
<rsalveti> no bots anywhere
<ogra_> yeah, they went on a group vacation it seems
<ogra_> super special group offer
<rsalveti> davmor2: can you check /var/log/lightdm/unity-system-compositor.log
<rsalveti> on the broken image
<rsalveti> hahah
<davmor2> rsalveti: sure give me a few
<kgunn> interesting before egl failure in that log i see "I/hwcomposer( 1015): unblank ioctl failed (display already unblanked)"
<kgunn> oh...that's just unblanking
<kgunn> nvmd
<ogra_> the next lines are more worrying
<kgunn> ogra_: yeah, but it looks like egl succeeded...then its bailing subsequent
<ogra_> right ... but we had no android changes during that time
<ogra_> image 136 had an android update ...
<ogra_> 137 had the new Mir ...
<ogra_> the former image works flawless ... the latter doesnt
<rsalveti>  /var/log/lightdm/unity-system-compositor.log will tell any mir specific error
<davmor2> right guys back with you now
<davmor2> rsalveti, kgunn: http://davmor2.co.uk/~davmor2/unity-system-compositor.log
<rsalveti> right, similar but different
<rsalveti> a bunch of calls are now triggering an exception in case of errors
<rsalveti> in this case it's  display_on
<rsalveti> on nexus 5 it was vsync_on
<kgunn> camako: ^ you following?
<rsalveti> so yeah, indeed mir causing the issue
<camako> yeah
<camako> kgunn
<kdub_> hmm
<davmor2> kgunn: if you and your team need info from a broken device just ping me as this manta now no longer turns off it will be available for logs etc if you need any that rsalveti didn't cover :)
 * kdub_ can look, seems more important than the optimization stuff i was looking at this morning
<kgunn> kdub_: thanks
<kdub_> also though, I have to whine that we don't have a nexus 5, and only test the nexus 4 in CI
<kdub_> :)
<kdub_> so I'll poke around the n10
<kgunn> kdub_: i keep forgetting your on CST now :)
<kgunn> i was waiting to bother you cali time :)
<kgunn> camako: i distinctly recall testing on manta....for mir0.5...did you ?
<kgunn> camako: altho...not sure i tested post alan's add
<camako> kgunn, not on manta
<kdub_> MI is EST, I now get the jump on the texans!
<kgunn> kdub_: oh wow...didn't realize that
<kgunn> EST
<kdub_> the problem is only on startup?
<rsalveti> yes
<rsalveti> hart to know if it'll happen later on though, as it's not even able to start
<kdub_> I have an idea of what's going on
<rsalveti> from what I saw in the diff the difference is that now those errors are critical
<kdub_> working on confirming
<rsalveti> which wasn't the case before
<rsalveti> but they were always there
<kdub_> right, I think that some restructuring changed it
<rsalveti> right
<kdub_> does the n4 have the problem?
<AlbertA> kdub_: no it works fine here with mir 0.5.0
<kdub_> ah, I have a very good idea then
<rsalveti> nops
<kdub_> bug yet too?
<kdub_> if not i'll file one
<kdub_> oh 1345533
<rsalveti> that's for n5
<rsalveti> for manta I'm not sure we have one
<kdub_> probably same issue
<davmor2> kdub_: n4 and n7 both work fine n10 and n5 seem to be hit by it
<greyback> racarr__: hey quick confirmation form you: there's no api for a client to know its position on screen is there?
<racarr__> greyback: Nope
<greyback> racarr__: thanks
<racarr__> np :)
<racarr__> lunch
<kdub_> davmor2, rsalveti : lp:~mir-team/mir/fix-1345533-0.5 has been checked on the nexus10, and will likely fix the n5 too
<kdub_> but I don't think the mir team has a n5
<davmor2> kdub_: nor do I over to rsalveti for that I think
<kdub_> davmor2, ah, thought you had one, sorry
<davmor2> kdub_: I have the n10
<rsalveti> kdub_: will check n5 later today
<rsalveti> do we have it in a silo or similar already?
<rsalveti> just to be easier to grab the packages :-)
<rsalveti> kdub_: not sure if that will fix n5 though
<rsalveti> as the exception was a different one
<rsalveti> or is display_on also triggering the vsync_signal_on?
<rsalveti> if so, then yeah
<AlbertA> rsalveti: right turn_screen_on() calls hwc->blank(...) and hwc->eventControl(..., HWC_EVENT_VSYNC,...)
<rsalveti> great then :-)
<davmor2> back to the are there packages available?
<davmor2> kdub_: ^
<AlbertA> davmor2: no not yet...
<AlbertA> camako will probably set up the silo when he comes online
<davmor2> AlbertA: ah cool thanks
<kdub_> rsalveti, right, the fix should catch/ignore either problem (vsync/blank)
<AlbertA> racarr__: ping
<racarr__> AlbertA: pong
<AlbertA> racarr__: is there a way to know if an input event has been handled on the nested case?
<AlbertA> basically if I install a eventfilter
<AlbertA> in the server
<AlbertA> can a client in a nested scenario consume the event so that my filter doesn't run?
<racarr__> sorry not quite parsing
<racarr__> whhere is the filter? where is the client?
<racarr__> (host/nested)
<AlbertA> so imagine unity system compositor
<racarr__> ok
<AlbertA> installs an event filter
<AlbertA> i.e. an append to the composite_filter
<racarr__> ok that will be like the first thing ever
<racarr__> to see events basically
<AlbertA> ok
<racarr__> before shell
<racarr__> etc
<AlbertA> so it's there a way for me to know if the a client like unity8, consumed a key event?
<racarr__> except...lol I wonder if
<racarr__> unity8
<racarr__> input filters probably dont work in unity8 right now
<racarr__> but not an urgent problem
<racarr__> um no.
<AlbertA> ok
<racarr__> currently all events are handled
<racarr__> there is some infrastructure for handling/not handling events
<racarr__> but not on the client side
<racarr__> there is also some design documentation that...we should one day have an accept/reject model
<racarr__> do we need it?
<AlbertA> well
<AlbertA> it's for a minor thing
<AlbertA> there's this power dialog
<AlbertA> that shows up if you hold up the power key for 2s
<AlbertA> but USC has policies
<AlbertA> to shutoff display on power key up (after a power key down)
<AlbertA> so we had to add hacks to ignore that if hits the 2s...etc
<AlbertA> so that USC does not shut off display
<racarr__> ah
<AlbertA> and instead unity8 can show the power off dialog
<racarr__> yeah
<AlbertA> basically I would want an ack or something
<AlbertA> that unity8 consumed power key up
<racarr__> robert_ancell: wanted to let you know header with mir cursor names landed so you should be able to add gtk cursor support
<racarr__> when...the fancy strikes you :)
<robert_ancell> racarr__, nice. Are there plans for custom cursors too?
<racarr__> robert_ancell: Yeah. it just needs protocol + add mir_cursor_configuration_from_rgba_pixels_function_names_are_so_long_:(
<racarr__> etc
<racarr__> next time I get bored + don't feel bad doing something that has no upcoming deadline lol
#ubuntu-mir 2014-07-22
<duflu> kdub_: Hello?
<kgunn> duflu: he's actually US eastern standard time (he moved back to michigan)....so its 11pm there
<kgunn> just for future reference
<duflu> Ah. Forgot
<duflu> kgunn: How long for?
<duflu> Oh "moved"
<kgunn> duflu: yeah...for the foreseeable future
<alan_g> alf_: (non-urgent) does the latest version work for you? https://code.launchpad.net/~mir-team/mir/enable-late-release/+merge/227178
<alf_> alan_g: yes, although I think that if the failure is consistently reproducible we could have a test for this, checking the process exit status, like we do e.g. for ServerShutdown removes_endpoint_on_signal (but checking for a successful exit)
<alf_> alan_g: not sure about any blocking details though
<alan_g> alf_: In principle, we could add a test that execs (say) the new test program. In practice, we need to be sure that it exists somewhere to be run. FWIW There are other tests like this I'd like to run but haven't built the infrastructure.
<alf_> alan_g: what stops us from just using launch_client_process(client_config) instead of an external client?
<alan_g> alf_: I guess that might work, but remember it calls exit() in the teardown code instead of exiting from main() - a scenario with potentially significant differences
<alf_> alan_g: ok (in any case, test not a blocker, but a nice-to-have)
 * alan_g feels increasing motivation to write yet another test execution framework
<alan_g> RAOF: are your (blocking) concerns addressed? https://code.launchpad.net/~mir-team/mir/libmircommon/+merge/226704
<alf_> anpok: did you file a bug about Mir not showing the latest frame in some cases?
<alan_g> camako: are your concerns addressed? https://code.launchpad.net/~mir-team/mir/libmircommon/+merge/226704
 * camako checks
<camako> alan_g, yes.. approved
<alan_g> thanks
<camako> np
<anpok> alf_: no I reflashed the device, another time and the issue was gone
<anpok> -,
<alf_> anpok: do you remember how to (try to) reproduce the issue?
<anpok> alf: pin entry dialog - since there is no animation/blinking cursor
<alf_> I am cross-compiling libmirserver23 from pristine trunk and copying the shared object to the phone, but unity8 crashes when using it (usc works normally)
<alf_> Has anyone seen that?
<duflu> alf_: Development branch is libmirserver24 :)
 * duflu goes into hiding
<greyback> anpok: ping
<anpok> greyback: pong
<anpok> greyback: thinking about injecting input?
<greyback> anpok: slightly different topic, we're getting a crash with QtComp, wanted to ask your advice
<greyback> anpok: crash happens running with autopilot, so apps are stopped & started very rapidly
<greyback> and input events can be injected after the surface has been destroyed
<greyback> anpok: http://pastebin.ubuntu.com/7835652/ is the stacktrace I get
<greyback> could it be that if QtComp tries to send event to client which has stopped, but mir hasn't fully cleaned up after it, mir could call mir::AsioMainLoop::register_fd_handler to create a fd for that client again?
<greyback> terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::system::system_error> >'
<greyback>   what():  assign: File exists
<greyback> is the exception thrown
<anpok> greyback: hm not calling surface->consume?
<greyback> anpok: we should be. BT doesn't seem to show that though
<anpok> ok
<greyback> compiler might have inlined it?
<anpok> hm cool devirtualization
<anpok> hm we are not creating a fd there..
<greyback> anpok: any ideas/theories?
<anpok> hm i am following the call down to asio
<anpok> the constructor seems to register the fd with the epoll fd
<anpok> i would have assumed that happens some time later
<anpok> EEXIST -> the supplied file descriptor fd is already registered with this epoll instance..
<anpok> do we have strace logs?
<greyback> anpok: they can be got. I can also show you how to reproduce, whatever you like
<anpok> oh then i take option 2
<greyback> ok. Install the qtcomp silo (https://wiki.ubuntu.com/Unity8/QtComp)
<greyback> then we want to run an autopilot test suite
<greyback> so
<greyback> https://wiki.ubuntu.com/Unity8/QtComp
<greyback> oops
<greyback> phablet-config edges-intro --disable
<greyback> adb shell powerd-cli display on bright&
<greyback> phablet-test-run -p ubuntu-html5-ui-toolkit-autopilot ubuntu_html5_ui_toolkit
<greyback> the last command should run the test. You'll see an app start & stop repeatedly
<greyback> I often get the crash during the test suite run
<greyback> and it's always after a stream of key events that it crashes
<dandrader> greyback, anpok, I got a bt with a tad more details http://paste.ubuntu.com/7836063/
<anpok> there is a race but not yet sure how to fix it
<dandrader> anpok, a race between who?
<anpok> i guess between unregistering an fd and registering another one with the same fd number..
<anpok> ah no the fd is kept alive through the InputChannel even when the surface is gone
<kdub_> anpok, maybe the new fd type would help :)
<racarr_> Morning
<anpok> greyback, dandrader: do we have ticket for that issue yet?
<greyback> anpok: no
<greyback> I can log one
<dandrader> ticket?
<greyback> bug
<anpok> dandrader: wording of my past...
<anpok> that sometimes creeps into present
<dandrader> :)
<anpok> hm trying to reproduce but I dont think that I get the error that I should get -
<anpok> 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >'
<anpok>   what():  Failed to send message to server: Bad file descriptor
<greyback> anpok: https://bugs.launchpad.net/mir/+bug/1346952
<greyback> anpok: hmm no, I reliably get a different error
<greyback> s/reliably/always/
<anpok> you always get the other exception message from above?
<dandrader> I do
<racarr_> need one more review on https://code.launchpad.net/~mir-team/mir/touchspot-visualizer/+merge/224731
<racarr_> cemil says he doesnt count as a proper review
<racarr_> :p
<groot_> I'm trying to port UT in my device, device boots but unity-system-compositor is failing all the time. I've the similar issue as posted here https://bugs.launchpad.net/ubuntu/+source/ubuntu-touch-session/+bug/1283326/comments/3
<racarr_> what is most recent qtcomp ppa/silo/thing I can install on my phone?
<groot_> and here https://bugs.launchpad.net/ubuntu/+source/ubuntu-touch-session/+bug/1283326/comments/4
<racarr_> trying to avoid rebuilding the whole stack while testing some things
<groot_> what should I do to fix this ?
<dandrader> anpok, the crash is happening during a long and rapid stream of key events
<dandrader> anpok, as autopilot generates those key events synthetically
<greyback> racarr_: https://wiki.ubuntu.com/Unity8/QtComp - silo6
<dandrader> but I guess you already know this as you're able to reproduce it locally (event if it not yields the same crash)
<groot_> Please, anyone can give me a solution? I've some logs if anyone wants to see :)
<racarr_> greyback: Ah thanks
<racarr_> greyback: Going to add touchspots
<racarr_> to qtmir/unity8
<greyback> racarr_: why?
<racarr_> unless you happen to be jumping with joy for new tasks
<racarr_> I figured I had some time to do it
<racarr_> thomi wants it
<racarr_> to assure quality
<greyback> racarr_: I was expecting them to be partof USC
<greyback> groot_: I'm guessing that unity-system-compositor didn't start up. You need to investigate if Mir works on your device. Get the "mir-demos" package and try out mir_demo_server_shell and some demo clients with it
<racarr_> I mean they could be....bar some other stuff that is taking a while
<racarr_> but I kind of feel like why not QML lol
<racarr_> because you probably want them to fade or pulse or burn on fire something
<greyback> racarr_: MultiPointTouchArea is your friend then
<racarr_> not you personally
<racarr_> lol
<greyback> I want them with particle effects
<racarr_> greyback: Oh thats one way...
<racarr_> I added a new
<racarr_> TouchspotVisualizer interface actually that juset gives raw pressure/point...
<racarr_> before they become input events or anything (down at input reader level)
<groot_> greyback, thanks. Before I do that, can you take a look at some logs? Maybe this'll help you find the exact problem.
<racarr_> so plan was to add an interface for that to qtmir
<greyback> sounds complicated. MulitPointTouchArea is very easy
<racarr_> hmm *goes to read*
<greyback> groot_: show me the logs. I'm not much good to you if mir doesn't work, I'm not a core mir developer
<groot_> greyback, no problem. here's syslog http://paste.ubuntu.com/7836697/
<groot_> lightdm.log http://paste.ubuntu.com/7836703/
<groot_> unity-system-compositor strace http://paste.ubuntu.com/7836711/
<ogra_> greyback, i think handholding him through running the test apps might be a start (i sent groot_ here after checking his logs)
<groot_> ogra_, you're right :)
<greyback> groot_: seems mir fails with "Bad file descriptor" - suspect you'll need someone with more core mir knowledge than I.
<racarr_> groot_: We will need to try the demo servers like greyback described to get something more
<greyback> groot_: but do install the mir-demos package, and try running the mir_demo_*_shell programs to see if they work
<racarr_> specific...the bad fd error is too weird...if you read
<racarr_> its a bad fd calling epoll_ctl on two fds which were just created, one an epoll, and one a timer
<racarr_> and...I dunno that seems reasonable lol.
<racarr_> so hard to get much out of the logs
<groot_> greyback, as ogra said, you may have to help me with this demo run :|
<groot_> racarr_, ^^
<Saviq> AlbertA, hey, I found that if unity-system-compositor crashes, power button wake doesn't work any more
<racarr_> groot_: First you need mir-demos then you can run a mir instance
<racarr_> i.e. mir_demo_server_shell &
<racarr_> and then pick a client i.e. mir_demo_client_*
<AlbertA> Saviq: this should help: https://code.launchpad.net/~albaguirre/unity-system-compositor/fix-1343919/+merge/227645
<AlbertA> alf_: I've updated https://code.launchpad.net/~albaguirre/unity-system-compositor/fix-1344101/+merge/227641
<groot_> racarr_, via ADB, right? I've to install mir-demos in desktop and run instance through adb ?
<alf_> AlbertA: just looking at that... so the power menu has exactly the same issues the greeter (may not have enough time to render and stale frame)
<racarr_> groot_: No adb in and then install mir-demos on phone
<alf_> AlbertA: perhaps we should apply the workaround you mentioned for the greeter (waiting a bit more to turn on the screen) for the power menu too. So if unity8 shows the menu after 2000ms perhaps we should turn on the screen after 2200ms (or something)?
<AlbertA> alf_: so what are you seeing now?
<groot_> racarr_, for that I need net connection, right?
<groot_> racarr_, it's failing "E: Failed to fetch http://ports.ubuntu.com/ubuntu-ports/pool/universe/m/mir/mir-demos_0.4.1+14.10.20140714-0ubuntu1_armhf.deb  Could not resolve 'ports.ubuntu.com'" :(
<racarr_> groot_: Yeah...
<racarr_> downnload on desktop
<racarr_> and adb push :)
<racarr_> should be fine
<alf_> AlbertA: hmm, I thought I was seeing "power menu hasn't rendered yet" effect, but I now think it's the stale frame effect (I am seeing the greeter momentarily before the power menu shows up)
<AlbertA> alf_: ahh, right
<alf_> AlbertA: so I am not sure the extra timeout would help
<AlbertA> alf_: well I think it would help
<AlbertA> alf_: because the dialog doesn't start drawing itself
<AlbertA> until that 2s alarm fires
<racarr_> alf_: Hey...something I've been meaning to ask.
<racarr_> Is there any generic way to write to GBM bos without using an opengl context? gbm_bo_write only works for the dumb bos...
<racarr_> which only work for the cursor bo.
<racarr_> which has the whole no DRI image problem so you can't EGLCreateImage (as you encountered doing software I guess)
<racarr_> The thing is. I can't actually use the cursor buffer for the cursors or touchspots
<alf_> AlbertA: YMMV, 2200 doesn't make much of a difference, but 2500 is better: the "not rendered yet" effect is gone, but we occasionally get a stale greeter frame
<racarr_> because software wont work on it
<racarr_> err
<racarr_> not software
<racarr_> GL
<racarr_> lol
<racarr_> I could just use software buffers but then
<Saviq> AlbertA, oh cool
<racarr_> no overlay on HWC for touchspots
<groot_> racarr_, installed mir-demos from here https://launchpad.net/ubuntu/utopic/armhf/mir-demos/0.4.1+14.10.20140714-0ubuntu1
<AlbertA> alf_: yeah it looks better with 500ms...
<AlbertA> alf_: so would this suffice?  http://paste.ubuntu.com/7836986/
<racarr_> groot_: Ok seems about right! So are you able to run mir_demo_server_shell
<groot_> which command should I run now?
<AlbertA> alf_: or just run another alarm?
<groot_> racarr_, ran it but got "segmentation fault (core dumped)"
<racarr_> groot_: Can you grab a backtrace with gdb? May have to use the same trick to install it
<alf_> AlbertA: Why not make the timeout itself 2500? I don't like too many things running concurrently :)
<AlbertA> alf_: because if the screen is on...
<AlbertA> alf_: and the dialog shows up, you can let go of the button (so power key up)
<AlbertA> before the 2.5 second alarm goes on
<AlbertA> i.e. in between 2 and 2.5s
<AlbertA> so basically that would turn off the screen
<alf_> AlbertA: ahh, right, and the screen would go off
<groot_> racarr_, mir_demo_server_shell& gives no error. gdb command is available in phone. What command should I run?
<alf_> AlbertA: well, I am OK with the thread if we know that screen_state_handler->set_screen_power_mode() is thread safe
<racarr_> groot_: gdb mir_demo_server_shell
<racarr_> then run
<racarr_> then bt
<alf_> racarr_: @"Is there any generic way to write to GBM bos without using an opengl context", no that I know of
<groot_> racarr_, it's giving "No stack" output.
<alf_> racarr_: do you want to avoid rendering with GL because of the hassle or because there is some problem with it?
<alf_> AlbertA: EOD, so preapproving MP to unblock
<racarr_> alf_: Mostly because of the hassle and in particular the hassle of
<alf_> AlbertA: do what you think is best :)
<racarr_> using opengl outside of the renderer
<AlbertA> alf_: yeah it's thread safe...but I think I will just setup another alarm
<greyback> groot_: just to confirm, you ran "gdb mir_demo_server_shell" and after a brief loading period, ended up at a command line. You entered "run", hit enter, and you should have seen some output about threads, then it stopped with a error? Did you enter "bt" then?
<groot_> racarr_, my bad sorry. Here's the output http://paste.ubuntu.com/7837084/
<groot_> greyback, thanks for pointing out
<racarr_> groot_: Hmm
<racarr_> something with your driver is unhappy ;)
<racarr_> surprise!
<racarr_> kdub_: ^ does that mean anything to you?
<racarr_> the stack trace
<greyback> groot_: good luck with it, you've gone into alien territory for me ;)
<racarr_> the segfault being at 0x0 kind of makes me think its deferencing one of the android device functions...hard to tell without debug info in libmirplatformgraphics
<racarr_> I can't find...our debug symbol packages
<groot_> greyback, don't say that. I've already spent a month trying to port ;)
<greyback> racarr_: http://ddebs.ubuntu.com/pool/main/m/mir/
<greyback> groot_: nah, hopefully these guys can help you. I just know nothing about working with the android drivers
<racarr_> greyback: Thanks :)
<racarr_> groot: If you install the package for libmirplatformgraphics-android from http://ddebs.ubuntu.com/pool/main/m/mir/
<racarr_> that corresponds to the version you see from
<racarr_> apt-cache policy libmirplatformgraphics-android (on the phone)
<racarr_> then repeat the gdb experiment
<racarr_> can get a little more info
<racarr_> android drivers are not my expertise either, but maybe we can at least distill it down in to a bug report with exactly what is going wrong or some such
<groot_> racarr_, thanks. just because you're looking at it gives me hope :). I'll try and let you know after a while.
<racarr_> groot_: Cheers :D
<racarr_> what kind of device is it?
<racarr_> (just curious)
<groot_> Sony Xperia U. First android series from sony ;)
<racarr_> Ah cool :) that shouldnt be too old or anything
<kdub_> groot_, reading through now...
<kdub_> lunchtime is over :)
<groot_> kdub_, thanks :). I'm installing libmirplatformgraphics now
<kdub_> great
<kdub_> so it looks like "bad file descriptor" is thrown from mir
<groot_> yes
<kdub_> it could just be having the mesa platform installed
<kdub_> which I assume you're installing the android one
<racarr_> kdub_: Look at the segfault from mir_demo_server_shell though
<racarr_> http://paste.ubuntu.com/7837084/
<kdub_> hmm, yes, more tricky
<kdub_> was it run as root? sometimes we have to change udev permissions
<groot_> racarr_, here's the output http://paste.ubuntu.com/7837213/
<groot_> kdub_, ^^
<kdub_> well, thats interesting
<groot_> I'll be back in 5 mins. Thanks for looking at it guys :)
<racarr_> I guess it means the hwc_composer_device struct
<racarr_> is bbad
<racarr_> or at leat this callback is
<racarr_> 0x0
<racarr_> or something...lol
<kdub_> racarr_, yeah, thats what I think too.. probably some workaround though
<groot_> I'm back. So, it can be fixed right ? :)
<kdub_> groot_, maybe :D are you able to compile/test patches?
<groot_> kdub_, I'll do anything if you walk me through it :P
<kdub_> groot_, its slightly involved, but basically, if you download lp:mir/0.5
<kdub_> and then run cross-compile-chroot.sh, that should try to cross compile for the device
<racarr_> (bzr branch lp:mir/0.5)
<kdub_> and at that point, we can just cherry-pick a library file and push it to the device (not much abi breakage)
<groot_> downloading right now. my net is very slow today :(
<kdub_> well, the script will go and download a bunch of arm packages and put them in a folder, so not a good day for slow net :)
<groot_> kdub_, is there a way to directly download the source without using bzr ?
<kdub_> not that I know of
<kdub_> and groot_ what's the resolution of the device?
<kdub_> i'll leave a patch for you to try if I'm not around
<kdub_> with my first idea
<groot_> 480 x 854
<kdub_> cool
<racarr_> out for lunch will be back soon though
<groot_> racarr_, yup come soon :p
<groot_> dl speed is now 0 !! :(
<kdub_> groot_, well, my first shot at figuring out what is wrong is here: lp:~kdub/mir/sony-experiment
<kdub_> (just hardcoding some stuff to see if that gets a sane mir environment)
<groot_> kdub_, looks like it'll take a while to download the source :(. Will you be available ?
<kdub_> a few more hours
<groot_> hopefully it'll be complete by then
<groot_> very dirty hack :D
<groot_> kdub_, is this the correct source https://launchpad.net/mir/0.5/0.5.0/+download/mir-0.5.0.tar.bz2
<kdub_> ah, good to know
<groot_> downloaded :)
<groot_> kdub_, what should I do now ?
<kdub_> install the arm cross compiler (g++-4.9-arm-linux-gnueabihf) and try that script (cross-compile-chroot.sh) in the root dir
<groot_> first modify framebuffers.cpp like yours?
<groot_> kdub_, ^^
<kdub_> yeah
<groot_> kdub_, I download this one http://packages.ubuntu.com/utopic/amd64/g++-4.9-arm-linux-gnueabihf/download
<groot_> but got error "dependency problems - leaving unconfigured"
<kdub_> just use apt-get
<groot_> kdub_, E: Couldn't find any package by regex 'g++-4.9-arm-linux-gnueabihf'
<groot_> guess it's not in the source.list
<kdub_> oh, /me is on utopic
<kdub_> you could probably try 4.8 (provided the ubuntu touch image is trusty too)
<groot_> kdub_, I'm using utopic image
<kdub_> the point here :) is that the toolchain version of the host cross compiler should match the version of the phone device image
<groot_> kdub_, it says to add the mirror to sources.list. http://packages.ubuntu.com/utopic/amd64/gcc-4.9-arm-linux-gnueabihf/download
<groot_> Maybe then I can use apt-get
<groot_> I'll try
<kdub_> sounds like a good suggestion
<kdub_> gmock incantations
<groot_> kdub_, still got unmet dependency error :(
<kdub_> groot_, maybe apt-get -f install? otherwise, out of suggestions
<groot_> kdub_, did that, no change. I just started the cross-compile-chroot.sh. I'll let you know what happens
<kdub_> if you dont have the cross compiler, it'll fail
<racarr_> back
<groot_> kdub_, it's retrieving many things from net. How can I check if I've any cross compileer installed?
<groot_> racarr_, welcome back :)
<groot_> kdub_, my desktop has 14.04 but phone's got 14.10. So 4.8 or 4.9 compiler?
<kdub_> 4.9 i suppose
<groot_> kdub_, looks like 4.9 is for 14.10 :(. I'll try with 4.8. What should I expect if all goes smoothly ?
<kdub_> something on the screen if running that demo shell
<groot_> kdub_, I meant after compilation. What files should I push back to phone ?
<kdub_> the other scripts have an enumeration
<groot_> kdub_, sorry, I don't understand.
<kdub_> the deploy-and-test script
<groot_> kdub_, I've to go. Will you be available tommorrow at the same time ?
<kdub_> yep
<groot_> kdub_, then I'll try to compile within this time. Thanks for everything you've done :)
<groot_> I'll check back tommorrow
<kdub_> cool
<groot_> OK, bye.
<AlbertA> ummm, why would an alarm not fire
<AlbertA> when coming out of deep suspend...
<racarr_> uhoh
<AlbertA> so I get the power key down event....which schedules an alarm
<AlbertA> that never fires...but only when out of deep suspend...
<kdub_> (wild guess) hardware timer got suspended?
<racarr_> sorry so its like
<racarr_> you set alarm then
<racarr_> suspend then come back
<racarr_> and alarm doesnt fire, or what?
<AlbertA> you suspend...
<AlbertA> screen goes off
<AlbertA> then you press and hold the power key
<AlbertA> so I get a power key down event
<AlbertA> so it should be out of suspend...
<AlbertA> which then schedules an alarm
<AlbertA> that doesn't trigger
<racarr_> how are you getting power key down events while its suspended
<racarr_> you mean early suspend
<racarr_> ?
<AlbertA> kernel
<AlbertA> usually hooks up the power key
<AlbertA> to wake it up
<AlbertA> and take it out of suspend
<racarr_> oh ok lol
<racarr_> hmm
<AlbertA> maybe an early resume issue
<AlbertA> like kdub_ said...maybe the hw timers are not brought up yet
<AlbertA> also something else is waking the screen up before USC actually does
<racarr_> hw timers not up yet is weird youd think]
<racarr_> someone could give you an error
<racarr_> my only other guess is maybe some funny signals flying around that mess things up...
<racarr_> ...cant think of anything specific
<racarr_> hmm
<AlbertA> so apparently it is an early resume thing....
<AlbertA> if I wait for powerd to broadcast that it's completely out of suspend before scheduling the alarms...then the alarms fire just fine
<racarr_> AlbertA: Very weird...wonder what the rules are
<AlbertA> nevermind...it wasn't going to deep suspend that time
<AlbertA> so alarm still doesn't fire...weird...
<AlbertA> oooh....
<AlbertA> why do I get
<AlbertA> a power key down and up at the same time?
<AlbertA> after coming out of suspend
<AlbertA> that's what was cancelling my alarm...
<AlbertA> don't know what to do about it though...
<racarr_> AlbertA: maybe its the power key up from before
<racarr_> you suspend?
<racarr_> I guess
<racarr_> you suspend on up
<racarr_> nvm
<AlbertA> right it suspends after power key up is received
<AlbertA> umm I don't remember this happening with powerd... which used a more recent version of the android input stack...
<racarr_> anyone want any reviews or anything before I end my core day?
<racarr_> the active reviewsd is actually kind of benign right now wow
<RAOF> :)
#ubuntu-mir 2014-07-23
<RAOF> Hm. I really need to fix keymapping before using the unity8 desktop session :)
<Sarvatt> RAOF: you and your dvorak..
<RAOF> :P
<RAOF> Bah.
<RAOF> C++, why you no map (list)?
<duflu> RAOF: Wha/
<duflu> ?
<RAOF> duflu: I want to iterate over the result of applying a function elementwise to an existing iterator.
<RAOF> Without constructing an unnecessary container.
<RAOF> This would typically be called âmapâ
<RAOF> Or possibly âapplyâ
<duflu> RAOF: Temporary results in a loop you don't wish to modify to accept  an apply functor?
 * duflu feels dirty for knowing what that means
<RAOF> I'd like to construct a list of SharedLibraries from a directory iterator
<RAOF> Now, I can do this by iterating over the directory, constructing the SharedLibrary, and shoving it into the list.
<RAOF> But I'd *prefer* to just pass an iterator to the list constructor.
<duflu> RAOF: I think most real-world problems involve picking and choosing from lists, and not a blind 1:1 mapping. As such, there's little re-use value in C++ providing that for you.
<duflu> Besides, C++ is already massive in spec
<RAOF> Well, that's very simple
<RAOF> map(filter(thing, predicate), functor) :)
<RAOF> Basically I wish iterators were substantially more powerful, because it's really awesome to be able to operate on them.
<duflu> I wish iterators had a common base class and weren't a pure pattern
<mzanetti> hey, anyone aware of efforts to make freeglut run on mir? I think its just the input part that uses XInput. The rest seems to be ok already.
 * mzanetti was trying to compile VoltAir on the phone
<duflu> mzanetti: I remember the simplicity of GLUT fondly. Would be nice but not aware of any efforts
<mzanetti> mhm...
<RAOF> duflu: _Yes_
<RAOF> alan_g: No, my blocking comments weren't addressed. On the other hand,  https://code.launchpad.net/~raof/mir/fix-unnecessary-virtual-package/+merge/227862 is simple and resolves them :)
<alan_g> RAOF: sorry. I got the incantation I used from both fginther and sil2100 so I let the majority rule.
<RAOF> alan_g: Yeah, that's totally reasonable.
<RAOF> I clearly need to poke sil2100 and fginther with a cluebat :)
<alan_g> RAOF: the more I get to understand the debian/control file the more I feel we've got wrong. Is that normal?
<RAOF> Not normal, no.
<RAOF> Hm. Now that I look at it...
 * alan_g goes to look at a problem he does understand
<RAOF> Excellent plan!
 * RAOF â dinner
<greyback> anpok: hey just checking in, any progress with https://bugs.launchpad.net/mir/+bug/1346952
<ubot5> Launchpad bug 1346952 in Mir 0.5 "[qtcomp] Random crash in Mir input when running AP tests: [terminate called after throwing an instance of '...' what(): assign: File exists] when constructing a mir::AsioMainLoop::FDHandler" [Critical,New]
<kdub_> hey folks
<Saviq> alan_g|lunch, hey, I'll join you for the interview with Jawad, sit in on your part and then do mine when you'll be relieved ;)
<anpok> greyback|lunch: debugging it - so yes reproducing the issue..
<alan_g|lunch> Saviq: ack
<racarr_> Good morning!
<groot_> racarr_, evening :)
<groot_> I need some help compiling mir
<racarr_> groot_: ok! Lets give it a go! What are you trying so far?
<groot_> racarr_, I'm trying to follow the cross-compile section of this http://unity.ubuntu.com/mir/building_source_for_android.html
<groot_> just changed saucy to utopic
<groot_> also downloaded mir tarball from here http://bazaar.launchpad.net/~mir-team/mir/0.5/revision/1792?start_revid=1792
<groot_> hope it's ok. I'm now confused with cross-compiler. Shoul I try install g++-arm-linux-gnueabihf/utopic ?
<racarr_> Is your desktop trusty?
<racarr_> I'm not 100% sure you can crosscompile from trusty to utopic
<racarr_> kdub_: ^?
<groot_> unfortunately yes
<racarr_> hmm
<kdub_> doesn't work as well as you'd like it to sometimes
<racarr_> I dunno maybe someone will say they have dsone it and it works but my guess i\s no...I didn't think you could install the utopic G++
<racarr_> groot_: If you don't want to upgrade your system...probably building on the phone itself is your best option
<groot_> racarr_, wouldn't that take more time ? Also how can I compile in phone (native compile?)? Cross-compile seemed easier.
<groot_> kdub_, how can I compile now? I want to test your fix :)
<kdub_> its more of an experiment
<kdub_> but native on-the-phone compile is slow, but you don't have to set up cross compiling
<racarr_> groot_: rCompile in phone../.isn't the fastest lol
<racarr_> from the phone, you first have to apt-get build-dep mir
<racarr_> then you just get the mir build directory and build it like normal
<racarr_> mkdir build; cd build; cmake .. -DMIR_PLATFORM=android;
<racarr_> make
<racarr_> oh
<racarr_> standup
<groot_> racarr_, I don't have net connection in phone :(
<greyback> racarr_: question on Mir's client buffer queue scheme: say client is starting up and Mir allocates it 3 buffers. Client draws its first frame and swaps. Does the compositor render that frame, or the 2 other yet-to-be-drawn-into frames have to be rendered first
<racarr_> greyback: The compositor should render that frame I think
<racarr_> the only requirement is that there is always a buffer available for the compositor
<racarr_> groot_: Hmm presumably we can get it for you with
<racarr_> adb or something
<greyback> racarr_: ok ta
<groot_> racarr_, I'll do it. Give me the commands serially :D
<racarr_> groot_: I am just thinking...there is no obvious waya (to me) gimme just a minute...I need to listen to some other stuff too lol
<groot_> racarr_, no problem. Take your time.
<racarr_> groot_: I dont really know...there must be some trick to get USB networking working
<racarr_> but I dont know it or the magic incantation to reveal it on google :p
<racarr_> so I can't really suggest anything better than downloading the deps and copying them over to phone...
<racarr_> you need a net connection lol
<racarr_> No wifi? :(
<anpok> galf_: how did you switch to 4.9 with arm-linux-gnueabihi-g++
<anpok> alf_: ^ :)
<alf_> anpok: added '-4.9' to cmake/LinuxCrossCompile.cmake
<anpok> ah :)
<groot_> racarr_, ohh :(. I don't know whether wifi is running or not. Is there a way I can access it through terminal ? I use router in my house so connecting will not be a probelm.
<racarr_> groot_: if you run phablet-network on the host system it will copy over your
<racarr_> wifi config to desktop
<racarr_> if you are using that
<racarr_> if not...you will have to use wpa_supplicant or some such to connect to wifi via terminal
<AlbertA> greyback: right it will draw that latest ready frame
<racarr_> connecting to wifi on desktop then using
<racarr_> phablet-network sounds easiest
<greyback> AlbertA: thanks for confirming
<AlbertA> greyback: it will not wait to fill the queue
<groot_> racarr_, I'll try now and let you know.
<racarr_> groot_: :)
<racarr_> lol....46 files modified for touchspots
<racarr_> that...
<racarr_> doesn't seem quite right
<groot_> racarr_, I don't use wifi in my desktop, desktop has broadband connection which is connected through router. So, there'll be config, right ?
<racarr_> groot_: Yeah...
<racarr_> you will have to google like...connecting wifi terminal, sort of stuff :p I don't remember the exact options, etc
<racarr_> if you have wifi encryption you will need to use
<racarr_> wpa_supplicant
<racarr_> its pretty easy
<tvoss> groot_, you want nmcli
<racarr_> oh that sounds true :p
<groot_> tvoss, how to use it ?
<tvoss> nmcli --help gives you an overview
<tvoss> groot_, should be something nmcli device wifi connect WIFI_NAME
<tedg> dednick, When I pass the FD to the helper I set MIR_SOCKET to "fd://%d", right?
<groot_> tvoss, alright I'll give it a try.
<tvoss> tedg, yup
<tedg> tvoss, Hmm, okay.
<tedg> Is there a way to get QtUbuntu to give more info than this: QUbuntu: Could not create application instance
<groot_> tvoss, connected to wifi, but speed is slow :)
<groot_> racarr_, how to compile mir? please give me the commands serially :)
<dednick> tedg: passing to the trust helper? or the prompt provider?
<tvoss> groot_, I cannot help with the speed
<tvoss> groot_, in the mir root directory, call dpkg-buildpackage
<tvoss> groot_, that likely will fail with a list of missing build dependencies that you have to install
<dednick> tedg: you need to pass the trusted socket to the helper, and the new_fd_for_prompt_provider sockets to the providers.
<tedg> dednick, Yes, to the prompt provider.
<tedg> dednick, So passing that socket to the provider as "fd://%d"
<dednick> tedg: yup
<groot_> tvoss, where's the mir directory? It's not in the root directory.
<tvoss> groot_, you have to branch mir by calling bzr branch lp:mir
<groot_> tvoss, I've the files in pc.  Push them will do ?
<racarr_> yeah
<racarr_> groot_: ^
<racarr_> then; cd <into-the-mir-source-directory>; mkdir build; cd build; cmake .. -DMIR_PLATFORM=android; make
<racarr_> wait patiently
<racarr_> :)
<tedg> dednick, Good, know any reason that QtUbuntu couldn't create an application instance then?
<groot_> racarr_, alright :)
<groot_> racarr_, this error happened http://paste.ubuntu.com/7842738/
<dednick> tedg: check unity8 logs?
<dednick> anything saying rejected?
<dednick> tedg: did you start the trust helper with trusted socket?
<tedg> No, it's not saying rejected.
<tedg> Think I must have the wrong number.
<groot_> racarr_, I think I've to install 14.10 on desktop :P
<racarr_> groot_: It looks like you forgot the apt-get build-dep mir part
<groot_> racarr_, you're right!!! I forgot you mentioned that. I'll give this another go.
<racarr_> brb in ~20
<groot_> racarr_, still got error " You must put some 'source' URIs in your sources.list". List doesn't contain the package
<racarr_> groot_: apt-get update
<racarr_> should take care of it
<groot_> racarr_, OK, I'll try again tomorrow. I've to go now. I'm not gonna give up :). Thanks for helping me.
<AlbertA> camako: kgunn: so there's a bug that already has a fix on devel...
<AlbertA> https://bugs.launchpad.net/mir/+bug/1347789
<ubot5> Launchpad bug 1347789 in mir (Ubuntu) "Crash in USC during mir::compositor::BufferQueue::BufferQueue::operator()" [Undecided,Confirmed]
<AlbertA> camako: kgunn: should that be backported to the 0.5 series?
<kgunn> AlbertA: yep...we will need thta
<kgunn> that
<kdub_> here's a fun one
<kdub_> https://bugs.launchpad.net/mir/+bug/1347828
<ubot5> Launchpad bug 1347828 in Mir "glmark2 [desktop] effect=shadow:windows=4 failure on mx3" [Undecided,New]
<racarr_> kdub_: For me that doesn't even qualify as a fun in the sense of like this is a nice hairy one bug
<racarr_> and more of just a "off to the crying closet"
<racarr_> type bug
<racarr_> failed acquire CCB space
<racarr_> lol
<racarr_> lol
<racarr_> not to mention ScheduleTA "didnt work properly"
<kdub_> yes, very informative :)
<racarr_> E/IMGSRV ( 3519): :0: KEGL_SGXDestroyRenderSurface: Timeout failed on waiting for previous render op
<racarr_> is kind of interesting
<racarr_> kdub_: Perhaps it has something to do with fences
<racarr_> i.e. like
<racarr_> surface is being destroyed
<racarr_> before the actual rendering of the last frame
<racarr_> finishes
<racarr_> E/IMGSRV ( 3519): :0: FreePDSFragBuffers: PDS fragment buffer for render surface still in useE/IMGSRV ( 3519): :0: FreePDSFragBuffers: PDS fragment buffer for render surface still in use
<kdub_> something, im' thinking some resource problem perhaps around contexts
<kdub_> but we'll just see
<racarr_> :)
<racarr_> good luck :D
<AlbertA> aahhh the good old KickTA...
<racarr_> :( I want to write...
<racarr_> constexpr size_t size = someMirGeometrySizeWidth*height*MIR_BYTES_PER_PIXEL(pixel_format)
<racarr_> (where the geometry and pxiel format are constant as well)
<racarr_> so that I can then write uint32_t pixels[pixel_size] {} and use automatic storage so that {} can be used to initialize the whole thing to black
<racarr_> I mean...lol it's purely a matter of conveniencee
<racarr_> but unfortunately can not use
<racarr_> IntWrapper with
<racarr_> constexpr
<racarr_> because it's not a http://en.cppreference.com/w/cpp/concept/LiteralType
<racarr_> oh maybe it coudl be though
<racarr_> I don't really understand the deep details of constexpr lol
<racarr_> lunnnch
<josharenson> random question, does/will mir support SDL?
<racarr_> josharenson: Yes!
<josharenson> woo hoo!
<racarr_> courtesy of bschaefer
<racarr_> who can help with issues and such im sure.
<racarr_> 95% sure it's SDL2 only
<racarr_> whatcha up to?
<josharenson> thanks, no issues, just wondering if I'll be able to play old games
<bschaefer> josharenson, you wont be able to play SDL 1.2 atm (until some layer gets put into place)
<bschaefer> josharenson, but anything for SDL2 will work with mir!
<josharenson>  bschaefer thats awesome, thanks
<bschaefer> (if you really want to mess with SDL1.2 + mir you'll need this branch: https://code.launchpad.net/~brandontschaefer/+junk/sdl1.2-mir)
<bschaefer> they aren't accepting patches for 1.2 soo yeah
<bschaefer> josharenson, np!
<racarr_> kdub: How should I implement mga::Buffer::write(void*,size_t)
<racarr_> I'm open to the idea that I shouldn't
<racarr_> lol
<racarr_> I just can't remember which android thing has which
<racarr_> for the touchspots, which end up being kind of like single buffered software clients
<racarr_>  / cursor
<racarr_> oh I see. gralloc_module_t :)
<kdub_> racarr_, I guess I'd want to avoid it
<anpok> is there a way to verify expectations added to a mock at the end of a scope?
<anpok> rather let the test fail unless expectations are met..
<kdub_> racarr_, you mean like mg::Buffer::write()?
<kdub_> anpok, you can verify explicitly
<kdub_> like Mock::VerifyAndClearExpectations()
<racarr_> kdub_: Yeah
<racarr_> to upload cursor images in to the buffer
<kdub_> racarr_, the pain there is all the pixel formats
<kdub_> so like, on the client side, we have a way to map it and return the address, but spare the client side buffer the pain of regulating all the pixel format stuff
<kdub_> like, the intention is to?
<anpok> kdub_: hmm it never fails
<racarr_> I guess I should look at how the client side works on android
<kdub> racarr_, like, whats the outer loop? to write to a cursor on the server side?
<racarr_> the outer loop?
<kdub> like, the larger picture of what having Buffer::write would accomplish
<racarr_> oh yes
<racarr_> to write to a cursor on server side.
<racarr_> write seems like a good choice because 1. they are always small buffers. 2. on mesa you can't even create GL contexts from the cursor buffer.
<kdub> ah
<kdub> so, its probably a little easier to structure like
<kdub> the platform has some writer object
<racarr_> I thought about that for a bit but coudln't think of
<racarr_> alternate implementations, is it easier?
<kdub> yeah, just because iirc, the mga::Buffer doesn't have access to the gralloc mapping stuff anymore
<kdub> whereas the platform could just keep the gralloc as a singleton
<kdub> or... even I guess that there could be a mg::Buffer::write(std::vector<Pixels>const&) and android could do a gl draw under the hood? (and mesa would just do the memcpy)
<robotfuel> kgunn:  do you know a good person I can ask to triage this unity8 crash? https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1347886
<ubot5> Launchpad bug 1347886 in unity8 (Ubuntu) "/usr/bin/unity8:6:__assert_fail_base:__GI___assert_fail:operator:std::_Function_handler:operator" [Undecided,New]
<kdub> racarr_, I guess I'm not feeling strongly that one is better than the other :)
<kdub> other than it probably has to be behind the platform abstraction, and we should have stronger types than void* for the pixels we want to use
 * kdub dreams of bool mir::PixelFormat::ABGR8888::premultiplied()
<kgunn> robotfuel: i'd like alf_ to take a look at that tomorrow....
<kgunn> it looks like it might be mir related
<kgunn> robotfuel: do you know which image that is/was ?
<robotfuel> kgunn: yesterday's proposed image
<kgunn> robotfuel: ok so something like ~143
<kgunn> robotfuel: any chance we understand/know what the device was doing ? or was this just random monkey ?
<robotfuel> kgunn: version_detail: ubuntu=20140722.1,device=20140717.1,version=144
<robotfuel> kgunn: it was the random monkey :/
<kdub> kgunn, robotfuel what about https://code.launchpad.net/~mir-team/mir/fix-1335481-0.5/+merge/227497 ?
<kdub> seems somewhat in the same ballpark
<robotfuel> kdub: it looks very close +1
<racarr_> kdub: sorry lol...alt tabbed and then....distraction
<robotfuel> kdub: I've added that to the bug, thanks
<racarr_> yeah I was thinking maybe android could do the GL draw under the hood....its probably easiest to use some sort of writing thing I guess though...with the android platform
<racarr_> and yeah....there are enough instances of void *pixels now
<racarr_> ill start looking in to something better lol
<racarr_> Hahahahahaha
<racarr_> I just tested the touchspots on the phone in
<racarr_> demo server shell
<racarr_> and they have
<racarr_> window decorations
<racarr_> forgot about that
<racarr_> hmm what am I going to do there
<robotfuel> kgunn: it looks like this one is also a mir issue https://bugs.launchpad.net/ubuntu/+source/+bug/1347901
<ubot5> Launchpad bug 1347901 in ubuntu-system-settings (Ubuntu) "/usr/bin/system-settings:6:__gnu_cxx::__verbose_terminate_handler:__cxxabiv1::__terminate:std::terminate:__cxxabiv1::__cxa_throw:boost::throw_exception" [Undecided,New]
<kgunn> robotfuel: ah crap i can't see it...
<kgunn> robotfuel: is there something i can do to see these bugs by default
 * kgunn vaguely remembers mail from duflu
<robotfuel> kgunn: my copy paste glitched https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings/+bug/1347901
<ubot5> Launchpad bug 1347901 in ubuntu-system-settings (Ubuntu) "/usr/bin/system-settings:6:__gnu_cxx::__verbose_terminate_handler:__cxxabiv1::__terminate:std::terminate:__cxxabiv1::__cxa_throw:boost::throw_exception" [Undecided,New]
<robotfuel> that should work
<robotfuel> kgunn: "void mir::client::rpc::MirSocketRpcChannel::send_message(const mir::protobuf::wire::Invocation&, const mir::protobuf::wire::Invocation&)" is what I see in the trace
<robotfuel> it doesn't look like it was able to complete the whole stack trace :/
<kgunn> robotfuel: following the link, looks there may be enough tho... kdub that one looks like its eminating from android platform possibly ??
<kdub> kgunn, I was looking at https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1347886
<ubot5> Launchpad bug 1347886 in unity8 (Ubuntu) "/usr/bin/unity8:6:__assert_fail_base:__GI___assert_fail:operator:std::_Function_handler:operator" [Critical,Confirmed]
<kdub> and this one https://errors.ubuntu.com/problem/3f606cde0c8ce2787f2a2ae3ed4b1a73738d975e
<kdub> the stack passes through the android code, but it looks like it throws somewhere around the ipc stuff, I'd say that looks like a different one
<kdub> oh, actually, i guess if the server was asserting and failing
<kdub> then maybe the client is just saying "wheres my server" in that stack trace
<tedg> kgunn, Silo 6 with the QtComp doesn't seem to start for me. Does it need to be rebuilt after the gcc build?
<kgunn> tedg: make sure you install ubuntu-touch
<kgunn> also add proposed to your sources list
<kgunn> tedg: i put a note at the top of the wiki....its been frustrating a lot of folks
<kgunn> https://wiki.ubuntu.com/Unity8/QtComp
<kgunn> i updated the instructions
<kgunn> silo 8 is gumming up the works
<tedg> Ah, k
<racarr_> ok touchspots are 95% done except the fact that they receive
<racarr_> window decoprations
<racarr_> going outside for a little bit (been at desk since 7 lol...ordered lunch in)
<racarr_> then will be back to work on that
<racarr_> back
<racarr_> thomi: Are touchspots black on orange or purple on orange or black on purple or black or
<racarr_> red on yellow
<racarr_> :p
<thomi> racarr_: huh?
<thomi> bzr diff
<thomi> oops
<racarr_> I mean has anyone already
<racarr_> picked the colors
<thomi> nope
<thomi> something bright I guess
<racarr_> ok
<racarr_> ubuntu orange + black outline
<thomi> sounds good to me
<thomi> that'll match those fancy videos the design team produce :)
#ubuntu-mir 2014-07-24
<racarr_> ...has anyone ever felt the desire to lay out code horizontally
<racarr_> I have this big stub class...and for a second I was imagining laying out all the functions in a grid
<racarr_> then remembered how code works lol
<RAOF> Hah
<racarr_> it would be nice though
<racarr_> lol
<racarr_> in other news mi::InputTargets -> mi::Scene
<RAOF> It might be nice to code as the AST. There's no particular reason that a big string of text should be the canonical representation for the program.
<racarr_> lol...one day im not going to be able to use emacs anymore :(
<duflu> racarr_: Only a few days ago I was commenting on that. At some point in the past decade or so a trend of horizontal coding (long identifiers, long lines) started to become quite visible in some circles like ours.
<duflu> Previously people read code vertically, the most obvious origin being assembly
<duflu> I say in some circles because other projects like the kernel, vertical structure dominates and 80 character lines are still enforced
 * duflu recalls the most extreme case in Compiz where Sam wrote several functions whose names exceeded 80, even 100 characters
<duflu> RAOF: Come to think of it, yes there is a reason for code to be linear. It reduces the ease with which you can create spaghetti
<duflu> P.S. Go rest
<racarr_> duflu: Lol. I don't just mean...long lines though
<racarr_> I mean like what if you could have two functions next to eachother
<duflu> racarr_: Yeah OK. Like windows without windows
<racarr_> yeah
<racarr_> window management
<racarr_> for source code
<racarr_> lol
 * duflu 's head explodes
<duflu> Whee, ssh works again on phablets. Life just got easier
<RAOF> Man there's a *lot* of faffing involved in adding logging to our stuff.
<RAOF> Which would be why we have abysmal logging.
<duflu> RAOF: I've counted 3 logging systems in Mir recently
<duflu> :)
<RAOF> Oh, really?
<RAOF> But mostly contained to 3rd_party, right?
 * duflu checks
<RAOF> We've got the *_report thing for our own code. I can't think of a separate logging mechanism in pure-mir code.
<RAOF> The android code has some different logging.
<racarr_> I agree on the report interfaces
<racarr_> and I think thats
<racarr_> err, not sure how to phrase it.. it's quite late
<racarr_> but when we discussed lttng in malta
<racarr_> I mean lttng isnt an alternative implementation of logging right
<racarr_> and its not useful as such
<racarr_> you want the probes in different sort of points
<racarr_> rather than trying to use it as a low overhead printf
<racarr_> so
<racarr_> one of the main drives of using reporting interfaces is gone there.
<racarr_> and then I think...well...if some logging really is REQUIRED
<racarr_> perhaps it can be in a reporting interface and tested lol
<racarr_> but I love logs
<racarr_> I love logs
<racarr_> so much
<racarr_> I love logs of everything
<duflu> (1) Android ALOGx() macros which call (2) mir::write_to_log() which is a stub; and (3) The cleaner logging in src/shared/logging used in reports
<racarr_> so I would rather have lots of adhoc logging
<duflu> I think everything should funnel back to (3)
<racarr_> than tested reports :p
<duflu> racarr_: I mean we should merge the underlying log function of them all
<duflu> ... er both.,
<RAOF> I don't mind everything going through reports, but if that's what we want, then we need (a) lots more reports, (b) lots more functions in the reports, and (c) for the output of those reports to go somewhere by default.
<RAOF> We should, by default, log on the order of 500 lines for standard start up.
<duflu> The Report pattern is nice (yes I think so now) because you can do expensive reporting that's disabled by default
<racarr_> duflu: That too :p
<duflu> That's different to always-on log messages
<racarr_> that could be
<duflu> Both are good
<racarr_> log domains...
<racarr_> i.e. the cateogires could be prefined
<racarr_> I think its more pain than its worth to have a method on a report interface for each kind of method
<racarr_> I mean not only is it a pain but its often useful to log implementation details of classes
<duflu> I like include/shared/mir/logging/logger.h more than the others, but it can all be improved
<racarr_> which may not line up with some sort of generic report...
<racarr_> lalala
<duflu> I think "Logger" is a bad abstraction. It should be a "Log" interface to which you "write"
<duflu> #define MIR_LOGGING_LOGGER_H_ http://www.youtube.com/watch?v=mL7n5mEmXJo
<RAOF> To the mailing list? :)
<duflu> RAOF: Sure. Happy to see some unification. So long as we keep the nice timestamps and formatting of the src/shared logger
<RAOF> Oh, we'd totally do that.
<duflu> Which I recall I copied from Xorg to some extent
<duflu> Or the kernel?
<duflu> RAOF: Erm, actually just assign mir::write_to_log = &my_new_function_that_writes_to_Logger
<duflu> And then they're unified :)
<RAOF> I think both, actually.
<RAOF> IIRC Xorg copied that logger from the kernel :)
<alf_> alan_g: Hi! @fix-libmircommon, What was the problem with the MIR_COMMON_LIBRARIES approach?
<alan_g> alf_: try doing "nm  libmircommon.so" ;)
<alf_> alan_g: That's quite unexpected... What's the rationale behind cmake not linking in the static libraries into the shared library?
<alan_g> I don't know. If you *just* force them all to be linked then the android-input archive causes problem.
<alan_g> Having discovered that I decided there wasn't much point to the individual archives
<duflu> alan_g: The subordinate modules of mircommon should be "add_library(foo OBJECT ...)" so they don't produce archives and are guaranteed to be fully included in the final shared library
<duflu> It would be quite nice to not have those *.a lingering in the lib/ directory
<duflu> alan_g: I might do that this evening if you're not
<alan_g> duflu: that's a cmake incantation I've no come across. Is there an example of how to use it?
<duflu> alan_g: It's newish: http://www.cmake.org/cmake/help/v2.8.12/cmake.html#command:add_library
<duflu> Designed for making bundles of objects to put into some other library later
<duflu> And without needing fancy linker flags to force inclusion of all symbols
<alan_g> Yeah, that felt ugly
<duflu> Well, it was right for the functionality we had before
<duflu> But CMake has improved on it
<groot_> racarr_, I've installed 14.10 on desktop :). If you're available, can you tell me what packages should I install to compile mir ?
<alan_g> groot_: look in the doc directory for building_source_for_pc.md it has the incantations you need
<groot_> alan_g, I'm building for android. So I checked build_source_for_android.md and installed the dependencies from root directory of mir.
<groot_> how to build now? It says to pass config to cmake
<groot_> in the doc
<alan_g> groot_: you're intending to cross compile?
<groot_> alan_g, yes.
<alan_g> groot_: does "sudo apt-get download gcc:armhf" work?
<groot_> alan_g, I think so. It outputs "Fetched 5,300 B in 1s (4,861 B/s) "
<alan_g> So you should be good to go with ./cross-compile-chroot.sh
<groot_> alan_g, all right. I'll let you know what happens.
<duflu> Whee... input lag of 3ms!
<duflu> More tweaking
<duflu> (compared to the current 13)
<alan_g> duflu: sounds worthwhile
<duflu> alan_g: Yes, it's the difference between meeting and missing the frame deadline
<alan_g> duflu: FWIW add_library(... OBJECT helps simplify things. Good suggestion - thanks
<duflu> alan_g: Glad to help
<greyback> anpok_: running tests suites with qtomp+your mir patch, everything seems to be working great!
<greyback> thank you for delving into that
<tedg> So, looking for a good way to debug a Mir connection.
<tedg> Getting the error from QtUbuntu that it can't create an application, but doesn't say why.
<tedg> Why can't I know why?
<kdub> we've been meaning to remove mir::Secrets for a while now...
<anpok> but people havent complained enough yet
<tedg> The Illuminati keep rejecting the MR?
<kdub> tedg, but --session-mediator-report might help
<ogra_> no more secrets !!!
<alan_g> tedg: does --connector-report log (on server command line) help?
<kdub> also --msg-processor-report might help
<tedg> Which command lines are those? The unity8 one?
<alan_g> Or  MIR_CLIENT_RPC_REPORT=log in the client environment
<kdub> tedg, probably easiest to use an environment variable
<kdub> right, like alan_g suggests :)
<tedg> K, cool. I'll do that and see what I get. I can add the env var easily.
<alan_g> A.k.a. MIR_SERVER_CONNECTOR_REPORT=log (in server environment) help?
<tedg> Hmm, adding MIR_CLIENT_RPC_REPORT didn't seem to print anything. Is it a stdout thing or should the log be somewhere?
<kdub> that should work on the client side, and it should go whereever stdout would go
<tedg> Hmm, okay. /me checks for typos
<tedg> Going to grab an strace to see if there's information there.
<anpok> alf_, alan_g: could you have a look at https://code.launchpad.net/~andreas-pokorny/mir/fix-1346952/+merge/227993
<alan_g> anpok: sure - after a cup of tea
<alan_g> camako: This should stop the test CI jobs installing mir-doc and a load of -dev package: https://code.launchpad.net/~alan-griffiths/mir/fix-1297100/+merge/228123 (I wonder how long that has been taking)
 * camako checks
<camako> alan_g, ack... So the CI team doesn't have to do anything...
<alan_g> camako: I just want some timestamps
<camako> alan_g, isn't this about installation, though? How does it affect build?
<camako> alan_g, https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1322202
<ubot5> Launchpad bug 1322202 in Ubuntu CI Services "Jenkins logs need timestamps" [Undecided,New]
<camako> alan_g, feel free to put your thoughts in there
<anpok> alf_, AlbertA: just updated..
<alan_g> camako: if you look at the test runner (e.g. http://s-jenkins.ubuntu-ci:8080/job/mir-mediumtests-runner-mako/) you'll see it installs the test packages using dpkg
<tedg> So it looks like what happening is that someone is setting up an epoll. And adding FDs to it.
<tedg> When it gets to the FD that is the Mir socket, epollctrl fails with EBADF.
<tedg> epoll_ctl
<alan_g> tedg: how are you passing the FD to the process? (The actual FD not the fd number in the parent process)
<tedg> alan_g, Via a dbus message
<alan_g> tedg: can you check the FD is valid at the point of receiving that message?
 * alan_g tries to remember a suitable incantation...fails
<tedg> alan_g, In theory, what's the best way to do that?
<alan_g> racarr_: you once gave me an incantation to check a FD. ^
<alan_g> tedg: try fcntl(fd, F_GETFD) - it shouldn't set errno if the FD's OK
<tedg> K
<anpok> alf_: bbiab, would be cool if I get your opinion before you eod
<racarr_> I think it was fcntl F_GETFD yes.
<racarr_> oh wow almost 10 already...
<groot_> hello
<groot_> racarr_, after many hours of downloading, compilation failed with some error.
<groot_> can you take a look please http://paste.ubuntu.com/7848515/
<racarr_> oh no
<racarr_> groot_: Hehe lookslike kdub made a typo in his little hack for you
<racarr_> if you do to that file src/platform/graphics/android/framebuffers.cpp
<racarr_> around l74, find that function and just
<racarr_> in the first line add
<racarr_> (void) hwc_device;
<racarr_> it should build
<racarr_> its just a warning about an unused variable :)
<groot_> racarr_: you mean in here, std::pair<geom::Size, double> determine_hwc11_size_and_rate(     std::shared_ptr<hwc_composer_device_1> const&    (void)       hwc_device)
<racarr_> groot_: No leave the declaration alone
<racarr_> groot_: I mean in the body of the funcftion
<racarr_> after { :)
<racarr_> and you need the ;
<groot_> racarr_: the body has only return statement "return {{480,854}, 60.0f};"
<racarr_> groot_: Yes so add a line before the return line
<racarr_> (void) hwc_device;
<racarr_> its just a no-op statement that lets the compiler know you are using the variable
<racarr_> normally this function queries the size from the hwc device, but kdubs little workaround hardcoded the size for your device
<racarr_> leaving the hwc_device variable unused, ala compile error because we have pedantic warnings
<racarr_> :)
<groot_> racarr_, ohh alright, trying again now :)
<racarr_> :D
<tedg> Well, on the plus side that didn't return an error. On the negative side, I still don't know why.
<alan_g> tedg: At least you know the problem comes after that. ;)
<alan_g> can you print the FD at that point and the connection string you're passing to Mir?
<kdub> groot_, you could also bzr pull from the branch, corrected the problem yesterday
<tedg> Yeah, I am doing that. It's 8, and fd://8
<tedg> Wonder if it's getting a close on exec set.
<groot_> kdub, I'm no good with c++ :P
<alan_g> tedg: presumably the exec happens before the dbuss call?
<tedg> alan_g, Well, there's a chain of execs :-) But there is one between the dbus call and the exec to the process that is connecting to Mir.
<alan_g> tedg: so the intention is for the process that connects to Mir to inherit the FD from its parent?
<tedg> Correct
<tedg> Hmm, that did a bunch more.
<tedg> Woot! I think that was definitely a step in the right direction.
<alan_g> OK I understood your original response to mean that it got if from dbus
<alan_g> *it
<tedg> alan_g, I have a "mir-connection-demangler" that gets it from dbus, and then it calls the app that is the prompt-handler.
<alan_g> So can you check the FD at the top of main()?
<tedg> Yeah, so it seems that it was set to close on exec. Seems gdbus did that for me.
 * alan_g goes while there's some little success happening
<tedg> Heh
<tedg> Thanks for your help alan_g|EOD
<alan_g|EOD> ;)
<groot_> racarr_, yay build completed :D. Now I should connect my phone and when it gets stuck at boot, I run deploy-and-test.sh ?
<racarr_> Err did you end up building on desktop
<racarr_> or phone? I thought you were bnuilding on phone
<groot_> nope, installed 14.10 on desktop today :)
<racarr_> ah
<racarr_> sounds right then!
<racarr_> you may ened to
<racarr_> after it gets stuck
<racarr_> adb shell
<racarr_> in and run
<racarr_> "stop lightdm"
<racarr_> oh I guess it crashed already and thats your problem
<racarr_> so probably not :p
<racarr_> once you've done that (will be interesting to see if tests run)
<racarr_> the next thing is to copy build-android-arm/bin/mir_demo_server_shell over to the device
<racarr_> and see if we can run that
<groot_> racarr_, I see that deploy-and-test.sh has lines to push all the binaries to the phone. So just running it will do the all the work ?
<racarr_> Yep
<racarr_> oh I newver realized it copies the demo servers too :)
<racarr_> brb lunch
<groot_> racarr_, you still here ?
<groot_> kdub: I ran the tests, some of them failed. Can you please take a look http://paste.ubuntu.com/7848753/
<kdub> okay, the unit tests passed
<dandrader_> kdub, AlbertA can we get this one top-approved?
<dandrader_> https://code.launchpad.net/~andreas-pokorny/mir/fix-1346952/+merge/227993 ^
<dandrader_> it's has already 2 approvals :)
<kdub> its okay by me
<dandrader_> kdub, then can you do it? what's the process?
<kdub> oh sure
<dandrader_> kdub, thanks!
<kdub> you just top approve it, and jenkins picks it up, rejects it, top approve again, and then its in
<kdub> ;)
<greyback> can someone also look at https://code.launchpad.net/~andreas-pokorny/mir/fix-1346952-0.5/+merge/228098
<greyback> it's just the backport of that patch
 * kdub doesn't know the rules around the backport process
<dandrader_> greyback, just backport the approvals :)
<groot_> kdub, so what to do now ? Also, some of the test failed, is that ok ?
<groot_> specially the test that reported my display size is 180, 1010101
<kdub> groot_, just stub test values
<kdub> groot_, does the mir_demo_standalone_render_to_fb work?
<racarr_> back
<groot_> kdub, I rebooted the device. I'll try and let you know.
<groot_> kdub, mir_demo_standalone_render_to_fb failed with "Segmentation fault (core dumped)"
<racarr_> backtrace?
<groot_> racarr_, here http://paste.ubuntu.com/7848940/
<kdub> so, the driver is looking malformed or something
<kdub> is it being pulled through hybris?
<groot_> kdub, how can I test ?
<kdub> you can try the tests from hybris
 * kdub forgets the package name
<groot_> kdub, tell me when you remember :)
<josharenson> let me see oy
#ubuntu-mir 2014-07-25
<RAOF> Grr. Our plugins are really arse-backwards.
<duflu> RAOF: We have plugins?
<duflu> Platform libraries?
<RAOF> duflu: Indeed.
<RAOF> Gargh. std::shared_ptr: All the downsides of garbage collection, but without the upside that references are guaranteed to be valid :(
<RAOF> Oh, right.
<RAOF> You can't use shared_ptrs to keep dlopened libraries in scope.
<anpok_> hum?
<RAOF> Well, automatically.
<RAOF> If you try and keep the library your code is in loaded by keeping a shared ptr to it, then you'll lose.
<RAOF> Because when the last reference to, say, your ClientPlatformFactory goes away, ~shared_ptr() gets called, which calls your destructor, which calls the destructor of your shared_ptr<mir::SharedLibrary> which dlcloses your library.
<RAOF> Which is all perfectly fine as far as we go...
<RAOF> But ~shared_ptr doesn't end there! It then needs to clean up its own stuff.
<RAOF> But you've just unloaded the library containing your particular template instantiation of shared_ptr.
<RAOF> Hilarity ensues.
<anpok_> but the shared_ptr<void*> of your library is entirely defined by the loader of that library
<RAOF> This is not necessarily the case.
<RAOF> Or, rather, this is clearly not the case here.
<RAOF> Oh, hm...
<anpok_> we need to change default visiblity to hidden?
<RAOF> Or possibly the other way 'round.
<RAOF> Oh, but it's not using shared_ptr<void*>. It's calling shared_ptr<mir::client::ClientPlatformFactory> which *is* only defined in the dso you've just unloaded.
<anpok_> ohhh
<RAOF> Which is rather annoying :)
<anpok_> it worked becaus it was never unloaded?
<RAOF> Yes.
<RAOF> Or, rather, we didn't bother trying to handle lifecycle, and just kept a reference around in a global.
<RAOF> Huh. If we built the android platform with clang it'd be failing.
<RAOF> Oh, of course. If you build the android client platform on x86-64 then it is indeed loadable, and doesn't do what you want :)
<alf_> alan_g: hmm, "libmircommon-dev:armhf (0.6.0bzr1792pkg0utopic5+autopilot0) breaks mircommon-dev and is installed"
<alan_g> alf_: quite
<alan_g> https://code.launchpad.net/~afrantzis/mir/fix-mircommon-debian-replaces/+merge/228247/comments/552518
<alan_g> alf_: let me try something
 * alan_g looks for the dpkg command for "--no-install-recommends"
<alf_> alan_g: perhaps breaks needs a version clause (e.g. < 0.6) to work as intended
<alan_g> alf_: no it doesn't (that worked before RAOF corrected it)
<alan_g> Hmm "Recommends is ignored by dpkg" - so that isn't it
 * alan_g updates the build scripts in the hope he knows what he's doing
<alan_g> Rats!
<alan_g> dpkg: dependency problems prevent configuration of libmirclient-dev:armhf:
<alan_g>  libmirclient-dev:armhf depends on libmircommon-dev (= 0.6.0bzr1800pkg0utopic3688+autopilot0); however:
<alan_g>   Package libmircommon-dev:armhf is not installed.
<alan_g> dpkg: error processing package libmirclient-dev:armhf (--install):
<alan_g>  dependency problems - leaving unconfigured
<alan_g> Setting up libmircommon1:armhf (0.6.0bzr1800pkg0utopic3688+autopilot0) ...
<alf_> alan_g: hmm, https://wiki.debian.org/Renaming_a_Package seems relevant
<alan_g> Can you add "Provided: mircommon-dev"?
<alf_> alan_g: yes, trying that
<alf_> alan_g: pushed
 * alan_g wonders if there's an easy way to co-ordinate the build and test jobs.
<alan_g> It is still odd how many -dev packages are installed in the test environment setup ... I wonder why they are pulled in.
<alan_g> alf_: how does setting the attribute to "default" change anything? (Surely it picks up the changed default?)
<alf_> alan_g: "default" means public in this context :)
 * alan_g finds that confusing
<alan_g> I'd prefer an approach that controls everything in the .symbols file. (But I don't know how possible it is.)
<alan_g> camako: FIY I'm trying out a version of the mako test runner scripts with added timestamps ... lp:~alan-griffiths/+junk/mir-medium-test-runner-for-jenkins/
<camako> alan_g, sounds good
<camako> alan_g, is there a way to start a jenkins review on demand?
<alan_g> camako: It is possible to edit the "Rebuild" parameters of jobs, so you might be able to fake it that way.
<alan_g> OK I've concluded my changes to the scripts are benign so I'm pushing them
<alan_g> Look for [timestamp] in e.g https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/2194/consoleText
<alan_g> alf_: Just guessing but maybe "Provides" needs "(= 0.5.0+14.10.20140724-0ubuntu1)"
<alf_> alan_g: I think the issue is with Breaks vs Conflicts, I've changed to Conflicts to try this out.
<alf_> alan_g: http://s-jenkins.ubuntu-ci:8080/job/mir-mediumtests-utopic-touch/1079/console
<alan_g> So just reverting -c 1789
<alf_> alan_g: Right, my understanding is that if we wanted to go with Breaks+Replaces, we would need to add a transitional mircommon-dev package
 * alan_g wonders: if that is true how did -c 1789 land?
 * alan_g decides to go back to looking at which symbols are^bshould be exported from each library
<alf_> alan_g: Not sure, possibly versioned Breaks clauses are treated differently?
 * alan_g isn't sure anyone understands this stuff. He got wildly different answers from different "experts" none of which actually solved the problem.
<alf_> alan_g: Was there a problem with pre r1789 (i.e. what I am trying out now)?
<alan_g> Only that RAOF thought it was "wrong" and had a "I swear this is right" incantation
<alan_g> https://code.launchpad.net/~raof/mir/fix-unnecessary-virtual-package/+merge/227862 "This really, really is the correct packaging incantation"
<alf_> Perhaps then, we just need to use Breaks+Replaces with (<< 0.6~), I will try that next
<kdub> ci traffic jam
<alan_g> Perhaps
<alan_g> kdub: https://code.launchpad.net/~afrantzis/mir/fix-mircommon-debian-replaces/+merge/228247 is the one to watch. (Once alf_ gets a working incantation)
<kdub> ah, ack
<alan_g> kdub: is there any reason for putting Fd in libmirclient? Putting it in libmircommon seems logical to me.
<kdub> it should be in mircommon, let me check
<kdub> alan_g, so it is in src/shared/fd
<kdub> I'm slightly confused about what was noticed as well :)
<alan_g> kdub: sorry, I jumped to a conclusion but...
<alan_g> $ nm -Co lib/libmir*.so | grep "[BT] mir::Fd" | cut --fields=1 --delimiter=: | uniq -c
<alan_g>      10 lib/libmirserver.so
<alan_g> I guess that should get swept up with my other fixes to libmircommon
<alan_g> %s/alan_g/sisyphus/g
<kdub> lol
<alan_g> kdub: in the fix-libmircommon branch it is in the right place. Sorry to have bothered you.
<kdub> oh, no problem
<alan_g> camako: in answer to you're earlier Q: if you're signed into jenkins (has to be over the VPN) then you can go to the http://s-jenkins.ubuntu-ci:8080/job/mir-team-mir-development-branch-ci/ and select "Build Now". After that fill in the branch, revision and MP.
<camako> alan_g.. sweet. (I got my VPN account so I can see it)
<alan_g> camako: if you're only interested in one of the individual jobs then you can go to the corresponding page and start it there
<alan_g> You don't get a review, but you can see the results on Jenkins
<camako> alan_g, yeah I'm playing with all that
<alan_g> Remember to use your new powers for good and not clog the system
<racarr_> Morning
<alan_g> alf_: this is what I meant about not seeing the need for the MIR_API macro: https://code.launchpad.net/~alan-griffiths/mir/fix-libmirclient/+merge/228336
<kdub> racarr_, if I run XCursorLoader unit test on the device with "./mir_unit_tests", I get a segfault, is there an incantation to avert that?
<racarr_> kdub: -.- weird...um
<racarr_> kdub: Maybe you didnt copy over the tresting
<racarr_> theme directory
<racarr_> or the incantation I used
<racarr_> was weird
<racarr_> (it wont crash in the server without a theme...but maybe the test would)
<racarr_> incantation in CMAke for setting the directory that is
<kdub> it seems like I'm missing some files or something on the device
<kdub> because CI isn't bothered by it
<racarr_> kdub: tests/unit-tests/input/testing-cursor-theme
<racarr_> kdub: cmake exports the location lol...so I guess
<racarr_> actually cross compile doesnt quite work...
<racarr_> I mean unless you put it in the same absolute path
<kdub> ah, okay
<kdub> well, i'll figure out a fix
<racarr_> :) sorry about that...
<racarr_> kdub: So I ended up going with the mg::BufferWriter interface...
<racarr_> kdub: Do you think I should just make mga::AndroidGraphicBufferAllocator implement it to avoid sharing the gralloc_module_t
<racarr_> not sure how much benefit there is in keeping the gralloc module confined vs
<racarr_> welll...obviously write is kind of a weird method on the allocator...
<racarr_> but it could be like mga::GrallocAdapter : BufferWriter, BufferAllocator
<kdub> racarr_, yeah, we'd have to find a good name for it, and then it would be duplicated between the client code and the server code
<kdub> so probably best to shift the client mapping code to mircommon (android has a few classes like that already), and then use that on the server side
<racarr_> hmm
<racarr_> the GrallocRegistrar doesn't quite translate though because register_buffer
<racarr_> isnt needed on the server right?
<racarr_> I mean, I guess this shared class would be more of a
<racarr_> than something with a specific role i.e. GrallocRegistrar or BufferAllocator
<kdub> racarr_, it is, that's like mmap
#ubuntu-mir 2014-07-27
<frew> hey guys, I ran into a really weird bug with mir
<frew> I can give any logs or w/e people want
<frew> basically, when I was using mir, which I guess came with 14.04?  my keystrokes started to lag after about an hour
<frew> more details here: https://unix.stackexchange.com/questions/144231/why-is-my-keyboard-input-slow-in-xorg and here https://groups.google.com/forum/#!topic/sysdig/yg5_HNbCsuo
#ubuntu-mir 2015-07-20
<RAOF> Bah!
<RAOF> ThreadSanitizer!
<RAOF> Plz be with the more reproducibleness.
<anpok> hi RAOF
<RAOF> anpok: Yo!
<RAOF> racarr: Oh, hey! I might need a little tutoring in what MirPointerButtons mean at some point :)
<duflu> RAOF: Is it non-obvious?
<duflu> ...
 * duflu looks
<duflu> RAOF: Oh it's a set of MirPointerButton values :)
<RAOF> Yeah.
 * duflu likes that plural naming pattery
<RAOF> The interesting question is: what does membership of the set mean? :)
<duflu> pattern
<duflu> RAOF: It means it exists in some universe and may mean up, down, or colour depending on the variable name... ? :)
<duflu> So it should be obvious like "MirPointerButtons buttons_down"
<anpok> Ah, pressed vs changed during that event? pick the first
<RAOF> Ah! But is that the set of buttons that are *now* down, or the set of buttons that changed for this event?
<RAOF> anpok has the question right :)
<duflu> RAOF: Usually in toolkit design yes. Usually the set of buttons down
<duflu> Although other information is also handy
<anpok> i believe the first.. at least i know a few places of code that assume that..
<RAOF> That was my understanding also.
<alan_g> +1
<duflu> It's not very friendly for people who use mice upside down, but we care less about them
<alan_g> You have reason to question that assumption?
<RAOF> I think I'm getting confused because there's no guarantee that a pointer down event corresponds to *one* button being pressed.
<duflu> RAOF: If you want one then you would get a MirPointerButton (singular) I guess
<RAOF> I think my std::logic_error guard on the difference in state between the previous MirPointerButtons and the current MirPointerButtons not containing exactly one difference is being hit :)
<duflu> Ah. You need MirPointerChord then
<duflu> Which sounds like a joke but I have seen it in APIs before
<alan_g> anpok: are we still trying to land 14.0?
<anpok> there is no 0.14.0 in wily-proposed
<anpok> s/no/now
<alan_g> But not V+O?
<anpok> the actual process was delayed because we waited for the deprecation cleanup in qtubuntu and platform-api to land before that
<alan_g> Sure
<anpok> dual landing did not work because we had to land packages not handled through mps... xorg-server gtk glmark..
<anpok> and I was told it would not work..
<duflu> alan_g: AFAICT the client API bump slowed things down more than usual
<alan_g> duflu: that was to be expected.
 * duflu wonders what the package count is that depends on libmirclient
<anpok> then on thu/fri there was a boottest failure.. because of mir landing
<anpok> this uncovered one mistake in the spread sheet configuration - I forgot to include an url-dispatcher MP that I prepared
<anpok> but still it is unclear why that boottest failure was related to that
<alan_g> It sounds like we should schedule a retrospective on the landing.
<anpok> yip
<duflu> RAOF: Come to think of it, it sounds like you need the full state "MirPointerButtons presently_down, changed_since_last_time"
<anpok> ah yes and we still need a libsdl bump which is currently in the works...
<RAOF> duflu: Nah, I just need changed_since_last_time.
<duflu> RAOF: So long as that's not the only thing you ever see :)
<duflu> You wouldn't know up from down
<duflu> Fortunately with have bit operations
<RAOF> That's why we have mir_pointer_action_button_down/up
 * duflu wonders if we can have the mouse wheel back as two buttons like other APIs do (and the hardware does)
<duflu> alf_: What approach are you using to test MPs to lp:mir with the dash?
 * duflu wonders if it's faster than his
<anpok> alan_g: I also like the idea of a retrospective, because that implies that it will end some day
<duflu> Heh
<alan_g> Agreed
<duflu> greyback: Silly question (not a trick): Is it easy to run unity8-dash in a Mir demo server?
<anpok> nope
<anpok> you need quite a few environment variables configured..
<duflu> -easy +possible
<anpok> or it depends.. it might not work properly - I havent tried though..
 * duflu now realises it was easy for alf_ to backport changes to his phone because he already had 0.14.0 on it
<anpok> I tried unity8 a few times.. and always forgot something
<anpok> yes
<anpok> i mean .. you could still grab silo4 I guess.
<anpok> or hmm run kvm with ubuntu-desktop-next on wily-proposed
<anpok> ah you need display off
<greyback> duflu: it's possible, I managed it a few times. You need a dbus server running and to set a couple of env vars, and to launch a few scope processes to make it useful
<duflu> It's fine. I already know how to do this testing. Just wishing for a simpler way
<alf_> duflu: What I do is (in a script, which I can share if you like): stop lightdm, cross compile and copy to the phone, start lightdm
<alf_> duflu: For 0.14 vs 0.13 it is just a matter of using the silo vs not using it
<duflu> alf_: Yeah that's the trick. You need a 0.14 phone so as to be mostly compatible with lp:mir
<duflu> alf_: Aha! I think I can see what you did. You were flinging the dash instead of keeping your finger down, right?
<duflu> That is indeed worse
<duflu> But something I never tried
<alf_> duflu: right
<duflu> alf_: Good to know.
<duflu> Annoyingly lag with finger held down is still much lower with dynamic double buffering. One thing is worse and one is better :S
<duflu> Oooh.. actually I see the same thing in Mir demos. The GPU enters low power mode if you're not touching it. That might be the problem
<duflu> Anyone know a reliable way to keep an Android GPU in full power mode without touching the screen?
 * duflu tries spinning the CPU
<anpok> change username to carmack?
<duflu> I thought John recommended against it...
<duflu> But this isn't all the time. Just sporadically
<duflu> greyback: Possibly a more feasible question: During inertial scrolling of the dash, what's the animation frame time?
<greyback> duflu: that animation should be ticking at the vsync rate
<duflu> greyback: Sounds reasonable. Can I confirm it anywhere?
<greyback> duflu: hmm, nothing obvious comes to mind without reading the renderer code
<duflu> greyback: Just wondering because the shell's indicator pull-down thing doesn't have the same smoothness issues as the dash
<duflu> Seems like it's done better
<duflu> But also it has fewer servers to pass through
<greyback> duflu: it's all the same animation framework
<greyback> but I agree, there's something up
<greyback> it's been this way for a year, I've never cracked it
<duflu> greyback: It could also be that the number of hops from kernel to client code is double for the dash vs shell elements
<duflu> I've seen nesting creating such bugs with Mir's demos too
<duflu> We need to work harder to keep the extra layer smooth
<greyback> duflu: yeah.
<greyback> that's a possibility
<greyback> but I suspect something with qt too, or as you maybe noted above: could the gpu be clocking down if finger is not on screen
<anpok> alan_g: btw the boottest failed because it only upgrades mir packages and then tries to reboot.. so we end up attempting to launch unity-system-compositor with mircommon4 and mircommon5 and libmirplatform7 and libmirplatform8 simultaneously
<greyback> duflu: but that would be a lousy experience for games. maybe it's configurable?
<duflu> greyback: I know clock-down happens because I can see it with a simple triangle (and touching it helps)
<anpok> because the upgrade replaces mir-platform-graphics-drivers-android
<anpok> +2
<duflu> greyback: GPU driver authors try to tell you to let them handle it (sleeping and power states). But they also mess it up (as Intel has on desktop too)
<anpok> duflu: maybe that just increases the cpu time of the client
<anpok> wakes it more frequently
<duflu> Yeah good point
<anpok> enforces additional redraws?
<greyback> duflu: there must be a knob somewhere, surely
<anpok> or simply just affects the animation calc in a bad way
<duflu> greyback: It's OK... I can see the numbers and have one idea in mind to try and fix Mir first...
<alan_g> anpok: we need better ways to validate deployment not just fix up one scenario at a time
<duflu> [1437388267.960199] perf: Scopes: 37.69 FPS, render time 17.79ms, buffer lag 34.87ms (2 buffers)
<duflu> [1437388268.985012] perf: Scopes: 30.27 FPS, render time 25.22ms, buffer lag 40.29ms (2 buffers)
<duflu> [1437388269.993894] perf: Scopes: 31.74 FPS, render time 23.42ms, buffer lag 40.46ms (2 buffers)
<duflu> [1437388271.002470] perf: Scopes: 36.70 FPS, render time 19.13ms, buffer lag 35.59ms (2 buffers)
<duflu> [1437388272.021942] perf: Scopes: 44.16 FPS, render time 15.96ms, buffer lag 29.12ms (2 buffers)
<duflu> [1437388273.043734] perf: Scopes: 40.15 FPS, render time 17.85ms, buffer lag 31.90ms (2 buffers)
<duflu> We're missing by a few milliseconds each time
<duflu> Whereas with triple buffers it stays around 14ms and hits the frame deadline more
<anpok> alan_g: i now wonder if we expect that to work at all?
<alan_g> anpok: if we don't have an automated test for it...
<duflu> And that will be an adventure for Tuesday
<greyback> duflu: /sys/devices/platform/kgsl-3d0.0/kgsl/kgsl-3d0 on my nexus7 gives GPU clock info
<greyback> I can see evidence of it clocking up when something animating anyway
<duflu> greyback: Cool. I only have the old N7... do we still support the new one?
<greyback> interestingly it's not clocking down
<greyback> duflu: I think it's the new one I'm using, which is supported
<greyback> N4 has same chip tho I think
 * duflu jumps for joy at the lack of Tegra-ness
<duflu> greyback: Some simple but interesting figures to ponder... https://bugs.launchpad.net/mir/+bug/1476201
<ubot5> Ubuntu bug 1476201 in Mir "Dynamic double buffering fails to detect inertial dash scrolling as slow; and stutters" [High,In progress]
<greyback> duflu: certainly is interesting. With that /sys path I pasted above, you can force the gpu into its highest clock, might help isolate if it is a GPU thing
<greyback> duflu: to me this motivates a mir test client which renders at 16ms
<duflu> greyback: We already have some. Just not tested in tandem with queue scaling it seems
<greyback> duflu: do we? Which one?
<duflu> Actually we do have that too. It's just not enough
<duflu> greyback: slow_client_framerate_matches_compositor
<duflu> And others related
<duflu> But that test only expects and tests 3+ buffers
<greyback> duflu: ah ok, I was hoping it in mir-demos
<duflu> greyback: Using mir-demos you can kind of... I use env MIR_CLIENT_PERF_REPORT=log mir_demo_client_flicker
<duflu> And then watch the render time. Keep making the window bigger till the render time tips over the edge
<greyback> that's an idea, will try it next time
<alf_> anpok: kgunn: hmm, I forgot that we shouldn't push to USC trunk until it is merged into usc/ubuntu, and approved a few MPs. Will that cause issues?
<anpok> alf_: hum we might get away without a usc rebuild to resolve the remaining 0.14 issues
<rakesh__> Hi all
<kenvandine> greyback_, I'm working on the mouse and touchpad panel for system-settings
<kenvandine> greyback_, we need API's for those settings, I'm sure it's pretty similar to what jgdx was asking about for display settings
<greyback_> kenvandine: hey. We have zero apis ready for that
<kenvandine> i figured :)
<kenvandine> https://wiki.ubuntu.com/MouseAndTouchpad
<kenvandine> i just wanted to make sure it'
<kenvandine> s  planned
<greyback_> it's on a list somewhere :)
<greyback_> lemme make trello cards to track it better
<kenvandine> greyback_, can you make sure the plans match our spec?
<kenvandine> greyback_, thanks!
<kenvandine> greyback_, can you give me the link to your trello board?
<greyback_> kenvandine: https://trello.com/c/ceklQc5o/177-add-apis-for-mouse-trackpad-panel-of-system-settings
<kenvandine> greyback_, can you add me?
<greyback_> kenvandine: ah sorry, done
<kenvandine> thx!
<greyback_> feel free to add more detail to the card
<kgunn> anpok: so catching up, i read backlog, what's the current thinking ?
<alan_g> greyback_: @https://code.launchpad.net/~alan-griffiths/unity-system-compositor/add-display-config-option/+merge/262110 - updated
<greyback_> alan_g: great thanks.
<anpok> kgunn: the problem of boottest with mir seems to only affect partial upgrades
<anpok> which is what boottest really tests..
<anpok> kgunn: so I currently look into which mir libraries collide in a breaking way.. then we should probably make sure that they do not get loaded simultaneously
<kgunn> anpok: i suppose the question is, did we think that we could support simultaneous versions ? or did we know/expect this would be an issue ?
<kgunn> or did we just not realize this is how proposed migration tests this ?
<seb128> kgunn, well, proposed migration pointed a real issue
<seb128> not a common usecase one, but still real
<seb128> doing partial upgrades can result in a non starting u-s-c/unity8
<seb128> I bricked my device this morning by using apt to update mir without updating u-s-c
<kgunn> seb128: yikes
<kgunn> so we missed this
<anpok> kgunn: I think this not yet meant to work yet. And I guess we just missed the link dependency issue we ran into
<anpok> i mean we havent done anything yet to load a server platform library from a diferent server version that potentially comes with its own set of mirplatform/common libs..
<kgunn> anpok: got it, and i think that even makes sense (server specific mirplatforms/common ver)
<kgunn> so we just need a protection in place to avoid the partial upgrade
<racarr> Good morning
<seb128> kgunn, anpok, so what's next? do you want to try to hack-around-unblock the update? or let it stay in proposed until you figure out & land some mir changes?
<kgunn> camako: ^
<camako> seb128, kgunn, This will take rebuilding mir, unfortunately. anpok will be updating the symbols map for platform lib.
<kgunn> camako: so will we need to retest ? or is this just about build order ?
<camako> kgunn, not a full test. Just sanity to make sure what was failing doesn't.
<camako> this is not a code change
<camako> just linker symbols
<kgunn> camako: ok, do we need to test a partial update doesn't fail ?
<kgunn> or will that happen with boottest anyhow
<camako> kgunn, not sure... anpok?
<anpok> yes .. thats what I will test
<kgunn> thanks
<racarr> Lunch!
<popey> bschaefer: kgunn I'm trying to run love2d on my nexus 7 / krillin / arale, and it seems to segfault in setMode (so I don't know if this is an SDL or Mir issue). should I file a bug or throw a click package at someone to look at? -> http://people.canonical.com/~alan/love2d.popey_0.17_armhf.click (it just tries to set a gl context full screen and segfaults when doing this)
<bschaefer> hmm almost sounds like SDL, possibly (if the size if incorrect that'll be an issue. ie. the size of the window requested vs the size of the device)
<bschaefer> but i should be checking an issue like that and printing an error (but thats to a log that isn't printed)
<bschaefer> popey, also N7 works with unity8? Last time i tried touch didnt work on that device and unity8 crashed :)
<bschaefer> this was like a year ago
<popey> nexus 7 2013
 * bschaefer doesnt remember which n7 he has
<bschaefer> mako?
<bschaefer> or something
<popey> flo
<popey> mako = nexus 4
<bschaefer> o dang
<popey> grouper = nexus 7 (2012)
<bschaefer> ooo yeah i have a 2012 one
<popey> ok
<bschaefer> shoots so i dont think i can test this out
<popey> well I am mostly testing on arale actually
<bschaefer> popey, is it reproduce able on desktop?
<popey> am debugging with the love2d developer who is adding stuff to the game file so we can get more info for you
<popey> no
<popey> I'll get back to you when I have more info, thanks
<bschaefer> popey, that would be nice, getting the SDL_LogError()
<bschaefer> would be good
<bschaefer> err let me double check that function
<bschaefer> popey, SDL_error.h:42:extern DECLSPEC const char *SDLCALL SDL_GetError(void);
<bschaefer> but for love2d... i think it uses
<bschaefer> some other wrapper for SDL2
 * bschaefer looks up love2d
<bschaefer> o nm it looks like its cpp
<bschaefer> popey, yeah i would check SDL_GetError() as thats where any error that is caught will be printed to
<bschaefer> popey, also what version of mir are you running?
<popey> uh
<bschaefer> 0.13? (as SDL2 isn't 100% working on that atm
<bschaefer> )
<popey> yes, 0.13
<popey> okay
<bschaefer> yeah theres some ABI breakage
<bschaefer> popey, im actually making a branch atm :)
<popey> the fact I have love2d launching at all was some feat :)
<bschaefer> well moving SDL to 0.14
<bschaefer> popey, i bet, anytime i try a new game out on SDL2 its usually a fight haha
<popey> :)
<popey> fun though :)
<bschaefer> very! I like the part when the pixels start changing colors :)
<bschaefer> popey, ill try to get this branch done in the next few days and put a ppa up
<popey> sweet, thanks
<bschaefer> np! thanks of testing all these new apps/devices out!
<popey> np :)
<mcphail> popey: where did you get the SDL library? The one in the repos segfaults in SDL_init
<popey> uhhh
<bschaefer> yeah repos should seg fault on mir 0.13
<popey> good question
<bschaefer> from an ABI break
<popey> I can't remember where I got it
<popey> -rw-r--r-- 1 alan alan  2397348 May 22 10:46 libSDL2-2.0.so.0.4.0
<popey> is that one of your builds mcphail :)
<mcphail> popey: let me find one... :)
<popey> http://termbin.com/s0si
<popey> oops
<popey> wrong channel
<popey> mcphail: which app should I steal them from?
<popey> :)
<popey> neverball seems like a good bet :)
<mcphail> popey: d1948f790f196bc19a141c43cd453b67  libSDL2-2.0.so.0.4.0 -- probably mine :)
<popey> d1948f790f196bc19a141c43cd453b67  libSDL2-2.0.so.0.4.0
<popey> yup
<mcphail> have you managed to get access to the backtrace in gdb?
<popey> mcphail: yeah, but no symbols so it's not much use
<racarr> </lunch> tidied my branches and did some reviews this morning. finishing mir on X review now
<racarr> then probably back in to input transport rework
<mcphail> popey: if I get a chance, I'll write something up about importing symbols for gdb. Makes life a lot easier
<bschaefer> you can always compile it with -g3
<mcphail> bschaefer: I mean something more like this: https://youtu.be/xTmAknUbpB0?t=32m16s where you're dealing with all those libs on the phone which don't have symbols embedded. Saves having to apt-get all the debug symbols and breaking the system image
<bschaefer> mcphail, o thats interesting, thanks! (Ill have to watch this now :)
#ubuntu-mir 2015-07-21
<RAOF> Hm.
<RAOF> Is the_global_event_sink really unused?L
 * RAOF once again wishes for a pervasive signals/slots mechanism in Mir.
<anpok_> RAOF: hm signal and slot with an explicit mentioning of the dispatcher the caller will be executed with
<tvoss> anpok_, easiest if the respective connection maintains the dispatcher
<RAOF> I guess you could add the latter :)
<RAOF> duflu: Why did you push the revert in r2759?
<duflu> RAOF: Because it removed the bit that actually detected the regression. Also I have a much smaller and simpler solution (now proposed)
<RAOF> The test you reverted does indeed catch the regression.
<RAOF> It tested that the regression behaviour did not occur.
<duflu> RAOF: OK, well if you found a new way to detect it, I'm sorry. Although you did the same to me. Objectively though, a better version is now proposed
<RAOF> I proposed my solution in your merge proposal.
<duflu> My test was also written when the bug still existed and failed prior to it being fixed. So I assume that's what you mean too
<RAOF> Right. I tested my test by reverting your fix, and it does indeed fail.
<RAOF> I disagree that your test is better; doesn't your test deadlock on failure?
<duflu> RAOF: No..?
<duflu> Oh it might have hung
 * RAOF will also note that my version of the test went in after 3 approvals + CI.
<RAOF> Right.
<RAOF> My version fails rather than hanging :)
<duflu> RAOF: Mine also got reviewed :)
<RAOF> Your revert?
<duflu> RAOF: Yes, the version I reverted to was approved.
<duflu> No need to argue. Not important. I'll redo it
<anpok_> hm alan_g i tried you gcc-5 fix branch..
<anpok_> demo server is working .. not sure why every attempt to start a server fails on ci
<seb128> hey there
<alan_g> anpok_: yes?
<seb128> what's the status of the new mir stucked in proposed in wily?
<anpok_> seb128: there was one obvious abi bump missing
<anpok_> seb128: but it did not fis the issue.. so I also bumped the server graphics platform abi
<alan_g> anpok_: nor I (yet) - I'm going to try reproducing
<anpok_> s/fis/fix
<seb128> so it's fix commited now? more rebuilds needed?
<seb128> let me know if you need with uploads or such
<anpok_> seb128: rebuilding silo 4 now.. I walso wanted to include a gcc-5 fix
<anpok_> but there is an odd ci failure..
<seb128> k
<seb128> which one?
<anpok_> the test runner fails to start mirserver - https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/5979/console
<seb128> k, no idea about that ...
<duflu> anpok_: If you don't need to, please keep out gcc-5 support. There's always risk
<duflu> And this late in the game we don't need more
<alan_g> anpok_: please don't add anything that isn't needed. There will be another release along soon
<duflu> RAOF: Sorry, your test is restored
<RAOF> duflu: Ta. I was mostly just surprised to see the revert without MP.
<alan_g> anpok_: From a first look at the failure I suspect that loading (and rejecting) the 0.13 platforms in a g++-5 build drags in a second copy of boost RTTI, You shouldn't delay 0.14 on getting that resolved.
<duflu> RAOF: It happens. Nobody yet has uncleanly reverted something. We're pretty good at it
<duflu> Also, we have "append-only" set. So "uncommit" is disallowed, for our own protection
<duflu> alan_g: I think the head of lp:mir/0.14 (from a few minutes ago) might fix your issue
<anpok_> ci is using vivid+o makos or wily makos?
<alan_g> anpok_: V+O
<duflu> It shouldn't matter if your ABIs are right, should it?
<anpok_> -> whats the right solution for that failure: https://ci-train.ubuntu.com/job/ubuntu-landing-004-1-build/275/console
<duflu> anpok_: Merge lp:mir/ubuntu back to lp:mir/0.14?
<anpok_> but there is no changelog entry yet
<duflu> Ah, that old problem
<duflu> anpok_: Then download it :)
<anpok_> and add it to mir/0.14 and add another one?
<duflu> anpok_: Yep.... https://launchpad.net/ubuntu/+source/mir
<duflu> Distro needs a continuous timeline. You shouldn't pretend the first attempt didn't happen
<duflu> Debs are messy. Can we have something new now?
<duflu> :)
<RAOF> Urgh! What the hell is happening here: http://s-jenkins.ubuntu-ci:8080/job/mir-clang-ts-wily-amd64-build/69/console ?
<duflu> VPN says no
<RAOF> I can't reproduce that locally; *my* threadsanitiser make test works.
<duflu> tsan with clang presumably?
<RAOF> Indeed.
<duflu> Or is the "clang" a misnomer in the task?
<duflu> Also.. for some value of "wily"
<RAOF> Well, my wily is up to date as of today; the builder should be too (as it's pulling from the archive)
<duflu> For some value of "today"
<RAOF> :)
<RAOF> I suspect that it's got to do with the fork() involved in the death-tests.
<RAOF> Because at least one of the failures is talking about the main thread of ClientLibraryErrorsDeathTest_createing_surface_on_garbage_connection_is_fatal racing with the RPC thread created by ApplicationNotRespondingDetection_responding_client_is_not_marked_as_unresponsive
<RAOF> (And now that typo has crossed my threshold of annoyance âº)
<RAOF> anpok_: You're familiar with the vagaries of ThreadSanitizer, right?
<anpok_> not really
<anpok_> I even fail to look up vagaries in the dictionary
<RAOF> :)
<anpok_> RAOF: but you can try treating me like a rubber duck - whats wrong?
<RAOF> ThreadSanitiser complains about an RPC thread started from ApplicationNotResponding's acceptance test racing with mir_connect_sync from ClientLibraryErrorsDeathTest.
<RAOF> From a heap block allocated from the ANRDetection test.
<RAOF> And the ANR detection tests start after the ClientLibraryErrorsDeathTests have already finished.
<RAOF> So I'm suspicious that the problem is actually that the fork() in the death tests is confusing ThreadSanitizer.
<alan_g> anpok_: alf_ hangout?
<alf_> alan_g: coming
<anpok_> now
<mterry> RAOF, poke about subscribing mir-team to abi-compliance-checker
<RAOF> mterry: Subscribed as of a couple of hours ago.
 * mterry hugs RAOF
<RAOF> Sorry about the delay.
 * RAOF was on holiday last week, too.
<alan_g> camako: with mir-on-x I ought to be able to see clients in a desktop window. Right?
<anpok_> alan_g: the server in a x-window
<alan_g> I see an X window (and titlebars painted in the server) but nothing from the client
<camako> alan_g, is it an intel gpu?
<alan_g> camako: yes
<camako> alan_g, try a non egl client
<camako> intel's gpu has support problems for the extension I am using
<camako> for egl clients only though
<alan_g> camako: Ah! multiwin works
<camako> \o/
<camako> alan_g, egl clients work but do not render.. you can try eglplasma and hit 'q'.. it'll quit fine.
<alan_g> Confirmed
<alan_g> Is mouse input supposed to work?
<ogra_> nah, it is unity8 ... its all gestures (you need to know the secret handshake to log in) :)
<alf_> alan_g: no, mouse is not supported yet
<racarr> Morning!
<kgunn> racarr: o/
<racarr> kgunn: Howdy :)
<racarr> kdub: Can you rereview client-specifie-dinput-regions when you get a chance I had to repropose it with a dependency
<racarr> (symbols.map stuff)
<racarr> no code changes
<kdub> sure
<racarr> kdub: Same thing for relative-pointer-events...had to resubmit without prereq :)
<racarr> thanks
#ubuntu-mir 2015-07-22
<duflu> greyback: Hey I spent a brief while relearning how QtMir does compositing today. And I suspect it's holding buffers longer than it should. Although I need to re-check Mir's logic before I can suggest something better. Are you sure you can't release your buffer pointer held in the texture earlier?
<greyback> duflu: you're correct in your suspicion. We only release a buffer when we acquire a new one, which is not ideal.
<duflu> greyback: I think the phone will be noticeably smoother if we release earlier :)
<greyback> duflu: we could improve this by releasing the buffer if we're notified a new one has been created, and we've fiished rendering that frame
<greyback> duflu: I don't disagree
<duflu> greyback: I need to re-check Mir again. I know cachine just the GL texture is fine for software surfaces but hardware surface safety is dependent on the EGL extensions we use :P
<duflu> *caching
<greyback> duflu: I don't understand what you mean by caching here.
<greyback> caching the whole buffer while it's being composited, so buffer can be released?
<duflu> greyback: For traditional texture uploads at least, it gets copied to the GPU. So you can reclaim the buffer immediately
<duflu> Although I think our hardware surfaces don't get copied. So need more care
<duflu> Never mind. If I have a promising idea I'll propose it
<greyback> duflu: understood
<duflu> greyback: Are there any software buffers used in practice on a phone, or all hardware?
<greyback> duflu: sdl-based apps use software buffers I believe
<duflu> greyback: OK, yeah I know about those. Same on desktop
<greyback> yep
<duflu> Does image 263 work for anyone else or am I being over-ambitious?
<duflu> I guess that's why it's called "proposed"
<alan_g> alf_: I'm deciding what to do for the rest of the sprint. Is "Fix fd leaks in acceptance tests" something I could take on?
<alf_> alan_g: yes, feel free to do so
<alf_> anpok_: ^^ See Daniel's comment about image 263
<alf_> duflu: Did you find an image that boots?
<alan_g> duflu: lp:1477051
<alf_> alan_g: thanks
<anpok_> alf_: I think I have an older image here too
<alf_> anpok_: and it fails too?
<anpok_> rc-proposed or devel-proposed
<anpok_> hmm I flashed 280 it seems
<ogra_> bug 1477051 FWIW
<ubot5> bug 1477051 in live-build (Ubuntu) "Phones on devel-proposed do not boot - /bin/sh: 1: /bin/sh: initctl: not found" [Critical,Confirmed] https://launchpad.net/bugs/1477051
<alf_> anpok_: so that's not devel-proposed then
<alf_> anpok_: ah, sorry, ubuntu-touch/devel-proposed/ubuntu has a 280 image for krillin
<alf_> anpok_: which is the latest
<alf_> anpok_: the latest for ubuntu-touch/devel-proposed/ubuntu mako is 263
<alf_> anpok_: I will try with 262
<anpok_> ok i am on krillin #277 and spinner spins now
<duflu> alf_: Yes, vivid works. But that doesn't help me right now
 * duflu wanders off
<alf_> anpok_: ubuntu-touch/devel-proposed/ubuntu mako 261 boots, will test silo with that
<ogra_> only the latest images dont boot (see the bug i posted above)
<ogra_> yesterdays builds should be fine
<alf_> ogra_: ack
<camako> vogons, after latest wily upgrade, my wifi doesn't work on my laptop (doesn't wired connection). Can't join standup.
<camako> ... (doesn't have wired connection)
<racarr> Morning!
<conyoo> um.. it's 19:38 o_O
<racarr> California \o/
<conyoo> hehe :P
<robert_ancell> kgunn, do you use a bluetooth mouse/keyboard in combination with a "slimport cable" (not sure of the actual term for it, i.e. the HDMI connector)
<kgunn> robert_ancell: yes
<kgunn> robert_ancell: yeah, it's "slimport"
<kgunn> soon it will be replaced by mhl
<kgunn> Mobile High-Definition Link
<robert_ancell> kgunn, do neither of those options allows audio/video AND USB?
<kgunn> robert_ancell: yeah, mhl is supposed to support audio i think...altho might depend on oem support/drivers
<robert_ancell> kgunn, yeah, but by switching to MHL/slimport mode does it no longer do USB on those pins?
<robert_ancell> So you could have a USB hub + HDMI connected
<robert_ancell> i.e. a complete docking station
<kgunn> robert_ancell: uh, that i don't know, altho at least with slimport there is a hub on a lot of cables....
<kgunn> not sure if that's power only
<kgunn> never check
<kgunn> ed
<robert_ancell> It appears to be just for power (so you can charge the phone while using the slimport)
<robert_ancell> It appears an OTG cable will give you USB and a slimport gives you HDMI but you can't get both :(
<robert_ancell> I wonder if any phone supports using an OTG + a DisplayLink device
<anpok> robert_ancell: the mhl solutions should allow both
<anpok> robert_ancell: can get an android buffer displayed on a drm device...?
<robert_ancell> anpok, sounds difficult! I guess the Android driver spec doesn't require anything like this (yet)
<anpok> http://support.displaylink.com/knowledgebase/articles/557853-how-do-i-connect-my-displaylink-device-to-my-andro
<anpok> hmm
<anpok> robert_ancell: we could just copy the contents in usc?
<robert_ancell> anpok, yeah, I guess that's what the app is doing more or less
#ubuntu-mir 2015-07-23
<duflu> alf_: Annoyingly, I upgraded, broke and then upgraded mako again. And something other than Mir has changed so I'm not getting consistent results any more. This will take time...
<duflu> Oddly, unity8 is no longer fast enough to qualify for double buffering in wily-proposed whereas it was a few days ago
<duflu> Still, could be something change in Mir too
<duflu> A scary (or spurious) realisation: QtMir doesn't schedule enough frames to render clients smoothly. The only reason they don't appear to hang is because of the frame dropping fallback.
<duflu> So it drops (stutters) when it could be rendering smoothly
<duflu> Although dropping should appear in the log. Hmm
<duflu> Bah, words. They're often wrong.
 * duflu is still excited about the potential for simple improvements in qtmir
<alan_g> anpok_: you merged the g++-5 changes to 0.14 - does that mean yet another attempt to land has started?
<anpok_> yes
<alan_g> /sigh - I was hoping it meant 0.14 had landed and 0.14.1 was speeding through
<anpok_> this time u-s-c boottest failed as it only upgraded mirserver and client libraries
<anpok_> but not the drivers
<anpok_> hence tries to boot without drivers
<alan_g> the team will owe you a drink for this release
<anpok_> when I reverted the driver abi bump (we did not bump it during the 0.14 period) assumed that it might not be broken ..
<alan_g> s/drink/large drink/
<anpok_> not mir bootest fails (in silo 004 still)
<anpok_> -not +now
<anpok_> because guess what .. there was an abi break we missed..
<anpok_> now looking into efficient ways to find it
<anpok_> and yeah merged the g++5 fixes..
<anpok_> I hoped a karma improvement like that might improve our odds
<alan_g> Early, automated detection is what we need. Not at the tail end of s stupidly involved manual process.
<anpok_> yes..
<duflu> greyback: Is it certain that QTimer::singleShot(0, this, SLOT(update())) will schedule a second frame (16ms later) or is there a risk it could coalesce into the current one being drawn?
<duflu> I guess it assumes everyone is on a single threaded event loop
<greyback> duflu: that call executed on the renderer thread. That appends an event to the main GUI thread (with the main event loop) to call the update() function, which indicates the scene is dirty, and tells the renderer to schedule a new pass
<duflu> greyback: Even when the current pass is still pending? It doesn't get cleared at the end of the pass?
<duflu> Hopefully at the beginning..
<greyback> duflu: the current pass is in progress when that is called
<duflu> greyback: I know. That's why I'm asking. Is it clever enough to know the current frame's not finished and a second one after that is needed?
<greyback> duflu: that's exactly what it's doing. I think it's reliable, it will schedule a second frame if there's another client buffer ready for compositing
<duflu> greyback: Yeah in theory we'd see more bugs if it didn't work, but I still want to verify
<greyback> code is a bit clunky tho, I'll admit that
<duflu> Actually it's about right for an event loop design. Only the Q* syntax is unfamiliar for me
<greyback> you'll get used to it ;)
<duflu> greyback: On a different note, is there somewhere you can put code to execute after the eglSwapBuffers?
<duflu> greyback: Oh, found it. Sorry
<greyback> duflu: I know what you're thinking ;) I did try a prototype to release buffers earlier, but can't find it now
<duflu> greyback: Yeah, it's a tangential thought. I should stay on the first task really
<greyback> ah found it
<greyback> lp:~gerboland/qtmir/remove-custom-framepump1/
<greyback> was causing rendering bugs tho
<duflu> greyback: OK, yes fair enough
<duflu> OK, bad news and good news...
<duflu> Bad news: When dynamic double buffering is working properly it may not be beneficial to Unity8.
<duflu> Good news: Predictive bypass (already landed and coming in 0.15) seems to raise frame rates by 25-35% (!)
<duflu> Which really means it avoids frame skipping
<greyback> duflu: why not beneficial to u8? As a server, or as a client of USC?
<duflu> greyback: As a client of USC... I should have noticed -- any surface that's bypassed/overlaid (like the fullscreen U8) doesn't get dynamic double buffering. Due to the extra compositor demands of bypass/overlays
<duflu> Predictive bypass reduces the problem, but apparently not enough
<greyback> duflu: sounds like we should test and see for sure
<duflu> greyback: I am. And it's not fun. Although in my full stack test with 0.14 predictive bypass was missing. So maybe it will free up the Unity stack enough to get the benefit back. It doesn't when running the pure 0.15 mir demos, is all
<greyback> ok
<duflu> Too many variables
<duflu> greyback: In theory you could achieve a similar benefit in QtMir for apps by changing that zero-millisecond timer to something non-zero (but still short enough to not miss frames)
<duflu> Or maybe not. Other parts might need to change too before there's any benefit there
<greyback> duflu: why delay the timer? If we know there's a new frame to be composited, we might as well schedule a new renderer pass immediately
<duflu> greyback: Hmm actually if the texture update for all surfaces is delayed in the same way, maybe not
<duflu> It only works if you know your max render time and have room to play with. So not a good idea for GL on a mobile device I guess
<greyback> yep
<racarr> Good morning!
<kgunn> racarr: gm
<wulfensteyn> um.. on wily (mir 0.14) clicking on gedit menu crashes unity
<wulfensteyn> also some strange crashes with gnome-calculator on demo server
<wulfensteyn> the keyboard works fine now :D the key repeat rate seems to be fixed
<wulfensteyn> +1
<bschaefer> mcphail, popey https://code.launchpad.net/~brandontschaefer/+junk/SDL2-new-mir-ABI
<bschaefer> is the new branch which is moving to the new mir ABI (though im using trunk mir
<bschaefer> )
<bschaefer> sooo you'll need a pretty new mir atm (not 100% how far off it is from main)
<bschaefer> ill try to get a ppa with the right version of mir on it
<popey> hello!
<popey> that's something to play with at the weekend :)
<bschaefer> popey, sweet :)
<bschaefer> popey, i should be around irc, soo just poke me at any point!
<robert_ancell> Does anyone know if Unity8 is planning to support client side decorations for applications (e.g. GNOME applications that are drawing a HeaderBar).
<robert_ancell> Asking here because I guess a Mir surface will have to hint if it should be decorated
<Trevinho> mh, wondering the same...
<robert_ancell> I guess we'd need a mir_surface_spec_set_decorated() or similar
<robert_ancell> bschaefer, Do you mean the Mir 0.14 API? That's in wily now
<robert_ancell> oh, 0.15.
<bschaefer> robert_ancell, aiming at trunk mir
<bschaefer> soo 0.15, but i dont think there was an API change from 0.14 --> 0.15
<bschaefer> but theres some new stuff
<robert_ancell> Most of that branch is Mir 0.14 I think
<bschaefer> yeah, waiting on some new 0.15 stuff to land (relative mouse support and an egl pixel format thing)
<bschaefer> relative landed soo i just need to implement those changes
#ubuntu-mir 2015-07-24
<RAOF> robert_ancell: mir_surface_type_freestyle is your winner.
<robert_ancell> RAOF, thanks!
<RAOF> You'll just need to not draw shadows.
<RAOF> Because, as a client, you can't do that correctly, so shouldn't try :P
<robert_ancell> Are the current shadows client side?
<RAOF> For GTK? Pretty sure they are.
<RAOF> Or, at least, GTK-on-Shell does client-side shadows.
<robert_ancell> I'm looking at what needs to be done to fix https://plus.google.com/+PopescuSorin/posts/Q2ExSx7K94c
<robert_ancell> I'm looking at what needs to be done to fix https://plus.google.com/+PopescuSorin/posts/Q2ExSx7K94c
<robert_ancell> I'm looking at what needs to be done to fix https://plus.google.com/+PopescuSorin/posts/Q2ExSx7K94c
<robert_ancell> I'm looking at what needs to be done to fix https://plus.google.com/+PopescuSorin/posts/Q2ExSx7K94c
<RAOF> There are a couple of things that need to be fixed there.
<robert_ancell> blah
<RAOF> mir_surface_type_freestyle will get you no decorations...
<robert_ancell> ok, my client was showing non of that going through :)
<RAOF> ...but then you'll have no way of moving the window :)
<RAOF> :P
<robert_ancell> RAOF, yeah, windows can't move themselves?
<RAOF> Correct.
<RAOF> There's planned API for it.
<robert_ancell> OK
<RAOF> (Plus, I don't know if U8 actually does anything different with type_freestyle yet)
<robert_ancell> Yeah, I suspect not
<robert_ancell> We should open up some bugs if not already there
<RAOF> (API is basically - âhey, Mir! This mouse button press started a window drag. Kindly move me with itâ)
<RAOF> Yeah, certainly.
<robert_ancell> RAOF, you don't know of a bug for the proposed surface moving API do you?
<robert_ancell> I'm not seeing one
<RAOF> No, sorry.
<robert_ancell> OK, I'll open one
<RAOF> Huh, and there's not even a trello card.
<RAOF> This is one of those things that we all just know needs to happen, I guess ;)
<robert_ancell> Yeah, there's a lot of those that are invisible unless you know about some random conversation that occurred
<robert_ancell> Let me shine some light :)
<robert_ancell> RAOF, Does X have a clever way of telling the X server to "move with motion events" or does the client just convert every motion event into a window move request?
<robert_ancell> i.e. are we improving on the status quo here?
<RAOF> We're improving on the status quo here.
<robert_ancell> Do you know if Wayland it doing the same?
<RAOF> Yes; as long as by âWaylandâ you mean GNOME Shell :)
<RAOF> (Or, less snarkily, xdg-shell, but that's only implemented by weston and Shell to my current knowledge)
<robert_ancell> Yes, I mean xdg-shell
<RAOF> See the âmoveâ and âresizeâ requests on xdg_surface
<robert_ancell> Ah, bug 1398849 is what I was looking for
<ubot5> bug 1398849 in gtk+3.0 (Ubuntu) "support client-side window decorations (GTK on Mir)" [Wishlist,Triaged] https://launchpad.net/bugs/1398849
<duflu> robert_ancell: The dragging functionality you want is logged as: https://bugs.launchpad.net/mir/+bug/1420334
<ubot5> Ubuntu bug 1420334 in Mir "[enhancement] Missing client API for relative surface movement" [Medium,Triaged]
<duflu> Good news! Not only is 0.14.0 released in wily but we now get free dbgsym packages and more platforms than we test even :)
<duflu> RAOF: Interestingly we build ppc archs that supposedly are big endian (by default). I bet they don't work...
<RAOF> duflu: You are correct.
<RAOF> There's only one spot that they don't work, though, which is pretty neat.
<duflu> RAOF: The spot I documented?
<RAOF> I don't know which spot you documented, but it was the spot in GLRenderer (IIRC?) that checks endianness and throws on BE architectures.
<RAOF> Because we're too lazy to work out how to read big endian buffers.
<duflu> RAOF: I documented what was missing for big endian in our pixel format typedef and also in ShmBuffer
<duflu> That might be what you mean by GLRenderer
<RAOF> Ah, GlPixelBuffer.
<RAOF> Ok. Thanks, internet outage, for getting me down to Hillarys to test out the Ubuntu Touch wifi hotspot silo...
<guest42345> hm firefox nightly builds are on gtk3
<attente> for a menu surface with mir_edge_attachment_horizontal, how does mir know to align the left edges (for LTR text) or the right edges (for RTL edges)?
<attente> *RTL text
<alan_g> attente: there's logic in CanonicalWindowManagerPolicy for that placement. (If that's what you're asking)
<attente> alan_g: how does a mir client change this behaviour?
<alan_g> A mir client doesn't - it request a placement and the server chooses how to implement it
<attente> alan_g: ok, thanks
#ubuntu-mir 2016-07-25
<tepper3> ls
<duflu> ls: No file or directory
<RAOF> Oooh, hosed system.
<RAOF> No ls?
<duflu> ls: Deprecated. Use a Mir shell instead.
<duflu> RAOF: Apparently Mesa 12 adds 'support' for GBM_FORMAT_XBGR8888. But using it results in backward colours still. I suspect nobody actually tested the new feature yet...?
<RAOF> Plausible?
<RAOF> I'd expect it to be associated with a piglit test, though.
<RAOF> (They're pretty easy to write, if you care âº)
<duflu> Never saw a test committed with the upstream change. But they say they added GBM_FORMAT_XBGR8888 for Android (where it is OpenGL's type RGBA in big endian). I'd be surprised if nobody else tested/fixed it yet
<duflu> I mean Android's RGBX type, which is big endian
<duflu> I used to have a manual test for it with mir-demos. I should dig that up
<tepper3> oh sorry :> i'm using irssi and mistaked the term tab
<RAOF> duflu: Piglit is in an entirely different repository; you wouldn't see any tests unless you were following it.
<duflu> Oh. I thought it was odd previously tests were committed separately
<RAOF> https://cgit.freedesktop.org/piglit/ is probably where tests would go.
<duflu> I need to check it's not our fault still
<duflu> alan_g: We don't have any report that simply logs what pixel format a surface is created as do we?
<duflu> I keep needing such a thing
<duflu> Hmm, or client report would do
<alan_g> duflu: I can't claim to know it all, but I doubt it is currently reported. We probably just report the surface name.
<duflu> I can't remember which report that is either
<duflu> But I think if I want the format of a specific client it should be a client report
<alan_g> I'd guess --scene-report has the surface create event and could add such detail, but we've never got around to adding much (optional) detail to any of the reports
<RAOF> We should write a logging Mir proxy.
<RAOF> Thanks to Protobuf being self-describing it'd actually be pretty easy, and would trivially log *everything*.
<RAOF> Lovely for debugging.
<duflu> #define if ...
<duflu> #define while ...
<RAOF> (Except, of course, for input events and anything else that comes over that socket, because yay)
<RAOF> Bah.
<RAOF> I really, really, wish things stuck in a std::function<> didn't need to be CopyConstructible.
<anpok> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4543.pdf
<RAOF> anpok: Of *course* there's an N document resolving that :P
<RAOF> anpok: Although, to be honest, std::packaged_task would work fine for me were it not for the tiny problem of I'm doing this because std::future's use of TLS makes hybris have a sad.
<anpok> ah yes
<alan_g> duflu: I know there are other options to play with, but is this a plausible starting point for using Xmir? https://code.launchpad.net/~alan-griffiths/miral/script-testrun-with-xmir/+merge/300866
<duflu> alan_g: That's the correct minimal syntax, yes, with two caveats:   (1) The default renderer on desktop is dri2 which is less reliable so sometimes try -sw.  (2) The -rootless option is not yet used by Unity8 but we hope to in future
<duflu> alan_g: Oh two more caveats...
 * alan_g wonders...
<duflu> alan_g: (3) Our dbus settings are broken and will hang GTK apps. Use export DBUS_SESSION_BUS_ADDRESS=none or such to stop it hanging. (4) gnome-terminal is broken (and only gnome-terminal). So try something else like gedit
<duflu> But maybe those problems are only in yakkety
<duflu> At least only (1) of four caveats is an Xmir bug
<alan_g> duflu: I've already got gnome-terminal "working" with the gtk-mir backend, just aiming to provide some support for other X apps.
<duflu> alan_g: Well it used to work perfectly. Something in yakkety broke it.
<duflu> yakkety is in flux
<alan_g> Luckily for me I can still work on xenial & vivid+overlay
<duflu> alan_g: You might actually want to run pure native X apps to avoid all the GTK/dbus problems.... like 'xterm', 'bitmap'
<alan_g> ack. For the moment I'm mostly wanting to document a test context for "where in the stack does it go wrong" questions.
<alan_g> It's hardly good support as (for example) Alt+F4 kills Xmir not the client
<duflu> alan_g: Actually that sends the close signal to the current window, just the current window
<duflu> in mir_proving_server anyway
<alan_g> This is miral-shell which currently does that for Ctrl+F4 and does SIGTERM with Alt+F4.
<duflu> alan_g: I think it's meant to be close current window everywhere else in the world :)
<duflu> alf_ What do I win?....
<duflu> =======================================================
<duflu>                                   glmark2 Score: 4
<duflu> =======================================================
<duflu> alan_g: Really common combos like that which exist in other operating systems too I think are best kept
<alan_g> I agree: that;s why "the shortcut key combination for closing the active Window is Ctrl + F4."
<duflu> alan_g: Isn't it Alt+F4 elsewhere?
<duflu> Ctrl+F4 doesn't exist in Unity7. Maybe in Windows?
<alan_g> I'm sure I use it in Unity7, but it can easily be app specific.
<duflu> Doesn't seem to do anything here
<alan_g> Mostly it came from demo_server with demo_clients
<alan_g> Trouble is there's a lot of "standards" in this area. I'll dig a bit.
<alan_g> You may well be right.
<duflu> alan_g: Well, check what the common defaults are in various window managers (not apps), and Windows, and OSX
<alan_g> duflu: https://en.wikipedia.org/wiki/Alt_key#Alt_key_combinations supports your case
<duflu> Maybe that's the only truly common window manager combo. The app equivalent is Ctrl+W
<duflu> which may or may not be implemented in an app
<duflu> Anyway, time to cook dinner since my callgrind graph is so uninteresting
<alf_> tvoss: Hi! Could you please take a look at https://bugs.launchpad.net/platform-api/+bug/1602604
<ubot5> Launchpad bug 1602604 in unity8-desktop-session (Ubuntu) "package repowerd 2016.06+15.04.20160706.1-0ubuntu1 [modified: lib/systemd/system/repowerd.service] [origin: LP-PPA-ci-train-ppa-service-stable-phone-overlay] failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,New]
<alan_g> greyback: how's qt compositing on MirAL going?
<greyback> alan_g: am assembling some MPs for you now
<alan_g> Nice!
<alan_g> greyback: all your MPs belong to trunk
<greyback> alan_g: thanks. I've bigger chunks to come, probably tomorrow
<alan_g> ack. Are you looking to review any of mine?
<greyback> I will now
#ubuntu-mir 2016-07-26
<woobydooby> sup, any idea when mir 0.24 will land in 16.10?
<duflu> woobydooby: As soon as we have confirmed it doesn't break Unity8 and friends :)
<woobydooby> oh, ok :D
<duflu> It's a big one too
<woobydooby> yeah, i've seen it's in a silo or something
<woobydooby> a silo is like a ppa?
<woobydooby> if i install 0.24 from the silo and it doesn't work can i revert?
<duflu> woobydooby: I believe a silo is just a PPA. You can revert if you have 'ppa-purge' installed
<woobydooby> ppa purge or something
<woobydooby> great then :D muhahaha
<woobydooby> thanks duflu
<woobydooby> hm.. btw.. kde conversation worlk okish on mir
<duflu> woobydooby: Thank you too. Please add your findings to https://code.launchpad.net/~mir-team/mir/0.24/+merge/300589
<woobydooby> there are some problems with the menu and other things but it's usable on unity8 desktop
<woobydooby> using it right now
<duflu> Unfortunately silos are often bloated beasts with lots of projects changing at the same time. Difficult to narrow down regressions
<woobydooby> :( we need to move to snaps
<woobydooby> snap refresh mir ))
<woobydooby> i've heard snaps cure cancer
<woobydooby> but i'm not sure if it's true
<duflu> Snaps don't reduce the number of ABI/API breaks in a release necessitating multi-project updates unfortunately
<woobydooby> oh i see :> so you also need to update qtmir and unity compositor and stuff along with mir
<woobydooby> ok, so looks like 0.24 is in the Mir staging ppa
<woobydooby> so.. after update i'll have mir 0.24 but all above will probably break, right? i will not be able to run unity8 desktop
<woobydooby> but i'll be able to play with mir in a vt
<duflu> I'm not sure actually. Depends which PPA/silo...
<duflu> I need to go visit the winter air for a while
<woobydooby> hehe
<woobydooby> lp  ~mir-team/+archive/ubuntu/staging
<woobydooby> dufu can an abstraction layer above mir help with the abi breaks? (not coder here, just thinking), so then.. mir can move much faster, you'll probably also need to update the abrsraction layer with mir but will not break the stuff above
<RAOF> Welcome to lp:miral :)
<woobydooby> OMG! that's so cool! like totally cool
<woobydooby> :P
<woobydooby> konverstaion eating 200% cpu, i've seen this with all qt5 apps
<woobydooby> back to irssi
<woobydooby> kde apps
<greyback> alan_g: your MPs are landed in trunk
<alan_g> greyback: thanks
 * alan_g looks forward to POC Qt compositing landing too
<greyback> alan_g: another bump from qtmir: https://code.launchpad.net/~gerboland/miral/qt-bump-to-qtmir-529/+merge/301168
<alan_g> greyback: ack. On my list
<greyback> alan_g: and I'd like your thoughts on a design matter I'm hitting. Please see https://code.launchpad.net/~gerboland/miral/qt-add-window-model-mir-side/+merge/301074
<greyback> just scan for the comments, I try to explain what I'm doing there
<alan_g> greyback: what's the question?
<greyback> alan_g: for one, I need to duplicate much of the miral::WindowInfo object, so that I can pass it across thread boundaries. I'm making my own copy
<greyback> I was considering adding a deep-copy method to WindowInfo
<greyback> but size & position are not included in that structure, but in the pointed-to Window
<greyback> hence just making my own WindowInfo struct, copying most of miral::WindowInfo into it
<alan_g> greyback: miral::WindowInfo::WindowInfo(WindowInfo const& that) :
<alan_g>     self{std::make_unique<Self>(*that.self)}
<alan_g> That's a deep copy
<greyback> ah. I missed that
<greyback> ok, I just need to see about window size & position
<alan_g> It doesn't deep copy the Window properties
<greyback> yeah
 * alan_g has an ambition to remove the member functions from Window, but hasn't achieved that yet
<greyback> oh good to know
#ubuntu-mir 2016-07-27
<duflu> greyback: I'm auditing devices to see if we're ready for turning off input resampling. It's looking OK so far (mostly as the touchscreens are emitting events at the same rate as they redraw now). Do you have any knowledge of relevant software changes?
<greyback> duflu: there were no software changes on my end
<duflu> Oh, except we need to go slower than the refresh rate to overcome the nesting penalty :(
<alan_g> greyback: is there any way I can help with the Qt integration?
<greyback> alan_g: until I've the foundations set up, not really. I will propose a series of MPs today
<duflu> Hmm, my touch screen test was flawed. I forgot Mir's Android platform still has https://bugs.launchpad.net/mir/+bug/1369763
<ubot5> Launchpad bug 1369763 in Mir "[performance] Android overlays don't honour eglSwapInterval 0" [Medium,Triaged]
<greyback> alan_g: when you return, I need a hand with one thing
<greyback> https://code.launchpad.net/~gerboland/miral/qt-add-window-model-qt-side/+merge/301261
<greyback> please grab that and test the "qml-demo-shell" with a client
<greyback> problem is that as I'm overriding the MultiThreadedCompositor implementation, there is nothing who calls WindowManager::add_display
<greyback> do you know any handy way I can get access to the WindowManger object?
<alan_g> greyback: A hack (that we would need to address later) would be to use a customized version of SetWindowManagmentPolicy that keeps a weak_ptr<> to the object it builds that you can grab.
<greyback> alan_g: ack. Was what I was thinking, but wanted to run it by you
<alan_g> I can thing of a couple of uglier hacks. But really its the Mir wiring that is wrong - if you can override MTC you ought to be able to do the stuff the default does.
<alan_g> *it's
<alan_g> greyback: a (slightly) better hack: std::dynamic_pointer_cast<AbstractShell>(server.the_shell())
<anpok> you need to replace the shell?
<greyback> only just :)
<anpok> the AbstractShell..
<greyback> I'm gonna rewrite it in Qt
<greyback> because, you know
<greyback> :D
<greyback> (kidding)
<anpok> Thats not funny.
<alan_g> anpok: he just needs to call a method on AbstractShell and Mir doesn't make it easy
<alan_g> /o\ The downcast isn't needed
<alan_g> greyback: you can just grab server.the_shell() and call add_display() Shell IsA DisplayListener
<greyback> alan_g: ah, not so bad
 * alan_g must do penance for thinking Mir got it wrong
<anpok> hehe
<anpok> inconceiveable thought
<alan_g> You keep using that word. I do not think it means what you think it means.
<anpok> kdub: is there an easy way to figure out if a BufferStreamId is represented by a buffer stream and not a buffer chain
<anpok> kdub: I dont want the client to regularly throw and catch on resize events
<greyback> alan_g: ok, I've MPs up for your reviewing pleasure.
<greyback> it's all a bit rough and WiP, but the main idea is there
<greyback> and gedit is usable
<alan_g> greyback: thanks
<kdub> anpok, no by design, because the server has no distinction between the two
<kdub> its really just for the benefit of the client that there's a distiction
<anpok> so they also share the same id space
<kdub> right, server-side they are both mc::Stream
<alan_g> greyback: nothing really bad. Looks like progress.
<alan_g> But I did crash it rather easily: By connecting gnome-terminal and then starting mir_demo_client_egltriangle from that.
<greyback> alan_g: ack. I'm not claiming it is very stable
<greyback> the model syncing stuff isn't great
<alan_g> That's something I can help with once we have a skeleton POC
<alan_g> greyback__: not pushed qt-add-window-model-qt-side?
<greyback__> alan_g: pushed now
<alan_g> ta
<greyback__> sorry
<greyback__> alan_g: just one nitpick with https://code.launchpad.net/~alan-griffiths/miral/add-indirection-to-stabilize-WindowManagerTools-ABI/+merge/301299
<alan_g> greyback__: thanks - I'll get to it in the morning. (And yes, renames work pretty well in CLion.)
<greyback__> alan_g: even -> to member access?
<greyback__> anyway, have a nice evening
<alan_g> that was just a global text substitution.
#ubuntu-mir 2016-07-28
<duflu> tsdgeos: I need your advice. A QML scrolling bug that still exists under Unity7 is which component (not QtMir I assume)?
<tsdgeos> duflu: it depends i guess, what kind of bug?
<duflu> tsdgeos: Speed/accuracy. If I'm running Unity7 then it's not QtMir, surely. What component is it?
<tsdgeos> duflu: i guess you could start with qtdeclarative-opensource-src
<duflu> tsdgeos: That's it, thanks
<tsdgeos> i don't understand exactly what you mean with accuracy
<duflu> tsdgeos: I mean webbrowser app scrolls well but dash and systems settings do not
<duflu> Even under unity7
<ohNoes_> sup all
<ohNoes_> the scroll is too fast now with Xmir
<ohNoes_> like when you scroll down on g+ it scrolls like 3 screens or such
<ohNoes_> worked fine before
<ohNoes_> xmir/yakkety-proposed,now 2:1.18.4-1ubuntu4 amd64 [installed]
 * duflu looks
<duflu> ohNoes_: Yeah are you using a laptop touchpad?
<duflu> ohNoes_: Please let me know what device you're using for scrolling. I'm working on triaging those issues right now
<duflu> Hmm is G+ a native or web app?
<duflu> I've never looked
<ohNoes_> duflu: mouse wheel
<duflu> ohNoes_: That's weird. Mouse wheels should not have changed. Any other basic apps affected?
<ohNoes_> duflu: run firefox on xmir, open g+ or any other longish page
<duflu> OK, I'll do that now.
<ohNoes_> scroll up and down with  mouse wheel
<ohNoes_> tried with geany, firefox
<duflu> I'm presently doing an Xmir and scrolling bug overhaul
<ohNoes_> nice :D
<ohNoes_> would be awesome.. like totally awesome to have a way to configure the scroll rate
<ohNoes_> maybe in system settings or something
<duflu> ohNoes_: System Settings suffers from bug 1605513 which is different. Thanks for pointing out the regression with Firefox!
<ubot5> bug 1605513 in qtdeclarative-opensource-src (Ubuntu) "Touchpad scrolling in dash and system settings is disproportionately faster than mouse wheel scrolling" [Undecided,New] https://launchpad.net/bugs/1605513
<ohNoes_> np :D
<duflu> ohNoes_: I can't reproduce any regression. Can you suggest another test case?
<ohNoes_> duflu: run firefox on Xmir, go to reddit.com, scroll down once (with the scroll wheel) and then count how many lines down. tap the arrow key UP until you are at the top of the page
<duflu> ohNoes_: Yep I figured it out thanks...  https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1607240
<ubot5> Launchpad bug 1607240 in unity8 (Ubuntu) "Xmir Firefox scrolling is too fast (mouse wheel) when run under Unity8 (since Xmir 2:1.18.4-1ubuntu4)" [Undecided,Confirmed]
<ohNoes_> duflu: if i scroll down once it goes 8 lines down
<duflu> Yeah
<ohNoes_> yay :d
<duflu> Saviq: Can you tell me what code in Unity8 synthesises the vscroll events from Qt wheel angles?
<duflu> What source package?
<anpok> duflu: i guess you need: http://bazaar.launchpad.net/~mir-team/qtmir/trunk/view/head:/src/modules/Unity/Application/mirsurface.cpp#L106
<anpok> and http://bazaar.launchpad.net/~mir-team/qtmir/trunk/view/head:/src/platforms/mirserver/qteventfeeder.cpp
<duflu> anpok: Thanks. But I found the answer (to multiple questions)
<duflu> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1607240/comments/6
<ubot5> Launchpad bug 1607240 in unity8 (Ubuntu) "Xmir Firefox scrolling is too fast (mouse wheel) when run under Unity8 (since Xmir 2:1.18.4-1ubuntu4)" [Undecided,Confirmed]
<duflu> ohNoes_:  https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings/+bug/1607240/comments/6
<ubot5> Launchpad bug 1607240 in unity8 (Ubuntu) "Unity8 default mouse wheel speed is 7.0 (it should be 1.0)" [Undecided,Confirmed]
<duflu> That will break non-Xmir apps but it's a start. We need to fix scrolling in multiple components still
<ohNoes_> oh wow! that worked just fine! thanks duflu :D
<duflu> Kind of. Except it's broken elsewhere now
<ohNoes_> yeah but it fixed muh firefox :D
<ohNoes_> for now
<ohNoes_> sort of
<ohNoes_> duflu: omg! this is super awesome! right? i mean the fact that you can change the scroll rate and it works. you can't do the same with unity7 right? i remember opening a such a bug like years ago
<duflu> ohNoes_: Yeah but it's not labelled. Just magic
<ohNoes_> awesome black magic :D
<duflu> anpok: Weird. QtMir multiplies vscroll by 15 to make angleDelta. And then on the way out just sets client vscroll = angleDelta. No division
<ohNoes_> duflu: smooth scrolling in gedit/Xmir only works with the keyboard or with the mouse wheel but only if the mouse pointer is over the scroll bar (when the scroll bar gets wider). if you try to scroll with the mouse wheel and the pointer is not hovering the scroll bar you get jerky scrolling, totally not smooth. maybe iz related
<duflu> ohNoes_: I know. It's a bit messy right now. Unity8 multiples, decimates, and then only partially unmultiples scroll values. We need to clean it all up... but multiple parts all at once
<duflu> "multiplies" I mean
<duflu> ohNoes_: By the way the keyboard is unrelated. Different code
<ohNoes_> even so, i find it amazing that i can change the scroll speed! :D
<ohNoes_> +1 will use unity8 again
<duflu> Hah. Yeah. It would appear more weird. Unity8 converts QtMir's scroll tick of 1 to 15. And then system settings' default scale is 0.5. So apps get +7/-7 instead of +1/-1
<duflu> The left hand doesn't know what the right hand is doing
<ohNoes_> X-)
<duflu> Anyway, that's progress. My only goal was to fix Xmir if required and it's not required. Dinner time
<alan_g> duflu: yes, just tried in miral+Xmir. Seems fine
<duflu> Yeah I would expect so
<duflu> Good night
<greyback_> alan_g: should I avoid referring to mir::scene::Surface and try use miral::Window as much as possible? Will Window grow to encapsulate more than a single surface?
<alan_g> greyback_: try to use Window. A Window will always correspond to a Mir Surface (but that can have multiple bufferstreams)
<greyback_> alan_g: ack. I've no objection, just wanted to be sure which direction your api is going
<alan_g> Really I'd like Window to go the way that Application did and for it just to be an identifier. But the APIs to allow that are not there yet.
<alan_g> Once your stuff is working I will do another pass at making that work.
<greyback_> ok
<alan_g> greyback_: any time you can't use the miral APIs is a time we need to enhance miral.
<alan_g> But don't let that stop you getting things working
<greyback_> alan_g: true
<greyback_> but I know you've plans for them too
<greyback_> just want to avoid jmping on something you're about to kill
<greyback_> alan_g: I could do with your perspective. Please have a look at lp:~gerboland/miral/add-interactivity-to-WM
<greyback_> just het last commit.
<greyback_> I'm trying to expose functionality provided in the WMPolicy
 * alan_g looks..
<greyback_> but getting access to the created WMPolicy isn't obvious to me, as it's wrapped with a builder which is only run inside the BasicWM
<alan_g> Can you pass the constructor somewhere to register the interface you want it to support? The the constructor just does "connector->register(this)" ... and the destructor can deregister
<greyback_> Yep. That was an option I was considering.
<greyback_> I can't really think of anything else
<greyback_> thanks
#ubuntu-mir 2016-07-29
<duflu> robert_ancell: The new Xmir seems technically correct but we've found it uncovers serious mouse wheel bugs in Unity8. Might need to hold Xmir till we can fix the whole stack at once
<duflu> Or just land it to motivate the fixes :)
<robert_ancell> duflu, it is landed into yakkety right?
<duflu> robert_ancell: It's proposed still. I don't mind which way it goes but it will motivate us to fix Unity8 pretty quickly when released
<robert_ancell> duflu, is there a bug tracking this?
 * duflu swears lots at Launchpad timeouts
<duflu> robert_ancell: Yeah I've got at least one open and emailed unitymirteam
<robert_ancell> duflu, do you know how to block it in -proposed?
<duflu> Nope
<duflu> I can do a Unity8 fix myself probably today. But have no idea what project the remaining code for Qt apps lives in
<duflu> They are interpreting vscroll as a number of pixels instead of a number of mouse wheel ticks. So scroll too slow
<bregma> that'd be somewhere deep in the SDK I imagine
<duflu> Yeah I need to search for dependents of libmirclient
<duflu> Interesting it seems both touch events and scroll events get slightly crippled by Qt as they pass through Unity8. Clients don't get accurate data if they're under Unity8 and we can't easily fix it without upstream Qt changes
<OhNoes_> hi all, so i just upgraded to firefox 48 and it's unusable with Xmir
<OhNoes_> :'(
<OhNoes_> firefox 48 is already in 16.10
<duflu> Fixes are coming. Surprisingly this also allowed me to fix high-resolution touchpad scrolling precision
<duflu> Which we thought would not be fixable for Unity8
<OhNoes_> yay! :D
<duflu> anpok: Hopefully your fixes are ahead of me already? :) ... https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bugs?field.tag=gtk-mir
<anpok> duflu: I dont know what you mean.. but I spent this week on mir again, because I triggered to many bugs there when fixing the gdk backend.
<duflu> anpok: I mean I assume you already fixed some of those GTK bugs upstream,,,?
<anpok> in the process of doing so... I will have to reshuffle the patches and sort out those which are still blocked..
<alan_g> anpok: IIRC you mentioned something about cut&paste support in gtk-mir recently?
#ubuntu-mir 2017-07-27
<alan_g> Hey RAOF, have you tracked down the next shutdown race?
<RAOF> alan_g: I have!
<RAOF> alan_g: It is terrible!
<alan_g> RAOF: Great!
<RAOF> alan_g: Check out the latest commit on https://code.launchpad.net/~raof/mir/no-ipc-on-compositor-threads/+merge/326827
<RAOF> I think it's failing another test, and it's ugly.
<alan_g> RAOF: ack. Will look
#ubuntu-mir 2017-07-28
<alan_g> greyback: fixed the (pre-existing) bug you found in lp:~alan-griffiths/mir/fix-1706718/+merge/328171
<greyback> alan_g: ack
 * alan_g wishes it had been spotted in the MP that introduced it. So much easier to track down!
<greyback> alan_g: approved
<alan_g> what are you passing to --x-cursor-theme? demo_server is a lot picky (not like miral-shell)
<alan_g> greyback: what cursor set did you ask for?
<greyback> alan_g: I installed breeze-cursor-theme, and tried asking Mir for "breeze" "breeze_cursors" "Breeze_SNOW"
<greyback> possibly user error, but the lack of any error was annoying
<alan_g> greyback: those will only work with miral, demo_server needs exactly the size image it asks for.
<greyback> alan_g: ah ok
<greyback> I wanted to test another cursor theme, maybe with different sized images, to ensure the hardware cursor kept working
<greyback> since I know it is particular about sizes (which you've written code to accomodate)
<alan_g> greyback: if you build & use "miral-desktop --cursor-theme breeze" against this it should play nice
<greyback> alan_g: ack, miral is building
 * alan_g muses: Several times GObject has loomed on my horizon. But on each occasion so far it has passed me by. I wonder what will save me before Monday?
<greyback> alan_g: cursors and miral work ok, thanks
<alan_g> greyback: thanks for the independent confirmation.
<alan_g> It's tempting to cherrypick a Mir 0.27.1 & MirAL 1.5 release.
