#ubuntu-mir 2013-07-29
<RAOF> Ok. What's on the list of "omg must be fixed" for landing now?
<bregma> RAOF, the definitive landing list is https://bugs.launchpad.net/mir/+bugs?field.tag=entering-saucy
<RAOF> Ok, that was what I was looking at.
<duflu> bregma: Did mir ever support non-Android armhf? I suspect a fix could be quite non-trivial. Particularly if you need to avoid compiling the Android bits and don't have any adequate substitute for them. It could be a challenge to make it build at all...
<bregma> duflu, I don't believe it was ever tested if it did support non-android on arm
<duflu> bregma: It might require a stub graphics driver implementation. Which is related to https://bugs.launchpad.net/mir/+bug/1118903
<ubot5> Launchpad bug 1118903 in Mir "Mir lacks a software rendering backend" [High,Triaged]
<bregma> maybe I'll play with that in my tomorrow
<RAOF> duflu: It should work on non-android with one of the free arm drivers.
<RAOF> duflu: If we happen to have any device supported by freedreno, of course :)
<duflu> RAOF: Are such things available on Qemu/Pandaboard?
<duflu> Should be for Panda anyway
<RAOF> What's the GPU on a pandaboard?
<duflu> RAOF: SGX540, http://pandaboard.org/content/platform
<duflu> Though it usually gets bundled into what's known as an omap4 driver
<duflu> I think
<RAOF> Hm, then not currently supported.
<duflu> bregma: Also, I think alan_g is working on the driver model. It's quite likely you need a quicker fix than when such a thing will be ready
<bregma> yep
<bregma> I think short-term strategy is to just not run the android-specific tests during packaging (as opposed to not running any tests, which is what we have now)
<duflu> There is some Android-specific linkage in there too... libhybris
<tvoss> good morning :)
<tvoss> RAOF, ping
<RAOF> tvoss: Pong.
<RAOF> Good morning!
<RAOF> Oh, you don't have to travel *nearly* as far to get to IOM.
<RAOF> That's why you're online :)
<tvoss> RAOF, yeah :) I'm mostly in the usual timezone
<tvoss> RAOF, waiting for the gym to open up
<duflu> Morning tvoss
<tvoss> duflu, good morning
<tvoss> duflu, how goes?
<duflu> tvoss: Almost good. Spent the weekend dealing with drain blockages. And I'm a bit unwell today...
<duflu> tvoss: How are you?
<tvoss> duflu, pretty good, waiting for the gym to open :) on the IoM
<alf__> duflu: Hi! I remember at some point you had a branch for a demo display server in which you could move client windows around. Do you have this still somewhere?
<duflu> alf__: Umm, that feature landed ages ago :)
<duflu> alf__: mir_demo_server_shell, and then Alt+drag (or three finger drag)
<alf__> duflu: Hmm, the demo shell makes all windows full screen, that's why I couldn't find it. I guess I need to replace the fullscreen policy.
<duflu> alf__: Not really. Demo shell only sizes all surfaces to fullscreen. The "fullscreen" state and policy is not set/enforced so they're still moveable
<alf__> duflu: ok, thanks, although I'd like the surfaces not to be fullscreen for demo purposes.
<duflu> alf__: Yeah, I've done the same for testing. Just remove a single line. You know which one
<alf__> duflu: thanks
<duflu> I'm almost disappointed more people have not played with our primitive window management yet
<dholbach> good morning
<duflu> Morning dholbach
<dholbach> hey duflu
<RAOF> Why am I surrounded by slow computers?!
<Saviq> robert_ancell, http://bazaar.launchpad.net/~mir-team/unity-mir/trunk/revision/20
<robert_ancell> Saviq, lp:~robert-ancell/unity-mir/libmirserver-includes corrects all the includes, though it doesn't build for me since the -I flags aren't being passed to the compiler so the includes don't resolve
<Saviq> robert_ancell, I had the same before - remove your CMakeCache.txt
<Saviq> robert_ancell, and see the output from cmake
<Saviq> robert_ancell, http://www.cmake.org/Bug/view.php?id=14310
<robert_ancell> Saviq, doesn't exist - this is a fresh debuild from trunk
<Saviq> robert_ancell, I expect you're missing a dep, but cmake completes because of the bug above
<Saviq> robert_ancell, try with mk-build-deps -s sudo -i
<robert_ancell> Saviq, ok, in that case the dep must be missing from debian/control
<Saviq> robert_ancell, ok, let me try
<robert_ancell> Saviq, mk-build-deps didn't help
<Saviq> robert_ancell, right, I only grepped for < includes
<Saviq> robert_ancell, trying in sbuild now
<Saviq> robert_ancell, trunk built fine, trying your branch
<duflu> alf__: Moving surfaces across monitors, I presume... ?
<alf__> duflu: exactly
<Saviq> robert_ancell, your branch builds just fine in sbuild, too...
<seb128> Saviq, robert_ancell: I don't have the start of the backlog, but that vcs fails to build for me on missing ubuntu_application_api_mirserver_priv.h
<robert_ancell> seb128, my one or trunk?
<duflu> RAOF: I can actually reproduce the lag with demo_client_fingerpaint too
<seb128> robert_ancell, lp:~robert-ancell/unity-mir/libmirserver-includes
<seb128> robert_ancell, hey btw, enjoying IoM?
<robert_ancell> seb128, yeah, you not here?
<seb128> robert_ancell, no, didn't get invited to this one...
<Saviq> robert_ancell, is this the same failure you get?
<seb128> Saviq, dpkg -S ubuntu_application_api_mirserver_priv.h ?
<robert_ancell> Saviq, I get http://paste.ubuntu.com/5924478/, but that sounds like the include path not being set again
<robert_ancell> actually, no that sounds like a unity api issue, not a mir issue
<Saviq> robert_ancell, are you using the mir integration ppa for that, though?
<Saviq> robert_ancell, maybe there's something there that's not yet in mir trunk?
<Saviq> robert_ancell, seb128 'cause it builds fine for me with https://launchpad.net/~phablet-team/+archive/mir/
<robert_ancell> Saviq, I'm using didrocks daily-build-next PPA, but that's not a mir header
<Saviq> in an sbuild, so starting from a clean slate
<seb128> Saviq, robert_ancell: I'm using daily-build-next as well
<seb128> too many ppas :/
<seb128> we need things in the archive
<robert_ancell> seb128, we have face time to try and make that happen this week :)
<seb128> robert_ancell, good luck ;-)
<Saviq> seb128, yeah, of course, just this stuff (unity-mir integration) is not yet archive-ready
<Saviq> seb128, it's not even image-ready yet (so it's not there yet)
<mlankhorst> morning
<mlankhorst> seb128: if it was ready for the archive I would agree, but I don't think it is currently. :P
<duflu> Hmm, having a bad run. Every time I update any system lately, it breaks for a new reason
<duflu> Has anyone else had trouble with system-compositor-testing?
<duflu> I've just updated and can't start X at all any more
<RAOF> I upgraded my ATI box from raring to saucy and added that PPA, and it worked this morning
<RAOF> FSVO âworkedâ, of course.
<RAOF> (values of âworkâ may include https://bugs.launchpad.net/mir/+bug/1204939)
<ubot5> Launchpad bug 1204939 in Mir "Unity doesn't start on ATI test machine (fails to find GL acceleration) (logind fails to track session?)" [Critical,Triaged]
<duflu> RAOF: No, this is intel. I shall update again to be sure, then log a bug
 * duflu realizes he doesn't need X to compile and run on Android
<duflu> But a desktop would be nice...
<duflu> Argh! Can't log bugs without a browser :(
<duflu> RAOF: Any ideas? https://bugs.launchpad.net/xmir/+bug/1206067
<ubot5> Launchpad bug 1206067 in XMir "X crashes on startup. Can't log in." [Critical,New]
<duflu> RAOF: Oh, the callstack matches an existing bug. Duplicate...
<mlankhorst> so what ati has issues?
<mlankhorst> ok wtf
<mlankhorst> yeah it definitely hits the wrong path on ati
<mlankhorst> which is funny since I don't see how it could.. ah well maybe #error reveals :P
<mlankhorst> [  2025.510] (II) Module "dri2" already built-in
<mlankhorst> [  2025.510] (II) Loading sub module "exa"
<mlankhorst> [  2025.510] (II) LoadModule: "exa"
<mlankhorst> [  2025.515] (WW) Warning, couldn't open module exa
<mlankhorst> [  2025.515] (II) UnloadModule: "exa"
<mlankhorst> [  2025.515] (II) Unloading exa
<mlankhorst> [  2025.515] (EE) Failed to load module "exa" (module does not exist, 0)
<mlankhorst> hm o.O
<mlankhorst> RAOF: I seem to be losing the exa module when I restart X.. did you add an unlink somewhere?
<mlankhorst> oh nm, you're installing it wrongly..
<mlankhorst> the modules appear to be installed to /usr/lib/xorg, not /usr/lib/xorg/modules..
<alf__> alan_g|tea: @multimonitor-gbm-display, what's the benefit of using vector::swap() instead of moving the contents?
<alan_g> alf__: it is as efficient, and less typing
<alf__> alan_g: it doesn't matter in this case, but with swap() object deletion is delayed until the temp vector goes out of scope
<alan_g> alf__: yes
<racarr> Mornnnning
<alf__> racarr: hi
<alan_g> racarr: Afternoon
<hikiko> bye
<racarr> XD. playing around in msh::...
<racarr> "Factory, Builder, Controller, and Source"
<racarr> are tghe surface interfaces -.-
<racarr> I dont think thats a pattern lol
<robert_ancell> RAOF, hey
<racarr> today is finally the death of single visibility focus mechanism
<racarr> started trying to finish the last OSK requirement (client side initiated hide/show). which I guess is minimize/restore. I realized the input stack doesn't ignore hidden surfaces, so I implemented that. Implementing that breaks existing multiple client input acceptance tests though, so I need to rebuild the single visibility focus mechanism to raise surfaces instead
<racarr> which is just almost finished :) then I think I will go back and add a second method to the SurfaceConfigurator, like
<racarr> attribute_applied
<racarr> and then unity8 can implement hide/show in response to minimize/restore
<racarr> hook it up in QT boom
<racarr> :)
<racarr> LUNCCCH
<racarr> back
<racarr> feels great to kill single visibility focus mechanism
<bschaefer> :), nice!
<racarr> the pervasive threading makes the input acceptance tests so hard...every time there is some little surprise.
<racarr> for example.
<racarr> inject_event_to_event_hub. hide_surface. inject_eent_to_event_hub
<racarr> is racy because the event isnt targeted until it gets to the dispatcher
<bschaefer> o .. so it might get to the wrong surface? So if you have the stack as A > B, then inject event wanting to go A, then hide, it'll get to B sometimes?
<racarr> yeah
<racarr> and its always like this so you always have to find a different way to synchronize it
<bschaefer> :( stacking issues are never fun
 * bschaefer has flash backs of compiz stacking
<racarr> and it seems like there is rarely a pattern
<racarr> aha yeah
<racarr> it's really mostly a test bug because
<racarr> in real behavior, if a surface is destroyed in between reading an event from the device and targeting it to a surface
<racarr> then...that's just what happened
<racarr> and it goes to a different surface XD
<bschaefer> so if a surface is hidden you destroy them?
<bschaefer> or rather, it goes from showing to hidden?
<racarr> err, s/destroyed/hidden
<bschaefer> right, just double checking :)
<racarr> RIght
<racarr> its only a problem when you need to orchestrate a particular series of events in a test or something
<bschaefer> a unit test...you can add a bunch of sleeps :)
<bschaefer> i mean hard for a unit test*
<racarr> no :( sometimes full server tests take a LONNNG time
<racarr> like valgrind in qemu
<racarr> so the sleep has to be really high
<racarr> but then tests would take too long
<racarr> plus it's an acceptance test XD it would be pretty hard for a unit test
<bschaefer> o my...yeah you don't want that
<racarr> would be nice to have cucumber for input acceptance tests
<racarr> Given a surface at 75,40 with size 30,30 and a surface at 63, 20 with size 50, 50, and the first surface is maximized, when a button is pressed then the first surface will...
<racarr> hahahaha...
<racarr> the fixture
<bschaefer> thats what cucumber can do? That is nice!
<racarr> would be hard to design though because
<racarr> of all these synchronization problems
<bschaefer> I've seen it in lp:mir, but i've never used it
<racarr> the thing is you implement these constructs
<racarr> given, when, then
<racarr> and the test format is
<racarr> given, and given, and given...when...and when...and when...then and then and then bla bla
<bschaefer> do you have to rebuild/tear down the server for each test?
<racarr> but the constructs are just regex
<racarr> with parameters
<racarr> and its hard to come up
<racarr> with a set of words and sentence and such
<racarr> that you can match with regex that describe your problem domain XD
<racarr> yeah normally
<bschaefer> yeah, well regex isn't always easy on the eyes either
<bschaefer> unless you are doing it a lot haha
<kdub> boost, gtest/gmock is like the perfect storm of compiler errors
#ubuntu-mir 2013-07-30
<duflu> Anyone know if VT switching has been descoped/deprioritized for USC?
<duflu> I mean... https://bugs.launchpad.net/mir/+bug/1192429
<ubot5> Launchpad bug 1192429 in Unity System Compositor "unity-system-compositor is on multiple simultaneous (and random) VTs" [High,Triaged]
<RAOF> duflu: Man, is your house built on quicksand or something?
<duflu> RAOF: Old suburbs...
<RAOF> â¦are nice, but obviously don't have the maintenance thing worked out.
<duflu> RAOF: Hey it's better than it used to be. For the first few years here I had a blackout every month or two
<RAOF> Although *my* old suburb doesn't seem to suffer from those problems (so farâ½). They *are* digging up the pavement, but that's to lay pipes for sweet, sweet fibre.
<duflu> RAOF: You win :/
 * RAOF heads out to lunch
<hikiko> hi
<RAOF> Hi!
<mlankhorst> g'day mate
<hikiko> :)
<mlankhorst> RAOF: but what good is fibre if you are limited by laggy intercontinental links. :P
<RAOF> mlankhorst: All the content that I can get locally is fast?\
<RAOF> Also, my uplink will be faster than the current anaemic 200-odd-KB/sec
<RAOF> And *those* links aren't saturated :)
<RAOF> Oooh! *That* might be why lseek isn't working!
<RAOF> Dear launchpad: 250kB/s. Really?
<ubot5> Error: Launchpad bug 250 could not be found
<RAOF> _Really?_
<hikiko> lol
<hikiko> RAOF, is there any script (eg ident) that I could run to fix all the formatting errors before I submit a branch?
<hikiko> indent*
<RAOF> Not that I'm aware of.
<RAOF> If you find one or make one (maybe it's possible to make an appropriate indent incantation?) please let me know :)
<hikiko> sure :)
<RAOF> Grr. We're going to need to throw away logind.
<dholbach> good morning
<RAOF> Good morning dholbach!
<dholbach> hey RAOF
<RAOF> ARGH!
<tvoss> alf__, ping
<alf__> tvoss: pong
<robert_ancell> RAOF, ping
<mlankhorst> ok that should fix the random lockups I was getting on radeon, had too much debug stuff on and the one I wrote broke :(
<didrocks> robert_ancell: kgunn: I just accepted Mir in universe \o/
<robert_ancell> didrocks, yay!
<kgunn> didrocks: a serious thanks for all the help
<didrocks> kgunn: no worry ;)
<kgunn> olli_: ^
<kgunn> boom
<olli_> kgunn, missing context
<olli_> but I assume something hit universe?
<olli_> robert_ancell, ^?
<robert_ancell> <didrocks> robert_ancell: kgunn: I just accepted Mir in universe \o/
<didrocks> olli_: yeah, "something" :-)
<seb128> congrats guys ;-)
<olli_> tvoss, ^
<didrocks> (it just hit it, didn't crash ;))
<didrocks> beautiful landing
<tvoss> didrocks, \o/
<seb128> didrocks, beautifully work as well if I want to install it? ;-)
<didrocks> seb128: needs now xmir being in distro and the patches for the drivers
<didrocks> then u-s-c will land in distro
<seb128> ok, a bit of extra waiting, I guess
<seb128> I'm sure there will be an email announcing the details once things are in place, going to wait for that ;-)
<didrocks> be warned, seb128 is ready!
<seb128> ;-)
<robert_ancell> kgunn, are you held up?
<RAOF> robert_ancell: Pong
<robert_ancell> RAOF, hey, is there still a regression in the -staging PPA that stops us copying to system-compositor-testing?
<RAOF> Hm, yes.
<RAOF> The intel driver will regress if we do that.
<duflu> robert_ancell: I found the new lightdm in staging broken my (raring) system on the weekend. Had to revert the new lightdm from staging
<robert_ancell> RAOF, what needs to be done to fix that?
<RAOF> robert_ancell: Fix the patch, basically. I'll upload a new intel tomorrow to the distro, and also to staging.
<robert_ancell> RAOF, can we revert for now so we can fix asap?
<RAOF> Actually, if Mir has landed in-distro, maybe I'll just upload straight to distro?
<duflu> Is this related to https://bugs.launchpad.net/xmir/+bug/1203776 ?
<ubot5> Launchpad bug 1203776 in XMir "X crashes w/ xserver-xorg-video-intel 2:2.21.9+xmir5870-1~saucy1 from System Compositor Testing PPA" [Critical,Triaged]
<robert_ancell> RAOF, can't until the MIR is complete
<RAOF> duflu: Yes.
<RAOF> robert_ancell: Oh, that's right. Not yet in main.
<robert_ancell> RAOF, but once that is done, yes
<robert_ancell> RAOF, can we revert?
<RAOF> Looking.
<RAOF> Oh, that's right.
<RAOF> I'm not sure that we *do* regress with what's in staging.
<RAOF> Or, at least, I'm not sure that the bugs in staging are the bugs in -intel :/
<RAOF> Anyway, reverting.
<alan_g> alf__: sees you've re-approved a lot of spurious failures. Is there a pattern to worry about?
<alan_g> *seems
<alf__> alan_g: I am not sure yet, let's see how the second reapproval goes
<kgunn> RAOF: is the -testing ppa intel issue simply worked around by accelOption = uxa
<kgunn> in xorg conf
<RAOF> kgunn: Yes.
<robert_ancell> RAOF, is  xserver-xorg-video-intel - 2:2.21.9+xmir15871-2~saucy1 the intel driver that should work?
<RAOF> Yes
<robert_ancell> RAOF, ta
<RAOF> tvoss is smoke testing
<kgunn> flickering is really bad
<kgunn> on my machine
<kgunn> but....push it
<RAOF> kgunn: With 2:2.21.9+xmir15871-2~saucy1?
<RAOF> Really?
<RAOF> That's new as of 5 minutes ago.
<kgunn> RAOF:  oh...need to test that
<RAOF> robert_ancell: Oh, how do I build lightdm from trunk?
<RAOF> I know I've asked you this before, but I think logind has gone and become more annoying.
<robert_ancell> RAOF, are you getting llvmpipe issues?
<RAOF> robert_ancell: As in - software rendering? Yes.
<robert_ancell> RAOF, can you look in /var/log/auth.log?
<robert_ancell> I had these issues last night
<RAOF> What would be in there? Is *that* where logind does it's logging?
<robert_ancell> RAOF, I had pam_systemd failing and reverting to the CK backup. Apparently that doesn't work for DRM anymore
<robert_ancell> RAOF, symptons are loginctl showing no sessions, ck-list-sessions showing sessions and the auth.log complaining about a /var/run directory already existing
<RAOF> robert_ancell: Ah, no. That's not my problem. I've got loginctl showing my session, just that it's not active.
<robert_ancell> RAOF, ok. To build lightdm it just get tarball and overlay debian/ from latest package
<robert_ancell> yes, yuck
<robert_ancell> RAOF, what do you need exactly?
<RAOF> robert_ancell: I need to write a blueprint, but we basically need to replace logind
<RAOF> robert_ancell: But http://paste.ubuntu.com/5928462/ should work as a stop-gap.
<robert_ancell> RAOF, shouldn't that be XDG_VTNR?
<alan_g> alf__: I'm looking into the graphicsplatform dependencies on frontend...
<RAOF> robert_ancell: Possibly. I'll recheck logind code.
<robert_ancell> RAOF, and that's now set in src/x-server.c
<alan_g> Is there any reason InternalNativeSurface::get_parameters() uses the surface, not the buffer to get the size?
<alf__> alan_g: At the moment the buffers and the surface have the same properties. I am not sure if/how support for resizing will affect this.
<alan_g> alf__: Would you be happy if I used the buffer properties and left any resizing issues for the future?
<RAOF> robert_ancell: You never actually set XDG_VTNR for unity seats.
<robert_ancell> RAOF, ah, k
<RAOF> Because you (quite sensibly) never set the xserver's VT number for unity seats.
<robert_ancell> RAOF, this is for fallback?
<RAOF> No, this is for u-s-c
<robert_ancell> RAOF, ah, ok
<alf__> alan_g: Sure, but I would also like to get Kevin's opinion later, since he is more familiar with the needs of the internal client.
<RAOF> I *think* we need to set the vt so that logind doesn't have a screaming hissy fit.
<robert_ancell> RAOF, can you file a bug / make branch - I'll just push that into main
<alan_g> alf__: Sure, I'm just using you as a first sanity check. ;)
 * robert_ancell has to wait again before updating the -testing PPA while mir decides to build *again*
<RAOF> robert_ancell: Will do, once I've tested that this actually fixes my problem.
<robert_ancell> RAOF, k
<duflu> alf__: Have you ever seen gcc optimize out functions, causing mock expectation failures?
<robert_ancell> thomi, can you block the CI uploading to the staging PPA?
<robert_ancell> thomi, there's new revisions landing faster than they're building
<thomi> robert_ancell: shouldn't we just let it catch up?
<robert_ancell> thomi, we'll never get a finished build at this rate
<robert_ancell> it's building 894 at the moment, but 895 is already in trunk
<robert_ancell> I need to get a built version and copy it over to -testing
<duflu> To the disassembler... :S
<thomi> robert_ancell: why can't we copy over the copy that's older than trunk?
<robert_ancell> thomi, when I go to copy from the PPA it only shows the building version, not the old one
<thomi> hmmm
<robert_ancell> didrocks, ^ don't know if we can get the previous built version?
<thomi> robert_ancell: we're on it
<alan_g> duflu: could it be that the mocks don't override the correct signature? (gmock doesn't use "override")
<duflu> alan_g: Thought of that. It's a match
<alan_g> duflu: or the base class forgot "virtual"?
 * alan_g knows these are silly, but so is the symptom
