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