[00:48] <RAOF> Ok. What's on the list of "omg must be fixed" for landing now?
[02:18] <bregma> RAOF, the definitive landing list is https://bugs.launchpad.net/mir/+bugs?field.tag=entering-saucy
[02:18] <RAOF> Ok, that was what I was looking at.
[02:21] <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...
[02:22] <bregma> duflu, I don't believe it was ever tested if it did support non-android on arm
[02:23] <duflu> bregma: It might require a stub graphics driver implementation. Which is related to https://bugs.launchpad.net/mir/+bug/1118903
[02:24] <bregma> maybe I'll play with that in my tomorrow
[02:24] <RAOF> duflu: It should work on non-android with one of the free arm drivers.
[02:24] <RAOF> duflu: If we happen to have any device supported by freedreno, of course :)
[02:25] <duflu> RAOF: Are such things available on Qemu/Pandaboard?
[02:25] <duflu> Should be for Panda anyway
[02:25] <RAOF> What's the GPU on a pandaboard?
[02:27] <duflu> RAOF: SGX540, http://pandaboard.org/content/platform
[02:27] <duflu> Though it usually gets bundled into what's known as an omap4 driver
[02:27] <duflu> I think
[02:30] <RAOF> Hm, then not currently supported.
[02:33] <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
[02:33] <bregma> yep
[02:34] <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)
[02:39] <duflu> There is some Android-specific linkage in there too... libhybris
[05:13] <tvoss> good morning :)
[05:13] <tvoss> RAOF, ping
[05:14] <RAOF> tvoss: Pong.
[05:14] <RAOF> Good morning!
[05:14] <RAOF> Oh, you don't have to travel *nearly* as far to get to IOM.
[05:14] <RAOF> That's why you're online :)
[05:15] <tvoss> RAOF, yeah :) I'm mostly in the usual timezone
[05:15] <tvoss> RAOF, waiting for the gym to open up
[05:34] <duflu> Morning tvoss
[05:34] <tvoss> duflu, good morning
[05:34] <tvoss> duflu, how goes?
[05:35] <duflu> tvoss: Almost good. Spent the weekend dealing with drain blockages. And I'm a bit unwell today...
[05:35] <duflu> tvoss: How are you?
[05:36] <tvoss> duflu, pretty good, waiting for the gym to open :) on the IoM
[06:49] <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?
[06:50] <duflu> alf__: Umm, that feature landed ages ago :)
[06:50] <duflu> alf__: mir_demo_server_shell, and then Alt+drag (or three finger drag)
[06:52] <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.
[06:53] <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
[06:54] <alf__> duflu: ok, thanks, although I'd like the surfaces not to be fullscreen for demo purposes.
[06:55] <duflu> alf__: Yeah, I've done the same for testing. Just remove a single line. You know which one
[06:55] <alf__> duflu: thanks
[06:57] <duflu> I'm almost disappointed more people have not played with our primitive window management yet
[06:58] <dholbach> good morning
[07:00] <duflu> Morning dholbach
[07:00] <dholbach> hey duflu
[07:34] <RAOF> Why am I surrounded by slow computers?!
[07:34] <Saviq> robert_ancell, http://bazaar.launchpad.net/~mir-team/unity-mir/trunk/revision/20
[07:40] <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
[07:41] <Saviq> robert_ancell, I had the same before - remove your CMakeCache.txt
[07:41] <Saviq> robert_ancell, and see the output from cmake
[07:41] <Saviq> robert_ancell, http://www.cmake.org/Bug/view.php?id=14310
[07:41] <robert_ancell> Saviq, doesn't exist - this is a fresh debuild from trunk
[07:42] <Saviq> robert_ancell, I expect you're missing a dep, but cmake completes because of the bug above
[07:42] <Saviq> robert_ancell, try with mk-build-deps -s sudo -i
[07:42] <robert_ancell> Saviq, ok, in that case the dep must be missing from debian/control
[07:42] <Saviq> robert_ancell, ok, let me try
[07:43] <robert_ancell> Saviq, mk-build-deps didn't help
[07:46] <Saviq> robert_ancell, right, I only grepped for < includes
[07:46] <Saviq> robert_ancell, trying in sbuild now
[07:51] <Saviq> robert_ancell, trunk built fine, trying your branch
[07:56] <duflu> alf__: Moving surfaces across monitors, I presume... ?
[07:57] <alf__> duflu: exactly
[07:59] <Saviq> robert_ancell, your branch builds just fine in sbuild, too...
[08:07] <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
[08:08] <robert_ancell> seb128, my one or trunk?
[08:08] <duflu> RAOF: I can actually reproduce the lag with demo_client_fingerpaint too
[08:08] <seb128> robert_ancell, lp:~robert-ancell/unity-mir/libmirserver-includes
[08:08] <seb128> robert_ancell, hey btw, enjoying IoM?
[08:09] <robert_ancell> seb128, yeah, you not here?
[08:09] <seb128> robert_ancell, no, didn't get invited to this one...
[08:10] <Saviq> robert_ancell, is this the same failure you get?
[08:10] <seb128> Saviq, dpkg -S ubuntu_application_api_mirserver_priv.h ?
[08:11] <robert_ancell> Saviq, I get http://paste.ubuntu.com/5924478/, but that sounds like the include path not being set again
[08:11] <robert_ancell> actually, no that sounds like a unity api issue, not a mir issue
[08:11] <Saviq> robert_ancell, are you using the mir integration ppa for that, though?
[08:11] <Saviq> robert_ancell, maybe there's something there that's not yet in mir trunk?
[08:12] <Saviq> robert_ancell, seb128 'cause it builds fine for me with https://launchpad.net/~phablet-team/+archive/mir/
[08:12] <robert_ancell> Saviq, I'm using didrocks daily-build-next PPA, but that's not a mir header
[08:12] <Saviq> in an sbuild, so starting from a clean slate
[08:12] <seb128> Saviq, robert_ancell: I'm using daily-build-next as well
[08:12] <seb128> too many ppas :/
[08:12] <seb128> we need things in the archive
[08:13] <robert_ancell> seb128, we have face time to try and make that happen this week :)
[08:13] <seb128> robert_ancell, good luck ;-)
[08:13] <Saviq> seb128, yeah, of course, just this stuff (unity-mir integration) is not yet archive-ready
[08:14] <Saviq> seb128, it's not even image-ready yet (so it's not there yet)
[08:46] <mlankhorst> morning
[08:47] <mlankhorst> seb128: if it was ready for the archive I would agree, but I don't think it is currently. :P
[09:38] <duflu> Hmm, having a bad run. Every time I update any system lately, it breaks for a new reason
[09:43] <duflu> Has anyone else had trouble with system-compositor-testing?
[09:43] <duflu> I've just updated and can't start X at all any more
[09:44] <RAOF> I upgraded my ATI box from raring to saucy and added that PPA, and it worked this morning
[09:44] <RAOF> FSVO ‘worked’, of course.
[09:45] <RAOF> (values of ‘work’ may include https://bugs.launchpad.net/mir/+bug/1204939)
[09:45] <duflu> RAOF: No, this is intel. I shall update again to be sure, then log a bug
[09:49]  * duflu realizes he doesn't need X to compile and run on Android
[09:49] <duflu> But a desktop would be nice...
[09:50] <duflu> Argh! Can't log bugs without a browser :(
[09:58] <duflu> RAOF: Any ideas? https://bugs.launchpad.net/xmir/+bug/1206067
[10:00] <duflu> RAOF: Oh, the callstack matches an existing bug. Duplicate...
[12:34] <mlankhorst> so what ati has issues?
[12:44] <mlankhorst> ok wtf
[12:48] <mlankhorst> yeah it definitely hits the wrong path on ati
[12:51] <mlankhorst> which is funny since I don't see how it could.. ah well maybe #error reveals :P
[13:11] <mlankhorst> [  2025.510] (II) Module "dri2" already built-in
[13:11] <mlankhorst> [  2025.510] (II) Loading sub module "exa"
[13:11] <mlankhorst> [  2025.510] (II) LoadModule: "exa"
[13:11] <mlankhorst> [  2025.515] (WW) Warning, couldn't open module exa
[13:11] <mlankhorst> [  2025.515] (II) UnloadModule: "exa"
[13:12] <mlankhorst> [  2025.515] (II) Unloading exa
[13:12] <mlankhorst> [  2025.515] (EE) Failed to load module "exa" (module does not exist, 0)
[13:12] <mlankhorst> hm o.O
[13:15] <mlankhorst> RAOF: I seem to be losing the exa module when I restart X.. did you add an unlink somewhere?
[13:17] <mlankhorst> oh nm, you're installing it wrongly..
[13:17] <mlankhorst> the modules appear to be installed to /usr/lib/xorg, not /usr/lib/xorg/modules..
[14:34] <alf__> alan_g|tea: @multimonitor-gbm-display, what's the benefit of using vector::swap() instead of moving the contents?
[14:40] <alan_g> alf__: it is as efficient, and less typing
[14:43] <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
[14:43] <alan_g> alf__: yes
[14:43] <racarr> Mornnnning
[14:44] <alf__> racarr: hi
[14:44] <alan_g> racarr: Afternoon
[15:16] <hikiko> bye
[18:05] <racarr> XD. playing around in msh::...
[18:05] <racarr> "Factory, Builder, Controller, and Source"
[18:05] <racarr> are tghe surface interfaces -.-
[18:05] <racarr> I dont think thats a pattern lol
[18:22] <robert_ancell> RAOF, hey
[18:28] <racarr> today is finally the death of single visibility focus mechanism
[19:29] <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
[19:29] <racarr> which is just almost finished :) then I think I will go back and add a second method to the SurfaceConfigurator, like
[19:29] <racarr> attribute_applied
[19:29] <racarr> and then unity8 can implement hide/show in response to minimize/restore
[19:29] <racarr> hook it up in QT boom
[19:29] <racarr> :)
[19:29] <racarr> LUNCCCH
[20:02] <racarr> back
[20:59] <racarr> feels great to kill single visibility focus mechanism
[21:01] <bschaefer> :), nice!
[21:23] <racarr> the pervasive threading makes the input acceptance tests so hard...every time there is some little surprise.
[21:23] <racarr> for example.
[21:23] <racarr> inject_event_to_event_hub. hide_surface. inject_eent_to_event_hub
[21:24] <racarr> is racy because the event isnt targeted until it gets to the dispatcher
[21:25] <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?
[21:25] <racarr> yeah
[21:25] <racarr> and its always like this so you always have to find a different way to synchronize it
[21:25] <bschaefer> :( stacking issues are never fun
[21:26]  * bschaefer has flash backs of compiz stacking
[21:26] <racarr> and it seems like there is rarely a pattern
[21:26] <racarr> aha yeah
[21:27] <racarr> it's really mostly a test bug because
[21:27] <racarr> in real behavior, if a surface is destroyed in between reading an event from the device and targeting it to a surface
[21:27] <racarr> then...that's just what happened
[21:28] <racarr> and it goes to a different surface XD
[21:28] <bschaefer> so if a surface is hidden you destroy them?
[21:28] <bschaefer> or rather, it goes from showing to hidden?
[21:28] <racarr> err, s/destroyed/hidden
[21:28] <bschaefer> right, just double checking :)
[21:28] <racarr> RIght
[21:28] <racarr> its only a problem when you need to orchestrate a particular series of events in a test or something
[21:29] <bschaefer> a unit test...you can add a bunch of sleeps :)
[21:29] <bschaefer> i mean hard for a unit test*
[21:29] <racarr> no :( sometimes full server tests take a LONNNG time
[21:29] <racarr> like valgrind in qemu
[21:29] <racarr> so the sleep has to be really high
[21:29] <racarr> but then tests would take too long
[21:30] <racarr> plus it's an acceptance test XD it would be pretty hard for a unit test
[21:30] <bschaefer> o my...yeah you don't want that
[21:33] <racarr> would be nice to have cucumber for input acceptance tests
[21:34] <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...
[21:34] <racarr> hahahaha...
[21:35] <racarr> the fixture
[21:35] <bschaefer> thats what cucumber can do? That is nice!
[21:35] <racarr> would be hard to design though because
[21:35] <racarr> of all these synchronization problems
[21:35] <bschaefer> I've seen it in lp:mir, but i've never used it
[21:35] <racarr> the thing is you implement these constructs
[21:35] <racarr> given, when, then
[21:35] <racarr> and the test format is
[21:35] <racarr> given, and given, and given...when...and when...and when...then and then and then bla bla
[21:35] <bschaefer> do you have to rebuild/tear down the server for each test?
[21:35] <racarr> but the constructs are just regex
[21:35] <racarr> with parameters
[21:35] <racarr> and its hard to come up
[21:35] <racarr> with a set of words and sentence and such
[21:36] <racarr> that you can match with regex that describe your problem domain XD
[21:36] <racarr> yeah normally
[21:36] <bschaefer> yeah, well regex isn't always easy on the eyes either
[21:36] <bschaefer> unless you are doing it a lot haha
[21:48] <kdub> boost, gtest/gmock is like the perfect storm of compiler errors