<duflu> alan_g: Nope
<alan_g> This is about the time I start adding #error to prove I'm looking at the right code. ;)
<duflu> alan_g, alf__: OK, I forgot LD_LIBRARY_PATH and unit-tests got some symbols from the wrong libmirserver
<duflu> What a fine waste of evening
 * alan_g wishes he hadn't done that too
<duflu> Of course, with rpath it would have been fine if I ran it on the build machine. But this is cross-compiled
<kgunn> RAOF: ping
<RAOF> kgunn: Pong
<kgunn> RAOF: hey...so robert & i got sunk by the very latest staging
<kgunn> seems x crashes...and boots us back out to the greeter (over and over)
<kgunn> i got logs
<RAOF> Yes please!
<kgunn> will attach them to a bug
<kgunn> RAOF: https://pastebin.canonical.com/95196/
<kgunn> there's that for the moment...launchpad being fussy
<kgunn> or our wifi is flakey
<RAOF> Hm. That's the wrong log :)
<RAOF> Or, rather, it's lightdm's log, which is useless, and I should really fix it's uselessness.
<RAOF> kgunn: Got /var/log/Xorg.0.log?
<kgunn> checking
<kgunn> RAOF: robert just looked over my shoulder...says "its a clean run"...so the xorg.0.log didn't have any useful info
<RAOF> kgunn: Ah.
<RAOF> Xorg.0.log.old might?
<kgunn> right...was looking in old
<RAOF> Ah.
<kgunn> robert's checking to see if he has a log
<kgunn> he's gonna turn on once more....just to make certain
<kgunn> RAOF: now he's having issues repro'ing....
<kgunn> i'm pretty reliable...i'll give another go
<RAOF> Cool.
<tvoss> RAOF, ping
<RAOF> tvoss: Pong.
<tvoss> okay, disabling the process group leader thingy helps
<tvoss> RAOF, Xorg.0.log says [     6.649] (II) intel(0): SNA compiled: xserver-xorg-video-intel 2:2.21.9+xmir15871-2~saucy1 (Chris Halse Rogers <chris@cooperteam.net>)
<tvoss> [     6.657] (II) intel(0): SNA initialized with Sandybridge (gen6, gt2) backend
<RAOF> Sweet. And setting XDG_VTNR does indeed fix acceleration, even with the tty detaching.
<tvoss> RAOF, okay, where do we need to set that?
<tvoss> RAOF, however, I'm experiencing the slowness issue right from the beginning
<RAOF> tvoss: In the lightdm branch I'm just proposing.
<tvoss> RAOF, awesome
<tvoss> so no need for me to mp removal of the session group leader stuff, right?
<RAOF> tvoss: Correct.
<tvoss> cool
<kgunn> RAOF: hey
<kgunn> just noticed xorg updated in main
<kgunn> arg
<kgunn> ...so new problem :)
<kgunn> right in the middle of me trying to repro
<RAOF> :(
<kgunn> RAOF: how long to rebase your patches on that ?...like...are we torpedo'd for the night ? (e.g. you have to sleep at some point)
<tvoss> kgunn, where are you?
<kgunn> in murry2
<tvoss> kgunn,  wanna hop over to the main ball room?
<kgunn> tvoss: ack...robert said he'll have the first dance
<tvoss> kgunn, fair :)
<kgunn> (seriously...i think maybe a 15min break to eat a bite...but i'll be right there after that)
<kgunn> RAOF: i'll still try to pin the ppa on staging to avoid the xorg from main....and then try to repro again
<kgunn> repro the xorg crash that punts me back out to greeter that is
<RAOF> I'll rebase xserver now.
<RAOF> I will be sleeping soon :)
<RAOF> tvoss: New xserver in staging, lightdm branch proposed for merging.
<RAOF> tvoss: Now, sleep.
<tvoss> RAOF, ack
<RAOF> tvoss: Oh, I haven't put up a blueprint for the logind work yet - I'll do that in the morning.
<tvoss> RAOF, no worries, go to sleep dude
<tvoss> and thanks for all the help
<kgunn> RAOF: so as a test...i pinned staging, updated...then robert corrected/built https://code.launchpad.net/~raof/lightdm/more-logind-workarounds
<kgunn> and then built u-s-c (so staging + local lightdm & u-s-c)
<kgunn> still get the x crash that punts me to greeter
<kgunn> good news, i gotta xorg.0.log
<kgunn> will attach to bug
<kgunn> until then https://pastebin.canonical.com/95204/
<kgunn> RAOF: ^
<kgunn> mlankhorst: would you possibly be able to take a peek at https://bugs.launchpad.net/mir/+bug/1206508
<ubot5> Launchpad bug 1206508 in XMir "Xorg crash on xmir punts user back out to greeter" [Critical,Triaged]
<kgunn> or rather the xorg log in there
<mlankhorst> kgunn: to the valgrind machine!
<robert_ancell> tvoss_, https://code.launchpad.net/~robert-ancell/lightdm/unity-session-vtnr/+merge/177591
<mlankhorst> and make sure to install xserver-xorg-core-dbg and xserver-xorg-video-intel-dbg, else valgrind won't be useful
<alan_g> hikiko: alf__ is right about not needing create_nested_platform(), but doing that requires a definition of NestedPlatform (and a constructor that takes the same parameters we gave the function). Can you do that with a stubbed implementation as an update?
<hikiko> sure alan_g right after I fix the other issues
<hikiko> alan_g, alf__ the only problem is that to call the constructor the NestedPlatform must inherit from mg::Platform so I have to add a stub implementation of all Platform methods (which isn't a problem since we ll need it anyway at some point)
<alan_g> hikiko: ack
<robotfuel> It seems like there is an opengl packaging conflict between main and system-compositor-testing today
<tsdgeos> hi guys
<tsdgeos> anyone that has some knowledge about mir I can talk about this patch http://paste.ubuntu.com/5929237/ i made to fix the focus problems i was having with the qml-demo-shell gerry was working on based on unity-mir ?
<tsdgeos> racarr: you here already or still to early for you?
<tsdgeos> alf__: ping âââ ?
<alf__> tsdgeos: hi
<alan_g> tsdgeos: Looks sensible
<alan_g> Although at some point we may want hidden surfaces to "contain" points
<benkaiser> Hey guys, I am running Ubuntu Touch on my Galaxy Note. How can I take a screenshot? even from the terminal?. gnome-screenshot doesn't work because it can't open the display (I am assuming this is because Mir is the display server?)
<tsdgeos> alf__: alan_g: basically i realize that msh::SingleVisibilityFocusMechanism::set_focus_to "raises" the window just because it hiddes the others, but doesn't "really raise" at the ms::SurfaceStack layer so i need that in contains otherwise the touch is directed to the "previous" window that is hidden but "on top" regarding ms::SurfaceStack
<tsdgeos> not sure if i made sense :D
<alan_g> tsdgeos: You make as much sense as the mechanism you describe
<tsdgeos> i'll create a Merge Request and explain the stuff there too
<alan_g> racarr is in the process of reworking that stuff
<alan_g> But a quick MP will beat him to trunk
<tsdgeos> :D
<tsdgeos> alan_g: https://code.launchpad.net/~aacid/mir/hidden_surface_no_contains/+merge/177621
<hikiko> bye!
<robert_ancell> kgunn, https://launchpad.net/ubuntu/+source/lightdm/1.7.8-0ubuntu1/+build/4837955
<tvoss> robert_ancell, https://code.launchpad.net/~thomas-voss/mir/revert-process-group-leader-patch
<mlankhorst> tvoss: why? o.o
<mlankhorst> looks more like mir needs to handle this case better instead..
<mlankhorst> tvoss: does mir handle SIGINT by any chance? if not it wouldn't surprise me if X was killed because mir was..
<mlankhorst> and if not.. Xmir really shouldn't touch the console in any way
<mlankhorst> you need to use KDSKBMUTE ioctl and tcsetattr, fwiw..
<racarr> An interesting idea for
<racarr> model synchronization...
<racarr> rather than taking controller objects in constructor, certain methods could require the controller object to be passed in, i.e. create_surface, destroy_surface, move_surface, etc.
<racarr> Then a central object, can lease out controllers and use that to enforce locking. so code could be written sort of like
<racarr> ms::UniqueController controller(surfaces) auto surface = session->default_surface() // do stuff // surface.raise(controller) // Surface can't have been destroyed because you have a unique controller
<racarr> I dunno ;) it's hazy
<olli> https://orders.letsorderfood.co.uk/order.asp
<olli> http://pizzakingiom.co.uk/
<olli> zip code IM1 2LY
<olli> robert_ancell, kgunn, tvoss, Saviq ^
<racarr> lol
<racarr> @ pizza king iom
<robotfuel> I notived the system compositor testing ppa has some new packages, is it ready for testing?
<robotfuel> bschaefer: ^
<bschaefer> robotfuel, there are some, but my u-s-c was removed :(
<bschaefer> you can try some out though :)
<robotfuel> bschaefer: it already fixed a bug with opengl and the r600 radeon driver :)
<robotfuel> bschaefer: I just started tests on a bunch of other systems
<robotfuel> hopefully the getting punted to the greeter on intel is fixed. :P
<bschaefer> robotfuel, o thats not good, and a fix would be nice!
<bschaefer> robotfuel, awesome, should I just check jenkins for the test updates?
<robotfuel> bschaefer: the punted to greeter issue was a bad patch from mainstream xorg.
<bschaefer> robotfuel, o man, i've had that happen to me a couple times, then I needed to switch back to UXA and normal X and I've not gotten it yet
<robotfuel> bschaefer: anything finished within the last ~hour minutes should have the latests results from the u-s-c ppa
<robotfuel> I think there is only one
<bschaefer> robotfuel, cool, let me check
 * bschaefer hopes to see an ati one
<robotfuel> bschaefer: yes the hd7450
<bschaefer> sweet
 * bschaefer goes to look for it
<robotfuel> bschaefer: http://10.97.2.10:8080/job/openarena-benchmark-ps-radeon-hd7450-le-xmir/48/
<bschaefer> just got there!
<bschaefer> but thanks :)
<tvoss> robotfuel, which xorg patch is that?
<bschaefer> robotfuel, awesome, it looks like its running xmir, and no errors in any logs i see :)
<robotfuel> bschaefer: 2:1.14.2-0ubuntu3+xmir1
<robotfuel> ii  xserver-common                            2:1.14.2-0ubuntu3+xmir1
<robotfuel> ii  xserver-xorg                              1:7.7+1ubuntu5
 * bschaefer reboots his ati machine
<bschaefer> robotfuel, is that the version of xmir on that ati machine?
 * bschaefer has an abi break with u-s-c
<bschaefer> err
<bschaefer> a depends issue rather
<robotfuel> bschaefer: yes http://10.97.2.10:8080/job/openarena-benchmark-ps-radeon-hd7450-le-xmir/48/artifact/results/dpkg-list.log has all the package versions
<bschaefer> robotfuel, sweet, let me double check mine
<bschaefer> robotfuel, but so far its looking like ati is working fine, at lease this run through
<bschaefer> robotfuel, is that using the daily build ppa?
<bschaefer> yes it is nmÂ¡
<bschaefer> !
<robotfuel> bschaefer: no that is the unity-system-compositor ppa
<bschaefer> o really?
<bschaefer> 1:0.9.9~daily13.04.18.1~13.04-0ubuntu1
<bschaefer> made me think it was the daily next one...
<bschaefer> robotfuel, hmm do you have a machine that you can test that out with?
<bschaefer> cause i get this in the daily next build:
<bschaefer>  unity-system-compositor : Depends: libmirserver0 (= 0.0.8+13.10.20130729ubuntu.unity.next-0ubuntu1) but 0.0.8+13.10.20130730bzr896saucy0 is to be installed
 * bschaefer hopes thats rebuilt soon
<robotfuel> bschaefer: they all seem to be busy.
<bschaefer> robotfuel, alright, ill do some manual testing then! Thanks
<bschaefer> tvoss, soo daily build next ppa seems to be working for me with xmir
<bschaefer> with an ATI card
<tvoss> bschaefer, \o/
<tvoss> bschaefer, what was the fix?
<tvoss> bschaefer, we have multiple changes coming to mir/lightdm to fix permission issues and such
<bschaefer> tvoss, im not sure, I just updated and and to downgrade my libmirserver, but things seem to be working...
<bschaefer> tvoss, hmm now im not sure .. this strange I have TTYs
<bschaefer> but:
<bschaefer> root       985  0.5  0.3 178820 15360 tty7     Ssl+ 13:48   0:00 /usr/sbin/unity-system-compositor --enable-input=false --from-dm-fd 10 --to-dm-fd 13 --vt 7
<bschaefer> is running
<bschaefer> along with:
<bschaefer> root      1017  0.6  0.5 110348 22416 ?        Sl   13:48   0:01 /usr/bin/X -core :0 -auth /var/run/lightdm/root/:0 -mir 0 -mirSocket /tmp/mir_socket -nolisten tcp
<bschaefer> tvoss, strange, but I just wanted to quickly update you, im assuming its later over there :)
<tvoss> bschaefer, it is, thanks for the update :)
<bschaefer> np!
<bschaefer> haha, and ctrl+c kills everything...that seems like a mir thing :)
 * bschaefer assumes mir got tty support
<tvoss> bschaefer, fix for that is propagating
<bschaefer> tvoss, yup saw you fixed that ~30 min ago :)
<bschaefer> but confirming with bregma and it looks like daily next build is working with xmir
<bregma> it works beautifully
<bschaefer> well confirming that ttys are working on xmir
<bschaefer> which made me doubt if it was xmir :)
<tvoss> bschaefer, we need to reenable the patch I just reverted, but a little more sophisticated
<bregma> touchscreen still doesn't work right, but I doublt that has anything to do with Mir
<tvoss> bregma, yup, still the good ol' x input stack :)
<bschaefer> cool :), but Ill continue to run it to see if I can get anything to go wrong (though things are looking good!)
<tvoss> bschaefer, awesome, thanks
<bschaefer> np!
<bregma> actually, I think my touchscreen problem is nTrig is crap
<tvoss> bschaefer, would be great if you could hammer it with phoronix-test-suite run pts/gaming-free and pts/gui-toolkits
<bschaefer> tvoss, great idea, let me go run those!
<kgunn> bschaefer: cracking up at the idea of you hitting the ctl+c :)
<kgunn> imagine us here....forgetting that bugs exists & hitting ctl+c about every 5 minutes
<bschaefer> haha
<bschaefer> kgunn, yeah i use ctrl+c tooo often as well
<mlankhorst> kgunn: no, why did you approve
<mlankhorst> it was so easy to fix by just doing a few more CORRECT ioctl's instead of reverting..
<kgunn> mlankhorst: because its really late & we need to "do something" - we did test & verified this worked....i tried not to...but unfortunately we proved the ctl+c was an issue
<mlankhorst> did you even read what I said in the review?
<kgunn> mlankhorst: yes...
<kgunn> mlankhorst: altho reading & knowing exactly what needs to be done 2 diff things
<mlankhorst> crtl-c, crtl-v from x.org, apply correct copyright header from xorg, done :P
<tvoss> mlankhorst, +1, it's on my plate for tomorrow morning first thing
<olli> bschaefer, pingf
<bschaefer> olli, hello!
<olli> bschaefer, the usc-testing ppa is up
<olli> mind giving an ATI system a spin
<bschaefer> olli, awesome, im the daily-build-next ppa and its working on ATI
<olli> kgunn reminds you to install usc at the end
<bschaefer> let me purge, remove and install the u-s-c testing ppa and give that a test
<bschaefer> yup
<olli> bschaefer, cool!
<bschaefer> and to pin the ppa as well :)
<olli> bschaefer, brb
 * bschaefer always forgets that part
<bschaefer> alright
<bschaefer> dammit Ctrl+C!
<mlankhorst> adding the mute thing would have been a lot faster :P
<RAOF> :)
<RAOF> But much less fun!
<bschaefer> olli, also, a couple hours ago robotfuel had some ATI tests on the u-s-c ppa and things were working as well
<bschaefer> xmir was version: 2:1.14.2-0ubuntu3+xmir1
<olli> robotfuel, can you give the ppa a  spin as well pls?
<robotfuel> olli: ok I'll kick off new tests runs
<bschaefer> awesome, I was just about to ask that :)
 * RAOF is minding ZoÃ« for an hour or so
<bschaefer> dang...well its working on u-s-c testing ppa as well, and ctrl+c no longer kills the server!
<bschaefer> olli, working on u-s-c testing ppa, and ctrl+c no longer kills the server
<robotfuel> bschaefer: it looks like there is new packages worked on the systems
<bschaefer> robotfuel, how new? As I just tested mine an hour or so again, and ctrl+c was no longer killing the server
<robotfuel> bschaefer: from u-s-c
<robotfuel> bschaefer: I didn't try control c
<robotfuel> bschaefer: I ran the openarena benchmark on it.
<bschaefer> cool, im still downloading games to run those...
<robotfuel> bschaefer: I get ret = 0 for buffer 26
<robotfuel> ret = 0 for buffer 18
<robotfuel> repeated over 100 times on nvidia, it doesn't seem like openarena is running
<robotfuel> bschaefer: in Xorg.0.log
<bschaefer> :(
<bschaefer> robotfuel, i was about to try running this on daily build next ppa, but there are so many games that it tests...
 * bschaefer goes to look at logs
<tvoss> bschaefer, ping
<bschaefer> tvoss, hello!
<tvoss> bschaefer, did you give the system-compositor-testing ppa a spin?
<bschaefer> tvoss, yup! ctrl+c is no longer killing the mir server :), but robotfuel is running into openarena not being drawn?
<bschaefer> or running
 * bschaefer is still downloading games
<bschaefer> for the test suite
<tvoss> bschaefer, okay, checking locally
<bschaefer> tvoss, alright, let me do that
<robotfuel> tvoss: it ran ok on intel and radeon, on nvidia I get: ret = 0 for buffer 26
<robotfuel> ret = 0 for buffer 18 repeated 100 times in Xorg.0.log and openarena hasn't finished it's first test in over an hour
<robotfuel> I have a compiz crash Jul 30 22:50:26 ps-nvidia-gt640-he gnome-session[1300]: WARNING: App 'compiz.desktop' respawning too quickly
<robotfuel> Jul 30 22:50:26 ps-nvidia-gt640-he gnome-session[1300]: CRITICAL: We failed, but the fail whale is dead. Sorry....
<robotfuel> bschaefer: tvoss ^
<bschaefer> haha...i've seen that error before and it usually not good...
<bschaefer> robotfuel, did the x serve go down as well?
<bschaefer> server*
<robotfuel> bschaefer: I still see the desktop background image, I don't see unity, the xserver didn't go down, but it's not usable
<robotfuel> bschaefer: I am writing a bug
<bschaefer> hmm must have just killed the gnome-session then...
 * bschaefer waits 4min to tests openareana
<tvoss> robotfuel, bschaefer just checked locally, openarena working fine on intel
<bschaefer> robotfuel, hmm have you restarted the tests?
#ubuntu-mir 2013-07-31
<bschaefer> tvoss, robotfuel openarena working on ati as well
<tvoss> bschaefer, ack and thx
 * bschaefer checks the lightdm logs
