[00:01] <RAOF> Technically that's argb windows rather than csd.  I don't expect darkroom is implementing csd at this point.
[00:08] <Sarvatt> ahhh there we go, needed to enable compiz blur to make this manageable
[00:09] <Sarvatt> heh and i get a nice 1 FPS while moving a window with that :)
[00:10] <Sarvatt> and then compiz dies
[00:15] <RAOF> At least your drivers support the needed extensions; intel doesn't, last I checked :)
[00:18] <Sarvatt> i'm on intel :)
[00:18] <Sarvatt> oh wow gnome-color-chooser
[00:21] <RAOF> Oh, maybe you're using mipmap blur.
[00:21] <Sarvatt> gaussian alpha blur works at least, slow as heck though
[00:22] <Sarvatt> didnt try mipmap
[00:23] <RAOF> Maybe our shiny new mesa enables it.
[00:23] <Sarvatt> i dont have the fake opengl 2.0 support enabled in driconf either
[00:26] <Sarvatt> looks like it was fixed here - http://cgit.freedesktop.org/mesa/mesa/commit/?id=0dc700850acb81c7088ab740959441521f8d38d9
[00:32] <Sarvatt> fixed in karmic i guess - http://macslow.net/?p=386
[00:41] <RAOF> notify-osd looks significantly better with blur enabled.  I should have turned it on sooner!
[00:44] <Sarvatt> ack, chromium controls moved over to the left now too, evil! :)
[00:45] <Sarvatt> is it horribly slow on 965 too?
[00:45] <Sarvatt> moving rgba windows around is a slideshow on 945
[01:10] <RAOF> I really like that chromium's over the other side; that makes it consistent.  Enabling gaussian blur is a significant performance hit, but not abysmal.
=== Amaranth_ is now known as Amaranth
[02:38] <Sarvatt> RAOF: so you're saying lucid + a 2.6.34 kernel is working for nouveau for you too?
[02:38] <Sarvatt> thats what cnd was saying and I was trying to make sure they aren't actually using nv without realizing it
[02:39] <RAOF> Sarvatt: Yes.
[02:39] <Sarvatt> what the heck
[02:39] <RAOF> The libdrm ABI break doesn't really affect the DDX in everyday use.
[02:40] <Sarvatt> sure it did, i tested the heck out of it when it first went in, libdrm with 0.0.15 + 0.0.16 kernel did not work
[02:40] <RAOF> Yeah, but the new libdrm has the 0.0.16 interface.
[02:40] <Sarvatt> in *lucid*?
[02:41] <Sarvatt> stock lucid?
[02:41] <Sarvatt> 2.4.18 with the abi reverts
[02:41] <RAOF> Oh.  Um.
[02:41] <Sarvatt> they are saying its working in lucid
[02:41] <RAOF> ECONTEXT
[02:42] <Sarvatt> *maverick* has the 2.4.20 libdrm with the new abi, but in #ubuntu-kernel and on the kernel team list tgardner and cnd are saying nouveau is working with the maverick backported kernel in lucid
[02:42] <RAOF> I am equally perplexed; it totally should be dying with a drm mismatch.
[02:42] <Sarvatt> they are just using -nv without realizing it as far as I can tell, can't get an xorg.0.log out of anyone :)
[02:43] <RAOF> I thought this was one layer up the stack; with the ABI of the libdrm_nouveau that the DDX is linked to changing underneath it.
[02:43] <RAOF> I thought nouveau died in a more spectacular way when that happened.
[02:50] <Sarvatt> apparently it unregisters cleanly now and nv loads if they are saying it works :D
[02:51] <Sarvatt> i can't for the life of me figure out what else could be happening
[02:54] <Sarvatt> thats awesome if that works though, backported kernels aren't supposed to be supported on the desktop anyway they were saying so at least they have nv
[02:55] <RAOF> Given how much I was looking forward to making a godawful libdrm symlink farm hack, that would be awesome, yes.
[02:57] <Sarvatt> was really hoping to speak to them about building the agp modules into the kernel at UDS :(
[02:58] <RAOF> Damn, yeah.
[02:58] <RAOF> That sucked all round.
[03:10] <Sarvatt> mesa needs libglew-dev to build now and its in universe :(
[03:12] <RAOF> You mean mesa-demos, right?
[03:13] <RAOF> I wonder how many people care about 3D graphics under VMWare.
[03:13] <Sarvatt> nope mesa, think they removed the bundled version when they split demos out
[03:13] <Sarvatt> no idea what part of the build actually needs it though..
[03:14] <RAOF> Doesn't mesa *build* libglew, though?
[03:15] <Sarvatt> bundled version is still there, hmm
[03:15] <Sarvatt> the dri target fails to build
[03:15] <Sarvatt> checking for GLW... configure: error: Package requirements (x11 xt) were not met:
[03:15] <Sarvatt> No package 'xt' found
[03:16] <Sarvatt> ok where the heck did i get glew from
[03:16]  * Sarvatt needs to get off the pc :)
[03:16] <RAOF> Sarvatt: No, that's it checking a bunch of pkg-config files to get what it needs to *build* GLW.
[03:17] <Sarvatt> yeah needs xt, i had a commit open where it was checking for glew.pc and got mixed up, sheesh
[03:17] <RAOF> apt-file says that xt.pc does not exist in Maverick.
[03:17] <Sarvatt> libxt-dev
[03:18] <Sarvatt> i've got it installed, hmm
[03:18] <RAOF> So, my apt-file cache is broken.
[03:23] <Sarvatt> Filename: pool/main/libx/libxt/libxt-dev_1.0.7-1_i386.deb
[03:23] <Sarvatt> MD5sum: 26737bd9e76f4893d2fe7643c1a95da3
[03:23] <Sarvatt> Archive: maverick
[03:23] <Sarvatt> maybe because it was just copied over from lucid?
[03:24] <RAOF> Your guess is as good as mine.  Maybe it's just baroke.
[03:29] <Sarvatt> this libgles-qemu is interesting
[03:29] <RAOF> It's a bit strange.
[03:31] <Sarvatt> even debianized
[03:35] <Sarvatt> the headers are all we need really, they still need the blob libs for each platform packaged to actually do anything with them
[03:38] <RAOF> Which isn't terribly useful if we want to actually, say, test things on our desktop :)
[03:39] <Sarvatt> they're different on each platform and testing it on the desktop isn't really useful though, powervr has a package where you can test what it'll actually be like on the devices in the sdk
[03:39] <RAOF> Sure the extensions will be different, but you'll get the same core APIs, right?
[03:40] <RAOF> And you're not going to be performance testing on the desktop.
[03:40] <Sarvatt> the extensions look crazy different on the different devices i looked at
[03:41] <RAOF> But if you're not using the extensions it doesn't matter; and since the extensions are crazy different you can't use them if you want to be portable.
[03:41] <bryceh> btw, I noticed that versions-current.html has been broken.  Surprised no one noticed, maybe it's not being used anymore?  Anyway, in case it's still useful it's back online - http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/versions-current.html
[03:41] <Sarvatt> i dunno just having different extensions available can make things take different code paths
[03:41] <bryceh> problem was that apt was exhausting its cache, I guess due to too many sources.  Odd.
[03:41] <Sarvatt> bryceh: it was working a few days ago at least
[03:42] <bryceh> oh ok.  I don't have a way to see how long it's been broken.
[03:43] <Sarvatt> i go to it a lot, thanks so much for fixing it :)
[03:45] <Sarvatt> we're pretty much caught up, just waiting for xserver to be uploaded and the dozens of packages to build against it and such, dont think anyones looking forward to that :)
[03:45] <Sarvatt> most of those green ones in maverick are in dep wait
[03:46] <RAOF> We need to merge -intel from experimental, but I can do that once mesa is done.
[03:47] <Sarvatt> RAOF: http://sarvatt.com/downloads/patches/copy-fb.patch
[03:47] <Sarvatt> (updated copy-fb patch for 2.11)
[03:47] <Sarvatt> its in x-updates
[03:48] <RAOF> Ta.
[03:49] <Sarvatt> been trying to get fedora to upstream it in #intel-gfx since its broken yet again in intel master
[03:49] <Sarvatt> the bgnr stuff needs to be upstreamed in xserver though first
[03:52] <Sarvatt> oh duh fglrx needs the 2.6.34 support patch I'm sure for maverick
[03:53] <RAOF> And then it'll break with the new X server? :)
[03:53] <Sarvatt> heheee
[03:58] <bryceh> I've added a hook to look up the nvidia-graphics-drivers version too
[04:08] <Sarvatt> does it check git repos or ftp or http directories?
[04:09] <Sarvatt> you could use say ftp://download.nvidia.com/XFree86/Linux-x86/latest.txt for the upstream versions
[04:09] <Sarvatt> oh you already do :)
[04:10] <Sarvatt> was going to say if it checked git the nvidia-settings git repo has the newest ones
[04:11] <Sarvatt> http://people.freedesktop.org/~aplattner/nvidia-versions.txt
[04:12] <RAOF> Alright.  Time to head out & collect my new glasses.  Also, luncheon.
[07:13]  * RAOF wonders what decided to eat all his ram _just_ as the build was about to finish.
[07:24] <hyperair> RAOF: a browser is a likely candidate.
[07:24] <hyperair> if i leave deluge's web UI on chromium for more than two days, it can drive my machine into OOM-massacre mode
=== schmidtm_ is now known as schmidtm
[19:59]  * hyperair wails at Sarvatt.
[19:59] <hyperair> it broke again!
[19:59] <hyperair> x-x-v-i, i mean
[19:59]  * hyperair downgrades before cautiously re-enabling gdm
[19:59] <Sarvatt> when did you upgrade
[19:59] <Sarvatt> i disabled page flipping a few days ago
[20:00] <Sarvatt> err disabled the disable page flipping patch! lol
[20:00] <Sarvatt> are you using an old kernel or something?
[20:00] <hyperair> just did
[20:00] <hyperair> 2:2.11.0+git20100526.03bbb4c8-0ubuntu0sarvatt~lucid
[20:00] <Sarvatt> which was the good one?
[20:00] <Sarvatt> that you had before
[20:00] <hyperair> no, my kernel is 2.6.34
[20:00] <Sarvatt> or do you upgrade every day?
[20:02] <Sarvatt> i just want to be sure its page flipping thats screwed up for you because i'm disabling it for everyone just based on you :)
[20:02] <Sarvatt> and not that the drivers broken in other ways after the update which it probably is
[20:03] <hyperair> i upgrade every day.
[20:03] <hyperair> 2:2.11.0+git20100525.b645ec83-0ubuntu0sarvatt~lucid
[20:03] <hyperair> this is the one i'm currently using
[20:04] <Sarvatt> so its not page flipping
[20:04] <Sarvatt> drivers just busted, ok
[20:04] <Sarvatt> updating it :)
[20:05] <Sarvatt> mesa is a mess right now, haven't been able to update it in like a week
[20:05] <hyperair> well come to think of it, that driver went bust on me and blackscreened, which is why i lost my uptime and had to reboot in the first place.
[20:06] <hyperair> which is how i ended up using the new driver.
[20:06] <hyperair> which then proceeded to go bust on me three times in a row with less than half an hour's worth of uptime each round
=== Amaranth_ is now known as Amaranth
[20:08] <Sarvatt> ok ok new one uploading with disable-pageflip.patch :)
[20:11] <Sarvatt> i keep trying to drop it because they are actually trying to fix it
[20:12] <hyperair> i dunno really, it could have been a random error that's not related
[20:12] <hyperair> after all, my uptime was ~3 days
[20:12] <hyperair> compared to the previous half an hour uptimes
[20:13] <Sarvatt> i needed to update to todays git checkout anyway, no biggie :)
[20:13] <hyperair> well if you don't get other complaints you could always enable it and i can just aptitude hold =p
[20:13] <Sarvatt> i locked up 4 times in the past 3 days that i'm sure was  because of it :)
[20:14] <hyperair> ahah
[20:14] <hyperair> lol
[20:14] <Sarvatt> the freezes when i dont have that disable page flipping patch are always the same, pc hard locks with the image still on the screen, not pingable and sysrq doesnt work
[20:15] <hyperair> hmm
[20:15] <hyperair> i see.
[20:15] <hyperair> oh well.
[20:16] <hyperair> ....shit. now i've got a corrupted git repository.
[20:16] <Sarvatt> i lost my /etc  git repo last time :(
[20:17] <hyperair> ouch =\
[20:17] <hyperair> well, i blame ext4
[20:17] <hyperair> nothing on my btrfs volume went missing.
[21:00] <Sarvatt> RAOF: wow you've been busy with mesa huh? I'm scared to ask how much longer this takes to build now :)
[21:07] <Sarvatt> hmm, radeong_dri.so stopped being built in the past few days for some reason it looks like, or it wanted to make my life hard and is called r300_dri.so now
[21:11] <Sarvatt> haha
[21:12] <Sarvatt> always great when 7 days of headaches are caused by a tiny stupid change you made :)
[21:14] <Sarvatt> commented out a line in a confflags-dri section  in mesa's debian/rules, everything after it wasn't getting passed :D only reason i needed all these other build deps was because of that
[21:20] <Sarvatt> llvmpipe is quite annoying to build during development cycles apparently, oprofile is broken every few days when binutils gets updated making llvm-dev uninstallable
[21:26] <Sarvatt> RAOF: are you sure you want to use the --with-dri-searchpath method? for libgl1-mesa-dri-gallium? I need to build what you've pushed to see how its set up but there are things hardcoded to  use /usr/lib/dri only that dont honor it we've found :(
[21:33] <tormod> heya sarvatt!
[21:33] <Sarvatt> heyo tormod! how the heck have ya been man?
[21:34] <tormod> remember keyboard layout went a bit wild sometime when running xserver 1.7? do you know the reason?
[21:34] <tormod> I mean, in xorg-edgers on karmic I think
[21:36] <tormod> there's an upgrade regression that reminds me of that, bug 583037
[21:36] <ubot4> Launchpad bug 583037 in xorg-server (Ubuntu) "arrow-left maps to ISO_Level3_Shift (affects: 1) (heat: 8)" [Undecided,Incomplete] https://launchpad.net/bugs/583037
[21:37] <tormod> bryce, btw your bug robot tagged that bug "hardy" without reason AFAICS
[21:44] <Sarvatt> that looks like a bug that'll go away once he drops the xorg.conf to me :D i have no idea though, i'm really sketchy in the xkb area since I just use english and occasionally japanese and things just work so I haven't had to fix anything to learn more about it :)
[21:46] <bryceh> tormod, well I'm sure it has a reason, but probably not a good one.  I'll investigate.
[21:47] <bryceh> btw, if anyone finds other issues with the automated scripts, file against http://bugs.launchpad.net/arsenal/ and that'll help me keep track of them
[21:48] <bryceh> Current Operating System: Linux nx6125 2.6.34
[21:48] <bryceh> what is nx6125?
[21:49] <Sarvatt> wow llvmpipe *stinks* on a CPU with only SSE2
[21:49] <Sarvatt> compaq laptop model number is my first guess :)
[21:49] <Sarvatt> yea google agrees
[21:49] <bryceh> oh that's the machine name, duh
[21:50] <bryceh> tormod, bug 586547
[21:50] <ubot4> Launchpad bug 586547 in arsenal "Tagged bug as 'hardy' inappropriately (affects: 1)" [Undecided,New] https://launchpad.net/bugs/586547
[21:54] <tormod> bryceh, I have also noticed bug status being changed and then back in one go, like in bug 468413 (after comment 31)
[21:54] <ubot4> Launchpad bug 468413 in xserver-xorg-video-ati (Ubuntu) (and 1 other project) "Radeon module loaded before agpgart (affects: 17) (heat: 108)" [Undecided,Incomplete] https://launchpad.net/bugs/468413
[21:55] <bryceh> tormod, actually in that particular case I did that manually
[21:55] <bryceh> but I have the scripts doing it automatically sometimes too
[21:56] <bryceh> it does this when the bug is in state Incomplete, since once there is a comment it turns into Incomplete (with response), but it needs to be in Incomplete (without response)
[21:56] <bryceh> I don't know of any way to achieve getting it into that state except by moving it to some other state and then back to Incomplete
[21:56] <tormod> oh I see
[21:56] <bryceh> I have a bug about this open against Launchpad
[21:56] <bryceh> but it got marked Low, which means it'll probably not get attention
[21:57] <bryceh> it's easy enough to work around in arsenal so dunno that I'll try to fix it in LP myself
[22:07] <Sarvatt> yay even more headache, nouveau_class.h was removed from libdrm, mesa 7.8.1 needs it still for nouveau, only master works there :D
[22:07] <Sarvatt> so debian-experimental doesn't build
[22:09] <Sarvatt> http://sarvatt.com/downloads/mesa_7.8.1-2_amd64.build
[22:10] <Sarvatt> RAOF must have built it on lucid with libdrm 2.4.18
[22:20] <bjsnider> what's the git command that downloads the current snapshot but doesn't grab the entire history?
[22:24] <hyperair> git clone --depth=1
[22:24] <hyperair> you can change --depth accordingly to control how many levels of history to download
[22:25] <bjsnider> i thought there was an actual command separate from clone
[22:25] <hyperair> no, i don't think there was
[22:26] <hyperair> there's also fetch
[22:26] <hyperair> but that's after cloning
[22:26] <bjsnider> like the "export" command in subversion
[22:26] <hyperair> git archive?
[22:26] <bjsnider> what does that one do?
[22:26] <hyperair> makes a tarball or zip
[22:26] <hyperair> out of the tree
[22:27] <hyperair> you can git archive --prefix=asdf/ HEAD | tar -x
[22:27] <hyperair> which is equivalent to svn export
[22:27] <hyperair> or you could just cd into another directory and GIT_DIR=/path/to/whatever/.git git checkout HEAD -- .
[22:58] <Sarvatt> argh, my bad, nouveau_class.h was removed post 2.4.20. commits after the nouveau_class.h removal were cherry picked into debian, I thought they did a git checkout 
[23:44] <RAOF> Sarvatt: No, debian-experimental doesn't build because I made a typo fixing up a trivial bug.
[23:45] <Sarvatt> well it didn't build for me because I built it against git libdrm, didn't get to whatever the typo was yet :)
[23:46] <RAOF> Ah, right.
[23:49] <RAOF> Sarvatt: What's hardcoded to /usr/lib/dri?
[23:51] <Sarvatt> when X starts it loads whatever's in /usr/lib/dri and would just load swrast if nouveau_dri.so was missing, not sure if you put that into the gallium package or left it in dri
[23:51] <RAOF> Ah.
[23:53] <Sarvatt> like if you install libgl1-mesa-dri-gallium a ton of GLX visuals and GLXFBConfigs go missing compared to when the gallium dri is installed to /usr/lib/dri/, and some people on ati say it causes compiz lockups all over the place
[23:53] <Sarvatt> did you rename all of the gallium drivers btw?
[23:53] <Sarvatt> still haven't finished building it, got distracted testing out libkms stuff
[23:53] <RAOF> No.
[23:54] <Sarvatt> they dont get used without renaming :(
[23:55] <Sarvatt> radeong_dri.so = r300_dri.so, swrastg_dri.so swrast_dri.so