[03:40] duflu: Oh, I've realised that one of my problems with DRI bypass is actually a generic problem with nested bypass, so I'm interested in how you've solved it [03:42] The problem is - what happens if you need to unbypass? You've only got one buffer from the server you're running against, and you've handed it out to the bypass-client. So now you need to wait for it to swap_buffers before you can unbypass, but there's no mechanism to make it swap_buffers (and can't be in general). [03:46] RAOF: My first prototype worked that way but then I realized the same problem. The client could hold it indefinitely. [03:47] So how did you solve that? [03:47] The current approach is to make client buffers (sometimes) scanout capable and give them directly to the server as required [03:47] RAOF, on the phone, when unity8/mir runs as the user it's logged in as - does it have enough permissions to get input directly? Or do we have to go via the system compositor? [03:48] robert_ancell: If we want to have any form of user-switching then input needs to go via the system-compositor. [03:48] RAOF, but we're not doing that for XMir right? [03:48] RAOF: There will be some smarts required to limit which clients get scanout capable buffers, and maybe event change it at runtime. But right now I just have all clients given scanout capable buffers. And sometimes they will be scanned out (bypass), sometimes not (composited) [03:48] Right. Which is why user switching under XMir is currently a terribly bad idea. [03:49] Also, we run XMir as root. [03:49] yes [03:49] I just got support to run Mir sessions and VT switch between them, but that's probably a no-go [03:49] And the design for 13.10 is that we trust XMir to acquire/release input when its session gets switched to/from. [03:50] As long as the Mir sessions can acquire/release input on VT switch, and unity-system-compositor can acquire/release input on VT switch that should work. [03:51] I think you need to be root to watch for VT switches [03:51] Indeed you do. [03:51] Anything we run on a VT needs to do so as root. [03:52] Is there any way to authorize certain processes to run on a VT? [03:52] Anything we run under unity-system-compositor *can* run unprivileged, as long as it gets input through u-s-c. [03:52] yeah [03:52] I'm not sure that's enough. [03:53] Because (if you're running on a VT) you need to be able to access /dev/input/* to get input. [03:53] yeah, and that's root right? [03:53] Indeed [03:53] And if your *user* can access /dev/input/*, then they can just open it, switch away, and they snoop all input. [03:53] * RAOF notices it's 2pm and goes for lunch. [03:54] yes, you would have to limit it to just the shell to be useful [04:18] Which is pretty similar to "just run the shell as root" [04:37] duflu: Ah. That doesn't help me, then (and won't work for the nested-compositor case) [04:37] duflu: We should probably work out how to do it properly :) [04:42] * duflu does lunch too [05:02] good morning :) [05:05] Aloha [05:06] robert_ancell, RAOF did we have any luck with the ati machine? [05:08] tvoss: I thought that got all resolved? [05:09] RAOF, not sure :) I hope it it is [05:13] tvoss, RAOF that's bug 1204939 and we don't have a solution [05:13] bug 1204939 in Mir "Mir doesn't start on ATI test machine" [Undecided,New] https://launchpad.net/bugs/1204939 [05:13] RAOF, duflu can you have a look at that one and triage it please? [05:14] RAOF, we saw [ 2417.963] (II) UnloadModule: "radeon" [05:14] [ 2417.963] (EE) Screen(s) found, but none have a usable configuration. [05:14] RAOF, from the next ppa that didrocks wanted to test [05:16] So the problem is that XMir hasn't been loaded at all. [05:16] RAOF, did the packaging changes mess things up? [05:16] OK, title improved but needs much more attention to be "triaged" [05:17] robert_ancell: Possibly? I would have thought the server would die if it couldn't load xmir.so [05:25] didrocks, good morning [05:25] hey tvoss [05:26] RAOF, any ideas why the new packaging might fail? [05:27] tvoss: Not off the top of my head. [05:28] didrocks, do we have access to the machine? would like to track this issue down [05:29] tvoss: the machines are currently running the tests for daily release [05:30] as having those in the image is the priority, no access to the machine now [05:30] didrocks: Do we have a dump of /var/log anywhere? [05:30] RAOF: you can have that if you uncompress the archive from yesterday [05:30] I'll give you a pointer in 5 [05:30] Ta [05:33] didrocks, you'll be in IOM right? [05:33] robert_ancell: right [05:33] RAOF: http://10.97.4.138/otto/saucy-i386-20130725-1116/archive/ubuntu_13.10_saucy_salamander_alpha_i386_20130725.1374764535.otto [05:33] RAOF: this is a tar file [05:33] didrocks, tvoss, see you guys there [05:33] you have a delta/ directory [05:33] robert_ancell: see you there as well dude! :) [05:34] in the delta, it's a bump of all what was modified [05:34] so you should have var/log and so old [05:34] Well, that is of moderate size! [05:34] so on* [05:34] RAOF: don't install that many packages :p [05:35] (it's really just a delta, with mir installed on top of it) [06:02] didrocks: It looks to me like xmir worked as expected on that test run - it's the failsafe session that failed to start. [06:03] RAOF: why failsafe was executed? [06:04] shouldn't we have u-s-c running? [06:04] lightdm.log shows that u-s-c started up fine, XMir started up fine, then upstart asked lightdm to terminate, which it did, cleanly. [06:05] (upstart sent SIGTERM ~20s after lightdm came up) [06:05] RAOF: the session even didn't start [06:05] (user session) [06:06] [+1.88s] DEBUG: Session 1085 running command /usr/sbin/lightdm-session gnome-session --session=ubuntu [06:06] Then: [+22.80s] DEBUG: Got signal 15 from process 1 [06:06] RAOF: right, the question is why the session was killed? [06:06] as nothing changed and the same package versions are working reliably on intel [06:06] with session starting [06:07] unity spawn [06:07] RAOF: it seems that the acceleration test maybe doesn't work (what is tested before starting unity) [06:07] so can't start unity -> required component [06:07] -> exit [06:09] Plausibly - ~/.cache/upstart/unity7.log contains a lot of ‘unity7 stop/pre-start, process 1216’ [06:09] RAOF: my guess is that acceleration doesn't work [06:11] There's no evidence of that in the Xorg.0.log, but it's possible. [06:14] But in gnome-session.log - compiz (core) - Info: Unity is not supported by your hardware. Enabling software rendering instead (slow). [06:21] yeah, seems like a good hint [06:21] Hey that's what I was getting after updating last night :/ [06:22] argh, gdb in an armhf chroot is pure pain [06:28] didrocks, what does the unity test script check? [06:30] tvoss: if hardware acceleration is available and multiple other things [06:30] tvoss: it's in nux sources, tools/ [06:30] but maybe duflu debugged it as he saw it [06:30] didrocks, is there a log of it? I think I saw something in /tmp [06:31] tvoss: just returning 0 or 1 if supported/unsupported [06:31] didrocks: No, I ignored the bug because it was on raring (which I assume we don't care about) [06:31] didrocks, hmmm, not what I would call overly chatty :) [06:31] Though interestingly, the fix was to downgrade the latest lightdm update [06:31] you can launch it with -p to have more logs, but you need access for that on the machine [06:31] but as duflu gets it [06:32] maybe he can run it to get more infos? [06:32] duflu: interesting, that is a potential issue, right, latest lightdm [06:33] didrocks: Also, on this raring machine I am not using USC. It's plain old X. Just that the staging PPA gave me a dud update [06:45] good morning [06:48] didrocks, can we downgrade lightdm on the machine for testing purposes? [06:49] tvoss: it's possible, will take time… time I don't have today TBH [06:49] tvoss: i'm already on pressure to deliver something I didn't know that was planned for IoM as top priority [06:49] tvoss: I pushed it back for the last 2 week mainly because of Mir already… [06:49] didrocks, ack [06:50] sil2100/jibel should be able to help though to do that [06:50] didrocks, ack [07:02] * RAOF is sad that you can't build X with clang ☹ [07:04] That's odd. I'm getting small amounts of graphics corruption since getting a new intel driver from staging [07:04] duflu, likewise [07:14] RAOF, duflu is there any way that I can try the staging ppa xserver and intel driver? [07:15] tvoss: Is that a trick question? You mean with the other PPA? Maybe just download the deb(s) [07:15] duflu, nope, not a trick question [07:15] didrocks, or can I try to switch to next for intel? [07:16] tvoss: daily-build-next -> intel [07:16] it's working from what the tests says [07:17] didrocks, okay, will give it a spin now [07:17] tvoss: keep me posted ;) [07:17] sil2100, hey there [07:17] Morning! [07:26] hey sil2100! [07:32] didrocks, apt-get dist-upgrade removes unity-common? is that okay? [07:32] yep ;) [07:34] didrocks, in progress [07:35] alf__, ping [07:50] okay [07:50] no hw accel on unity [07:58] didrocks, tried daily-build-next with intel, comes up but no hw-accel, flickering screen [07:58] tvoss: interesting that times out on tests are so big that they pass then… [07:59] tvoss: ok, so clearly either an issue with latest Xorg or lightdm [07:59] didrocks, you sure? [07:59] I will reenable the system-compositor-testing ppa now [07:59] and compile usc and mir from current trunk [07:59] that's what you essentially do, correct? [07:59] tvoss: duflu mention that revering lightdm helped [07:59] tvoss: yeah, you have latest usc and mir normally [08:00] didrocks, ack, I will stick with the older xorg and intel driver in the testing ppa then === didrocks is now known as didrocks_reallyb === didrocks_reallyb is now known as didrocks_busy [08:04] duflu, which version of lightdm did you downgrade to? [08:04] tvoss: 1.7.5bzr1634raring0 [08:04] The broken one was 1636 [08:05] duflu, ack and thx [08:05] duflu, did you experience flickering, too? [08:05] tvoss: No... But then this raring machine is using plain X, not Mir [08:05] duflu, ack [08:05] ... so that I can start new Mir servers concurrently [08:07] hmmm, compiling mir trunk fails with unit-tests requiring eglCreateImageKHR [08:07] I thought we had fixed that [08:25] back in 30 [08:27] duflu, ack [08:49] sil2100, any luck with the unity-test script? [08:52] sil2100, ping [08:52] RAOF, ping [08:52] tvoss_: still waiting for the machine to be free ;/ We might consider killing some jobs if this is urgent [08:52] sil2100, nope, no worries [08:52] any eta? [08:53] Let me see how far the stupid unity testing is [08:53] sil2100, ack [08:54] tvoss_: I would say around 30 minutes, since unity testing is finishing and then just some smaller jobs are queued up [08:54] sil2100, ack and thx [08:55] jibel: can we somehow block the autopilot-saucy-daily_release job not to accept any new requests for a moment? [08:56] sil2100, stop the slave on the machine [08:57] sil2100, sudo stop jenkins-slave on ait [08:57] ati [08:58] sil2100, but wait until the current runs are finished [08:58] as it will interrupt them [08:59] tvoss_: Pong [09:00] RAOF, hey there :) I'm trying to bisect and track down why daily-build-next gives me a fucked up xmir stack [09:00] RAOF, starting with system-compositor-testing ppa, what would be next? installing mir and usc from staging? [09:01] Hm. Wouldn't you install from daily-build-next? [09:01] You're trying to work out the component that's broken in daily-build-next, right? [09:03] jibel: thanks! [09:03] RAOF, yeah, the problem is: daily build next is completely unusable for me on intel [09:04] tvoss_: And you want to find which component of daily-build-next is broken for you, so you'd install components one-by-one from there, right? [09:04] RAOF, ack [09:06] RAOF, I was wondering whether I could update X and xorg-video-intel before getting the new mir from daily-next [09:07] You could, yes. [09:08] RAOF, okay [09:09] RAOF, that would work although the packaging added the xorg-xmir package? [09:09] You'd need to ensure that xserver-xorg-xmir is installed, but apart from that, yes. [09:09] okay [09:15] Hurray! Pixman is less annoying that I thought! [09:15] Although ‘the docs are the source’ remains a less than optimal state. [09:22] RAOF, ? [09:25] Oh, RegionUnion and RegionSubtract don't mind if the destination Region is the same as one of the arguments. [09:25] Although it's not obvious that this is the case. [09:26] RAOF, ah [11:54] Any news on when mir will be enabled by default to alpha/beta? [11:58] Walther, on it :) [12:01] alf__, ping [12:02] tvoss_: Huh? Last I checked it required adding a ppa, required open drivers instead of binary blobs for gpu, etc [12:02] I mean, I'm running saucy already [12:03] and tried manually installin mir once with catastrophic results, went back to "regular plain saucy" [12:03] Walther, yup, we are working on getting Mir and XMir into the archive right now. For binary driver support: That's not something we are targetting for 13.10, so it will be Mir/XMir on open source drivers, falling back to vanilla X on closed-source drivers [12:03] hm, ok [12:04] (I just happen to have a too new GPU that doesn't really have passable support in open drivers :/ ) [12:04] on work computer, not an issue though [12:04] Walther, that's unfortunate [12:05] 7970, last time i tried, just doesn't want to cooperate on anything else than bin [12:05] didrocks_busy, I was able to come up with a somewhat usable solution from staging ppa [12:05] But yeah, thanks to all for doing your job, will join testing when I can [12:06] Walther, thanks :) looking forward to finally being able to support you [12:07] hehe [12:07] Also, how's the status of native apps other than demos going? [12:07] as in, the fallbacking to X when needed, and actual mir-supporting apps [12:24] didrocks_busy, okay, taking the intel driver from the system compositor testing ppa gets rid of the weird glitches [12:25] tvoss_: so, there are more fixes that were in the pipes? [12:25] didrocks_busy, I have got lightdm from system-comp testing, intel driver from system-comp testing, everything else from staging, with usc build manually [12:26] tvoss_: do you know the diff between u-s-c in daily-build-next and in the staging ppa, [12:26] ? [12:26] did you try to revert lightdm as well to distro? maybe it's lightdm from staging "fixing" it === 20WACTA0R is now known as tvoss [13:35] hi, question: what exactly is the crtc? I got an exception on trunk: "Output has no associated crtc [13:35] and I was getting another flipping related one before [13:36] a CRT is a tube monitor ... i would guess the last C means connector [13:37] oh. it [13:37] thanks ogra_ :) I didn't realize it :) [13:38] mlankhorst, ping [13:40] pong, but not a work day for me [13:50] mlankhorst, okay: I'm seeing a driver needs flags 0, nested not support in Xorg.0.log [13:50] that's for kms with the latest intel from daily-build-next [13:51] it's not mir enabled, then.. [13:52] and if it is it'll have to wait till monday, gone [13:58] mlankhorst, thx [15:12] What's the state-of-art for flashing a device with a unity-mir image? Still to flash a special saucy-preinstalled-phablet-armhf.zip ? [15:15] bregma: is brandon around today? [15:16] he should be, but he's on left coast time so he will probably start his day within an hour or so [15:21] bregma: duh! he just told me seattle yesterday...(gray hair moment) [15:23] kgunn, it looks like the all-important https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1203207 may also be blocked on some issues, I'm going to file bugs for those and tag them entering-saucy [15:23] Launchpad bug 1203207 in mir (Ubuntu) "[MIR] mir" [Undecided,New] [15:23] kgunn, if you could get that intel bug tagged, that would be great [15:28] bregma: on it...yeah...sorry [15:37] bregma: there now https://bugs.launchpad.net/mir/+bug/1205383 [15:37] Launchpad bug 1205383 in Mir "Xmir intel vladmir head broken" [Critical,Triaged] [15:37] kgunn, thanks [16:07] kgunn, hey, i've a couple things to finish then I can help look into which rev has causing the ati issue [16:07] bschaefer: thank you [16:08] since you had a local card...you might be able to use that....i think you might have been on -testing ppa [16:08] kgunn, np! I've a desktop with an ATI card, in the evergreen family but I should get the info for didrocks ati machine [16:08] excellent! [16:09] kgunn, yeah, also would you happen to know how to point a local built mir to get lightdm load it? [16:09] so I can start reverting trunk mir to figure out what rev caused the problems :) [16:11] tvoss_: hey dude, good morning/afternoon/whatever-is-there :) [16:12] xjunior, otp, with you in a few [16:19] bschaefer: honestly...i think if you build is....it tries to use your usr bins first [16:20] at least i'm pretty sure...cause i fell victim one time, it wouldn't work from ppa [16:20] kgunn, alright, Ill have to dig around to how to make lightdm point to my buiild ;) [16:20] but only i was broken...and yeah..oops [16:20] old binary in my usr dir [16:21] right, hmm well I ll need staging, worst case I can move it into /bin but that is reall the worst case [16:22] bschaefer: might ask tvoss when he's off the phone [16:22] kgunn, sounds good, thanks! === didrocks_busy is now known as didrocks [19:27] hi everybody [19:27] trying to get mir to work on saucy [19:27] ran into a problem that has been reported before, but i haven't found a solution yet [19:28] here is my /var/log/lightdm/unity-system-compositor.log [19:28] ERROR: /build/buildd/mir-0.0.6bzr848saucy0/src/server/graphics/gbm/gbm_cursor.cpp(46): Throw in function mir::graphics::gbm::GBMCursor::GBMBOWrapper::GBMBOWrapper(mir::graphics::gbm::GBMPlatform&) [19:28] Dynamic exception type: boost::exception_detail::clone_impl > [19:28] std::exception::what: failed to create gbm buffer [19:28] any ideas? [19:29] smintheu, are you running on ati? [19:29] nvidia if i'm not mistaken [19:29] lspci -v | grep "VGA compatible" [19:29] 01:00.0 VGA compatible controller: NVIDIA Corporation G84GLM [Quadro FX 570M] (rev a1) (prog-if 00 [VGA controller]) [19:30] smintheu, how did you install? from the testing ppa? [19:30] yes [19:32] I saw on launchpad that other people encountered this, and that it was supposedly fixed as of yesterday [19:32] https://bugs.launchpad.net/mir/+bug/1203070 [19:32] Launchpad bug 1203070 in Unity System Compositor "unity-system-compositor doesn't start on some ati card (with opensource driver)" [Critical,Fix released] [19:32] if I understood correctly, it's supposed to be fixed [19:32] but I still have the same problem [19:33] smintheu, the testing ppa is behind as we are busy landing in distro [19:33] smintheu, can you wait until next week? [19:33] tvoss, sure, just playing around a bit [19:33] tvoss, I'll give it another try next week [19:34] tvoss, by landing in distro you mean that mir/xmir is going to become default in the daily builds? [19:34] smintheu: that's the idea [19:35] kgunn: cool. I'll give it a try again next week [19:35] tvoss, kgunn: thanks for your help [19:35] smintheu, yw :) [19:35] tvoss_, sweet, confirmed it fixes the cursor issue :) [19:36] even though I assume it was already :) [19:36] bschaefer, yup [19:36] bschaefer, what are you running now? [19:36] which version exactly, which ppa? [19:37] tvoss_, I running testing, but compiled u-s-c my self [19:37] im* [19:38] though I had to remove the *.sleep part [19:41] bschaefer, fair [19:41] bschaefer, interesting bit is actually daily-build-next [19:41] tvoss_, o the sleep binary is in that ppa? [19:42] bschaefer, it's a wrapper script [19:42] or rather what so interesting part of that ppa? [19:42] tvoss_, o well that makes more sense [19:43] o that should have the the cursor fix...hmm I wonder if I should be testing this ati card with that [19:44] bschaefer, if you can it to work, you are my hero [19:44] tvoss_, well I think thats what Im looking at today :) [19:44] * bschaefer installs ppa [19:44] bschaefer, first purge the testing ppa [19:45] tvoss_, thanks, almost didn't do that... [19:48] bschaefer: wanna stay in here ? [19:48] kgunn, sounds good [19:48] cool [19:48] robotfuel: we moved :) [19:49] so i just realized chris == robotfuel... [19:50] ha [19:50] haha [19:50] bschaefer, did you install the next ppa? [19:50] tvoss_, doing that right now! just got down purging and updating [19:51] bschaefer, ah :) [19:51] now upgrade with the new ppa...hopefully things don't go tooo bad [19:53] tvoss_, but looking at the ppa, theres no mir there? [19:53] and after purging the testing ppa, should I be compiling mir my self? [19:53] opps, I guess theres more then 1 page! [19:54] * bschaefer is not use to that many packages in a ppa [19:54] tvoss_, hmm working here [19:55] wtf? no flickering? [19:55] bschaefer, did you remove the pinning file for the testing ppa? [19:55] tvoss_, shoot [19:56] tvoss_, sorry! got your hopes up... [19:56] * bschaefer upgrades again [19:56] how many times has each of us done that [19:57] :), now I don't feel as bad haha [19:57] kgunn, so am i expecting a crash or flickering? [19:58] bschaefer, unity not coming up [19:58] tvoss_, alright, that doesn't sound good :(, is mir still running in the background with the xserver? [19:58] or is it the server as well? [19:58] ? [19:58] usc will be running, but xmir won't start [19:59] err, so do you mean unity it self just crashes [19:59] oo alright, when I hear unity doesn't run im thinking only compiz/unity [19:59] ack [20:03] hmm i just get a "no signal" from my monitor now ... thats somewhat strange [20:04] can you ssh to the machine? [20:05] tvoss_, well I should have gotten the ip first, but yeah i can guess a few [20:05] should be 1-6... [20:05] dang, forgot to install openssh...hmm thats going to be fun [20:05] openssh-server [20:05] bschaefer failsafe mode is yourr friend [20:07] thanks, installing now, but the error I got was strange [20:07] * bschaefer looks at the longs [20:07] logs* [20:08] (EE) no screen founds [20:09] but that could be attempting failsafeX [20:09] bschaefer, please get the xserver-xmir deb from the mir staging ppa manually and install it manually [20:10] This is a very general message telling you that something went wrong and there is no screen left which the server can successfully drive. Usually you'll see another error message describing what went wrong in more detail: [20:10] EE no screen found ^ from xorg [20:10] kgunn, right, thats correct [20:10] tvoss_, hmm getting the deb manually from the staging ppa? [20:11] you mean add the ppa, and only install that package? [20:11] bschaefer, cancel that [20:11] alright, well the screen part is still true, but I can ssh into it now [20:11] bschaefer, can you check if xserver-xorg-xmir is installed? [20:11] dm_connection_start [20:11] Failed to read header [20:11] from lightdm log [20:11] tvoss_, yeah let me check [20:12] tvoss_, Installed: 2:1.14.2-0ubuntu2+xmir1.1 [20:12] ack [20:12] bschaefer, can you pastebin Xorg.0.log? [20:13] tvoss_, yup! [20:14] tvoss_, Installed: 2:1.14.2-0ubuntu2+xmir1.1 [20:14] opps [20:14] http://paste.ubuntu.com/5916056/ [20:16] tvoss_, ^ [20:17] it wants exa ? [20:17] thot that was an intel thing [20:17] on my Xorg failsafe attempt it has: [ 33.829] (WW) Warning, couldn't open module vbe [20:17] instead of exa... [20:18] kgunn, it looks like it sees it doesn't exist [20:19] kgunn, err, actually ati has XAA/EXA [20:19] http://dri.freedesktop.org/wiki/ATIRadeon/ [20:20] * bschaefer wonders if XAA would workd [20:20] work* [20:21] bschaefer, try xaa please [20:21] was just trying [20:22] bschaefer, kgunn the interesting line is https://www.google.de/search?client=ubuntu&channel=fs&q=Driver+needs+flags+0,+incompatible+with+nested,+deleting.&ie=utf-8&oe=utf-8&gws_rd=cr&ei=adryUZCXL8SBtAa9v4CQDQ#safe=off&client=ubuntu&hs=i1p&channel=fs&sclient=psy-ab&q=%22Driver+needs+flags+0%2C+incompatible+with+nested%2C+deleting.%22&oq=%22Driver+needs+flags+0%2C+incompatible+with+nested%2C+deleting.%22&gs_l=serp.3...7152.7609.0.78 [20:22] 45.2.2.0.0.0.0.78.147.2.2.0....0...1c.1.22.psy-ab..2.0.0.Umv3IgNixhE&pbx=1&bav=on.2,or.r_cp.r_qf.&bvm=bv.49784469,d.Yms&fp=2582c0630cd1accc&biw=1316&bih=680 [20:22] bschaefer, kgunn even Driver needs flags 0, incompatible with nested, deleting. [20:23] hmm it didn't seem to like my xconf file... [20:23] * bschaefer tries again [20:26] tvoss_, hmm but my xmir isn't even crashing, I don't think it gets that far [20:26] it does... [20:26] tvoss_, nevermind I see what you were looking at now :) [20:30] tvoss_, hmm its loading my xorg.conf but its still looking for exa and not xaa [20:38] bschaefer, kgunn hold on, looking at the source package from the next ppa, there is a conditional for xmir, translating into an XMIR preprocess define [20:38] bschaefer, kgunn looking at the ati and intel source package, there is nowhere a define of the preprocessor macro [20:39] hmm [20:39] bschaefer, kgunn xorg-xserver has an xserver-xorg.h.in that will get configured and finally (hopefully) contains the define [20:39] wait so theres a define in the ppa thats replacing what? [20:39] however, the header is nowhere included in the drivers [20:40] bschaefer, kgunn so in total: I think we don't compile the x drivers for XMIR with nested support [20:40] * bschaefer re calls RAOF mentioning to always include a header similar to that [20:40] little confused....who added the define ? is that upstream ? [20:40] * bschaefer greps [20:40] tvoss_, well that would cause some problems... [20:40] bschaefer: yep....recal that too [20:41] header hell [20:41] preprocessor hell :) [20:42] okay guys, I'm eoding now [20:43] please keep me posted here on irc, will pick up tomorrow morning [20:43] tvoss_, alrright, have a good night sleep! [20:43]