<bschaefer> np
<bschaefer> robotfuel, I don
<bschaefer> dont see any problems in any logs :(
<bschaefer> things seem to have started correctly
<robotfuel> https://bugs.launchpad.net/xmir/+bug/1206732 has logs
<ubot5> Launchpad bug 1206732 in XMir "compiz crashed with latest s-c-t ppa on nvidia gt640 " [Undecided,New]
<bschaefer> robotfuel, actually: http://paste.ubuntu.com/5930923/
<bschaefer> so you are not getting any input device set correctly?
 * bschaefer checks his own logs
<bschaefer> it sounds like a permission issue possibly....
<robotfuel> bschaefer: it's the same preseed and files that worked for intel and ati
<robotfuel> bschaefer: I think it's the compiz crash
<bschaefer> robotfuel, yeah, there use to be a permissions problem when running mir from the tty but that wouldn't make sense there...
<bschaefer> robotfuel, that would make sense :)
<bschaefer> but you should still be able to run open areana even if its crashed
<bschaefer> as long as it didn't bring X down
<bschaefer> robotfuel, o dammit, sorry, i missed this line: <robotfuel> tvoss: it ran ok on intel and radeon, on nvidia I get: ret = 0 for buffer 26
<bschaefer> I read it as all 3 were failing!
<tvoss> ah okay
<tvoss> falling asleep now :) grab you guys later
<bschaefer> tvoss, have a good night!
<tvoss> bschaefer, thx and bye
<robotfuel> bschaefer: I am re-running the test to see if it's reproducible
<bschaefer> robotfuel, thanks!
<robotfuel> I just needed to grab all the logs first ;)
<robotfuel> I'll check back after I commute home
<bschaefer> alright, are you a bit past your EOD?
<robotfuel> bschaefer: I got the same result, but without the compiz crash
<robotfuel> bschaefer: have you seen the ret = 0 for buffer 26 ret = 0 for buffer 18 before in the xorg.0.log?
<bschaefer> robotfuel, :(, whats strange is i just ran pts/gaming-free
<bschaefer> and I get sent back to lightdm
 * bschaefer double checks
<robotfuel> bschaefer: with the s-c-t ppa?
<bschaefer> s-c-t?
<bschaefer> u-s-c?
 * bschaefer is using the u-s-c tesitng ppa
<bschaefer> testing*
<bschaefer> and I don't see anything in my xorg.0.log about buffers ret = 0
<bschaefer> robotfuel, where did you see the greeter crash info at?
<robotfuel> bschaefer: it was this bug https://bugs.launchpad.net/xmir/+bug/1206508
<ubot5> Launchpad bug 1206508 in XMir "Xorg crash on xmir punts user back out to greeter" [High,Triaged]
 * bschaefer looks
<robotfuel> bschaefer: it looks like that bug covers 2 different scenarios
<robotfuel> bschaefer: if you read the last comment
<bschaefer> robotfuel, well im getting kicked to the greeter when trying to run this pts/gaming-free test
<bschaefer> for the phoronics test suite
<robotfuel> bschaefer: what happens when you run glxinfo?
 * bschaefer install it
<robotfuel> bschaefer: maybe with export DISPLAY=:0 or export DISPLAY=:0.0
<robotfuel> bschaefer: install mesa tools to run it
<bschaefer> yeah, hmm just a bunch of info :)
<bschaefer> robotfuel, it doesn't crash if thats what you're wondering :)
<bschaefer> and glxgears works as well, and openarena works
<robotfuel> bschaefer: that would be good to add to a bug
<bschaefer> im just not sure why gaming-free causes me pain
<robotfuel> I haven't tried games
<bschaefer> robotfuel, could you run this on a machine: run pts/gaming-free?
<bschaefer> err, it adds a lot of games though...
<robotfuel> bschaefer: I can't openbenchmarking.org is blocked from the lab. that's where it downloads from
<robotfuel> bschaefer: I'll download it now and try when I get in work tomorrow
<bschaefer> i see, hmm well Ill have to look at this tomorrow!
<bschaefer> robotfuel, well that could work, i should go eat some dinner ..
<bschaefer> robotfuel, thanks for the help today!
<chjunior> what's this new package? xserver-xorg-xmir ?
<chjunior> also, seem like the arrow at the top-left corner is gone, right?
<TheDrums> I think the testing instructions need to be modified, had to manually pull in unity-system-compositor.
<duflu> RAOF: Are you familiar with undefined symbol xorgMir? (https://bugs.launchpad.net/bugs/1205822)
<ubot5> Launchpad bug 1205822 in XMir "Software rendering fallback in use instead of intel driver: (EE) Failed to load /usr/lib/xorg/modules/drivers/intel_drv.so: /usr/lib/xorg/modules/drivers/intel_drv.so: undefined symbol: xorgMir" [Undecided,New]
<chjunior> it seem like Mir or XMir has some memory leak. I might be wrong, but it feels like it starts up super fast, but gets slower as times goes by.
<RAOF> duflu: That's failure to run against an XMir-enabled server.
<duflu> RAOF: I feel you're just restating the problem. I'm still confused. But so long as you're aware of it...
<RAOF> duflu: Specifically, it's failure to follow the instructions to pin the PPA âº
<RAOF> But I can make that failure more obvious, so shall.
<chjunior> RAOF, is the arrow at the top-left corner gone?
<RAOF> chjunior: Yes
<RAOF> Now the only way to tell is (a) by checking logs, or (b) hitting Ctrl-C :)
<chjunior> haha, that's the reason for the question
<chjunior> RAOF, what ctrl-c should do? Nothing happened here
<RAOF> Oh, has that fix propagated? Yay!
<RAOF> chjunior: It would have killed mir
<chjunior> I guess it's fixed then :P
<chjunior> which logs should I look at? R
<chjunior> RAOF,
<RAOF> chjunior: /var/log/Xorg.0.log, or you can run âxrandr -qâ and check for XMir Mode Of Death!
<RAOF> I'm going to be sad when we have actual xrandr support and I can no longer call it the Mode Of Death.
<chjunior> :) That's a good name
<duflu> There is always something new that you can declare "of death!"
<RAOF> But probably not in a user-visible string
<RAOF> âº
<chjunior> RAOF, is stuff still going to the output buffer? like password and everything I type
<RAOF> I'm not sure. I think the fix for ctrl-C should have also fixed that, but I've not tested it.
<RAOF> You still can't user-switch, though.
<RAOF> Which reminds me - racarr!
<RAOF> racarr: How goes notify-on-focus? âº
<RAOF> Sweet! I win the âable to get dma-buf size out of the kernelâ award!
<chjunior> RAOF, and I win the "Trying things someone waned were buggy just to see the world burn"
<chjunior> had to restart after user-switch
<chjunior> do you think XMir will be ready for 13.04 performance-wise ?
 * duflu wonders how long is too long for stress testing to run on armhf
<RAOF> chjunior: 13.04? A bit late for that :)
<chjunior> wow, sorry, messed up with numbers
<RAOF> chjunior: 13.10? Yes; there's some subtlety in GLX bypass that needs to be worked out, but we should be able to get approximately 0% performance penalty on composited desktops.
 * duflu cancels all real-life for the next few weeks to make that happen :/
<chjunior> I thank you all duflu, RAOF and others for that
<RAOF> duflu: Indeed, got some time to talk composite-bypass?
<duflu> RAOF: Depends how far down the rabbit hole you want to go :)
<RAOF> Just a high-level discussion of how composite bypass interacts with nested compositors
<RAOF> (Of which XMir is one)
<RAOF> Because currently the answer to that appears to be âbadlyâ
<duflu> RAOF: I will need to refresh my memory of the bypass work done so far
<RAOF> Because for nested compositors, composite bypass means âhand out the buffer we received from our server to a clientâ, and that has a bunch of failure modes.
<duflu> RAOF: No, that's the "old" method I'm not using any more
<RAOF> duflu: Right - but you're not doing a nested compositor.
<duflu> RAOF: You're right. That issue needs to be solved/avoided in the nesting logic. I found it problematic so didn't do that
<RAOF> duflu: Since you're running on the hardware you *can* choose to allocate scanout-ready buffers.
<duflu> RAOF: Yes, the conditional-ness of that is TODO :)
<duflu> Presently everything can be scan-out
<RAOF> So, do you have any thoughts about solutions for nestedness?
<duflu> RAOF: It actually makes very little sense to pass any buffers from the Display classes down to the client. Because the buffer allocator can of course make a scanout capable buffer without Display* getting involved
<duflu> Not to mention you can't trust clients...
<duflu> RAOF: My present approach accepts *any* scanout capable buffer, which can come from the client or can come from the Display (default compositing)
<RAOF> But, on the other hand, nested bypass *requires* that you send the buffer you receive to the client.
<duflu> RAOF: Why? that's got high risk of the client misbehaving and breaking the server, surely?
<RAOF> How do you bypass if the client isn't rendering to a buffer acquired by the nested server?
<RAOF> ie: The nested server needs to call mir_surface_swap_buffers() on something. What is that something?
<duflu> RAOF: Bypass doesn't care which server created the buffer. It still works
<duflu> With obvious memory management trickery
<RAOF> How does the buffer get from the nested compositor to the display?
<RAOF> It *sounds* like you're talking about client-allocated buffers, which would indeed work fabulously for this.
<duflu> RAOF: Yes I was thinking that
<duflu> Just doesn't work with mirserver's memory management yet
<duflu> Because the client (which is a server) is the one allocating the buffer
<RAOF> Indeed.
<RAOF> If we can do *that* then bypass is easy, and xmir is easier.
<RAOF> It was my understanding that this was not on the table.
<RAOF> Sounds like a job for Afternoon Team Meetingâ¢!
<RAOF> Oh. Is that going to occur with everyone in IOM?
<duflu> Maybe... ?
<racarr> Are we having the weekly this weeting?
<racarr> Oh that's what was just being discussed :) Hi
<racarr> RAOF: client-focus-notifications...I dunno
<racarr> I feel as if the branch is unpopular in a profound way :p it needs more review
<racarr> and maybe better ideas
<racarr> I kind of feel like it's done
<duflu> RAOF: I kept thinking about it over lunch...
<RAOF> duflu: Oh, and?
<duflu> and I don't think there are any fundamental conflicts between nesting and bypass...
<duflu> ... just that both at once will require more work so as to not negate bypass benefits
<duflu> ... which should be a simple matter of implementing my DisplayBuffer changes
<duflu> I mean, any "NestedDisplayBuffer" should be enhanced to implement bypass like GBM does now
<duflu> It should all just work so long as both servers use the same logic and enable bypass at the same time
<RAOF> I still don't see how?
<RAOF> I mean, you can *certainly* handle bypass on the outer compositor; that works regardless of the client.
<duflu> RAOF: And once implemented in the inner compositor (implemented for NestedDisplayBuffer or whatever), then why wouldn't it work?
<RAOF> What do you mean by "implemented" in this case?
<duflu> RAOF: It's a new function I've added to the DisplayBuffer interface. You can safely stub it or implement for bypass support
 * RAOF looks at the DisplayBuffer interface
<duflu> Though I may be relying on memory too much
<RAOF> I think the fundamental problem is that for bypass the inner compositor *is not* allocating a DisplayBuffer
<duflu> RAOF: It has to... for N-buffering and to ensure you're not trusting clients
<RAOF> Which turns around our buffer allocation strategy.
<RAOF> You are asserting that server-allocated buffers are incompatible with bypass.
<robert_ancell> RAOF, duflu, kdub, racarr, hikiko, alf__, thomi, meeting..
<duflu> RAOF: Only what you're proposing nesting should do turns things around. And in an unsafe way
<robert_ancell> Not sure how the WiFi will hold up here though
<RAOF> duflu: Actually, I think with triple buffering *and* 2 buffers available client-side it can be safe.
<RAOF> Hm, maybe.
<duflu> RAOF: On the other hand, I will be free to fully discuss bypass in about 24 hours :)
<mlankhorst> morning
<robert_ancell> RAOF, kdub, racarr...
<RAOF> robert_ancell: Logging in to a session with webcam.
<robert_ancell> RAOF, ack
<RAOF> Am I appearing in the hangout?
<RAOF> I see a bunch of people, but no audio or video.
<robert_ancell> RAOF, you show a photo
<racarr> abnormally interested in buffers today
<racarr> still thinking about bypass
<RAOF> Please do.
<RAOF> There's also the extra special case of XMir DRI2 bypass to consider, which has the extra frission of not allowing protocol changes!
<racarr> There is? -.-
<RAOF> (Although the DRI2Invalidate event will be useful there)
<RAOF> racarr: Well, the case we're aiming for with XMir is to have Unity fullscreen, drawing directly on the framebuffer, for ~0% XMir overhead. Same for fullscreen GL games.
<duflu> RAOF: Actually, I think we can afford to enforce the extra restrictions on clients when the client is a nested server (hence very few of them, and controlled by us)
<duflu> But generalized bypass does not have that luxury
<RAOF> duflu: With the unfortunate DRI2 case above :)
 * duflu has no idea what the DRI2 issue is still
<RAOF> If we want ~0 performance regression on fullscreen games, which we obviously do, then we need to give the DRI2 client (ie: the fullscreen game) a framebuffer to render on.
<racarr> RAOF: Ok yes
<racarr> I was thinking of that
<racarr> as the case
<RAOF> This means we need to hand out something that will become the framebuffer in response to DRI2BufferBackLeft
<duflu> I cannot comment further outside of pure speculation :)
 * duflu goes to find coffee
<duflu> Hmm, at what point does the stack depth affect performance?... I keep seeing large stacks in mirserver up to 72 frames deep...
<dholbach> good morning
<duflu> Morning dholbach
<dholbach> hey duflu
<duflu> racarr: Careful with asking community contributors to "fill in testing". Sometimes that can scare people off, or at least make them lost interest to the point of never completing the work. It's a fine line.
<duflu> -lost +lose
<duflu> ... but it's good and right to ask at least once, I guess. The question then becomes "is the work important enough to us that we fill in the testing ourselves?"
<tvoss_> good morning :)
<RAOF> Eeeloe,
<tvoss_> duflu, ping
<duflu> tvoss_, pong
<tvoss__> RAOF, ping
<duflu> tvoss__, pong?
<RAOF> tvoss__: pong
<RAOF> tvoss__: 17:43 <RAOF> Got a kernel patch to work, fixing up some xserver packaging, the ppa doesn't seem to have caught fire...
<tvoss__> RAOF, ah cool, what does the kernel patch do?
<RAOF> Add enough llseek support to dma-buf to let us get the size of one
<tvoss__> ack
<RAOF> Which was blocking radeon support for egl-platform-mir upstream\
<tvoss__> RAOF, awesome
<tvoss__> RAOF, want me to give the intel driver update a spin?
<RAOF> The shiny shiny ickle one? I haven't pushed that anywhere yet.
<RAOF> I need to go and make dinner; I'll be on later.
<tvoss__> RAOF, yup
<tvoss__> RAOF, I was talking about http://bazaar.launchpad.net/~mir-team/mir/xf86-video-ati-vladmir/revision/2539
<tvoss__> RAOF, can I just compile it against the testing ppa?
<tvoss_> duflu, so when using the switch branch with system-comp-testing, the usc just crashes
<tvoss_> RAOF, ^ could you quickly verify?
<duflu> That's different
<duflu> tvoss_: Oh, I noticed yesterday I had changed the ABI without bumping the soname. Make sure *everything* is rebuilt
<duflu> ... of libmirserver that is
<duflu> tvoss_: Me forgetting to bump the soname means it's possible to accidentally forget to rebuild everything that uses libmirserver
<tvoss_> duflu, that is, I need to rebuild usc, right?
<duflu> tvoss_: Yes anything that uses libmirserver. It should have given you a runtime error (missing library) but won't because I forgot to bump the soname/ABI
<duflu> tvoss_: I wasted hours last night for the same reason. tests crashing inexplicably
<duflu> I'll fix it today...
<tvoss_> duflu, cool, let me know when I can take a look
<duflu> tvoss_: No need to wait for me. You can rebuild everything now
<tvoss_> duflu, ack
 * duflu is waiting on cross-compiles
<duflu> robert_ancell: At what point can we not bump the server ABI any more? Seems like we have several activities in progress that will do so
<duflu> -will +should
<robert_ancell> duflu, we'll need to be ABI stable at release, but I think long term we'll just bump the soname every time we make a non-additive change and recompile u-s-c and unity-mir each time that happens
<duflu> robert_ancell: Cool
<robert_ancell> I don't think we need to worry too much about changing the ABI as long as we bump soname given the small number of libmirserver consumers
<duflu> robert_ancell: Yes I forgot to bump and it's caused several people to forget to rebuild
<robert_ancell> duflu, right now, we don't need to bump it - the system-compositor-testing PPA is manually kept in a safe state
<robert_ancell> once u-s-c hits universe then we're solving that in jenkins with a dependency done by didrocks
<robert_ancell> Long term, we'll rely on sonmae
<duflu> robert_ancell: PPA rules don't help me while people keep playing with pre-release branches :)
<robert_ancell> Just don't want to slow things down too much requiring the soname bumps and associated changes in debian/*
<robert_ancell> duflu, who's doing that / what?
<duflu> robert_ancell: I mean WIP branches (switch)
<robert_ancell> i.e. running u-s-c from the PPA with a locally built version on Mir?
<didrocks> robert_ancell: kgunn: btw, the ppa worked on ati and intel
<didrocks> let me retry another run in a few
<kgunn> didrocks: \o/ hells yeah
<didrocks> let's cross fingers ;)
<didrocks> and retry
<kgunn> sure
 * duflu suspects people are messaging each other from within the same physical room
 * duflu thinks that's strange
<didrocks> duflu: we don't want to interrupt the meeting
<didrocks> duflu: but you are not that far from truth :)
<mlankhorst> http://paste.debian.net/hidden/f5f6260b/ does this look ok? untested though
<mlankhorst> oops, looks like it's wrong :p
<mlankhorst> oh correct after all, weee
<hikiko> alan_g, ping
<alan_g> hikiko: hi
<hikiko> hi :)
<alan_g> How is it going?
<hikiko> mmm fine in general but I have a question
<hikiko> I tried to replace the create_nested_platform with the NestedPlatform constructor
<hikiko> in the_graphics_platform()
<alan_g> Yes
<hikiko> but it seems that the lambda cannot return a deduced type
<alan_g> You need to specify the return type explicitly
<alan_g> See mir::DefaultServerConfiguration::the_input_report() for an example
<hikiko> let me check it :)
<hikiko> oh so you use []()->Type
<hikiko> but this will cause a problem when I call create_platform isn't it?
<hikiko> because I have a condition
<hikiko> in non nested mode I return mg::Platform in nested mgn::NestedPlatform
<hikiko> or I can use []()->mg::Platform
<alan_g> hikiko: you must return shared_ptr<Platform>
<hikiko> ah the abstract type
<hikiko> ok :)
<alan_g> And NestedPlatform must extend Platform
<hikiko> (sorry I am not so familiar with lambdas)
<alan_g> See mir::DefaultServerConfiguration::the_input_report() for an example
<hikiko> yes that's done :)
<hikiko> ok
<hikiko> thanks a lot
<mlankhorst> kgunn: been working on it, but tests were failing since they didn't handle the extra ops :P
<kgunn> mlankhorst: thanks!
<mlankhorst> http://paste.debian.net/hidden/2d845546/ can you test that one? :P
<robert_ancell> alf__, alan_g, tvoss_, can you add some info to bug 1203590 if you know what we need from lttng/systemtap
<ubot5> bug 1203590 in systemtap (Ubuntu) "[MIR] systemtap" [Undecided,New] https://launchpad.net/bugs/1203590
<Saviq> duflu, re: bug #1206633
<ubot5> bug 1206633 in Mir "mir doesn't start "Error opening DRM device" on nVidia" [Undecided,New] https://launchpad.net/bugs/1206633
<Saviq> duflu, I was running as root
<duflu> Saviq: OK. Just means it's not a trivial mistake :)
<mlankhorst> bah one unfortunate side effect is that VT switching no longer seems to work..
<Saviq> duflu, yeah, I had robert_ancell next to me for immediate help, but we didn't get anywhere, hence the bug
<hikiko> alf__,
<alan_g> alf__: in multimonitor-gbm-cursor should I be seeing any difference in behaviour? Or  does that need other changes?
<hikiko> ^ that was my question :D
<duflu> alan_g: What's the recommended way to ignore uninteresting calls, in tests which really should have no expectation of them?
<alan_g> duflu: to stub the calls, not mock them
<duflu> alan_g: Mixed stub methods in a mock class?
<duflu> Problem is I have two test cases which needs it mocked. The rest of the tests shouldn't care ("not interested")
<duflu> -needs +need
<alan_g> duflu: you could, e.g. derive a mock class for the test from a shared stub class.
<duflu> Sounds like overkill but would work I guess
<alan_g> duflu: there's also NiceMock (which IMO is overused in our code)
<mlankhorst> meh w/e, this fixes control-C at least..
<duflu> alan_g: Wait, no. I need the mock class in every test. Just one method I wish to ignore in most (it's called during destruction)
<alan_g> duflu: Then it's probably easier to have the one class and set expect AnyNumber in the constructor
<duflu> alan_g: I thought I similar in SetUp and got bogus failures. Maybe the constructor is indeed a better idea
<duflu> I thought I *tried*
<alan_g> That should work too
<alan_g> hikiko: you have review comments - mir.nested-platform-constructor
<hikiko> thanks alan_g let me see :)
<mlankhorst> does mir disable xserver vt switches?
<kgunn> mlankhorst: w/o you proposed change in http://paste.debian.net/hidden/2d845546/
<kgunn> i had the vt problem already
<mlankhorst> looks like strictly speaking xserver should be spawned with -sharevts -keeptty  :P
<mlankhorst> considering at this point xserver no longer controls the server
<duflu> So close to finishing, but out of time
<mlankhorst> https://code.launchpad.net/~mlankhorst/mir/setsid/+merge/177800 try 2
<didrocks> kgunn: do you know on which part of boost you build-dep on?
<didrocks> kgunn: because right now the package deps on libboost-all-dev which is now in universe
<didrocks> and there is a discussion on #ubuntu-devel to only deps on what it's needed
<xnox> i see that from linking it's: libboost-program-options-dev libboost-system-dev but there might be other header/template only portions of boost used.
<xnox> -lboost_chrono -lboost_date_time -lboost_filesystem -lboost_system -lboost_thread -lboost_program_options -lboost_regex
<didrocks> robert_ancell: hey
<robert_ancell> didrocks, hello
<didrocks> robert_ancell: so I don't see libboost-all-dev in the MIR
<didrocks> https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1203207
<ubot5> Launchpad bug 1203207 in mir (Ubuntu) "[MIR] mir" [Undecided,New]
<didrocks> and Mir depends on it
<didrocks> the discussion we just had on #ubuntu-devel is that we should of course only build-dep on what we rely on
<didrocks> 11:58:43          xnox | i see that from linking it's: libboost-program-options-dev libboost-system-dev but there might be
<didrocks>                        | other header/template only portions of boost used.
<didrocks> 11:59:06          xnox | -lboost_chrono -lboost_date_time -lboost_filesystem -lboost_system -lboost_thread
<didrocks>                        | -lboost_program_options -lboost_regex
<robert_ancell> didrocks, ok, we can switch to that
 * xnox is doing a test build with ^
