[00:05] RAOF, are there things worth asking that we can't get apport to do? [00:05] Yes; run a Mir server and client, and check if *that* works. [00:06] Other than that, we should be able to collect all the relevant logs. [00:06] ta, I'll ask them for that [00:07] robert_ancell: Hey, if someone starts a Mir client and attaches it to unity-system-compositor's socket, what happens? [00:08] RAOF, they can connect, but they'll never get focussed. (Actually can't remember if Mir's default behaviour will give them focus) [00:08] Either way, it does need to be fixed (Haven't filed a bug yet) [00:24] * robert_ancell -> lunch [03:15] RAOF: It appears someone has started on making VBE KMS-friendly. But it never hit any kernel tree yet. Do you know anything?... http://lists.freedesktop.org/archives/dri-devel/2013-January/034058.html === chihchun_afk is now known as chihchun [03:38] duflu, is bug 1192429 fixed now we have those VT changes in? [03:38] bug 1192429 in Unity System Compositor "unity-system-compositor is on multiple simultaneous (and random) VTs" [High,Triaged] https://launchpad.net/bugs/1192429 [03:39] robert_ancell: I will have to update and enable it to retest... [03:39] duflu, are you still on the PPA? [03:39] robert_ancell: Saucy, yes. I had planned on moving to no-PPAs soon anyway [03:40] robert_ancell: Is the fix in distro yet? [03:40] duflu, yes [03:41] not a specific fix for that problem, but VTs seem to be working well now (aside from the input always going to XMir) [03:43] robert_ancell: Is there a bug for that one? [03:43] duflu, yes, I'll just find it [03:43] robert_ancell: OK, please tag it: vt [03:43] duflu, bug 1192843 [03:43] bug 1192843 in XMir "XMir does not relinquish input on session switch" [Critical,In progress] https://launchpad.net/bugs/1192843 [03:43] tagged [03:44] That's cool. ppa-purge results in me getting mir package upgrades [03:46] duflu, oh, why did you bump the soname for libmirserver? [03:46] robert_ancell: Because the switch branch seems to have changed enough ABI things that it became necessary [03:47] Loading the old version by mistake was causing serious bugs [03:47] duflu, we always rebuild dependencies so it should be impossible to have an old version [03:47] robert_ancell: Not so on my Nexus4, which has not been updated :) [03:47] duflu, but after that change it did break exactly like that because debian/rules wasn't updated to fix the version [03:48] robert_ancell: I thought any ABI break should result in an ABI bump? [03:48] That's surely why we separated ABI from version? [03:48] duflu, only for libmirclient. libmirserver is still considered ABI unstable [03:48] I'll send out an email clarifying [03:48] robert_ancell: Alright, that would be helpful [04:03] I keep on getting bug #1210798 (private bug) on saucy from unity-saucy-compositor, ie. not starting up. sandy bridge intel graphics. will monitor the situation as/when updates come :) [04:03] Error: Launchpad bug 1210798 could not be found [04:03] I'll make it public, not much private there unless something ubersecret in the coredump [04:04] bug #1210798 - there [04:04] damn you ubot [04:06] robert_ancell: Yes, VT switching works for me in USC. Bug updated. [04:06] duflu, thanks [04:07] RAOF, when we bump a package name (e.g. libmirserver0 -> libmirserver1) is there a manual approval for that to land in the archive? [04:07] robert_ancell: yes, I already looked at it but the deal is that I need to ack it with someone with upload rights before publishing [04:08] bug 1210798 [04:08] bug 1210798 in unity-system-compositor (Ubuntu) "unity-system-compositor crashed with SIGSEGV in eglGetDisplay()" [Undecided,New] https://launchpad.net/bugs/1210798 [04:11] ah, hmm, I wonder if it's about me having libhybris installed on x86 [04:13] Mirv, that reminds me, we need to make u-s-c attach unity-system-compositor.log automatically [04:13] * Mirv runs unity-system-compositor [04:14] ok, so the bug is just crashing without explanation if libhybris/etc installed on x86 [04:15] Mirv, you uninstalled libhybris and that fixed it? [04:16] robert_ancell: yes. it uninstalled libhardware etc as well. [04:16] good morning :) [04:17] morning tvoss_ [04:17] tvoss_, I thought you were on holiday? [04:17] robert_ancell, nope, only Friday [04:18] robert_ancell, lool is on holiday, my alter ego :) [04:18] ah, tag team [04:18] * tvoss_ is happily running a non-slow XMir right now :) [04:18] duflu, ping [04:21] RAOF, ping [04:23] tvoss_, ping [04:23] tvoss_, you know you can just ask questions out loud :) [04:23] I think I can work with XMir, this mirror-by-default is good enough for what I need until true multi-monitor support [04:23] Mirv, nice! [04:25] Mirv, woot [04:25] tvoss_, pong [04:25] duflu, hey there :) tried the bypass branch with xmir, seeing some occasional rendering hiccups [04:25] "nice!" to you, that is :) [04:27] robert_ancell, yup :) [04:27] tvoss_, interesting. Not sure how to gauge if it is bypass to blame, or just hiccups that were hidden by extra buffering before [04:27] tvoss_: Pong [04:28] tvoss_: What is a hiccup? [04:29] duflu, seems like a buffer arrives out-of-order [04:29] tvoss_: Weird. I can't reproduce any such issue with plain Mir. [04:30] Maybe something unusual about XMir vs normal clients [04:30] duflu, ack, RAOF ^ [04:30] tvoss_: On intel, I presume? [04:31] RAOF, bug 1211063 - does XMir load color profiles on startup and just not handle changes which would be via XRANDR yet? [04:31] bug 1211063 in Unity System Compositor "Color profile change is not instant when unity-system-compositor is running" [Undecided,New] https://launchpad.net/bugs/1211063 [04:31] robert_ancell: We don't handle colour profiles *at all* at the moment. [04:32] RAOF, I thought so too - Is Jussi confused [04:32] ? [04:34] I think so? [04:34] RAOF, ack [04:35] RAOF, is that a known issue? [04:35] tvoss_: No, but it changes the plausible causes. [04:35] RAOF, true :) anything else I can help to track down/triage the bug? [04:35] eg: We have in the past failed to flush correctly on radeon, so the buffer we submit to Mir didn't necessarily have fresh content. [04:36] tvoss_: What would be really good is a vsync'd app, displaying an increasing counter, counting up one per vblank, and a 60+Hz film of said client ;) [04:37] RAOF, hah, nexuiz has got such a display, let me see if I can trick it into vblank ;) [04:37] XMir *is* the client we have that's most likely to show out-of-order artefacts, as it's the only client we have that doesn't submit a new frame each vblank. [04:41] RAOF, true :) [04:42] * tvoss_ needs more coffee [04:42] Actually, the requirement for vsync is spurious; all we need is something that displays a monotone counter that increases at least once per vsync. [04:42] tvoss_: I will modify some demo client(s) to increase my visual test coverage... after lunch [04:43] duflu, yeah, I will move over to the new place, back in 30 [04:51] * RAOF heads off to the doctors with Zoë. Taking my laptop, so I should be around. [05:19] thomi, do you remember what the trigger was to make Jenkins do a test on a MP? I would like Jenkins reviews of https://code.launchpad.net/~a7x/lightdm/multiseat/+merge/178511 ideally before I approve the branches [05:20] robert_ancell: I take it a7x is not a member of ~canonical? [05:20] nope [05:20] robert_ancell: I believe in that case you need to vote to approve the MP (you don't need to top-approve it thought) [05:21] thomi, actually, he is a member of ~contributor-agreement-canonical - perhaps we should allow that group to trigger Jenkins [05:21] robert_ancell: you can ask, but I doubt it'll go through. Signing the contributor agreement doesn't mean Canonical has any kind of leverage over them, in case something bad happens [05:22] but I agree, it's a real PITA [05:22] thomi, well, you could kick them out [05:22] but yeah, I know what you mean [05:22] if we had more time we should set something up on prodstack as a firewalled builder [05:22] shouldn't be too hard to achieve [05:24] thomi, is there a way to manually trigger a build, e.g. like the form we use for rebuilding? [05:24] yeah, you don't want to add an approve vote? [05:25] robert_ancell, why does unity-system-compositor only work in lightdm [05:26] smartboyhw, because no-one has used it in anything else. There's no particular reason why it couldn't be used elsewhere [05:26] robert_ancell, oh [05:27] robert_ancell: I think I found the right job, just trying it now [05:28] hmmm, nope! [05:29] robert_ancell: I'm not sure how to do that, sorry. I can email fginther, and get back to you tomorrow, if you like [05:29] thomi, np [05:29] it's not that important [05:29] ok [06:37] tvoss_: I still can't reproduce any "hiccups" using bypass on mir_demo_server_shell with the example clients [06:37] duflu, hmmm, might be XMir specific then [06:37] I'm using Intel BTW [06:38] RAOF: Is XMir now a well-behaved normal client? (no GBM-specifics) [06:38] duflu: No. [06:39] RAOF: How so? Please forgive my forgetfulness... [06:39] Because it doesn't use GL to render; it uses the DDX's methods to render. [06:40] And it's not going to use GL to render for the forseeable future. [06:42] good morning [06:43] RAOF: Hmm, OK. I don't really need to know what that means, other than to ensure that XMir only uses the buffer given to it by the client library, and for never longer than till the next swap. That's still true right? [06:43] dholbach: Morning [06:43] duflu: That is true. [06:43] OOooh. [06:43] I have a plausible hypothesis. [06:43] hi duflu [06:43] How many times to you allocate buffers? [06:44] Or: how many times will you send a buffer that the client hasn't seen before? [06:44] RAOF: Max 3 unique ones. Allocated lazily (when they're first required) [06:48] I think the current code fails to handle the case where buffer->age == 0, but that should only happen once per buffer allocation. [06:49] tvoss_: How many times do the hiccups occur? [06:49] RAOF, hmmm ... difficult to tell, but regularly [06:49] So, unlikely to be that you're hitting the age==0 case. [06:50] I can also see some damage/age-related bugs when toggling CCSM>OpenGL options [06:50] But that's not really related [07:31] tvoss_: What are you running to see hiccups in XMir? I suspect this might also be an issue - https://bugs.launchpad.net/xmir/+bug/1211186 [07:31] Launchpad bug 1211186 in mir (Ubuntu) "[regression] GL(X) apps don't have vsync when running under XMir" [Undecided,New] [07:32] duflu, gnome terminal [07:32] tvoss_: Hmm, which branch or Mir/bypass and what revision? Keep in mind the input lag fix only just landed [07:32] -or +of [07:32] duflu, only landed now? [07:33] duflu, as of Friday iirc [07:33] tvoss_: Only landed in r955 [07:34] So looks like Friday night/Saturday your time [07:34] duflu, let me recheck [07:36] tvoss_: Would have only landed in lp:mir midnight Friday night your time [07:37] * didrocks again sees issues with ATI [07:37] sil2100: doesn't seem around, let me try to match with a commit :/ [07:37] ? [07:37] I'm here, what's up? [07:37] sil2100: didn't you see my ping? [07:37] Did I miss a ping? [07:37] 09:19:30 didrocks | sil2100: the -ati machine seems wracky again, it was ok on Friday/Saturday [07:37] 09:19:38 didrocks | sil2100: I think it's mir being the issue with that [07:37] 09:19:48 didrocks | (the tests are ran in mirslave) [07:37] 09:20:10 didrocks | can you see if anything was committed between latest good mirslave run and the new bad one in mir itself? [07:37] 09:20:24 didrocks | (so look at when exactly mirslave check started to fail) [07:38] 09:20:37 didrocks | and potentially match that with a mir rebuild which happened just before? [07:38] 09:21:20 * | didrocks reboot ati to save it first [07:38] multiple ones even ^ [07:38] Ah! Ok, just saw the ping ones, didn't manage to read the rest of the context ;) Looking at mirslave [07:38] Runs [07:39] 11th was fine it seems [07:40] Grargh ATI [07:41] isn't memory corruption fun? :P [07:42] sil2100: no, look closer, sometimes the autopilot job is green, but just have one test running [07:42] (on ati) [07:42] and the job went stuck [07:42] I know, since job 72 failed since it only ran 1 job [07:43] But 71 seems ok, so checking changes in mir etc [07:43] * didrocks hopes they were some [07:43] sil2100: also package list (both post-setup) maybe? [07:45] mlankhorst: I personally prefer texture corruption across suspend/resume cycles. That's more fun. [07:46] pfft :p [07:48] but I guess I'll try to isolate the issue at least [07:48] and figure out why ati is kernel corrupting on me [07:49] didrocks: still looking, but hm, doesn't seem like there were any intrusive changes - the build started failing when running Mir version from 12.1, but the only changes made since the time it was ok are the packaging change (shlib in rules) and one CMake change ;/ And unity-system-compositor had no new changes since 10th [07:50] Looking at the postsetup list for anything else [07:51] yeah, let's hope we can find something [07:51] But why is it always ati affected ;/?! [07:52] didrocks: how exactly did the ati machine hang up? [07:53] sil2100: so, what we saw last week, is that (it was 100% of the time at first): [07:53] u-s-c couldn't start or starts and hangs [07:53] unity couldn't start (stuck on opengl plugin, when duflu is running unity_system_compositor) [07:53] so the first opengl app hangs [07:54] then, the machine times out of 2h [07:54] if you then restart with regular xorg [07:54] nothing happens [07:54] didrocks: duflu? [07:54] the machines hangs [07:55] duflu: sorry, I meant you run unity_support_test from compiz [07:55] uh [07:55] sil2100: so, it's really annoying, everytime, that's what screwing up the ati machine [07:55] * duflu barely remembers what that means [07:56] duflu: you do run it if the unity plugin is setup to know if unity can be ran in that session [07:56] or should fallback on llvmpipe mode [07:56] IIRC [07:57] didrocks: since diffing the postsetup pkg lists show that only mir packages, unity-system-compositor and unity-autopilot are different between runs [07:57] sil2100: ok, no kernel, no driver? [07:57] weird, we had the issue 100% of the time [07:57] and then, not anymore [07:57] at all, in mutiple runs [07:57] sil2100: when did you see that starting again? [07:58] didrocks: We've seen that problem before... https://code.launchpad.net/~vanvugt/ubuntu/quantal/nux/fix-1039155/+merge/128422/comments/281152 [07:58] didrocks: I compared the last ok run (which ran more than 1 test), which was from yesterday [07:58] With the one today, which started failing [07:59] duflu: right, here the issue is that with Mir/u-s-c on ATI, the program hangs [07:59] (unity_support_test) [07:59] geh [08:00] didrocks: Yes there have been problems on various machines where unity_support_test causes bugs if executed from within Compiz. I think I was advocating not running it from within Compiz (which solved the issues at the time) [08:01] duflu: but this only happen when u-s-c is running [08:01] with regular Xorg, no issue [08:01] and not everytime :p [08:01] didrocks: The issue is much older than that and has been happening for an unlucky few for a year [08:01] didrocks: can I try re-running the mirslave stack? Since I missed last week and want to make sure the failure now is reproducible [08:01] duflu: I mean, we run compiz hundreds of times everyday [08:01] (or does it crash ati for good?( [08:01] if not thousands [08:02] from the past 8 month on this particular machine [08:02] duflu: only running xmir shows that issue [08:02] sil2100: it's running every 4h automatically now [08:02] sil2100: so let's wait for next run [08:02] Ok [08:04] didrocks: I know and I could never reproduce it either. However those who did have the problem before, found the solution was to unity_support_test externally, as in https://code.launchpad.net/~vanvugt/ubuntu/quantal/nux/fix-1039155/+merge/128422 [08:05] duflu: but it would be good to know why Xmir is showing the issue more [08:05] that doesn't explain the reason [08:05] didrocks: True :( [08:08] RAOF: Fun fact: DRM will successfully scan out non-scanout GBM buffers (!?) [08:08] duflu: do you think we should try it now? [08:08] duflu: and that will be compatible with u-s-c? [08:09] didrocks: I can't remember all the details and how things fit together, but I do think it would be good to avoid any fork/exec from compiz [08:09] duflu: mind proposing an updated branch? [08:09] didrocks: I'm on the critical path to deliver bypass support, so want to finish that first [08:10] duflu: sure, do you have any idea when you can tackle that one? (roughly?) [08:10] didrocks: 1 week ? :/ [08:10] hum… [08:10] ok [08:10] we have to find something/someone to do it beforehand [08:11] as otherwise it will mean no more Mir delivering in a week [08:11] Unacceptable ;/ [08:14] didrocks: so hm, the workaround/solution would be to remove running unity_support_test from within compiz and just running it like in the branch duflu mentioned, i.e. separately (maybe upstart?) [08:15] I wonder if this would indeed help [08:15] sil2100: yeah, we need someone to try that with xmir though [08:15] sil2100: /etc/X11/Xsession.d/ is fine for now [08:15] (see #ubuntu-desktop) [08:19] sil2100: You need to do it in a parent process of the X session, because if unity_support_test fails then export LIBGL_ALWAYS_SOFTWARE=1 has to be inherited by the compiz process [08:19] duflu: right, thanks! [08:19] duflu: How did you discover that? [08:20] RAOF: I was just curious. Not sure why. It's weord [08:20] weird [08:20] didrocks: I understand that you're hacking on it right now? Or should I try? But I won't be able to test it on xmir though, so will have to find someone running it [08:20] sil2100: please do, I'm in a ETOOMUCH already :/ [08:20] sil2100: why can't you try on xmir? [08:20] duflu: We might accidentally allocate scanout-capable gbm buffers anywoy [08:20] RAOF: Makes me think GBM's idea of scanout is different to DRM's, which would be important to know [08:20] didrocks: I am afraid it will make my system boom ;) Is it safe? [08:21] sil2100: it's easy to revert anyway [08:21] install unity-system-compositor [08:21] and uninstall it [08:21] for removing it [08:21] sil2100: what driver are you using? [08:21] RAOF: All I have to decide right now is (width >= 800 && height >= 600) ... :/ [08:21] Ok, sounds easy [08:21] didrocks: the open radeon driver [08:22] duflu: It's also possible that there's *no* buffer which is incapable of scanout, depending on how funky intel's scanout hardware is. [08:22] sil2100: excellent, that's what we need :) [08:22] RAOF: Yeah I figured drivers would be different on this. I will probably have to play with video cards [08:22] sil2100: I would advise you to first try with regular Xorg [08:22] sil2100: and ensuring that the script is ran [08:22] \o/ will do [08:22] thx! [08:29] RAOF: Tho if you try to DRM flip a buffer with wrong dimensions that's pretty fatal [08:30] At least, Mir makes it fatal [08:30] superrr deadly [08:32] didrocks: I'm quickly rebuilding compiz to remove that patch for running it from compiz, once this is done I test the scripts [08:34] thanks sil2100! [08:37] Back in 30ish [09:12] RAOF: XMir is buffer usage hardware, right? :) [09:15] guys, using mir_demo_server + mir_demo_client_accelerated on the Nexus 4 i get a black screen [09:15] any clue of what may be wrong? [09:15] brb, reboot [09:15] tsdgeos: Probably surfaceflinger is still running? [09:16] duflu: nope [09:16] phablet@ubuntu-phablet:~$ ps -A | grep surf [09:16] phablet@ubuntu-phablet:~$ [09:17] tsdgeos: I have seen similar issues... Mir lacks explicit support for turning the screen on if it is off. But that's not usually an issue if you have fully disabled surfaceflinger (and reboot): https://wiki.ubuntu.com/Touch/Testing/Mir#Switch_from_SurfaceFlinger_to_Mir [09:17] tsdgeos: Also, that issue I have seen is obvious because Mir will throw exceptions [09:18] mir_demo_server* will throw exceptions [09:18] not here [09:18] stuff is here [09:18] on the shell [09:18] without complaining [09:18] tsdgeos: Any hint that the backlight is *on* ? [09:18] how could i know? [09:18] it seems to be [09:18] use powerd-cli to force it on [09:18] It's usually obvious (not properly black) [09:18] i.e. if i reboot i get the "google" logo [09:19] until i start mir_server_demo [09:19] tsdgeos: Yeah [09:19] that turns gray [09:19] looks "ok" to me [09:19] tsdgeos: OK, so your server is running but not showing clients then [09:19] tsdgeos: Because it sounds like the glClear from mir_demo_server* is working [09:20] should it show some FPS readings? [09:20] because the unaccelerated one does [09:20] but i still can't see anything on screen [09:20] tsdgeos: Yes it will always be 60 FPS on Nexus4 [09:20] see no output here [09:20] tsdgeos: Does the client start/hang? [09:20] i do see 60fps with the unaccerelated [09:21] but the accelerated only gives [09:21] phablet@ubuntu-phablet:~$ mir_demo_client_accelerated [09:21] Starting [09:21] Connected [09:21] __pthread_gettid -2 [09:21] Surface created [09:21] and that's it [09:21] tsdgeos: OK then you have a GL-specific issue. Probably related to hybris [09:21] :/ [09:22] who do i nag ? [09:22] tsdgeos: https://bugs.launchpad.net/mir/+filebug ;) [09:22] so it's going to be another day without any work done [09:22] awesome :D [09:23] tsdgeos: Did you get all your binaries from the phablet image or hand built? [09:23] all image + apt-get upgrade [09:24] ugh [09:24] did you check that there are no bits in the apt-get upgrade that reach into the android side ? [09:24] tsdgeos: Same result for mir_demo_client_egl* ? [09:25] (are yoou sure surfaceflinger works at all after you upgraded) [09:25] duflu: the egl ones print stuff to the shell [09:25] (if not, Mir wont either ... apt-get has to be used with *lots* of care) [09:25] but can't see stuff on screen either [09:25] tsdgeos: How about mir_demo_client_fingerpaint? [09:25] That should work (software rendering) [09:26] nothing [09:26] and it ended (returned to shell) after a while [09:26] seems the demo server quite [09:26] -e [09:26] duflu: yes indeed it is buffer_usage_hardware :P [09:27] tsdgeos: It sounds a lot like your client and server are mismatched. :/ [09:27] may be [09:27] sadly s-jenkins:8080/job/ubuntu-touch-phablet-image-saucy-mir/ hasn't had a correct build for a long time [09:28] RAOF: Good. Because bypass cripples software buffer performance slightly. I have disabled bypass of those [09:28] Huh [09:29] Not surprising. I would expect pushing pixels across the bus to GPU-land to be a bit slower [09:29] But you need to do that bypass or not bypass? [09:30] ogra_: what's your suggestion then to get something "up to date" given the last successful image is from 6 days ago? [09:30] duflu: well just do staging transfers from GART to VRAM :-) [09:31] tsdgeos, poke rickmm ... once he is up ... and beyond that use the latest normal image, diable SF there and install the Mir stuff you need (i dont think the Mir image does much different) [09:31] mlankhorst: I don't know what you mean [09:32] ogra_: then why is it red :'( [09:32] perform a gpu assisted copy from system memory to VRAM [09:32] * tsdgeos tries to do something else until ricmm or grayback are online [09:32] RAOF: In buffer_usage_hardware we're just sending (smaller) instructions across the bus and the filling/blitting originates from the GPU. It's quite different [09:32] tsdgeos, no idea, i'm not affiliated with that image [09:33] mlankhorst: Sounds interesting. Mir doesn't seem to with Intel at least. [09:33] ogra_: sure, not blaming you, just crying out loud [09:34] duflu: intel has no dedicated VRAM :P [09:34] tsdgeos, well, grab the latest normal image, disable SF and install Mir ... shouldnt be different :) [09:34] mlankhorst: I know. Which makes me surprised there's any performance difference. But I would expect it with real cards [09:35] can try that i guess [09:35] ogra_: tx [09:48] How can I see if xmir is currently used? [09:49] sil2100: unity-system-compositor should be running [09:51] Ok, don't see it running here - is there anything else I need to do besides installing unity-system-compositor ? Any configuration switch? [09:52] shouldnt' [09:52] duflu: RAOF: ^ [09:52] sil2100: cat /var/log/lightdm/unit* [09:52] * duflu checks [09:53] http://paste.ubuntu.com/5976702/ [09:53] sil2100: You should have unity-system-compositor running, and also "ps auxw | grep mir" reporting mir options to X [09:53] This is from /var/log/lightdm/unity-system-compositor.log [09:53] That's *very* informative :) [09:54] Heh [09:54] sil2100: Wrong URL? [09:54] hm, good url but it seems the log has some non-ascii characters in it [09:54] Let me paste just the relevant parts [09:55] inkerlinker.c:1095| ERROR: Library '/system/lib/libGLESv2.so' not found [09:55] Segmentation fault (core dumped) [09:55] sil2100: hybris installed on your machine? [09:55] libhybris [09:55] You win the "I've got hybris installed" award. [09:55] I wonder what's hybris doing on my system [09:55] we need to stop diverting libgles from there... [09:55] really [09:58] seb128, in the works as I understand it [09:58] tvoss, great ;-) [09:59] seb128, I have had that issue multiple times in the recent past :) [09:59] tvoss, you are not the only one ;-) [10:04] Ok, xmir works now with all things hybris uninstalled [10:04] Thanks guys! [10:04] didrocks: the Xsession.d detection seems to work fine [10:05] sil2100: you do have the file in /tmp/? [10:05] /tmp/unity_support_test.0 [10:05] Yes [10:05] I also did the test that duflu recommended in that merge [10:06] Why do we even have libhybris on desktop? https://launchpad.net/ubuntu/+source/libhybris [10:06] i.e. made unity_support_test -> /bin/false and had a fallback to llvmpipe [10:06] Works both for xmir and standard x [10:07] didrocks: now the steps to proceed... I will fill in a merge to lp:nux with the xsession.d file, but what about compiz? Since we don't daily release that yet [10:07]