[04:09] took 14 tries to actually get X up that time, what the heck is going on [04:09] [ 260.085195] [drm:i915_gem_do_execbuffer] *ERROR* Invalid object handle 1073741824 at index 1 [04:09] [ 260.085230] BUG: unable to handle kernel paging request at 00100150 [04:09] [ 260.085243] IP: [] i915_gem_do_execbuffer+0x20f/0x780 [i915] :( [04:10] plymouth segfaulted a few of those times [07:28] Sarvatt: Why did you delete the Karmic packages from xorg-edgers/nouveau? [14:24] they were very out of date and didn't work, didn't want anyone to think we wanted them to test that as part of your email :) [14:25] bryce updated the ddx in there in karmic but the libdrm was still really old and couldnt handle it, it'll need all new packages if you want karmic in there now [14:29] RAOF: sorry, meant to ping you with that response :) [14:32] bryceh: nouveau actually requires xserver 1.7+ as of the beginning of january btw, a karmic backport wouldn't be that easy [14:59] we need some kind of generic lbm-nouveau package we can make the ddx depend on, right now the ddx is depending on linux-backports-modules-nouveau-2.6.32-12-generic | linux-backports-modules-nouveau-2.6.32-12-generic-pae | linux-backports-modules-nouveau-2.6.32-12-server so its going to break every abi bump [15:08] RAOF: whats up with http://git.debian.org/?p=pkg-xorg/driver/xserver-xorg-video-nouveau.git;a=blob;f=debian/patches/01_include_snapshot_date;h=76fb0c0f64dc4e401131d53972d49ef03f42245b;hb=refs/heads/ubuntu ? you're patching configure directly before autoreconf runs and it doesnt exist? thanks for updating git btw, working on getting everything in the main PPA so people can try 3D [16:05] hyperair: did you upgrade your geforce mx machine to lucid? [16:05] xorg-edgers is all set up for 3D acceleration for your card now if so, just install xserver-xorg-video-nouveau [16:07] hmm, guess I do need that plymouth update as well actually, its disabling render acceleration without the patch on nouveau [16:10] Sarvatt: it's at home, i can't really testi t. [16:10] Sarvatt: think 5 hours away by bus [17:31] isn't it true that radeonhd is useless in lucid since we use kms for ati? [17:34] i suppose you could still boot with nomodeset to use radeonhd [17:34] well yes [17:35] but I guess it's too much to educate people to do that :) [17:35] and in the meantime close bugs filed against it [17:35] yeah [17:36] i think it's better to remove it [17:36] yep, I'll file a bug about it.. [17:37] which probably means removing it from -video-all, if that hasn't been done yet [17:38] yeah it's dropped from ubuntu [17:39] I mean -video-all [17:39] good :) [17:40] since intrepid, actually [17:40] heh [17:40] was in universe then i guess [17:41] yep [18:10] shoot, this isnt good enough http://pastebin.com/f56c3e6cc [18:10] just looked and the actual device is SUBSYSTEM=lbm-drm [18:20] some people might want to use radeonhd still for audio over hdmi, might be better to just add a note in the man that KMS needs to be disabled to use it? [18:30] Sarvatt, well if it's (radeonhd) not installed by default, why not just have the postinst set up something to blacklist the radeon drm module? [18:33] yeah a postinst installing a modprobe conf to have options radeon modeset=0 would be a good option [18:46] i think 70-acl.rules and 50-udev-default.rules need to be adjusted for lbm-drm as well in udev [18:46] bah [18:48] ./rules/rules.d/50-udev-default.rules:SUBSYSTEM=="drm", GROUP="video" [18:48] ./extras/udev-acl/70-acl.rules:SUBSYSTEM=="drm", KERNEL=="card*", ENV{ACL_MANAGE}="1" [18:50] Sarvatt: you mean that radeonhd is better with audio-on-hdmi than ati? [18:51] there was no audio-on-hdmi with radeon ums [18:51] only radeonhd [18:51] not sure what's state it's in with kms [18:51] ok [19:07] looks like it was merged before christmas [19:45] SUBSYSTEM!="drm|lbm-drm", GOTO="drm_end" -- is that udev rules syntax right? [19:45] looks ok to me [19:56] there we go - http://sarvatt.com/downloads/patches/udev-lbm-nouveau.patch [19:56] * Sarvatt hates working with bzr [20:07] anyone know if there is the equivalent to git format-patch for bzr? [20:10] ahh ok bzr diff -p1 is good enough [21:16] Sarvatt: autoreconf isn't run as a part of the build, it's run as a part of get-orig-source. [21:19] Sarvatt: We could re-jiggerit so that it autoreconfs at build time instead. [21:43] wow, looks like nouveau gallium was this easy to build.... - http://paste.ubuntu.com/371223/ [21:44] Sarvatt, are you going to upload it to xorg edgers ppa? [21:45] yep as soon as i'm sure its working :) [21:46] Sarvatt: Sweet :) [21:50] it only oh... doubles the build time though :) [21:51] How could the xserver-xorg-video-nouveau packaging be made more obvious to you? [21:52] it's just you can't build it without manually running autoreconf if you checkout from git, the other ones dont work like that so I have to disable that patch thats expecting a file thats not there to use the scripts [21:53] I think it might just be that the pristine-tar branch has the wrong version. Maybe. [21:53] argh, gotta run out for a bit and mesa still didn't finish :( if anyone wants to try it you can have edgers and edgers/nouveau both activated right now then grab the source and apply that patch i pasted [21:53] i patched the xserver in edgers with the nouveau patch and have a newer ddx in edgers that's needed for the newer libdrm [21:54] Ah, you've got a newer libdrm in there? Yeah. Needs a newer DDX :) [21:54] Hurray for mass register renames! [22:45] looks like it worked [22:45] http://paste.ubuntu.com/371258/ [22:46] sarvatt@arcueid:/opt$ glxgears [22:46] 7712 frames in 5.0 seconds = 1542.342 FPS [22:46] :D [22:47] compiz is working too [22:48] Gallium 0.4! Another minor version bump :) [22:49] http://pastebin.com/f4706fe37 [22:49] nouveau_dri.so working fine too [22:49] * Sarvatt cheers [22:50] Yay! [22:50] i dont know if its broken on non-nouveau though, i'll upload it to edgers and find out though :) [22:51] that was so easy compared to how hard i was making it out to be :D [22:53] :P [22:53] Hush! [22:53] You had a valiant and protracted struggle with mesa, only triumphing after great effort! :) [22:55] uploading it now, its expected to use both PPA's at the same time for now for anyone that wants nouveau gallium :D' [22:55] not sure i want to put the udev/plymouth stuff into edgers yet [22:56] 7.8.0~git20100207.1a45c2bc-0ubuntu0sarvatt2 is the mesa version with gallium [22:57] _very_ interested in hearing anyones experiences with it if they use it [22:57] * RAOF shall fire up his nvidia laptop forthwith. [23:12] Sarvatt, I'd be very interested in testing it... which is this other PPA you speak of? [23:13] johanbr, https://launchpad.net/~xorg-edgers/+archive/ppa/+packages [23:14] Oh, yeah. You want !nvidia testers, too, don't you? Let's offer up this intel laptop to the altar of xorg-edgers. [23:16] fmarl, but I got the impression there was another one? (not xorg-edgers) [23:19] johanbr, there are some PPA card specific IIRC. [23:19] ahh, alright, I think I've seen that somewhere [23:19] thank you [23:21] Sarvatt: Incidentally, I understand the plan is that linux-backports-modules-nouveau will be added to the linux-* metapackages; thus the DDX won't actually have to depend on any particular package. The current state is temporary. [23:25] Sarvatt: Mesa is missing some build-depends. [23:25] Stupid configure script not picking it up. [23:52] hmm... what am I missing if I get Mesa rendering rather than gallium? [23:52] glxinfo output: http://pastebin.com/f35fd9cf [23:52] johanbr: You'd be missing the fact that mesa FTBFS :) [23:53] I'm test-building a new package here; I think it'll build, then I'll re-upload to xorg-edgers. [23:53] ahhh :) [23:53] thank you :) [23:54] huh? missing build depends? just got home, lets see [23:55] Sarvatt: Missing xserver-xorg-dev, libpixman-1-dev, x11proto-core-dev [23:56] (At least). [23:56] Sarvatt: My local copy's test-building in a pbuilder right now; you don't have to trouble yourself :) [23:56] oh sheesh, xorg state tracker depends [23:57] xserver-xorg-dev for mesa? [23:57] Yes. xorg state tracker depends. [23:57] Cunningly concealed inside a $(shell pkg-config ...) call in the Makefile. [23:57] who needs the xorg state tracker? [23:58] Because testing for things in configure, where you can usefully override them, is for chumps. [23:58] i'll just add the depends for now so it builds and start seeing how much i can trim it down [23:59] it built locally because i have xorg-server build depends installed, sorry about that