<didrocks> xnox: thanks man :)
<sil2100> \o/
<didrocks> robert_ancell: if so, we'll probably have to update the MIR as well (eventually)
<didrocks> IIRC filesystem wasn't in main last time I checked
<sil2100> hm, interesting though - libboost-all-dev had to be in universe like, since longer?
<xnox> a long time ago mpi was not wanted in main, so because of that -mpi- portion is split into universe, the rest source packages are in main (if there are rdepends) some of the binary packages might be in universe if there are no rdepends.
<xnox> if archive reorg ever happens, this mess with two source packages for default boost will go away.
<xnox> so build passes & all unit tests pass (build-time tests) \o/
<sil2100> Yeaaa
<sil2100> robert_ancell: anyway, strange thing that it wasn't noticed earlier that libboost-all-dev is in universe - I didn't see it mentioned in the MIR too!
<robert_ancell> sil2100, yeah, I think it was missed because the source package is in main, but not all the binaries
<kgunn> mlankhorst: i was going to try your mp...but now we got an issue with the boost version in main :-/
<xnox> robert_ancell: https://code.launchpad.net/~xnox/mir/boost-split/+merge/177804
<robert_ancell> xnox, awesome, thanks!
<xnox> sil2100: robert_ancell: so chrono & regex will be "rescued" from universe -> main. but that's ok, cause the source package they are build from is in main already. All others are in main already. No M.I.R. is needed for those
<robert_ancell> xnox, just added the note how we don't need the debian/changelog entry. Otherwise looks good
<xnox> robert_ancell: well the daily landing should be able to use it correctly..... unless you are not using daily landing =)
<xnox> robert_ancell: dropped changelog entry.
<robert_ancell> mlankhorst, I fixed that MP you made - it is rebuilding
<mlankhorst> ok
<hikiko> for some reason I cant trigger a jenkins rebuild
<hikiko> did anyone else have the same problem?
<alan_g> hikiko: Not logged in over VPN?
<hikiko> no
<hikiko> I tried from the web interface
<hikiko> do I need a Canonical's IP for this?
<alan_g> You need to log into the web interface via the VPN
<hikiko> I see
<alan_g> hikiko: Do you have a plan for what to do next?
<hikiko> alan_g, I was about to push the fix and ask you
<hikiko> shall I continue the nested platform or do the native one first?
<alan_g> hikiko: I'd imagine that writing the nested one would identify the functions needed from the native one.
<hikiko> alan_g, alf__ suggested that the nested platform will keep a pointer to the underlying native platform (mg::Platform => either GBM or Android) and call the native funct when necessary, I guess your idea is that I will add a fill_ipc, get_ipc, create_buffer_alloc... etc in the NativePlatform class and call these?
<hikiko> sorry :s/NativePlatform class/native platform interface
<alan_g> hikiko: Yes. (If we end up with NativePlatform being identical to Platform we can merge them.)
<hikiko> the native platform interface will end up to call the GBM/Android functions?
<hikiko> oh, ok :)
<alf__> hikiko: alan_g: I think that the NativePlatform interface will turn out to be very close to mg::Platform, since we mostly want to relay requests
<alf__> hikiko: alan_g: but we can decide later, as Alan suggests
<hikiko> yes, maybe I could just keep the create_native_platform and create a 2nd constructor for each platform
<hikiko> ok we ll see
<alan_g> hikiko: I'm assuming your earlier spike gives you enough to write a first draft of the nested code.
<hikiko> yes, although in the previous branch I used to keep a ptr to the native mg::Platform
<hikiko> there was no NativePlatform interface
<hikiko> but it's not a big deal to add the methods to the native platform class
<alf__> mlankhorst: @setsid, does the change also affect vt switching combinations (Alt+F*) or only Ctrl-*?
<mlankhorst> it ignores all keyboard input in mir, would need to actually handle input for it to be useful
<mlankhorst> I don't know what the previous behavior was, though..
<mlankhorst> xorg seems to generate XF86Switch_VT_1 etc, but I have no idea why it does, and not simply change to the appropriate vt
<alf__> mlankhorst: ok, so we need to be able to handle at least VT switching key combinations ourselves before this lands, and also add a kill Mir key combination, otherwise development will become painful
<mlankhorst> ... while you still run with --disable-input ?
<robotfuel> with openarena benchmarks xmir is faster than x on intel now
<mlankhorst> yeah but getting 400 fps on glxgears, so dno how reliable that is :p
<racarr> MORNING
<kdub_> too early for shouting :)
<racarr> Lunch break :) will be a little long (~1 hour) little sister is off exploring down town SF and got a little spooked so I am going to go meet up with her :)
<racarr>  Back
<crippledmonk> just installed daily and added ppa for mir. did apt-get update, reboot etc. Is there anything I should do in order to verify it's using mir?
<bschaefer> crippledmonk, if you want to verify tou are using xmir do: ps aux | grep mir
<bschaefer> s/tou/you
<bregma> ps -ef | grep unity-system-compositor
<crippledmonk> bschaefer: I got this   todd      4166  0.0  0.0   4444   824 pts/0    S+   14:11   0:00 grep --color=auto mir
<bschaefer> crippledmonk, nothing else?
<bschaefer> crippledmonk, make sure you have unity-system-compositor installed
<crippledmonk> just a sudo apt-get unity-system...... in term
<bschaefer> yup!
<bschaefer> you can also check by doing apt-cache policy unity-system-compositor
<crippledmonk> it gave me errors...unity-system-compositor : Depends: libmirserver0 (= 0.0.8+13.10.20130730bzr898saucy0) but 0.0.8+13.10.20130731.2-0ubuntu1 is to be installed
<crippledmonk> E: Unable to correct problems, you have held broken packages.
<bschaefer> :(, hmm unmet dependency
<bschaefer> bregma, is that a better way to look for mir?
<bregma> if unity-system-compositor is not running, xmir is not running on mir
<bschaefer> crippledmonk, can you do an apt-cache policy libmirserver0?
<bregma> does xmir actually run with proprietary drivers?
<bschaefer> and, pastebin it here: paste.ubuntu.com
<bschaefer> bregma, not that I know of, but if u-s-c is running, you'll have the mir server running as well
<bregma> exactly, but if you;re running the proprietary nVidia or AMD drivers, you're not going to see that
<bschaefer> bregma, but you wont see u-s-c either though will you?
<bregma> no, exactly
<bschaefer> o yeah, well he has a broken package soo hes going to have to downgrade the libmirserver :)
<bregma> so, if crippledmonk is running a proprietary video driver he may be disappointed
<bschaefer> right
<bregma> he should make sure he's using the right ppa
<crippledmonk> done.
<bschaefer> he really should be using u-s-c testing ppa and not daily
<bregma> because daily is always broken
<bschaefer> yeah
<crippledmonk> I wiped my HDD  did install and that's it
<crippledmonk> well not quite I followed this guide. http://www.ubuntukiller.com/2013/07/install-and-test-new-mir-in-ubuntu-1013.html
<bschaefer> crippledmonk, soo, you should purge the daily build ppa and use this one
<bschaefer> https://launchpad.net/~mir-team/+archive/system-compositor-testing
<crippledmonk> accept I did fresh install not upgrade
<bschaefer> crippledmonk, o so you are using this ppa? mir-team/system-compositor-testing
<bschaefer> that wont hurt you :)
<crippledmonk> already deleted working on change
<bschaefer> crippledmonk, alright, use purge-ppa
<bschaefer> it cleans things up nicely
<bschaefer> err ppa-purge :)
<crippledmonk> it's not working...
<bschaefer> crippledmonk, hmm whats not?
<seb128> bschaefer, bregma: hey, just checking, how are the ibus 1.5 fixes going? got merged in?
<crippledmonk> sudo ppa-purge :mir-team/system-compositor-testing
<bschaefer> seb128, approved and waiting to be merged!
<bschaefer> sudo ppa-purge ppa:mir-team/system-compositor-testing
<bschaefer> try that
<bschaefer> crippledmonk, ^
<seb128> bschaefer, great, thanks ;-) (sorry for the ping on -mir, I though that was -unity)
<bschaefer> seb128, no worries :)
<crippledmonk> command not found ppa-purge
<bschaefer> crippledmonk, right, you should install it :)
<bschaefer> sudo apt-get install ppa-purge
<bschaefer> crippledmonk, but... umm you want that ppa
<bschaefer> crippledmonk, so you have this ppa right? ppa:mir-team/system-compositor-testing
<crippledmonk> now it's purging
<bschaefer> crippledmonk, I thought you had installed a different ppa...to many! sorry
<bschaefer> crippledmonk, sooo once you purge, you'll want to install it again :)
<bschaefer> http://www.olli-ries.com/running-mir/
<bschaefer> these are the same instructions, but a bit neater
<crippledmonk> Well, Getting ready to restart lightdm according to guide...Will see.
#ubuntu-mir 2013-08-01
<RAOF> Note to self: don't run xorg integration tests while performing tasks you care about.
<duflu> That's odd. My main machine can't run GL clients any more. And I upgraded _nothing_ since yesterday
<duflu> Back in a minute
<duflu> I hope
<duflu> Woo, it's not PPA problems this time. We landed something in multi-monitor which makes half the example clients crash
<duflu> ping kduv
<duflu> ping kdub
<RAOF> Hurray!
<duflu> Yeah, right, hurray
 * RAOF is off for lunch
<duflu> alf__: out->used implies out->connected right?
<duflu> Actually, it doesn't have to... but used is still more important I guess
<alf__> duflu: As things are now (and I don't really expect this to change) out->used implies all of out->connected, has valid mode etc
<duflu> alf__: What about when an output is in use, but suddenly disconnected? Does the server reconfigure or would that make used && !connected ?
<duflu> I'm guessing an output could be "used" but possibly not "connected". That's an error to log, but theoretically possible
<alf__> duflu: the new configuration that reaches the client should have an updated used field (i.e. not used) if an output is not connected
<duflu> alf__: Sounds reasonable. But I will check all conditions for now...
<alf__> duflu: but I guess it doesn't hurt to sanity check all the relevant fields
<alf__> duflu: ok
<dholbach> good morning
<didrocks> RAOF: good evening!
<RAOF> didrocks: Aloha!
<didrocks> how's life in the winterish side of the world? :)
<RAOF> Dark, now :)
<didrocks> but butâ¦ you're not in the IoM!
<didrocks> did you see my emails about xmir and so on?
<didrocks> email*
<didrocks> even
<RAOF> didrocks: I did indeed. The XMir stack is preparing for an upload.
<didrocks> excellent! so still on track for today?
<RAOF> It might even include an autopkgtest for X, depending on how ambitious I am.
<didrocks> \o/
<didrocks> maybe let's try to have a first upload, and then adding it :p
<didrocks> not adding a potential last minute "zomg"
<RAOF> I should be able to finish it this evening.
<didrocks> excellent, do you mind poking/sending me a quick shotout?
<didrocks> so that I promote stuff in main in proposed
<RAOF> didrocks: Sure.
<duflu> Ugg. bzr tells me there's nothing to merge, but also my diff is 10kloc. It's not.
<didrocks> RAOF: excellent! thanks a lot. Let's cross fingers
<didrocks> nothing to merge, 10kloc? humâ¦
<didrocks> are you in a case with \r\n eventually?
<didrocks> I've already been trapped by that
<duflu> didrocks: bzr was confused by me merging branches, reverting, and then trying to merge again. The diff remained but there was "nothing to merge"
<duflu> Fixed now
<didrocks> ah, but the revert was
<didrocks> bzr merge . -r -1..-2, right?
<didrocks> so you have a commit
<didrocks> then, merging a revert
<didrocks> and committing, right?
<duflu> didrocks: Yes I think I did that. Because I'd already backed it up offsite. So didn't want to uncommit
<didrocks> ok, so that makes sense, not bzr being confused :)
<didrocks> basically the revert is "new code" more advanced than your merge itself
<didrocks> (there is no marker that this commit is a revert of this one, and should be considered again then)
<duflu> didrocks: Yes it looks like bzr is trying to mark branches as merged, even when they differ
<didrocks> right, because the commit id is already in
<didrocks> basically, you have to bzr branch trunk, then, creating a manual diff (from your commit change) and reapplying it :(
<kgunn> duflu: hey...tvoss keen to push for your switch branch because it fixes some issues....but
<kgunn> i remembered kdub had found a perf hit on android
<duflu> kgunn: Fixed AFAIK
<kgunn> just curious if you had a chance to investigate
<kgunn> oh swet
<duflu> He was testing it too early
<kgunn> ...or sweet even
<duflu> kgunn: Nexus4 gives 60FPS on everything
<kgunn> kdub: ^ wanna give another go ?
<kgunn> duflu: is it switching or bypass branch ?
<duflu> kgunn: switch
<kgunn> duflu: awesome
<duflu> kgunn: I will still ask kdub to re-test though
<kgunn> duflu: think you'll be able to mp next week ?
<duflu> kgunn: I was aiming for today. Fingers crossed
<duflu> kgunn: That's "switch", not "bypass"
<kgunn> duflu: right...still lot's of effort...great
<duflu> kgunn: Incidentally, I suspect the fix I did for the Android frame rate might resolve some of greyback's concerns about Mir's swapbuffers being slow for Qt
<duflu> Maybe
<duflu> Does anyone have operator permission to ban morphis?
<seb128> !ops
<ubot5> Help! Channel emergency! (ONLY use this trigger in emergencies) - elky, Madpilot, tritium, Nalioth, tonyyarusso, PriceChild, Amaranth, jrib, Myrtti, mneptok, Pici,  jpds,  gnomefreak, bazhang,  Flannel, ikonia, maco, h00k, IdleOne, bkerensa, nhandler, Jordan_U, DJones or k1l!
<duflu> Not big deal. Wait and see if the noise stops I guess
<seb128> duflu, I'm asking on #ubuntu-devel, that's actually happening on -devel and -touch as well and is quite annoying
<duflu> kgunn: Regarding 30FPS on Android... I just discovered that can happen if you accidentally have multiple Mir servers running. It actually works, at half framerate
<kgunn> :)
<kgunn> makes sense
<kgunn> duflu:
<duflu> alf__: Would this be multimonitor? https://bugs.launchpad.net/mir/+bug/1207226
<ubot5> Launchpad bug 1207226 in Mir "[regression] Synchronous clients become asynchronous framedropping clients after a VT switch" [Undecided,New]
<alf__> duflu: I can't reproduce this. Is this with lp:mir? What's your monitor setup exactly, and what commands are you running running?
<duflu> alf__: Yes plain old lp:mir. One monitor connected (but three supported). Just run any client and it happens
<alf__> duflu: which server?
<duflu> alf__: demo_server_shell at least. Let me test demo_server
<duflu> alf__: If you can't reproduce it, I will debug tomorrow
<alf__> duflu: could it be that you have left-over processes?
<duflu> alf__: No, I've rebuilt and retested several times
<duflu> Actually it's probably just the compositor losing vsync on VT switch
<alan_g> duflu: alf__ - anyone need to review https://code.launchpad.net/~robertcarr/mir/client-focus-notifications/+merge/166440 again - or shall I top-approve to get it off the review queue?
<duflu> alan_g: Yes I need to
<duflu> Or at least verify my previous concerns were addressed
<alan_g> np
<duflu> alf__: Apologies. I thought I had tested with trunk, twice. Now only happens in my own branch :)
<alf__> duflu: no worries
<duflu> Too many machines/branches going at once
<duflu> I did have the forethought to test trunk. And yet I messed that up somehow
<alan_g> duflu: time for rest
<alan_g> RAOF: got time to fix https://code.launchpad.net/~mir-team/mir/expose-debug-buffer-id-to-client/+merge/176843 so that we can land it?
<duflu> alan_g: I won't get to that review today. But I would like to tomorrow....
<alan_g> duflu: that's OK, I'm just keen to reduce the review backlog (but only where possible)
<RAOF> alan_g: Not today; barring firefighting, tomorrow.
<alf__> RAOF: alan_g: could we change it to WIP then?
<RAOF> alf__: Done.
<alf__> RAOF: great thanks
<alf__> RAOF: let's see how light we can make our MP list :)
<didrocks> RAOF: can I help you in any way?
<RAOF> didrocks: Not really; I'm just preparing the packages, testing them, and then I'll upload them. In a bunch.
<duflu> It's a bad sign that I read "barring firefighting, tomorrow" as "barfighting tomorrow"
<alf__> duflu: :D
<didrocks> RAOF: good luck! :)
<RAOF> didrocks: Hm. This might not all be ready and sufficiently tested for me to upload tonight. Is it urgent that I push through, or is your late today/early morning your time ok?
<didrocks> RAOF: I prefer we push safe things, just be aware that as I have then to promote build-deps in main, it will take time
<didrocks> RAOF: I wanted to ensure that today's Mir + u-s-c worked TBH (and be done with this)
<didrocks> but again, better to be on the safe side of things :)
<kgunn> robert_ancell: i was gonna test lankhorst's mp....unless, you tell me you're already doing it
<RAOF> didrocks: I probably _could_ get it done today, but it'd be late.
<didrocks> RAOF: that would be better, but I don't want you having to overwork for it :)
<didrocks> RAOF: just keep me posted, we'll see
<alan_g> hikiko: BTW your work got a mention: http://www.phoronix.com/scan.php?page=news_item&px=MTQyNTI
<hikiko> haha :)
<hikiko> that's only an option
<hikiko> anyway, I wope we have the full mir on mir soon
<hikiko> :s/wope/hope
<robert_ancell> kgunn, testing it now
<hikiko> alan_g, I have a question
<hikiko> I added a check that the host socket and the socket that is used by the nested mir to accept connections is not the same
<RAOF> Grah. Stupid alioth!
<hikiko> and if it
<hikiko> s the same I just throw an exception
<hikiko> but I wonder if it's better to rename the socket myself px add a 0 at the end
<hikiko> eg /tmp/mir_socket for host /tmp/mir_socket0 for nest
<alan_g> hikiko: no. it is better to report the problem than hide it
<hikiko> cool :)
<alan_g> hikiko: Use AbnormalExit to give a nice explanation
<hikiko> ok!
<RAOF> didrocks: Grr. Alioth seems to be down again; I won't have the full stack ready tonight.
<didrocks> RAOF: don't worry then, thanks for trying :)
<xnox> hikiko|lunch: so can I run and test it yet? =)
<hikiko|lunch> xnox, not yet I am afraid :) sorry eating! brb in a while
<thomi> robert_ancell: https://bugs.launchpad.net/mir/+bug/1207312
<ubot5> Launchpad bug 1207312 in Mir "Need the ability to record video of the screen " [Undecided,New]
<robert_ancell> alf__, regarding https://code.launchpad.net/~robert-ancell/mir/alt-ctrl-backspace/+merge/178036 - do you want to merge your common code in now and I'll rebase on it, or do the rebase yourself when merging it in?
<alf__> robert_ancell: Let's get the common code in first, and I will give rebasing a try. I will let you know if there are any issues. BTW, we also need VT switching code.
<alan_g> hikiko: I've made a second review comment - after more thought than the first.
<robert_ancell> alf__, I have the VT switching code done
<robert_ancell> in lp:~robert-ancell/mir/setsid-alt-ctrl-Fn
<robert_ancell> tvoss_, what was the problem we had in the system compositor that we turned the input off for? We need to re-enable the input for mlankhorst patch to go through
<alf__> robert_ancell: ok, if the common code (multimonitor-examples) lands early enough today I will take your branches, rebase them and MP them. Otherwise whoever gets to it first can do it.
<tvoss_> robert_ancell, it makes the ati tests fail when trying to allocate a bo for the hw cursor
<robert_ancell> tvoss_, right, so we just need to disable the cursor then
<tvoss_> robert_ancell, right
<hikiko> alan_g, I saw it thanks, just a question: it's not possible at all that we release the connection before deleting the platform? I mean
<hikiko> we are sure that nested mir will never be disconnected before the exit?
<alan_g> hikiko: we don't need it (yet)
<alan_g> so don't make anything more complicated to allow it.
<robert_ancell> racarr, are you awake?
<alan_g> hikiko: http://en.wikipedia.org/wiki/You_aren't_gonna_need_it
<hikiko> ok alan_g one more question:
<hikiko> if I make mir connection const
<hikiko> i wont be able to call is valid and get error and release
<hikiko> whithout cast
<hikiko> :s/without cast//
<hikiko> :p
<alan_g> hikiko: why do you think that?
<hikiko> because they get char* not const char*
<hikiko> eeh
<hikiko> const MirConnection* :p
<hikiko> and MirConnection*
<alan_g> MirConnection* const connection;
<alan_g> Make connection const, not what it points to
<hikiko> this doesn't make it read-only?
<hikiko> :s
<hikiko> shall i make it mutable?
<alan_g> What for?
<hikiko>  I call mir_connect_sync in the constructor
<hikiko> connection = mir_connect_sync
<alan_g> But you shouldn't - call it in the initializer list
<hikiko> then makes sense :D
<hikiko> ok
<robert_ancell> Can I get a second opinion on https://code.launchpad.net/~robertcarr/unity-system-compositor/disable-cursor/+merge/174006?
<alan_g> robert_ancell: done
<robert_ancell> alan_g, ta
<robert_ancell> alan_g, feel like https://code.launchpad.net/~robert-ancell/unity-system-compositor/vt-switch/+merge/178072 too?
<alan_g> what look at usc twice in one day?
<robert_ancell> indeed
<robert_ancell> a wild Thursday for all involved
<alan_g> robert_ancell: is there a way to test it without forcing my system to reboot into usc world? (I never do that.)
<robert_ancell> alan_g, not easily
<robert_ancell> rather, no, you would have to go into u-s-c world
<alan_g> I'll have to pass then
<kgunn_> alf__ hey so that was it....
<kgunn_> thnaks for the help
<alf__> kgunn_: no problem, let me know how things go when you connect a second monitor
<kgunn_> i'll probably demo tomorrow at wrap up....i still need to find an extra mon
<kgunn_> you bet
<kgunn_> exciting stuff
<alf__> kgunn_: It would be great if you could find a monitor today and try it out, so we have more time in case of problems
<kgunn_> yep...i think i may creep out of the meeting i'm in
<robert_ancell> mlankhorst, around?
<seb128> robert_ancell, he's off today
<robert_ancell> seb128, ah, thanks
<seb128> yw
<jono> robert_ancell, would you mind responding to the post on mir-devel with the guy trying to get Mir running?
<robert_ancell> jono, looking...
<jono> thanks, pal
<kgunn> racarr: ping
<kgunn> robert_ancell: your answer on mir-devel....didn't i just prove you need the mesa bit
<robert_ancell> kgunn, only if you're running a client right?
<robert_ancell> which is the obvious next step
<kgunn> yep
<robert_ancell> I'll clarify
<kgunn> cool...was just double checking, it sort of hit me since i just stumbled today
<robert_ancell> kgunn, this problem will all disappear soon when the patch is in the archive
<kgunn> ;)
<kgunn> robert_ancell: that's what you say to all the girls
<robert_ancell> kgunn, that's how you end up with two children
<kgunn> :))
<alan_g> alf__: happy with this version? https://code.launchpad.net/~alan-griffiths/mir/negate-negative-error-codes/+merge/178041
<alf__> alan_g: yes, approved
<alan_g> alf__: thanks
<alan_g> Have a great evening
<robert_ancell> racarr, around?
<om26er> how do I stop surfaceflinger ?
<kdub_> om26er, 'stop'
<om26er> kdub_, figured that, though I had to first 'android-chroot'
<om26er> the doc probably needs to be updated
<kdub_> om26er, would be an easy patch to make :) (docs are generated from mir source)
<om26er> kdub_, sure, branching lp:mir :)
<racarr> robotfuel: kgunn: Oi. sorry. family stuff
<racarr> should have sent an email
<racarr> err robotfuel sorry, tab completion error
<racarr> https://code.launchpad.net/~robertcarr/mir/client-focus-notifications/+merge/166440
<racarr> can I top approve?
<racarr> Let's land this too https://code.launchpad.net/~mterry/mir/session-for-surface/+merge/174406 as per the discussion at end?
<kdub_> racarr, i suppose, i think we'll have to unwind it though eventually
<racarr> kdub_: Yes definitely
<racarr> I feel sort of like it doesn't make our unwinding much harder than it already is though
<racarr> espescially as long as we don't use it internally and just let it be to unblock mterry
<racarr> and I feel like we have blocked mterry for too long on something that should be trivial
<kdub_> racarr, well, switched to abstain
<racarr> kdub_: Ok. I think it conflicts with some stuff so I will merge it later once I have an idea of what all that is up conflicts
<smintheu> hi all
<smintheu> I just saw that a bunch of mir-related packages are in my dist-upgrade
<smintheu> is there any way to check if i'm running mir now?
<kdub_> smintheu, look for a unity-system-compositor executable with 'ps ax' is a good way
<smintheu> from the documentation i read earlier a 'ps aux | grep unity' should show me that if unity-system-compositor is running, i'm running mir, is that right?
<smintheu> kdub, it isn't
<smintheu> after the update, is there anything I should do to 'activate' mir?
<racarr> Can we try and land death-to-single-visibility today
<racarr> would like to land that and no-input-for-hiddne-surfaces
<racarr> so I can unjam test_client_input.cpp
<racarr> and begin improving that
<racarr> Taking off for a while. my entire family is in town for just the day so going to spend some time with them . I will come back for a while in the evening to iterate if anyone has time to do some reviews.
#ubuntu-mir 2013-08-02
<ricmm> hi
<ricmm> anyone around?
<RAOF> ricmm: Sure; best to actually ask your question, though.
<ricmm> RAOF: seeing this with latest Mir in the phone image that runs unity-mir
<ricmm> http://pastebin.ubuntu.com/5938197/
<ricmm> catching a SIGBUS there
<ricmm> any ideas?
<ricmm> examples run fine
<RAOF> Hm. Nothing obviously springs to mind.
<RAOF> Except that SIGBUS is one of those fun errors that's only ever going to occur on armd
<kdub_> oh hmm
<RAOF> Oh, hey, arm guy!
<kdub_> ricmm, we moved that code between libraries recently, perhaps something isnt updated
<kdub_> i'll try it, one minute
<ricmm> thanks kevin
<ricmm> kdub_: any clues?
<kdub_> ricmm, i'm not seeing any problems with the example programs i have
<kdub_> not set up for the unity-mir though on this device at the moment
<ricmm> can you think of any API changes that might've triggered this?
<kdub_> no :/
<kdub_> ricmm, actually, yes!
<ricmm> :)
<kdub_> we changed the way that the display size is handed out, perhaps there's something amiss there
<kdub_> it should be backward-compatible though...
<kdub_> but if something is wrong, mabye its trying to make a surface that's a nonsense size
<ricmm> lemme catch the call to create_surface and see the params
<ricmm> kdub_: http://pastebin.ubuntu.com/5938258/
<ricmm> size looks fine, it has been working like this before
<ricmm> depth 0 means anything?
<kdub_> right, that looks fine
<kdub_> depth 0 is just the stack ordering position, its ok
<ricmm> what change with the size passing?
<kdub_> that was a client side api change, this is an internal client, so what i mentioned probably won't affect anything
<duflu> RAOF: ping
<RAOF> duflu: pong
<RAOF> Would you quite like to talk bypass?
<duflu> RAOF: I've removed the explicit (and slightly hacky) workaround fix for the input lag bug... but suspect it might still be fixed by that branch. Can you retest?
<duflu> RAOF: No bypass this week :(
<RAOF> duflu: Still the "switch" branch?
<duflu> RAOF: Yes.
<RAOF> I'll give it a try. It may take me a little while to get to that.
<duflu> RAOF: Actually, maybe wait. I might try to do an independent fix for that bug
<RAOF> Excellent. The best kind of testing :)
<duflu> RAOF: I just realized, even if my branch eliminates the cause of the bug under double buffering, it introduces triple buffering which is expected to cause the same bug. I think we need to fix the compositor...
<RAOF> ok
<RAOF> Ok. Who changed the mir_connection_get_display_info ABI on me?
 * duflu points to multimonitor guys
