[04:16] cnd: is there any way i can help with the input backport? would it make it easier to have an updated ubuntu+1 branch in git thats updated with later 1.11 stuff and actually builds? do you think it's a realistic goal still? I feel like its getting too late atm because peoples worlds could possibly be broken and they expect precise to have no problems but it might be totally unfounded :) [04:19] RAOF: we need a non-virtualized ppa to pocket copy to the archive dont we? how does that happen? it needs to builds on arm/armhtf/powerpc on top of what ppas build for im sure dto do the binary copy [04:20] to do the abi transition in a ppa so things arent broken [04:25] doing the whole transition in a ppa and copying to the archive will break armhf/armel/powerpc because the xserver-xorg-dev requirements wont be bumped to let it depwait then rebuild for most stuff and will be rebuilt against the wrong abi i imagine on those arches === chris_ is now known as RAOFer [05:52] Sarvatt: Yeah, I guess we will need a non-virtualised PPA. [05:52] RAOFer: got a ppa in mind? [05:53] can see if i can get one non-virtualized so stuff builds on all arches [05:54] * Sarvatt will file an rt ticket [05:54] Ta muchly. [05:55] point me at a ppa, dont think ubuntu-x-xswat/x-updates makes much sense because we put other stuff there [05:55] x-testing? [05:57] We should probably make a new one; x-staging [05:58] Hm. But I seem to have forgotten how to actually create a new PPA :) [05:58] done, cool beams [05:59] beans too [05:59] https://launchpad.net/~ubuntu-x-swat/+archive/x-staging :) [05:59] * RAOFer was imagining a cooling laser. [05:59] Sarvatt: Have you found i915/GM45 unstable on Precise recently? [05:59] on precise? no [06:00] on intel 2.17.0/libdrm 2.4.28 which i held off updating because of the bugs yeah :) [06:00] 3.2 problem? [06:00] Maybe. [06:00] It seems to like kernel oopsing. [06:02] gotta admit i havent paid attention to my only machine in those specs with precise userspace so im not sure [06:03] :) [06:04] i've been hitting an oom problem on everything else with git userspace [06:04] sandybridge/ivybridge [06:04] Hm. Did that cause it to oops somewhere in drm_mm_foo? [06:05] no no oops it always triggered corruption and gigabyte+ /var/log/Xorg.0.logs full of repeating messages of oom errors [06:06] Bah! [06:06] Stupid oopses, making writing to disc silently fail! [06:07] I'm all like "Hah! I shall dmesg > the-damn-thing-OOPSed.log and come back to it later". [06:07] And then later it's all like "I don't know what you're talking about officer" [06:22] cnd: Yeah, if you'd like an updated ubuntu+1 branch give a hoy. It should build as it stands, though :) [06:23] i dont think it builds, patch 221? [06:23] or 220 [06:24] drop 210_pixman_null_ptr_check.patch fails [06:24] drop 220_xi21_always_deliver_raw_events.diff fails [06:24] 220 still enabled and doesnt work, 210 fails with later x 1.11 checkouts [06:24] Hm. [06:26] RAOF: sooo, https://launchpad.net/~ubuntu-x-swat/+archive/x-staging *should* build all arches now :) [06:26] Nice. [06:26] that was surprisingly easy [06:27] easy enough where if we upload something and it doesn't trashing it and making another would be trivial [06:28] * Sarvatt didn't file any rt tickets [06:29] boss disabled the "virtual builders" requirement on the ppa, i'm not sure if that does what we want but sounds right [06:29] It does, doesn't it. [06:42] roll around on fire er? [06:43] *Run* around on fire, thank you! :) [06:43] wait RAOF is on a canonical IP, ya using a canonical server as a bouncer? [06:44] Yup. [06:44] WHAT! [06:44] which? :) [06:44] A canonistack instance. [06:44] ohh gotcha [06:45] Running a shiny new smuxi instance. [06:46] Bah. [06:46] Bye bye, GM45. [06:46] This, by the way, is why there's a RAOFer. [06:47] It won't even have dropped any useful debugging info to disc. [06:47] Stupid thing! [06:48] sorry in advance becuase it was the libdrm 2.4.27 upgrade that caused it [06:48] * Sarvatt TIL [06:48] Oh, 2.4.27 is to blame? [06:49] that was like the only change outside of the kernel between precise and oneiric [06:49] Yeah, but the kernel freezing hard is ultimately a kernel problem :) [06:50] 3.0 is so darn good for drm at this point, i'm still living on it [06:51] sent 6 commits to stable in the past 2 weeks, all the good stuff without the pain :) [06:51] ivybridge is great on 3.0 now, 3.2 is all kinds of screwed up [06:51] Heh. [06:56] intel guys are living in 3.3 and dont send stuff to stable, 3.2 is kinda in limbo until it releases from what i see but thats very opinionated [06:58] stuff cced to stable now is whats supposed to go into 3.2 even if 3.2 isnt a stable release [07:21] hmm, fedora17 will drop dri1 drivers [07:22] not a huge surprise, just an observation [07:24] actually, we'll have that for precise too, since upstream has dropped them from 8.0 :) [07:25] Yup [07:27] tjaalton: rhel 7 wont though? :P [07:27] Sarvatt: that's years off :) [07:27] so likely will [07:28] tjaalton: recovered from the concert now? :) [07:29] Sarvatt: hehe, yeah.. was great :) [07:29] we drove there, so only had one beer there [07:31] RAOFer: so is there something packaging wise I could do to help get the new stack in precise? [07:31] which new stack? [07:31] 1.11 [07:31] I presume. [07:31] that [07:31] mesa 7.11? [07:31] oh ok [07:31] well mesa too [07:31] yea i feel the same way [07:31] actually I could test mesa master on the sis crap [07:32] if llvmpipe is any faster [07:32] mesa's gonna need some love with the new source package shipping dri1 drivers from 7.11 crap [07:32] Won't the answer be "We killed DRI1, suckas!" [07:32] Sarvatt: no way, drop dri1 i say [07:32] :) [07:32] they're going out of their way to still support dri1 drivers even though they are dropped from 8.0.. [07:33] even if fedora wont rhel will later [07:33] Maybe. [07:33] in practice though, they haven't really been supported for years [07:34] To what extent do the existing DRI1 drivers actually run GNOME3 or Unity? [07:34] and seems like fedora/rhel7 will put effort in making llvmpipe more capable [07:34] RAOFer: they don't, llvmpipe supports opengl 2.x so it's better [07:35] to what extent do they play openarena or use blender better than swrast? lots.. [07:35] if you're using that old crap llvmpipe doesnt really help [07:35] The fact that they don't support GNOME3 or Unity means that, at best, they're not well supported. [07:35] Yeah, llvmpipe doesn't really scream "make old hardware more usable" to me. [07:35] well, if you're using old crap they are still crap no matter which driver you use :) [07:36] who sticks a sis in a system that doesnt support sse2 where llvmpipe is faster [07:36] Sarvatt: who runs openarena on one? [07:36] very true :) [07:36] the point is likely just "get a session going" [07:37] like mga has been busted on compiz for years [07:39] i dont think it ever passed the unity check though but thats unrelated, having accelerated 3d regardless of using unity-2d would be helpful in some situations [07:41] Yeah, it's kinda helpful. [07:42] It's a "we won't do anything to deliberately break it" kinda helpful, though. [07:42] * RAOF → birthday dinner. [07:45] so like airlied and ajax were the ones making sure the dri1 interface works still at the time, i really think it'd be work packaging 7.11 dri drivers even if i do it, no worries [07:45] birthday?! happy birthday RAOF! [07:46] or happy birthday to the person you are celebrating for if i misunderstood :) [07:48] http://fedoraproject.org/wiki/Features/DRI2DriversOnly [07:49] that suggests that having dri1 drivers around would need "very convincing arguments" [08:11] good morning! is there a known reason why powering off (e.g. unplugging) the screen will cause the xserver to crash? [08:12] power off != unplugging. in any case, if X crashes, that's what they call a bug. [08:13] jcristau: i mean hard power off, not pressing the standby button. the x stays alive when i just do that. [10:16] Bah. i915!!!!!! [10:17] * RAOFer suddenly realises why other people really hate it when the graphics stack is unstable. [10:22] RAOFer: I'm here hoping to hear news about the random lag I get with Nvidia drivers in Unity (Quadro NVS 290 in TwinView) === jibel_ is now known as jibel [12:48] Hi! [12:50] I'm a complete X newbie and I would need some help, since I need this for preparing a specific package [12:50] Is there a way I could get info about the xserver current video ABI on the system? [12:51] In the past, around natty, there was that videoabiver file which is now deprecated [12:51] But in the newer versions? [12:51] I would be grateful for some pointers [12:51] what are you trying to do? [12:54] I need my package to install selected binary drivers basing on the ABI version [12:54] Since there's a different driver version for every ABI [12:54] ewww. [12:55] Yep, I was thinking the same thing [12:55] ;) [13:36] hi [13:38] anybody willing to look at my nVidia GT215 bug on launchpad? https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/897436 [13:38] Launchpad bug 897436 in xserver-xorg-video-nouveau (Ubuntu) "Screen corrupted without nomodeset on nVidia Corporation GT215 [GeForce GTS 360M] (affects: 1) (heat: 11)" [Undecided,New] [13:46] inetpro: try a mainline kernel, for instance this one http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.2-rc4-oneiric/ [13:46] and get rid of nvidia before booting it [13:46] the driver, that is [13:48] tjaalton: you mean that as a temporary solution? [13:51] or do you mean I should test that to confirm whether this new kernel fixes it? [13:52] sorry, I may be a bit new to your processes of troubleshooting it [13:52] the latter [13:52] ahh [13:53] to be honest I don't have the laptop with me right now but will try that in a few hours time [13:55] yes, the driver is in the kernel [13:55] cool, I'll let you know how it goes later [13:56] and then I guess I should also try precise alpha / daily CD [13:57] it has the same kernel [13:57] I hope that kernel is in there as well? [13:57] ahh [13:57] sounds great [13:57] you can just try the live image and report back [13:57] thanks tjaalton [14:15] boa tarde === yofel_ is now known as yofel [15:27] RAOF, I'm currently trying to create a patchset for backporting xserver input subsystem master into 1.11 [15:27] just fyi === soreau_ is now known as soreau [22:10] cnd: Sweet. Anything I can do for you? [22:12] RAOF, let me go through what I'm trying to do [22:12] my idea is: backport everything that is input related from master on top of the 1.11 stable branch [22:13] I started doing that, but found one general API/ABI break: options parsing [22:13] so I left that out [22:13] I now have a branch with a backported server [22:13] I'm going to make sure it compiles and runs [22:14] and then I'll package it up and push it to ppa:utouch-team/xorg-unstable [22:14] I'm going to assimilate things in there [22:15] And then I'll pull those patches onto ubuntu+1, push it into the staging PPA, and rebuild the world against it. [22:15] ? [22:15] that's one possibility [22:15] I don't want to be redoing work twice unnecessarily [22:15] but I don't know how I can do everything we need for the input side without being the one who brings up the server for precise [22:16] Yes! [22:16] RAOF, have you made any changes to the server packaging or added patches in your 1.11 tree? [22:17] No; just the forward ports of input stuff. [22:17] Locally, because they don't work properly :) [22:17] Oh, and I've pulled in a more recent merge from Debian. [22:18] ok [22:18] so I'm going to try to bring up the xserver today and tomorrow [22:18] make sure input modules work [22:19] and try out running with the binary nvidia and fglrx drivers that are already released for 1.11 [22:19] I assume they are already released... [22:19] They are, yes. [22:19] I'm perfectly happy for you to bring up the server for precise; we'll be staging it in https://launchpad.net/~ubuntu-x-swat/+archive/x-staging [22:20] I'm off from the 15th through the 19th, so hopefully I'll have things in a state where you can work with it [22:20] RAOF, perhaps I'll bring up the server without XInput multitouch first [22:20] and push it to the x-staging ppa [22:20] and keep the multitouch stuff in the utouch-team/xorg-unstable branch for now [22:21] sound good to you? [22:21] oh :) [22:21] That seems fine to me; the x-staging server will have the rest of the 1.12 input stack, though? Just not the multitouch work? [22:22] yeah [22:22] cnd, hi, are all input patches you are backporting in xserver master already? [22:22] ricotz, everything I have backported so far are, yes [22:22] it doesn't include any of the XI 2.2 multitouch patches [22:22] cnd: Would you like widespread (ie: pushing to the distro) testing of that, before adding multitouch? Does Unity work without multitouch yet? [22:22] cnd, ok [22:23] RAOF, if unity doesn't work without multitouch yet, please ping bregma and/or DBO [22:24] pushing the server to distro without multitouch would be really helpful, but only after it has soaked in x-staging for a bit and we have covered all the main modules [22:25] We wouldn't push the server from x-staging to the distro until everything's been built against it. Then we'll pocket-copy. [22:26] ok