<RAOF> Ahem.
<RAOF> Yes, that commit did indeed break mir_connection_get_display_info
<RAOF> Grr. I wonder what's easier. Fixing mir_connection_get_display_info, or switching to the new API.
<tvoss_> good morning :)
<duflu> RAOF: Robert was right when he said "everyone forgets to bump ABIs"
<duflu> Morning tvoss_
<tvoss_> duflu, good morning
<RAOF> duflu: This isn't actually a deliberate ABI break. This is just a buggy implementation of the deprecated function.
 * RAOF 's symbol file branch wouldn't have helped here
<RAOF> Ok. Whoever wrote the mir_connection_get_display_info was too trusting :)
<RAOF> Ok. I'm going to go and collect something; back in 20 minutes or so. Then I'll fix this.
<tvoss_> RAOF, see you :)
<tvoss_> duflu, on the switch branch: Alf mentioned that it might break the mm use-case he is working on
<tvoss_> did you have a chance to look into that?
<duflu> tvoss_: Yes I have a fix/workaround in mind.
<duflu> ... but still think we need a more robust solution later, as discussed with alf a while back
<tvoss_> duflu, okay, what would be your proposal to move forward?
<duflu> tvoss_: I'll do a fix/workaround to work with the existing mm logic today, I hope
<duflu> Just saying I think the MM assumptions are wrong/unsafe
<tvoss_> duflu, existing as in what alf and kdub are landing right now?
<duflu> tvoss_: Yes I've discussed it with alf already
<tvoss_> duflu, ack. I will grab some breakfast and be back after that
<alf__> duflu: What's unsafe about the MM assumptions?
<duflu> alf__: The assumption that each monitor will compositor_acquire at roughly the same time. I think we need better guarantees that it only happens once per vsync
<duflu> But I will do a workaround in the switch branch, which should work in theory
<alf__> duflu: the problem is that we don't have a single vsync, we have as many vsyncs as outputs
<duflu> alf__: Yes, I know. I can probably defer the discussion if I can workaround in switch before my EOD
<alf__> duflu: ok, I would be interested in any sane alternatives, but I don't have any in mind
<duflu> It will be a blocker for bypass though. Which is why I've changed it...
<alf__> duflu: I guess that indicates that it needs to be configurable. At this point it doesn't seem that we can have a one size fits all swapper.
<duflu> alf__: I've had a few ideas. But am too rushed to revisit today. I'll try and give you a workaround in the switch branch tho
<tvoss_> duflu, alf__ we should tackle that together on Monday morning.
<duflu> alf__: The squashed render_surfaces issue seems to be triggered by my lazy allocation optimization. render_surfaces' RenderResourcesBufferInitializer is making the poor assumption about when it is executed, and interacting with the wrong GL context
<duflu> alf__: So I'm wondering if I should disable the optimization or leave the render_surfaces bug for fixing separately?
<alf__> duflu: what resource are you allocating lazily?
<duflu> alf__: The buffers
<duflu> alf__: Aha! Never mind. I have a simple fix
<racarr> Strange jenkins error on no-input-for-hidden-surfaces
<racarr> is what racarr would be wondering about if he were awake ;)
<duflu> racarr, welcome to Friday
<RAOF> alf__: Hey, so mir_connection_get_display_info is broken. What should I be fixing - the false assumption that config->displays[0] is always valid if num_displays > 1, or making that assumption true?
<alf__> RAOF: the false assumption that config->displays[0] is always valid (if by valid you mean connected and used)
<RAOF> alf__: Good, that's what I'm in the process of doing.
<alf__> RAOF: hmm, config->displays should be config->outputs...
<RAOF> Quite true.
<alf__> RAOF: Do you want to wait a moment so I can fix that?
<RAOF> Ok
<alf__> RAOF: so you don't have to make another change soon, but whatever is more convenient for you
<RAOF> Well, this is blocking me now, and the update will be trivial.
<alf__> RAOF: ok, then feel free to change it now and I will ping you for an update (perhaps we need to wait until Monday to push the s/display/output/ change so we don't break everything)
<RAOF> Ideally we'd land this at the same time.
<RAOF> Actually, no.
<RAOF> We're breaking ABI, so your change bumps SONAME regardless.
<RAOF> Monday is fine.
<alf__> RAOF: if I push the change today will it break the packages?
<RAOF> Not any more than the packages are currently broken.
<alf__> RAOF: (I assume so, since you won't be able to update the mesa/x again until next week)
<alf__> RAOF: ok, either Kevin or I will have an MP ready for you. When you feel like it next week approve it and make the Mesa/X changes at your convenience.
<RAOF> It actually doesn't change X or Mesa (at this point), so we kindof could get away with silently breaking ABI.
<alf__> RAOF: ok, where is the breakage then?
<RAOF> mir_connection_get_display_info segfaults
<RAOF> Because its implementation assumes that config->displays[0] is always valid.
<alf__> RAOF: sorry, I misunderstood the whole discussion, looking
<alf__> RAOF: ok, feel free to make the change and we can rename afterwards (hopefully later today)
<RAOF> Hm. We've got no tests for mir_connection_get_display_info.
<alf__> RAOF: I am sure we had... I guess they were remove when introducing the new API
<RAOF> Indeed.
<RAOF> didrocks: Good morning.
<RAOF> How goes IoM?
<didrocks> hey RAOF!
<didrocks> RAOF: foggy? ;)
<didrocks> how is the other side of the planet?
<RAOF> Darkening!
<RAOF> alf__: https://code.launchpad.net/~raof/mir/fix-mir_connection_get_display_info/+merge/178216 is there for your viewing pleasure.
<alf__> RAOF: a more reliable test would be to check that (.used == 1 and .connected == 1 and .current_mode < .num_modes)
<didrocks> RAOF: btw, any luck with testing xmir/xorg and upload that to distro?
<didrocks> (or still building?)
<RAOF> didrocks: See conversation above. The libmirclient1 that landed this morning broke xmir.
<RAOF> *Apart* from that, everything seems to be good to go.
<RAOF> :)
<didrocks> RAOF: ahah, ok, so once your MP merged, I need to repush mir to distro
<didrocks> then you push all the crack
<didrocks> we promote
<didrocks> and then u-s-c
<duflu> alf__: For future-proofing can we not test booleans against "1" ? :)
<duflu> *"can we please not"
<alf__> duflu: sure :)
<RAOF> alf__: Thanks
<robert_ancell> RAOF, hey, can you do a quick triage on bug 1206744
<ubot5> bug 1206744 in XMir "black screen on nvidia gt640 with system-compositor-testing ppa" [Critical,New] https://launchpad.net/bugs/1206744
<RAOF> Bah! What's happened to radeon?
<alf__> RAOF: hmm, test failure about uninitialized variable
<RAOF> Hm, quite true.
<RAOF> Why didn't that error locally?
<RAOF> Evening ZoÃ« time.
<duflu> Back in 20ish
<alan_g> hikiko: you've not addressed https://code.launchpad.net/~hikiko/mir/mir.nested-mode-connection/+merge/178042/comments/401241 - should be a 5 minute job?
<hikiko> I ve fixed i t already alan_g :)
<hikiko> pushing!
<hikiko> oh no
<alan_g> alf__: ^ - want to re-review?
<hikiko> I was referring to another comment
<hikiko> sorry
<hikiko> you mean to replace MirConnection* with unique_ptr?
<hikiko> https://code.launchpad.net/~hikiko/mir/mir.nested-mode-connection/+merge/178042/comments/401765
<hikiko> I am pushing this fix
<alan_g> hikiko: it is better to resolve "Needs Fixing" comments than "Comment" comments.
<hikiko> yes I pushed alex's changes except the MirConnection*
<hikiko> do we really need this?
<hikiko> (because we use it once)
<hikiko> and never again
<alan_g> hikiko: because we throw in the constructor the destructor never executes. So the connection is leaked.
<hikiko> oh
<hikiko> i see
<alan_g> unique_ptr isn't IMO the cleanest solution - I'd write an RAII class
<hikiko> sorry if I sound too naive but I don't know what a RAII class is
<hikiko> http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization
<hikiko> is it this?^
<alf__> hikiko: yes
<hikiko> cool :) I'll read it (I've never used it before)
 * duflu is not a fan of RAII. Most notably because it confuses object destruction for resource close. If you for example "delete my_file", that does not delete or destroy the file like destruction usually implies
 * alan_g Likes RAII - but thinks it should be called "use destructors for paired operations"
<tsdgeos> guys
<tsdgeos> i've come across
<tsdgeos> class ForwardingInternalSurface : public mg::InternalSurface
<tsdgeos> with the comment
<tsdgeos>  // TODO this ought to be provided by the library
<alan_g> tsdgeos: ack I wrote that
<tsdgeos> I agree, since i think i need something similar to make http://bazaar.launchpad.net/~phablet-team/platform-api/mir-packaging/ compile again
<tsdgeos> so i copy that class in there or?
<alan_g> tsdgeos: you could as a workaround. I'll be fixing that in a few days (sorry didn't know of your dependency)
<tsdgeos> ok
<tsdgeos> will do
<RAOF> alf__: MP should be fixed; review at your leisure.
<alf__> RAOF: great, thanks
<duflu> RAOF: I proposed a new, different, fix for the lag bug, if you wish to continue hacking into the night :)
 * duflu -> dinner
<RAOF> didrocks: Hey, it's ok for me to upload the stack before that mir fix lands, isn't it? It'll be blocked in -proposed until everything works?
<didrocks> RAOF: it will be blocked in -proposed until someone put mir in main
<didrocks> RAOF: what can happen TBH during the week-end
<didrocks> (low chance though)
<didrocks> RAOF: can you bump the build-dep?
<didrocks> that way, we'll be sure that we'll need a new Mir version
<didrocks> (even if it's artificial)
<didrocks> wdyt?
<RAOF> I could do that, I guess?
<RAOF> Actually - unity-system-compositor *does* have auto tests, right?
<RAOF> The bug only occurs under u-s-c, and is highly likely to be caught by *any* u-s-c testing
<didrocks> RAOF: those tests are integration tests
<didrocks> RAOF: they can't run autopilot
<RAOF> So those tests aren't run before promotion from -proposed?
<didrocks> RAOF: exactly
<RAOF> Ok; build-dep bump it is.
<RAOF> Fire in the hole!
<arsson> Is there still two cursors?
<RAOF> Nope.
<RAOF> So, now that everything's uploaded to proposed, time to disappear for the weekend.
<RAOF> What could possibly go wrong!
<tvoss_> RAOF, ping
<robert_ancell> alf__, you are working on a patch for alt+ctrl+backspace in the examples?
<alf__> robert_ancell: yes
<robert_ancell> alf__, ok, I was working on that too - I'll stop then
<alf__> robert_ancell: basically, your branch adapted to mir::examples::ServerConfiguration
<robert_ancell> alf__, ok
<robert_ancell> alf__, I just rebased so it uses mir::examples::ServerConfiguration, but I didn't remove the duplication yet
<alf__> robert_ancell: well, then you are farther ahead than I am :)
<robert_ancell> I was stuck on std::initializer_list - how to have one build in filter in the config but also support other filters that the examples require
<robert_ancell> built in filter rather
<alf__> robert_ancell: yes, we need to get rid of initializer_list and replace it with a mutable container (e.g. vector) or perhaps some other abstraction
<robert_ancell> yes :)
<robert_ancell> alf__, ok, should I stop and leave you to make the merge then?
<alf__> robert_ancell: I am not sure now, since you are further ahead than I am. I just declared intention of doing it, haven't really started yet
<robert_ancell> alf__, ok, I'll continue then - I'll be off on Monday after I fly back from IOM so feel free to finish it off if you have plans there
<alf__> robert_ancell: ok, sounds good then
<thomi> racarr: any progress with the stress test / thread race fix?
<alan_g> hikiko: how are you doing?
<hikiko> alan_g,
<hikiko> I did it
<hikiko> it wasn't that simple
<hikiko> I had to overload * as well
<hikiko> to keep using the same methods
<hikiko> but it seems to work :D
<hikiko> I am testing and I will push in a moment
<alan_g> Cool, I have an automated test for it: lp:~alan-griffiths/mir/sketch-for-nested-mir-tests
<hikiko> thanks a lot! :D I will merge it
<alan_g> you merge that and run bin/acceptance-tests --gtest_filter=TestNestedMir*
<hikiko> alan_g, I got some ok and passed
<hikiko> can I push the merge?
<alan_g> hikiko: please do
<racarr> :(  just merged trunk in to client focus notifications again and lots of test failures
<kdub_> trunk looks ok to me (rev920), aside from the already known problem tests
<racarr> kdub_: Yeah its just some weird interaction
<racarr> probably having to do ith some redone test fixture and stubs vs mocks and blabla bla still investigating
<racarr> its kind of cryptical somehow
<racarr> broken pipe, connection refused, etc.
<racarr> The thing is ApplicationMediatorReport session_connect and session_create_surface fail
<racarr> but, session_disconnect
<racarr> which contains session_create_surface as a literal textual subset
<racarr> passes
<racarr> I think something funny is going on with test_protobuf_client
<racarr> maybe the event sink is trying to send events after the client has already destroyed it's surface
<racarr> i.e. done->Run(); client destroys surface quickly
<racarr> err
<racarr> client disconnects
<racarr> then the event sink is unclogged
<racarr> and the socket is invalid
<racarr> and I guess
<racarr> an exception isnt being handled
<racarr> due to some unrelated change
<racarr> nah keeping the client alive doesnt fixit so its somethingelse
<racarr> it may be happening when trying to send the focus lost message on close_session
<racarr> need to investigate the ownership of the MessageSender
<racarr> i.e. perhaps EventSender can not take a strong reference
<racarr> I see. It can only happen in the ~SessionMediator Session closed without disconnect code path
<racarr> and even then only sometimes
<racarr> so, it seems like the client process finishes succesfully
<racarr> and dies without disconnect then the server gets sigterm by the testing process manager
<racarr> and shuts down, ~SessionMediator is reached
<racarr> which sees that disconnect was never called and calls SessionManager->close_session...
<racarr> so, then SessionManager::close_session tries to clear the focus
<racarr> the client which is being closed now, never closed it's surface either
<racarr> so, the focus mechanism sees that said surface last had focus
<racarr> and delivers an unfocused event
<racarr> eventually ending in SocketMessenger throwing because of broken pipe
<racarr> Almost surely, event_sender taking a weak reference to the message sender will fix it
<racarr> but im concerned in that I do not understand why it didn't happen before
<racarr> kdub_: Any ideas perhaps?
<kdub_> hmm
<kdub_> so a client is outliving the server?
<racarr> kdub_: No, the client is shutting don, without calling disconnect or release_surface
<racarr> so then the testing_process_manager kills the server
<racarr> and in ~SessionMediator when close_session is called
<racarr> eventually the surface is unfocused
<racarr> causing things to try and send an event over the wire
<racarr> and unhandled broken pipe exception
<kdub_> i'd hope there's a better way handle that than a proxy
<kdub_> havent thought too deply though how yet
<racarr> kdub_: Mm. there are a bunch of ways to make the test pass but it feels like
<racarr> something is wrong
<racarr> kdub_: One thing is I think
<racarr> EventSender can take std::weak_ptr<MessageSender> perhaps?
<kdub_> i suppose
<racarr> but it seems
<kdub_> that was the proxying though
<racarr> also not correct XD
<racarr> yeah
<racarr> kdub_: This is a total diversion but I saw a crazy idea yesterday from john carmack on handling mutable state in multithreaded C++ game logic
<racarr> first, you use a seperate garbage collected heap for all your mutable data i.e. your non asset data.
<racarr> and basically you write all your code, kind of in the style we are using for multithreading except with two crazy differences
<racarr> 1. Rather than any of your actors or whatever actually updating state, they return partially applied functions to do such, and then the main frame loop
<racarr> sorts out how to apply such
<racarr> but then the also clever bit is
<racarr> well how do you actually enforce this, if you are handing out pointers still
<racarr> so the objects can look at eachother
<racarr> so the idea is during the garbage collection step (which you do every frame), you copy the entire mutable heap
<racarr> and all your objects that have pointers to other objects
<racarr> you update with a pointer to the heap from the last frame
<racarr> which you then mprotect
<racarr> so basically each of your actors, can have "real" enforced purity
<racarr> and you have a small bit of monadic code that applies all these unctions they create
<racarr> :p not really an architecture for mir but I thought it was really fascinating
<racarr> Back from lunch, Ill produce a reduced test case. so this doesn't muddle client focus notifications
<racarr> i.e....events_sent_during_disconnect_do_not_crash_server
<racarr> got a reduced test but the ownership doesnt work like I thought it did so just weak_ptr isnt enough
 * kdub_ forgot to mention... if i go dark, its because the internet company cut me off early
<kdub_> transferring my service over the weekend
<racarr> the connected sessions abstraction is making this hard to solve
<racarr> sigh I tried having the EventSender used connected_sessions to verify that
<racarr> the session was still around
<racarr> but this whole process of disconnect happens during the
<racarr> connected_sessions.remove call
<racarr> so of course that is a deadlock
<racarr> part of the reason this code is so difficult is socket session killing itself
<racarr> by calling connected_sessions.remove
#ubuntu-mir 2013-08-03
<smartboyhw> Mir developers: Is the "two-pointer" bug fixed?
<mlankhorst> it's a feature, so you know the hw cursor is active
<smartboyhw> mlankhorst, I'm sorry, but I seriously don't like this feature
<GridCubexmir> this seems to be the best place to ask
<GridCubexmir> hello! :) im testing xmir/xubuntu in my machine using a live iso. my vga is 02:00.0 VGA compatible controller: NVIDIA Corporation GF119 [GeForce GT 520] (rev a1) and im using the generic drivers so far, the issue its that i have two monitors and so far im just being able to mirror them, thats the default behaviour, what should i try to do to see if i can extend the desktop to both monitors?
<mlankhorst> I think the multimonitor branch is not merged yet
<GridCubexmir> alright then
<mlankhorst> I'm surprised gf119 works, thought it required one of the 3.11 rc's :P
<GridCubexmir> o
<GridCubexmir> thanks
<GridCubexmir> lets try now not using nouveau now :D
#ubuntu-mir 2013-08-04
<vibhav> What exactly would be expected in a python biding for the mir API?
<vibhav> I have been working on a mir-python binding and I have planned to bind all the methods the API is currently providing
<vibhav> Is there anything else that should be added?
<vibhav`> d
#ubuntu-mir 2014-07-28
<alf_> RAOF: Hi! I was playing with debian/control to solve https://bugs.launchpad.net/mir/+bug/1348515 and noticed some interesting results.
<ubot5> Launchpad bug 1348515 in Mir "New mircommon-dev is not replaced by libmircommon-dev" [High,In progress]
<alf_> RAOF: If we remove the version from Breaks,Replaces then the replacement doesn't happen and the builds fail.
 * RAOF wonders again why we have a mircommon-dev :)
<alf_> RAOF: If we set the version to something less strict (e.g. << 0.6) then both packages get installed :/
<alf_> RAOF: Conflicts,Replaces,Provides works as expected
<RAOF> Is something in the CI infrastructure manually install mircommon-dev?L
<RAOF> Anything with Provides: is incorrect.
<RAOF> mircommon-dev isn't a virtual package, with multiple different implementations that you can select from :)
<alf_> RAOF: @mircommon-dev installed in CI, Yes, we fixed that, but that's ortogonal to "New mircommon-dev is not replaced by libmircommon-dev"
<RAOF> Ah, so we just need to fix the versioning.
<RAOF> Which our processes make unnecessarily difficult, because we don't *have* a version.
<RAOF> (This is why the packaging branch should not be trunk)
<RAOF> :)
<alf_> RAOF: right, but changing the version to e.g. << 0.6, doesn't work well both packages get installed :/
<alf_> RAOF: According to https://wiki.debian.org/Renaming_a_Package , the way to do it is either Conflicts,Replaces,Provides (and it doesn't have to be a virtual package), or Breaks,Replaces + transitional package
<RAOF> Because the package version is now 0.6.0bzr1792pkg0utopic5+autopilot0, and 0.6.0bzr is not strictly less than 0.6
<RAOF> We don't need a transitional package because nothing that isn't in src:mir depends on mircommon-dev
 * RAOF will be back soon
<alf_> RAOF: @"0.6.0bzr is not strictly less than 0.6", I don't think that's the reason, our latest mircommon-dev is still 0.5.0.
<alf_> RAOF: https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/2209/console , is a run with Breaks and Replaces with version (<< 0.6~) .
<alf_> RAOF: It seems we are setting up both packages: "Setting up libmircommon-dev:armhf (0.6.0bzr1797pkg0utopic24+autopilot0)" "Setting up mircommon-dev:armhf (0.5.0+14.10.20140724-0ubuntu1)" which is weird
<RAOF> Hm.
<RAOF> I shall check exactly how apt invokes dpkg.
<RAOF> Hm. Actually, why not solve the problem once and for all...
<RAOF> alf_: Do you know how Alan fiddled with the setup process?
<RAOF> alf_: Rather than calling dpkg exactly the way apt would call it, it occurs to me that it'd be simpler to just call apt :)
<alf_> RAOF: AFAIK, the runner scripts are here: https://code.launchpad.net/~mir-team/+junk/mir-medium-test-runner-for-jenkins/
<RAOF> Sweet.
<RAOF> Let's play âlocal apt repositoryâ then...
<alf_> RAOF: Note that if you want to try debian/control fixes, base them against lp:~afrantzis/mir/fix-mircommon-debian-replaces, since in this branch I have reverted the fix for not installing mircommon-dev which is now in lp:mir/devel. If you just use mir/devel you will not get mircommon-dev at all in CI so any fixes will not have an effect.
<RAOF> Really? I thought it pulled mircommon-dev from the apt-get install glmark2-es2-mir?
<RAOF> (ie: from the package in the archive)
<RAOF> Ok. I think that *should* work. I might wait until Alan is on and ask him how to test it :)
<RAOF> But first, some shopping.
<racarr_> GOod morning...probably missing standup...sorry..have to go out and get a USB Key accidentally deleted my refit partition (meant to just delete OSX)
<racarr_> and now computer doesnt boot :)
<racarr_> I have never understood
<racarr_> wqhat the Native
<racarr_> in NativePlatform
<racarr_> means
<kdub> racarr_, it is confusing
<kdub> we really have buffer-allocating platform code and display-showing platform code
<kdub> and we awkwardly mix it into that class for the modes that don't need the display-showing code
<racarr_> kdub: I guess I understand the purpose I just odnt understand
<racarr_> the word "native"
<racarr_> I guess its kind of like
<racarr_> for a nested server
<racarr_> its certain hooks to the "underlying native" platform or something
<racarr_> I dunno
 * kdub thinks the structure is a bit wrong, and the name is a bit of a bandaid
<kdub> but, bigger fish to fry
<racarr_> all I know is LUNCH LUNCH LUNNNNNNNNNNNNNNNNCH
<racarr_> kdub: Indeed. I was only bringing it up incase there was some like
<racarr_> clever way of looking at it I was missing
<racarr_> lol
<racarr_> Back
#ubuntu-mir 2014-07-29
<bschaefer> racarr_, can a cursor exist (render) with a mir surface that never swaps buffers?
<bschaefer> attempting to manually swap said surface causes a crash :(
<racarr_> bschaefer: I dont exactly understand the second bit
<racarr_> but to the first bit...should be able to!
<RAOF> We don't expose the ability to use a surface as a cursor yet, do we?
<bschaefer> racarr_, well, the issue im see is in SDL2 they do a cursor test just by simply rendering the cursor (a surface/window exists but is not renderered)
<bschaefer> RAOF, so yeah, thats what would be needed i suppose (or at lease how this one SDL2 test assume cursors work)
<RAOF> Can we tell SDL that we don't support hardware cursors?
<bschaefer> RAOF, hmm
<bschaefer> RAOF, so thats a hardware cusor? I wonder if it assumes the system cursor is a hardware cursor?
<bschaefer> RAOF, i think we can live with out that support, considering most the time a window will come along with the cursor (otherwise thats a pretty boring app)
<RAOF> Well, can we tell SDL that it'll have to draw its own cursors if it wants to draw something special?
<bschaefer> for now i can just set the cursor for the surface, and if they don't render the window then they wont get anything
<RAOF> Oh, right!
<bschaefer> RAOF, not that i know, ill have to dig into that, but i think it just sets the cursor
<bschaefer> and wishes it luck
<RAOF> Because the cursor is only going to change when it's *over* the surface.
<bschaefer> right
<bschaefer> cool, i can live with that
<bschaefer> just wanted to double check :). Thanks!
<RAOF> And the surface isn't going to appear until some rendering has been done to it.
<RAOF> Right, I think I see your problem now :)
<racarr_> hmm
<racarr_> shouldnt the surface be in the input targets though
<racarr_> even if its never posted a buffer
<bschaefer> yeah, the test was interesting ill have to write my own where the window is being rendererd
<bschaefer> racarr_, yeah, inputs and all is fine it just never gets to the swap buffers stage
<bschaefer> so when i set the cursor
<bschaefer> configure for the surface
<bschaefer> you need to swap the buffers to get the new cursor right?
<bschaefer> as, from i can tell doing a set cursor config on a surface yeilds nothing until a swap happens
<racarr_> I wouldn't thinky ou would no
<racarr_> as far as I can tell doing a swap doesn't change anything with respect to doing hte set cursor
<racarr_> and there is a test that
<racarr_> you can change the cursor without anything else happening
<racarr_> and the appropreiate things happen...so
<racarr_> something weird is happening
<RAOF> racarr_: If you haven't submitted a buffer we don't show the window at all, right?
<RAOF> racarr_: So the surface *won't* be in the input targets list?
<RAOF> Or, at least, if the surface is in the input targets list that'd be a pretty horrible bug, because it would look like you'd have input mysteriously going nowhere.
<bschaefer> racarr_, i can take a look, where is the input target list kept?
<bschaefer> i would think the mir_server somewhere?
<bschaefer> racarr_, yeah in your example if i comment out that first swap buffers
<bschaefer> nothing shows up, and soo i cant see any cursor changes (since it has to be over a surface)
<bschaefer> sooo i guess the overall issue, there is no swap at the very beginning, so no mir_surface is rendered so i cant see the cursors getting changed
<racarr_> RAOF: I think it will be and it would be a horrible bug
<racarr_> bschaefer: Ok possible if nothing
<racarr_> is ever rendered
<racarr_> at all
<racarr_> then the cursor wont show up
<racarr_> hahaha
<racarr_> like from any surface.
<bschaefer> racarr_, yeah haha
<RAOF> Ah, cmake
<RAOF> *Of course* set(VAR value PARENT_SCOPE) doesn't actually set VAR in the *current* scope.
<RAOF> Whyever would I expect that behaviour?
<RAOF> Oops.
<RAOF> Don't do testing in a dirty tree.
<alan_g> alf_: anpok want to give an opinion on this or shall I top-approve? https://code.launchpad.net/~alan-griffiths/mir/fix-libmirclient/+merge/228336
<alf_> alan_g: just commented
<alan_g> Just saw that. ;)
<alan_g> BTW I'd be happier if it were *only* the unit tests that linked directly to the internal classes - maybe we should record that as a bug?
<anpok> hm or the opposite .. acceptance tests not using the libraries
<anpok> i mean we have integration tests that dont include/touch/need the complete system
<alan_g> Yes, the acceptance tests ideally use the libraries.
<anpok> the $<TARGET_OBJECTS.. will pull in the object files built for the target
<anpok> ?
<alan_g> yes
<anpok> nearly like libtool convenience library
<alan_g> alf_: It is great how the review process unearths hidden problems: https://code.launchpad.net/~alan-griffiths/mir/fix-libmirclient/+merge/228336/comments/553784
<alan_g> greyback: is the "PrivateProtobuf" stuff being used?
<alf_> alan_g: @"It is great how the review process unearths hidden problems", +1
<greyback> alan_g: not that I can see, no
<alf_> greyback: Yesterday my eye caught a comment about not showing the last frame. Do you have a bug for that, more information about how to reproduce etc?
<alan_g> greyback: cool. No immediate plans either?
<greyback> alan_g: none that I'm aware of either
 * alan_g stop worrying about breaking it
 * alan_g finds ua_ui_set_clipboard_content()/ua_ui_get_clipboard_content()
<groot_> hello all
<groot_> racarr_, you here ?
<groot_> I was trying to investigate my device being stuck at boot logo. Yesterday I tried removing hwcomposer.so from android system and reboot.
<groot_> This time device booted up and a small ubuntu logo appeared followed by a hello screen to choose language.
<groot_> But it got stuck there. So I'm thinking maybe mir has problems with hwcomposer module. How can I debug it ?
<alan_g> groot_: the guys that know about bringing up devices new best (kdub and AlbertA) are not up yet.
<alan_g> groot_: can you adb into the device and see what's running? Or is that broke too?
<groot_> alan_g, I see. I'll wait for them. kdub helped me a lot to debug my issues :). Are they gonna be here soon ?
<groot_> alan_g, I've ADB access
<alan_g> Probably an hour or so
<groot_> alan_g, I can upload some logs if you want to take a look.
<alan_g> groot_: I'd be guessing as much as you are
<alan_g> But if you've adb you can try running mir_demo_server_basic and clients
<groot_> alan_g, all right. I'll try and see what happens.
<alan_g> alf_: (non-urgent) please have another look at https://code.launchpad.net/~alan-griffiths/mir/fix-libmirclient/+merge/228336
<alf_> alan_g: ok
<alan_g> alf_: is anything still happening with https://code.launchpad.net/~afrantzis/mir/fix-mircommon-debian-replaces/+merge/228247?
<alf_> alan_g: RAOF thinks that Breaks,Replaces is the right way to go, and wanted to try some script changes to use apt instead of dpkg
<alan_g> alf_: understood.
<alf_> alan_g: @fix-libmirclient, 136- mirclient , do we remove the explicit link because it's linked through libmirserver?
<alan_g> alf_: no, because I accidentally reverted that before checking in. (And, as you observer, it "just works")
<alan_g> alf_: fixed
<groot_> kdub, hello. I've come again to solve my device hang issue. Are you here ?
<kdub> yep, I thought you had a segfault issue though
<groot_> kdub, something interesting happened. Yesterday I tried removing hwcomposer.so from android system and reboot.
<groot_> This time device booted up and a small ubuntu logo appeared followed by a hello screen to choose language.
<groot_> But it got stuck there. So I'm thinking maybe mir has problems with hwcomposer module.
<kdub> oh, well if you do that you start using the backup mode (the fb module), which is deprecated in android, but seems it works on your device
<kdub> groot_, so that assessment is right... I was thinking that your hwcomposer module was malformed or loaded incorrectly, because a lot of the function hooks we call in hwc were nullptrs
<groot_> kdub, I'm sure that hwcomposer is fine since we use the same source on other custom roms. So probably it is loaded incorrectly.
<kdub> also, where you trying to run with hwcomposer as root?
 * kdub forgets if that was aske
<groot_> kdub, I'm not sure. hwcomposer is loaded during system startup? how to know it's running as root ?
<kdub> well, I meant running the test binaries
<kdub> like mir_demo_server_basic
<groot_> kdub, ohh I didn't use sudo. Just ran them normally when hwcomposer was present before.
<kdub> groot_, it tries to access some files in /dev, its a common problem with new devices that the permissions arent set up to run as the normal user
<kdub> so, might be worth a shot
<groot_> kdub, just to let you know, I ran some mir_demo commands like flicker, eglflash, scroll etc after removing hwcomposer.so. They worked, device screen was updated with the commands
<groot_> I'll test with hwcomposer beign present
<kdub> right, it seems the backup module is working
<groot_> kdub. just tried with sudo. Without sudo it segfaults and with sudo it falls back to command prompt. But those tests are failing, saying "couldn't connect to display server"
<kdub> so that wasnt the root of the problem
<groot_> kdub, So hwcomposer is the main issue here?
<kdub> yep!
<groot_> kdub, so how to know it's from my end or it's loaded incorrectly? I'm ready for some tests :)
<kdub> not quite sure, as we're hitting null function hooks that apparently aren't there in sf
<kdub> some devices have a .so that's just a passthrough to load another blob .so... is this driver like that?
<groot_> kdub, it's not. You can take a look if you want https://github.com/AndroidOpenSourceXperia/android_hardware_ste-sony/tree/master/display/libhwcomposer
<kdub> oh great, its open
<groot_> :)
<kdub> are any of those ALOGE's in hwcomposer_device_open printed in logcat?
<kdub> that seems to be the fn that fills the fn hooks
<groot_> kdub, I'll check and let you know.
<groot_> kdub, no errors like that. In fact, there's no log with that log tag.
<kdub> hmm, well, from what I've been told it seems like its not getting to lines 1681-1686
<groot_> kdub, there's a error in logcat "E/MMHwBufferPool( 1875): allocate: HWMEM_EXPORT_IOC failed". Maybe it's related ?
<kdub> well, sure doesn't sound good to me
<kdub> but it could be from any component
<groot_> kdub, is there a way to pinpoint the exact functions causing hwcomposer issue? (like backtrace)
<kdub> groot_, i'd see if it gets to those lines I pointed out in hwcomposer... that can be done via gdb or sprinkled printf
<groot_> kdub, can you tell me which commands to run ? I've the device attached.
<groot_> kdub, ^^
<kdub> groot_, short answer, its a bit too interactive to do over irc.
<kdub> but basically, after you have things built with debug symbols, you just run gdb and set up the breakpoints on hwcomposer_device_open
<kdub> and you can step over the lines of code to see if those function hooks get filled
<groot_> kdub, I'll try that. But hwcomposer is a .so file. I used "gdb programm_name" to get backtrace. How to do it with lib files? That part I don't understand :)
<kdub> ah, so when the executable starts up, the linker will stitch that .so file into the program (because the executable will ask for hwcomposer)
<groot_> kdub, all right. Lastly, what executable I should run?
<groot_> mir_demo_server_shell ?
<kdub> ./mir_demo_standalone_render_to_fb is the simplest thing that will drive the display, but that one will work also
<groot_> kdub, All right. I'll be here when I'm done with the test.
<kdub> groot_, good luck!
<groot_> kdub, thanks. It seems hard to me, do I have to build mir again? Or just the hwcomposer with "-g" flag ?
<kdub> hwcomposer
<kdub> mir should have been built with it, since you built it yourself
<chmodplusx> Hey guys, I was poking around wayland stuff and considered buildining it but I came across the link to Mir on the ubuntu website. Any pointers I should know that arent listed on the site?
<racarr_> Morning
<willcooke> hey racarr_
<alan_g> kdub: (non-urgent) please have another look at https://code.launchpad.net/~alan-griffiths/mir/fix-libmirclient/+merge/228336
<kdub> sure
<kdub> any other takers? https://code.launchpad.net/~kdub/mir/fd-refcount/+merge/228306
<racarr_> why am I putting the pixel 0x00 0xff 0xff 0xff in to an argb buffer and getting green lol...
<kgunn> racarr_: its really rgb ? ending up 00ffff ?
<racarr_> kgunn: Well...I dunno...I guess something really isn't
<racarr_> the buffer really does report being ARGB though, and my pixel really is 0, 255, 255, 255
<racarr_> and I do get green...
<racarr_> lol I guess that buffer isnt really ARGB or I have
<racarr_> made some strange error
<racarr_> touchspots are all done besidfes being
<racarr_> green...
<racarr_> lol
<kgunn> yea! for green touch spots
<racarr_> well in particular they are blue circles on green rectangles
<racarr_> instead of orange circles on transparent
<racarr_> :p
<kgunn> racarr_: oh wait....rgba vs argb
<kgunn> racarr_: suppose swap the values around would prove the theory
<racarr_> kdub: You were...talking about something the other day with android buffer maps and pixel format mess...is there anything in particualr beyond having to get the pixel format right?
<racarr_> kdub: ...my buffer reports being mir_pixel_format_argb8888
<kdub> racarr_, that should be all, as far as I remember
<kdub> and green would be 0xFF00FF00
<anpok> no tiling madness?
<racarr_> no tiling madness my
<racarr_> circle shows up as expected...
<racarr_> I guess I am getting yellow lol.
<racarr_> it was hard to see......
<racarr_> but my buffer says it should be argb8888, and I put in
<racarr_> 0, 255, 255, 255 and get yellow which means my buffer is really...bgra
<racarr_> or something
<racarr_> starting in b
<racarr_> what....:/
<racarr_> grrr
<kdub> racarr_,
<kdub> mir_pixel_format_argb_8888: gets translated to HAL_PIXEL_FORMAT_BGRA_8888
<kdub> so sounds like a byte ordering thing
<racarr_> I...feel like I must not understand what pixel formats
<racarr_> mean
<racarr_> why do we have something called pixel_format_argb if the pixels are bgra
<kdub> " * The order of components in a format enum matches the
<kdub>  * order of the components as they would be written in an
<kdub>  *  integer representing a pixel value of that format.
<kdub> "
<racarr_> kdub: Oh...I see...lol. thanks :)
<racarr_> This is a strange choice for us
<racarr_> considering both systems we have ever run mir on
<racarr_> are little endian...
<racarr_> (well arm is little endian by default at least)
<racarr_> there's something I still dont understand...
<racarr_> the cursor (which I guess has never been used on ARM)
<racarr_> (i.e. black_arrow.c)
<racarr_> gets put in a GBM_FORMAT_ARGB8888 buffer
<racarr_> however the image file
<racarr_> is RGBA?!?!
<racarr_> so what on earth is GBM_FORMAT_ARGB8888 in memory....
<racarr_> well
<racarr_> RGBA apparently
<racarr_> lol
<kdub> we don't have a bgra format
<kdub> probably because android doesn't have a corresponding pixel format
<kdub> there's a HAL_PIXEL_FORMAT_BGRA_8888, but that would be mir_pixel_format_argb_8888
<kdub> fun, huh?
<racarr_> yes lol
<racarr_> IO understand now
<racarr_> what confused me
<racarr_> was just the comment from the gimp C file outputer lol...the cursor image thing is ARGB in our terms.
<racarr_> ...do we have any other
<racarr_> transparent surfaces anywhere
<racarr_> because now I am writing it in BGRA...(though I dont think its going to work on mesa now...not sure what I am going to do...)
<racarr_> but I get
<racarr_> white for the background
<racarr_> (writing ff ff ff 00 in to HAL_PIXEL_FORMAT_BGRA)
<racarr_> and my renderable says shaped
<racarr_> I've got go to outside lol...between my seeming inability to put a pixel of the correct color on the screen, the people outside with jack hammers
<racarr_> and the person yelling at the person with a jack hammer
<racarr_> I am about to lose it:p
<racarr_> back after lunch
<racarr_> ugh of course...my pixels arent premultiplied...I wonder how alan got gimp to produce such a nice black_arrow.c
<kdub> oh, there's an output plugin
<racarr_> mm but it produces the pixels in the opposite order we need
<racarr_> and doesnt premultiply
<racarr_> unless I am missing like an extra
<racarr_> options page
<racarr_> or something
<racarr_> maybe it depends on the input format oO
<kgunn> fwiw, ti did the same damn misnaming....
<kgunn> created the same headaches
<kdub> yeah, the best is when like
<kdub> marketing somehow gets involved ;)
<racarr_> lol...
<racarr_> premultiplied alpha sounds like something people might pay extra for
<kdub> and even more for MostSignificantByte premultiplied alpha
<kdub> with some tiling
<racarr_> lol
<racarr_> Whee...fresh install
<racarr_> feels nice :p
<racarr_> so how do I update this
<racarr_> server-ABI-sha1sums file
<racarr_> eh nvm pipe find + some stuff to xargs sha1sum
<racarr_> lol...this is ridiculous
<racarr_> my two branches which I am proposing
<racarr_> ok nvm maybe it will be fine
<racarr_> conflicts galore
<racarr_> ...sorry speaking outloud in half sentences
<RAOF> Heh.
#ubuntu-mir 2014-07-30
<racarr_> ok really is there a script to update the sha1sums file? it turns out to be easy to make a mistake lol
<racarr_> for example find include | grep -v client | egrep "\.h$" | xargs sha1sum
<racarr_> will accidentally skip internal_client.h :p
<racarr_> It seems like there are already
<racarr_> a bunch of missing files from
<racarr_> the sha1sum file?
<RAOF> That would not be surprising.
<duflu> RAOF: Mesa isn't talking to libmirclient any more. Does it need rebuilding or did we break the client ABI? (https://bugs.launchpad.net/mir/+bug/1350163)
<ubot5> Launchpad bug 1350163 in Mir "[regression] Mir GL clients crash immediately on startup (Mesa is trying to use X11 instead of Mir)" [Critical,New]
<RAOF> duflu: Oh, that works if you set EGL_PLATFORM=mir
<duflu> RAOF: So what changed? Isn't it a bug that a process with no $DISPLAY is trying to use X?
<RAOF> Dunno, haven't looked into it yet.
<RAOF> FWIW, X11 is the fallback when autodetect fails; it might be falling there.
<RAOF> To luncheon!
<duflu> RAOF: Well Mesa hasn't changed in a month. So I guess we removed/changed a symbol used in detection of libmirclient
<RAOF> Uuuum.
<RAOF> Does nothing actually link with libmirplatform?
<alf_> alan_g: https://code.launchpad.net/~kdub/mir/fd-refcount/+merge/228306/comments/553483, something missing?
<alan_g> alf_: no
<alan_g> Those lines can be replaced with nothing
<alf_> alan_g: ok, it's not very clear from the comment :)
 * alan_g was in a minimalist mood when he wrote it
<alf_> alan_g: but I see kdub got the point
<groot> hello all
<groot> kdub, I tried but didn't able to figure out how to debug hwcomposer with gdb. Now I'm trying to use ALOGE to print those information you requested. Can you check if it's the correct way ?
<groot> http://paste.ubuntu.com/7905245/
<kdub> groot, lets log the opposite, eg
<kdub> if (ctx->dev.common.module != NULL) ALOGE("ctx->dev.common.module is not NULL");
<kdub> that way we can see if it hits those lines at all, so we can rule out problems in lines 7-10
<groot> kdub, all right. I'll compile and test.
<kdub> groot, cool
<groot> kdub, I forgot you also mentioned that i can do this by printing :). This seems much easier.
<kdub> groot, that should work too
 * kdub bequeaths groot with the community helper of the month award
<groot> kdub, :P
<groot> kdub, here's the output. I also enabled printing from libhardware.so to see if modules are loaded. Last lines seems interesting to me.
<groot> http://paste.ubuntu.com/7905383/
<kdub> groot, could you pastebin the .c file again?
<groot> kdub, you mean hwcomposer.c ? It's here https://github.com/AndroidOpenSourceXperia/android_hardware_ste-sony/blob/master/display/libhwcomposer/hwcomposer.c
<kdub> right, but with your modifications
<kdub> for the logging
<groot> kdub, here it is http://paste.ubuntu.com/7905418/
<kdub> groot, okay, one more thing.. lets log the return value
<groot> kdub, how can I do that? something like  ALOGE("%d", ctx->dev.prepare); ?
<groot> hmm, they are functions so this'll not work probably
<kdub> groot, so down there at lines 1762-1776, the function can return a few different values, lets make sure it returns the 0 at line 1765
<groot> kdub, I don't know which file calls this function :(
<kdub> groot, so what i mean is put printf("the return code was 0"); in line 1764
<groot> kdub, Ahh, I'm a fool. Will do now and compile.
<groot> kdub, seems it returns zero. http://paste.ubuntu.com/7905563/
<kdub> groot, okay, seems like we've hit a dead end... have to think of other things to try
<groot> kdub, allright. I'll try to do some more debugging in the mean time.
<racarr> Morning
<kdub> hola
<robotfuel> kgunn: ping, https://bugs.launchpad.net/mir/+bug/1347053 is a serious bug, someone should be assigned to fix it.
<ubot5> Launchpad bug 1347053 in mir (Ubuntu) "Clients are crashing with a fatal exception in MirSocketRpcChannel::send_message()" [High,Triaged]
<racarr> annd back
<racarr> what is the latest progress on software opengl
<racarr> one of the problems in qtmir testing is it's difficult to mock/stub out/separate
<racarr> the QtSG and the QML engine and its tying together with the QWindows and
<racarr> to test a convincing amount of hte code without Qt going and rendering some opengl for you ;)
<racarr> or at least trying to make sure a context iws valid etc
<racarr> Is there a special qmake incantation to get qtmir to build against a local install of mir I tried
<racarr> bzr clean-tree, exporting PKG_CONFIG_PATH, qmake, make
<racarr> and I see the include directories get thrown in to the path, etc
<racarr> except something is apparently still linking against my old system mir because
<racarr> it cant find
<racarr> Rectangles
<racarr> well so much for keeping my system install clean :p
<racarr> ill build packages at least
<racarr> ...Rectangles had nothing to do with the versioning
<racarr> it just can't find it...why would that be...
<racarr> ah
<racarr> it needs to link explicitly against mircommon
<racarr> the Appliucation plugin
<racarr> Why am I having to link it against mircommon but other people are able to build it...
<racarr> anyway going to propose a change to mircommon pc that includes the link flag
<racarr> this is literally a brand new install too so I dont think its anything messed up on my system...
<racarr> anyway...https://code.launchpad.net/~mir-team/mir/mircommon-link-flag/+merge/228950 :)
<racarr> back soon
<racarr> back
<racarr> time to wrestle some qmake
<racarr> trying out the existing qtmir tests...
<racarr> [libprotobuf ERROR google/protobuf/descriptor_database.cc:57] File already exists in database: mir_protobuf_wire.proto
<racarr> familiar?
<racarr> I guess im linking against libmirprotobuf twice
<racarr> because of this mircommon linkage...
<racarr> Sharing ServerRunner and InProcessServer out of mir_test_framework seems like such a pain that its almost better just
<racarr> copied to qtmir...
<racarr> i.e. do we really want to publish a new library in any shape or form
<racarr> probably not :p
#ubuntu-mir 2014-07-31
<RAOF> kdub: I'm not sure exactly what you mean in your concern about MIR_SERVER_PLATFORM_MODULE_PATH.
<duflu> Hah. Sounds ominous. Mir 0.6.0 "expected" 2 hours ago
<duflu> https://launchpad.net/mir/+milestone/0.6.0
<duflu> alf_: Oh err, I forgot about the nesting again :)
<duflu> I think I'm still wishful it wasn't there
<duflu> alf_: Around?
<alf_> duflu: yes
<duflu> alf_: I'm logging off, but please check if I'm imaginging things: https://bugs.launchpad.net/unity-system-compositor/+bug/1340510
<ubot5> Launchpad bug 1340510 in Mir "session screen seen upon quick power key strike" [Medium,In progress]
<duflu> In case it is that easy
<duflu> *imagining
<alf_> duflu: looking
<alf_> duflu: I will have to dig deeper into the logic there, but in any case we still have the problem of the greeter being too slow to render, so we end up drawing the dash simply because we don't have something newer to draw
<duflu> alf_: If we avoid telling USC to compose immediately on resume then it will wait till the nested server has a new frame
<duflu> I think that's the bug
<duflu> Seems pretty simple actually
<duflu> So long as we're not masked by other bugs
<alf_> duflu: well, one aspect of the stale frame issue is already solved (dropping old buffers from the queue), I will experiment with your suggestion. It may work if unity8 is not redrawing the dash before the greeter.
<duflu> OK, I must resist the temptation to hack and log off
<alf_> duflu: enjoy your day!
<duflu> alf_: The only annoying part is you need to specify in the server config if you are a system compositor expecting nested servers. If not then behave like a nested one (compose_on_start = true)
<duflu> I guess a single "bool am_inner_server" would do
<alan_g> alf_: (if you're still about) does this make sense? https://code.launchpad.net/~alan-griffiths/mir/fatal-error/+merge/229086
#ubuntu-mir 2014-08-01
<duflu> AlbertA: Around?
<alan_g> alf_: fixed for mir_server_mesa_egl_native_display_is_valid() - is it OK now? https://code.launchpad.net/~alan-griffiths/mir/fix-mirplatformgraphics/+merge/228815
<alf_> alan_g: looks good, (top) approved
<alan_g> thanks
<alan_g> greyback: does this capture all the "configuring Mir" issues we discussed a while back? https://bugs.launchpad.net/mir/+bug/1351255
<ubot5> Launchpad bug 1351255 in Mir "[enhancement] It should be possible to customize configuration options without going via boost options and the commandline" [Wishlist,New]
<greyback> alan_g: yep, thank you. I commented on what would work for us. See what you think
<alf_> alan_g: When we call mir_connection_release() the lifecycle callback for connection lost gets called... Do you know if this was done on purpose?
<alan_g> alf_: I've no recollection of the issues around that
<alf_> alan_g: thanks
<alan_g> greyback: if mo::DefaultConfiguration had a virtual function "bool accept_unparsed_arguments(vector<string> const&)" would that work for you?
<greyback> alan_g: not clear what that does. Do I pass it the env vars? What does the return value mean?
<alan_g> You could override it with your own command-line processor logic
<alan_g> @https://bugs.launchpad.net/mir/+bug/1351255/comments/1
<ubot5> Launchpad bug 1351255 in Mir "[enhancement] It should be possible to customize configuration options without going via boost options and the commandline" [Wishlist,New]
<alan_g> It isn't literally what you asked for, but would be easier to implement.
<greyback> alan_g: so I need to give Mir a list of command line arguments to ignore?
<alan_g> No. Anything Mir doesn't recognised is passed in the argument
<alan_g> Anything Mir did process has been stripped
<greyback> alan_g: ok I see. Let me think about it please
<alan_g> Actually, maybe void is a better return type: if you're unhappy you can just throw an exception.
<alan_g> void mo::DefaultConfiguration::handle_unparsed_arguments(vector<string> const& argv)
<alan_g> greyback: Another option would for you to pass a function<void(vector<string> const& argv)> to the constructor
<greyback> alan_g: I think either would work for me. What I'd have to do is pass argv into mir, and then based on the handle_unparsed_arguments calls, re-assemble the stripped argv to then pass to Qt
<alan_g> greyback: yes. You'd prefer vector<char*>? (To use "tokens.size(), tokens.data()")
<greyback> alan_g: yep, would prefer char*
<alan_g> OK, so long as you can accept you don't control the lifetime of the pointee.
<alan_g> A "function<>" would probably be the least coupled approach, does that cause any problems?
<greyback> alan_g: not really, I can work with it
<alan_g> greyback: OK one unparsed_arguments callback coming up
<greyback> alan_g: thank you :)
#ubuntu-mir 2014-08-03
<nerdsville> Hello all :)
<nerdsville> I was interested in helping out with the Mir Desktop Env. development
<nerdsville> How would I get started
#ubuntu-mir 2015-07-27
<dandrader> anpok, any ETA for mir 0.14 in vivid+overlay?
<mariogrip> Xmir: Failed to send message to server: Broken pipe ... Any ideas?
<anpok> dandrader: there is a problem with unity8-ap tests - need to investigate
<dandrader> anpok, :(
<anpok> other than that manual testing did not show any problems so far
<anpok> mariogrip: server died?
<mariogrip> I assume the server is running when unity8 is still running, isn't that correct?
<mariogrip> anpok: ^
<anpok> mariogrip: yes.. which version of Xmir are you using?
<mariogrip> the newest in wily repo
<anpok> how do you start it?
<mariogrip> 2:1.17.2-1ubuntu1
<anpok> dandrader_: i just got 36 failures out of 43 in u8-autopilot on rc-proposed
<mariogrip> export DISPLAY=:1 && Xmir $DISPLAY
<anpok> you need a bit more to ensure that unity8 allows you to connect
<anpok> and Xmir does not need a display env variable
<anpok> it relies on -mirSocket to point it to the sessions mir socket .. i.e. /run/user/<userid>/mir_socket
<anpok> -mir could be an application name, for which unity will be able to find a desktop file ..
<anpok> and then you should use the parameter -damage for now
<anpok> Xmir -mirSocket /var/run/<userid>/mir_socket -mir calculator -damage :2 &
<anpok> then export DISPLAY=:2 .. and start an x11 application
<anpok> mariogrip: ^
<anpok> brb
<mariogrip> anpok: thanks, i will give it a try
<kgunn> reading scroll back and i think dandrader wasn't around for this one
<kgunn> <anpok> dandrader: there is a problem with unity8-ap tests - need to investigate
<dandrader> kgunn, I read that
<kgunn> rather <anpok> dandrader: there is a problem with unity8-ap tests - need to investigate
<kgunn> what the hell...
<kgunn> that is not the line i am copying
<kgunn> <anpok> dandrader_: i just got 36 failures out of 43 in u8-autopilot on rc-proposed
<kgunn> there
<kgunn> anpok: so are you saying virgin rc-proposed with no silos installed that's what we see ?
<greyback__> kgunn: I'm told the usual thing is, if a test fails, run it again. Seems occasionally there are random fails with AP and unity8
#ubuntu-mir 2015-07-28
<alan_g> greyback: hi, not urgent but... it would be good to tick this off - https://code.launchpad.net/~alan-griffiths/unity-system-compositor/add-display-config-option/+merge/262110/comments/665431
<greyback> alan_g: will get to it today
<alan_g> thanks
<dandrader> anpok_, about unity8 hiding USC cursor: the API you pointed me to, mir_surface_configure_cursor, works on a client MirSurface. But unity8, being a nested server, has a mir::graphics::DisplayBuffer instead
<dandrader> anpok_, So I don't know how to get a MirSurface out of a mir::graphics::DisplayBuffer
<dandrader> anpok_, hmm... will try out mir::Server::the_cursor()->hide()
<anpok_> yeah that would be the nested cursor object
<dandrader> anpok_, calling "the_cursor()->hide();" gives me a "pure virtual method called" exception :(
<dandrader> anpok_, in in mir::graphics::mesa::Cursor::hide() (this=0xc3d220) at /home/dandrader/mir/0.14+mouse/src/platforms/mesa/server/kms/cursor.cpp:224
<anpok_> o_O
<dandrader> anpok_, maybe the cursor part doesn't know it's running as a nested server
<anpok_> yes it should instantiate mir::graphics::nested::Cursor
<kdub> nested seems to return a nullptr hardware cursor
<kdub> oh, but the the_cursor shouldn't call that... so if you're calling mg::Display::cursor(), you get a nullptr, but if you're calling the_cursor(), you get mgn::Cursor
<kdub> strange
<dandrader> kdub, I called the_cursor() from mir::Server
<dandrader> anpok_, ahhh... sorry. I'm running qtmir from my test laptop, so there's no USC there of course. It's not nested in this case :)
<dandrader> anpok_, but that should still be the API I should use to hide the mir cursor, right?
<greyback_> dandrader: if not nested, there should be a hardware cursor. Not sure if that hooked into mg::Cursor
<dandrader> greyback_, from the looks for the stack trace, it seems to be
<dandrader> s/for/of
<anpok_> dandrader: yes and both the kms and the nested server should properly react to hide()
<anpok_> -server +cursor
<anpok_> so there is something clearly wrong
<kgunn> anpok_: so what's up with the comment on the citrain dashboard for silo 11 about no xorg-xserver found ?
<kgunn> anpok_: also, is that silo ready for testing ?
<dandrader> anpok_, problem was that I was calling the_cursor->hide() on MirServer constructor. Doing it much later works fine
<greyback_> dandrader: probably safest place to put it is MirServer::add_init_callback
<dandrader> greyback_, thanks will try that
<dandrader> greyback_, it worked :)
<greyback_> dandrader: you sound surprised :D "Wow Gerry got something right"
<dandrader> hehehe
<greyback_> dandrader: you see I had 1 comment on mirSurface, but an otherwise hapy
<greyback_> am otherwise happy
<dandrader> greyback_, ok, I think I know where that might be coming from
<dandrader> greyback_, fixed
<greyback_> dandrader: sweet
<greyback_> dandrader: I need to check the unity8 bit, then it's all approved
<greyback_> and I hope to have my multimon branch updated to your comments today
<dandrader> greyback_, ok. I'll base the cursor stuff on top of mirSurface
<kgunn> vogons does anyone know what's up with silo 11 ?
<ogra_> someone read a vogonic poem to it and it imploded ?
<anpok_> that or the xorg-server source package in there still confuses the silo
<anpok_> i plan to mark as tested in a bit
<anpok_> i hope that state is resolvable
<kgunn> anpok_: ta, do we need any other eyes on it for testing ?
<anpok_> well .. the way you spelled that *we* implies that the only possible answer is yes?
<guest42345> um... there is something wrong... i can run gedit on mir server without a problem but in windowed mode it crashes unity when clicking on the menu (wily)
<anpok_> i am currently handling the AP tests.. and i havent found a failure that wasnt in the vanilla image - and I had a run through our manual tests on krillin
<greyback_> anpok_: I was being pinged by CI people about that last night. They considered it an error condition, maybe you should ask them to see what is wrong and if it's fixable?
<anpok_> yes pinged back a few times already
<alf_> join #ubuntu-ci-eng
<mcphail> bschaefer: got your ping about your new SDL branch. Very exciting! Does this require a more modern version of Mir than the one shipped with vivid on the phone?
<bschaefer> mcphail, yeah it requires at lease 0.14 (possibly 0.15)
<mcphail> bschaefer: ok. Cheers. Look forward to playing with it when the phone catches up!
<bschaefer> mcphail, cool thanks for testing!
<mcphail> thanks to you for your hard work
<kenvandine> greyback_, any idea when the mouse and touchpad settings API will be worked on
<greyback_> kenvandine: nope, sorry
<greyback_> kenvandine: it's not high on our list atm, you need to ping maybe kgunn to get it more effort
<kenvandine> ok, i had asked bfiller to bring it up in the stake holders meeting
<kenvandine> but he's on holiday right now
<greyback_> ah, we just had that meet. Sorry, I should've thought to invite you
<kgunn> greyback_: might be a good one for dednick....
<greyback_> true
<bschaefer> mcphail, o also i think i hacked the configure.in and never actually fixed it correctly (ill look at that now but fyi it wont try to compile the mir backend atm)
 * bschaefer update the config
#ubuntu-mir 2015-07-29
<robert_ancell> What is the expected behaviour if a surface is created with an unsupported surface format? In XMir on Nexus 4 we use an unsupported format and the green and blue channels are swapped. Is something mapping between the formats and making a mistake or is this something we shouldn't be able to do?
<duflu> robert_ancell: I've fixed that in the next release 0.15. Added a client function that chooses the correct pixel format for your EGLConfig so that the colours are right
<robert_ancell> duflu, bug?
<robert_ancell> duflu, and that means you can provide any pixel fomat when creating a surface and it always works?
<duflu> robert_ancell: Bug 1460149
<ubot5> bug 1460149 in mir (Ubuntu) "Visible corruption in SDL apps (Neverball, Neverputt) on Nexus 4 / Nexus 7." [High,Triaged] https://launchpad.net/bugs/1460149
<duflu> robert_ancell: No. You need to choose your EGLConfig according to your desire first. Then there is only one right answer for the pixel format and the new function will tell you what it is
<duflu> Set up EGL first, then create your surface.
<robert_ancell> duflu, so the current behaviour is undefined or should have Mir thrown a fit by me giving an unsupported format?
<duflu> robert_ancell: Current behaviour is buggy and hard to identify without the human visual system (if two channels appear wrong). Using the new client function in 0.15 however the colour mix-up won't happen
<robert_ancell> duflu, you are saying there is a new helper function that will pick the correct format for me, right?
<duflu> robert_ancell: Yes, it's super simple. Most of Mir's examples/ are already updated to use it
<robert_ancell> duflu, right, so the question still stands - what is the contract Mir makes regarding passing a pixel format that is not in the supported list.
<duflu> robert_ancell: It will try and ask your graphics driver (android/mesa) and see if it can create a surface with that format. Now only if the driver can't do it will it fail
<robert_ancell> What is the definition of supported if there are formats outside that list that work?
<duflu> robert_ancell: Your problem is you're asking for a supported pixel format, so it works. But the byte order is backwards to what EGL has in mind. So the new client function resolves that
<robert_ancell> No, I'm asking for an unsupported format (it's hard coded and doesn't check the supported formats)
<duflu> robert_ancell: "supported" is now defined as whatever the driver can create with. It will try whatever you give it, and fail surface creation if unsupported. Your issue is that it is supported but you're asking for the reverse format of what EGL's using
<robert_ancell> So "supported" != all formats - "unsupported"
<duflu> robert_ancell: Supported (for hardware surfaces) is no longer a fixed list in 0.15. We just ask the driver and it will tell you. Because different drivers have different abilities
<duflu> The "supported list" you get technically is only right for software surfaces, and is a kludge even still
<duflu> I only identified the problem and started fixing it recently
<duflu> Actually for other reasons (bugs) Mir 0.15 on desktop will successfully allow all-but-one pixel format for software surfaces. But to support legacy clients that think the supported list is just for hardware, we don't yet advertise it. Probably needs an API extension
<robert_ancell> OK, I think I'm even more confused than when I started. Does the "supported" list mean anything at all?
<duflu> robert_ancell: So in summary, if you're using hardware (GL) surfaces, ignore the supported list. The reliable solution is the new function in 0.15
<duflu> The "supported list" still has a use for software clients only
<robert_ancell> So, when does 0.15 land?
<duflu> robert_ancell: Soon hopefully. We are about to start the release process. Although delays getting 0.14 finished are holding it up (that was major due to a client ABI break)\
<duflu> robert_ancell: I know... Mir's handling of pixel formats and byte ordering had a lot to be desired. I've cleaned it up significantly in 0.15
<duflu> It's always the way. You fix something hardly anyone is asking for yet, and before the fix it out, everyone needs it
<robert_ancell> duflu, :)
<greyback> duflu: hey, thanks for the qtmir patches, I hope to review them today. Sorry for the delay
<duflu> greyback: No problem. I'm busy enough that I'd rather it took time anyway
<duflu> robert_ancell: https://code.launchpad.net/~vanvugt/mir/one-for-robert-ancell/+merge/266194
<alan_g> alf: I moved this back to review for a fix, could you re-review? https://code.launchpad.net/~alan-griffiths/mir/fix-intermittent-memory-leak/+merge/266127
<alf> alan_g: looks good
<alan_g> thanks
<robert_ancell> duflu, thx
<alan_g> greyback_: @add-display-config-option - fixed. (What ping?)
<greyback_> alan_g: I swear I pinged you on irc.
<greyback_> anyway
<alan_g> greyback_: in unrelated news I've MP'd an initial WM change to qtmir: https://code.launchpad.net/~alan-griffiths/qtmir/use-WindowManager/+merge/266219
<greyback_> alan_g: sweet, thanks
<alan_g> alf: don't try to push ~alan-griffiths/unity-system-compositor/add-display-config-option before Mir-0.15 - it depends on -c 2713 (which happend after 0.14 was forked)
<alf> alan_g: ack
<alan_g> alf: in case you want to see the end (I hope) of something you started: https://code.launchpad.net/~alan-griffiths/mir/enable-FD-leak-checking-for-acceptance-tests/+merge/266208
<alf> alan_g: \o/
<alf> alan_g: Is there a way to fix (as a future task) the g_source_attach() leaks that we currently ignore, or is the problem inherent in the way we do things?
<alan_g> alf: I've not thought about it.
<alf> alan_g: ok
<alan_g> But it would be nice
<alan_g> Rats! Where's Mir-0.15 when I need it? I want to write qtmir code that needs -c 2714...
 * greyback still waiting for 0.14 in vivid+overlay. Hope it won't be long now
<mcphail> yes! ETA would be great
<davmor2> mcphail: More than an hour less than a million
<anpok> greyback_: too long is over..
<greyback_> no wai
<greyback_> omg
 * greyback_ creates a silo
<anpok> yeah not sure what I should to with that rest of the week..
<anpok> yeah releasing somethig should be good idea
#ubuntu-mir 2015-07-30
<RAOF> Excellent. There's a solid reproducer for that deadlock...
 * kdub should have needed stronger coffee this morning before trying to clean up the mcl::BufferStream unit test
<kdub> *should have had
#ubuntu-mir 2015-07-31
<RAOF> Grr.
<RAOF> Threadsafety by making every individual component threadsafe is maybe not the best idea.
<racarr> RAOF: Yeah...I had this thought when I studied
<racarr> Chromium and they have this...uh
<racarr> well rather than each component is thread safe its more like components live in threads
<racarr> and the threads are like
<racarr> higher level than the components
<racarr> e.g. render thread, ipc thread, etc...
<racarr> grr sorry I can't think of how to articulate it quickly
<RAOF> The google juice for that would be CSP (communicating sequential processes) I believe.
<racarr> but it was a really different model that I thought probably made more sense
<racarr> yeah I mean
<racarr> it looked like that because the main communication between them was
<racarr> this fd thing but
<racarr> even without going full like...
<racarr> I mean even with still using shared memory concurrency
<racarr> youc an group components in a smarter way and not
<racarr> require thread safety on each one
<RAOF> Just on the interface between them, yeah.
<RAOF> (CSP doesn't imply not shared-memory, either)
<racarr> yeah thats true.
<racarr> Running out to Go club (Game not Lang)!
<RAOF> Coo!
<RAOF> Have fun!
<AlbertA> vogons: so prepping for 0.15 release, abi compliance checker complains mir client is not ABI compatible because of enum MirPixelFormat mir_pixel_formats has changed...
<AlbertA> any opinions on the matter?
<RAOF> AlbertA: False positive.
<RAOF> Or, rather, only code that currently fails to work will change behaviour.
<RAOF> (I believe what it's complaining about in the value of mir_pixel_formats has changed)
<AlbertA> yeah I couldn't think of anything....but it's late....
<AlbertA> RAOF: right, which should be unused or just used for bounds checking
<RAOF> The only way code can usefully use it is still valid (as a guard value).
<RAOF> Correct.
<AlbertA> as long as it doesn't go down should be ok....
<RAOF> It technically is an ABI change, as something which called mir_foo(..., mir_pixel_formats) changes behaviour from erroring to passing.
<RAOF> But people who write such code deserve what they get :)
<RAOF> Hm.
<AlbertA> he he yep
<RAOF> Actually, that could plausibly break a test-suite.
<RAOF> But almost certainly doesn't, and shouldn't break any code that *users* care about.
<RAOF> So, go ahead.
<AlbertA> test-suite probing behavior of mir client apis?
<AlbertA> with invalid inputs?
<AlbertA> I suppose so....but is there such a thing in the wild?
<RAOF> A toolkit could reasonably use that to check its handling of Mir errors, for example.
<AlbertA> umm true... but that's why you mock those things :)
<RAOF> I don't think there is such a test-suite in the wild, and I don't think that âinputs which were invalid remain invalidâ is an ABI guarantee we make.
<duflu> AlbertA: Yep mir_pixel_formats is intended to be a value current for the code it's compiled into. One should expect (and plan for) other users to be aware of a different value for mir_pixel_formats
<duflu> AlbertA: Also, my MP up for review solves an issue that will block 0.15.
<duflu> Although I'm making great progress optimizing QtMir, that won't be finished for a while
<AlbertA> duflu: thanks, which MP?
<duflu> AlbertA: My only one up for review :)
<AlbertA> always triple buffers?
<AlbertA> duflu: ok
<RAOF> Man, GLibMainLoop is thorny.
<duflu> greyback: Fun fact: I successfully prototyped very short buffer holds in QtMir and found less than expected performance. Then looked at Mir again and found I had regressed the short hold feature back in Feb. Mir needs fixing :)
<greyback> duflu: em, woo!
<kenvandine> kgunn, with silo 0 installed, usc doesn't start, is that known?
<kenvandine> ERROR: /build/mir-GtufN4/mir-0.13.4+15.04.20150717/src/platform/graphics/platform_probe.cpp(59): Throw in function std::shared_ptr<mir::SharedLibrary> mir::graphics::module_for_device(const std::vector<std::shared_ptr<mir::SharedLibrary> >&)
<kenvandine> Dynamic exception type: N5boost16exception_detail10clone_implINS0_19error_info_injectorISt13runtime_errorEEEE
<kenvandine> std::exception::what: Failed to find platform for current system
<greyback_> kenvandine: known issue, USC needs rebuild
<kenvandine> greyback_, ok, so is someone doing that?
<kgunn> kenvandine: yep, sorry....
<greyback_> kenvandine: yep, will ping when it ready
<kenvandine> thx
<greyback_> someone rebuilt bits before it was all ready... :)
<kgunn> i rebuilt mir last night and got stuck on the u-s-c merge
<kgunn> greyback_: ah,....that would be me
<kgunn> greyback_: altho i did retarget mir0.14 and the whole bit
<greyback_> kgunn: no worries, I had mir & qtmir updated, but wanted to finish usc before rebuilding
<kgunn> yeah, i prolly shouldn't have done the piece wise rebuild
<kgunn> esp after sending out mails
<kgunn> classic
 * kgunn hasn't checked mail and can only imagine
#ubuntu-mir 2016-08-01
<duflu> Fun. I have two mice + one touchpad + trackpoint all controlling the same cursor
<anpok> yes that setup immediately wants you to have a more than one cursor on screen
<duflu> Umm, three mice + touchpad + trackpoint
<duflu> One cursor is better. You only want to follow one cursor with your eyes. Even if reaching for a different peripheral
<anpok> hm I could offer a graphcis tablet that can offer two pointer devices..
<duflu> I could do that here... but won't bother
<tjaalton> sil2100: hi, did you check that xmir in xenial-proposed is good now on arm64?
#ubuntu-mir 2016-08-02
<duflu> robert_ancell: Good news... I have no Xmir changes ;)
<robert_ancell> duflu, \o/
<alan_g> alf_: I have a design question: I'm trying to restrict the symbols published by libmiral to the public API by generating a symbols.map. And ran across the tests using miral::MRUWindowList (which isn't public). The question: is it best to 1. publish this class? 2. export it in a "private" stanza from the lib? Or, play linker games to make it accessible to tests?
<alan_g> 4. Stop testing an implementation detail and write tests of the functionality it supports
<alan_g> alf_: nevermind: Now I've tried it the "linker games" approach feels right.
<alf_> alan_g: Sorry, was AFK. Yes, (3) seems best if you can pull it off. As a side note, I don't think (4) is a good choice as the default rule, since it would essentially mean no unit testing.
<alan_g> alf_: FWIW https://code.launchpad.net/~alan-griffiths/miral/add-symbols-map/+merge/301754
#ubuntu-mir 2016-08-03
<alan_g> greyback: can I draw your attention to the changes in miral-qt/src/platforms/mirserver/windowmanagementpolicy.cpp here: https://code.launchpad.net/~alan-griffiths/miral/reduce-WindowManagerTools/+merge/301885 - possibly something you're aware of already?
<greyback> alan_g: the fact there was overlap did occur to me, I just considered it a convenience thing. I've no problem removing it
<alan_g> "removing" == deleting these functions?
<anpok> greyback: is ltinkl away for longer?
<greyback> alan_g: yep
<greyback> anpok: longer than a piece of string? :)
<greyback> anpok: he was online yesterday, i don't think he's on holidays
<alan_g> greyback: Ok, I'll do that instead. ;)
<anpok> greyback: I am looking at qtubuntu and an input filter plugin called qcomposeplatforminputcontextplugin
<anpok> can you shed some light on what part decides whether a plugin like that would be loaed
<anpok> .. it currently is not.. so thats why ubuntu touch is not handling compose sequences..
<greyback> anpok: could you try testing with this env var set: QT_IM_MODULE="compose"
<greyback> I see the XCB qpa plugin has a cheeky qputenv("QT_IM_MODULE", QByteArray("compose"));
<greyback> we might need to duplicate that
<anpok> ok
<anpok> it works on desktop qt
<anpok> with unity8
<anpok> so .. I was wondering if that env var could be a list? because we stil need malitt too
<anpok> or maybe because we dont have maliit loaded on desktop it falls back and loads the compose plugin..
<greyback> anpok: I'm not sure, need to read more
<greyback> QPlatformInputContextFactory obviously only creates one instance
<anpok> greyback: hm we could implement compose sequences in mir.. i had hopped it would not be necessary
<anpok> greyback: QT_IM_MODUE=compose does the trick..
<anpok> and breaks maliit
<greyback> I don't see an obvious way they can co-exist in Qt
<greyback> only idea is to create a QCombinationInputContext class, which imports both maliit & compose plugins underneath
<anpok> hm we could extend maliitphablet to handle keys and include the compose key handlng there..
<greyback> do we really need support for OSK and physical keyboard at the same time?
<anpok> hm probably not
<greyback> alan_g: small api comment with miral::WindowInfo - any reason you don't use mir::geometry::Size for min/max sizes?
<greyback> and for the increment, would not an increment of 1 be the same as having no increment set?
<alan_g> greyback: I guess. IIRC it was all optional (so width could be set without height) and I simplified by always having min/max with 0/numeric_limits<>::max. You're right the same could be done with increments.
<alan_g> But... I think there's some independence between min_width and min_height and they shouldn't be combined in one value.
<greyback> alan_g: sure, they're independent values. I just thought the Size type was a natural container for the pair of vals
<greyback> no biggie anyway
<alan_g> greyback: I'll pick up the change to increments though
<greyback> ok
<alan_g> alf_: you've approved two miral MPs (thanks!) but not looked at the prerequisite?
<alf_> alan_g: looking
<alan_g> thanks
<alan_g> greyback: https://code.launchpad.net/~alan-griffiths/miral/simplify-size-increments/+merge/301909
<greyback> alan_g: approved!
<alan_g> alf_: reworded https://code.launchpad.net/~alan-griffiths/miral/add-introducing_the_miral_api/+merge/301779 - better?
<greyback> alan_g: a question: have you a plan on how SurfaceObserver fits in with miral's api?
<greyback> say if a window is repositioned, both SurfaceObserver::moved_to and WMPolicy::advise_move_to will fire
<alan_g> yes. (But SurfaceObserver isn't in the MirAL API)
<greyback> ok, I'll try to avoid relying on SurfaceObserver
<peat-psuwit> Hello.
<peat-psuwit> http://bazaar.launchpad.net/~mir-team/mir/development-branch/view/head:/src/platforms/android/server/device_quirks.cpp#L176
<peat-psuwit> Why the pixel format is hard-coded to mir_pixel_format_abgr_8888?
<anpok> that is only used to query information about the gpu..
<anpok> do you ran into problems with that?
<peat-psuwit> anpok: Well, the problem is my device don't support that format.
<peat-psuwit> As the context is created, an exception gets thrown.
<peat-psuwit> "std::exception::what: could not select EGL config for use with framebuffer"
<anpok> peat-psuwit: hm then you could write a function that tests the device name and in your case returns a differen pixel format ..
<anpok> make an MP for that..
<peat-psuwit> anpok: Actually, I have another idea. I'll put that in try-catch block. If that failed, then try another format.
<peat-psuwit> Thanks for your idea anyway.
#ubuntu-mir 2016-08-04
 * alan_g wonders if he really needs to wait for "someone other than the reporter" to confirm lp:1605182
<duflu> alan_g: If you're a member of the project you can skip Confirmed and jump to Triaged
<duflu> Assuming you took a moment to check for duplicates
<alan_g> duflu: that makes sense. thanks.
<duflu> alan_g: Also my comment #1 confirmed it
<alan_g> I didn't find any open duplicates. I expect a new cause, not one of the earlier fixes.
<duflu> Random segfaults on krillin might end up being in the graphics driver, but it's worth checking
<duflu> I know krillin segfaults if you unload and reload the android platform. So it's not very stable
<alan_g> Problem is my krillin bricked a couple of months back
<duflu> If it becomes important I'll try manually reproducing it
<duflu> Since I can cross compile again today
<alan_g> I'll see if valgrind spots anything suspicious on desktop - wouldn't be the first time.
<zzarr> hello!
<zzarr> are there plans for Mali drivers?
<zzarr> same old me, same old question
<alan_g> like on N10 and krillin?
<duflu> Nexus 4 uses Mali, with the Android backend. I think zzarr means something like a desktop/chromebook?
<duflu> Oh, I own a chromebook with Mali graphics. That's interesting
<duflu> Also interesting I prototyped/fixed the one Mir bug that was blocking that device from starting up yesterday
<duflu> Although will refine it more, aiming for Mir 0.25
 * duflu runs away
<zzarr> I meant a Mir driver (without android) for Mali
<alan_g> I'd *expect* that to work via Mir's mesa driver, not with something Mali specific. But duflu's the one with Mali hardware. (See above)
<zzarr> sorry, alan_g, I misread what he wrote, that's interesting :D
<alan_g> zzarr: does the mesa support work for (e.g.) an X11 stack?
<zzarr> alan_g, I haven't tried in a while, but other people have gotten it to work as I understood it
<alan_g> zzarr: in that case Mir should, in principle, be able to run using mesa.
<zzarr> cool :)
<zzarr> what drivers do I need?
<alan_g> Whatever "other people" used
<zzarr> (kernel-driver... that I know, but user space?)
<zzarr> okey :)
<zzarr> I will try later today :D
<zzarr> 3 hour left of my workday, then me and my sister will go jogging and then food, so maybe 6 hours from now
<alan_g> zzarr: if you do get X11 going try: https://bazaar.launchpad.net/~mir-team/miral/trunk/view/head:/building_and_using_miral.md
<zzarr> I'll save that link :D
<zzarr> I saved the document instead :)
<zzarr> do you have any idea what Chromebook duflu have?
<alan_g> Sorry, no
<zzarr> do you know what vendor?
<alan_g> Sorry, no
<zzarr> or about when he bought it?
<alan_g> Sorry, no
<zzarr> I'll have to ask him when he's online again
<alf_> Trevinho: We just experienced the google-mock+gcc-6 issue ourselves, thanks for the bug and fix
<Trevinho> alf_: good :-)
<Trevinho> alf_: we need someonre to upload that in ubuntu...
<Trevinho> someone*
<Trevinho> alf_: I've submitted also a debian bug
<kdub> so if i understand, then once that's uploaded, we won't need a patch to mir or usc?
<alf_> kdub: That's right
<kdub> alf_, cool, thanks Trevinho
<alf_> Trevinho: do you have any candidates for pushing this?
<Trevinho> alf_: Laney should be uploading that
<alf_> Trevinho: ack, thanks
#ubuntu-mir 2016-08-05
<zzarr> hello again!
<zzarr> duflu, what kind of a Chromebook do you have?
<duflu> zzarr: The old HP Chromebook 11
<duflu> Exynos chip
<zzarr> okey
<zzarr> my Chromebook is an ASUS Chromebook Flip with a Rockchip RK3288
<zzarr> I remember that I had a problem last time I tried Ubuntu on it, I had to set the priority of the kernels on the SD every time I had started Chrome OS
<zzarr> duflu, do you recognize that problem too?
<duflu> zzarr: Don't know, sorry I haven't had time to play with it for about a year
<zzarr> okey, no problem
<zzarr> alan_g told me you had a Chromebook with a Mali GPU and so do my
#ubuntu-mir 2017-07-31
<alan_g> greyback: following on our discussion of display vs output... https://code.launchpad.net/~alan-griffiths/miral/deconflate-output-from-display/+merge/328221
<greyback> alan_g: ack!
<xnox> Sarvatt, Trevinho - do we still need content-hub, and does content-hub still need libertine?
<xnox> i think we want to drop libertine, no? and can we make content-hub not depend on libertine if that is the case.
<Trevinho> xnox: AFAIK no,
<xnox> Trevinho, but i thought mir-kiosk people said they want content-hub for copy&paste or something.
<Trevinho> xnox: oh, well I'm not much into that discussion honestly...
<xnox> or is the no, towards not possible to make the two not working together.
<Trevinho> xnox: I think libertine is free to go though
<xnox> Trevinho, hm, ok. I just don't seem to see the usual people in the channel.
<xnox> hence you got the ping =)
<Trevinho> :-D
#ubuntu-mir 2017-08-01
<alan_g> RAOF: hanging out?
<RAOF> alan_g: oops. Out at ZoÃ«'s birthday dinner at the moment.
<RAOF> Sorry!
<RAOF> Forgot to email you earlier.
<alan_g> RAOF: nm. Nothing urgent. I'll be at doctor's next week.
<RAOF> K.
<RAOF> Learning new and interesting ways that pthread_cond_destroy can hang.
<alan_g> Someone has to. I'm digging into why mixing Mir trunk, MirAL trunk and Xenial leads to a segfault on exit. (Except, naturally, under valgrind)
<alan_g> I strongly suspect it's protobuf 9, but not clear why 0.26.3 doesn't trigger the same
<alan_g|lunch> make
<xnox> alan_g|lunch, nothing to be done with xnox
 * alan_g needs to find the time to implement "focus follows intent". ;)
<xnox> alan_g, nice. I kept saying at Intel that RealSense should be used to implement focus follows eye-sight.
<alan_g> xnox: Unfortunately, I don't think that would work. I read notifications or chat while typing elsewhere too often.
<ogra> yeah you want focus-follows-thought
#ubuntu-mir 2017-08-04
<RAOF> alan_g: Ooh, hypothesis!
<alan_g> RAOF: ?
<RAOF> alan_g: The test fails in CI because it's on an old kernel that doesn't support getrandom.
<alan_g> Doh! that even makes sense.
<RAOF> You could test this by LD_PRELOADinf a shim that returns ENOTSUPP from the call m
<RAOF> This would imply that the fallback code in libuuid is faulty.
<RAOF> Which is entirely possible! It doesn't try reading from urandom if libc exposes getrandom()
<RAOF> So this would be a seldom-hit Falcao path
<alan_g> Although... why would this only affect artful/amd64? Surely the kernel is the same
<RAOF> Newer glibc, newer libuuid?
<alan_g> I'd guess glibc, but can check
<RAOF> It might have just gained the getrandom code path.
<RAOF> util-linux (source package for libuuid) was updated on the first of August.
<RAOF> Hmmmmmmmmmmmmm
<bub_> Is it possible to run software using Qt in Mir for Ubuntu Core?
<xnox> yes
 * ogra_ applauds xnox for that excessive answer :P
<ogra_> alan_g, bub_ just asked in #snappy about this and i wanted to point him to the mir demo docs, but that seems to be still down ... is anyone from the mir team after it to get it back in place ?
<ogra_> ( https://developer.ubuntu.com/snappy/guides/mir-snaps that is)
<alan_g> ogra_: last I heard Saviq was chasing davidcalle about it
<ogra_> yeah, i saw that too, but that was ages ago
<ogra_> i would have expected it to be fixed by now
<ogra_> (and david being french ... and france having hilariously long summer vacation times ... i suspect we wont be able to catch him soon)
<alan_g> ogra_: Saviq says he's on vacation
<ogra_> alan_g, yeah, see what i wrote in brackets ;)
<ogra_> frenchies ...
 * alan_g feels in no position to comment on national behaviours. (Not since June 2016)
<xnox> alan_g, yeah, we are all just local milk people now.
<alan_g> I don't know what that means but it sounds sad.
<JanC> why is that hilarious?
