[00:42] <Sarvatt> is it normal that the server requires renderproto 0.11 but only advertises 0.10 support?
[00:42] <Sarvatt>  ... RenderQueryVersion(client-major-version=0, client-minor-version=11) = {major-version=0, minor-version=10}
[00:43] <Sarvatt> #define SERVER_RENDER_MINOR_VERSION             10
[00:45] <Sarvatt> ah i guess it doesn't matter because there were no new requests added in 0.11
[00:47] <jcristau> 0ce42adbf4cff9e7f049d9fc79d588ece5936177 is.. small.
[00:49] <Sarvatt> its missing BlendMaximum, the only other server side one as far as I can see from the protocol
[00:49] <Sarvatt> oh no thats that
[00:50] <Sarvatt> yeah so the server does 0.11, it should be defining it
[00:51] <Sarvatt> everything between min and max are client side pictops, i added the stuff to this tracing program and was wondering why none of it was getting used
[02:06] <Sarvatt> hmm i understand hurd failing, but why is kfreebsd failing with the same error
[02:06] <Sarvatt> os/os_time.c:51:4: error: #error Unsupported OS
[02:07] <Sarvatt> __FreeBSD__ isn't defined there?
[02:07] <Sarvatt> the kfreebsd porting guide says otherwise
[02:08] <jcristau> no __FreeBSD__ is only real freebsd
[02:08] <jcristau> so src/gallium/include/pipe/p_config.h needs adjusting
[02:09] <Sarvatt> http://glibc-bsd.alioth.debian.org/porting/PORTING says otherwise :(
[02:09] <Sarvatt> oh
[02:09] <Sarvatt> so just needs an  || defined(__FreeBSD_kernel__)
[02:09] <Sarvatt> i misread
[02:13] <jcristau> looks like there are 2 places where PIPE_OS_BSD and PIPE_OS_LINUX do different things.  rtasm/rtasm_execmem.c we want the linux path, and util/u_cpu_detect.c we want the bsd path.. :)
[02:17] <Sarvatt> yeah i just checked that too
[02:17] <Sarvatt> reading my mind there :)
[02:18] <Sarvatt> hurd on the other hand..
[02:20] <jcristau> it's already hard to care about kfreebsd.  hurd is on some other planet ;)
[02:21] <Sarvatt> exactly, at least kfreebsd is somewhat trivial to fix :)
[02:23] <Sarvatt> oh yay a fresh batch of Gaetan Nadon updates to make my script rebuild all drivers for trivial updates :)
[09:31] <Bernardo> hi
[17:41] <Sarvatt> man, adding dri2 to xtruss is harder than I thought it'd be. something wacky about DRI2SwapBuffers events
[18:33] <hyperair> Sarvatt: compiz: ../../intel/intel_bufmgr_gem.c:1318: do_bo_emit_reloc: Assertion `!bo_gem->used_as_reloc_target' failed. =O
[18:34] <Sarvatt> with what versions?
[18:34] <hyperair> 7.9.0~git20100520.f4905256-0ubuntu0sarvatt2~lucid
[18:34] <hyperair> that's mesa
[18:34] <Sarvatt> 520?
[18:35] <Sarvatt> thats just mesa-utils
[18:35] <hyperair> er sorry
[18:35] <Sarvatt> that stopped getting updated then
[18:35] <hyperair> 7.9.0+git20100611.3eca311b-0ubuntu0sarvatt~lucid 0
[18:35] <hyperair> this is mesa-common-dev
[18:36] <hyperair> Sarvatt: the 20100610 one didn't have a problem
[18:39] <Sarvatt> oh?
[18:40] <Sarvatt> was going to say it looked like a change on the 7th
[18:40] <hyperair> D=
[18:41] <hyperair> [UPGRADE] libgl1-mesa-dri 7.9.0+git20100610.63834285-0ubuntu0sarvatt~lucid -> 7.9.0+git20100611.3eca311b-0ubuntu0sarvatt~lucid
[18:41] <hyperair> Sarvatt: i've been bisecting my kernel all weekend, so my X has been getting restarted pretty often.
[18:42] <Sarvatt> what about libdrm, i upgraded that at the same time
[18:43] <Sarvatt> i'm not surprised if its a 965+ libdrm problem with whats in there recently - http://cgit.freedesktop.org/mesa/drm/commit/?id=f179137f8f5bf272b79266575121c7a04038290c
[18:43] <hyperair> Sarvatt: nope, no libdrm upgrade recently.
[18:43] <Sarvatt> huh, what version
[18:44] <Sarvatt> dont tell me one from may with the epoch bump problem :)
[18:44] <hyperair> 1:2.4.20+git20100513.a3305b07-0ubuntu0sarvatt~lucid 0
[18:44] <hyperair> loooool
[18:44] <Sarvatt> lol
[18:45] <Sarvatt> i even poked you  on irc about fixing it incase you didn't read the page :)
[18:45] <hyperair> i guess i'll just upgrade libdrm and it'll sort itself out?
[18:45] <Sarvatt> yeah
[18:45] <hyperair> did you?
[18:45] <hyperair> i must have been out
[18:45] <hyperair> or rebooting, as i've been doing a lot recently
[18:45] <hyperair> you running a .35 kernel by any chance?
[18:45] <Sarvatt> sudo apt-get update && sudo apt-get install libdrm-dev/lucid libdrm2/lucid libdrm-nouveau1/lucid libdrm-radeon1/lucid libdrm-intel1/lucid
[18:45] <Sarvatt> yeah i am
[18:46] <Sarvatt> how the heck were you able to use stuff with the old libdrm, haha
[18:46]  * hyperair shrugs
[18:47] <Sarvatt> so yeah that probably accounts for a large number of your crashes :)
[18:47] <Sarvatt> ohh Depends: libc6 (>= 2.4), libdrm-intel1 (>= 2.4.21)
[18:47] <Sarvatt> the epoch satisfies it :(
[18:47] <hyperair> see, this is why you shouldn't use epochs unless absolutely necessary
[18:48] <hyperair> and for unofficial packages, never use epochs >_>
[18:48] <Sarvatt> it wasn't on purpose!
[18:48] <hyperair> hahah
[18:48] <Sarvatt> and only lasted 2 days
[18:48] <hyperair> i had bad timing eh
[18:49] <hyperair> Sarvatt: this wouldn't have any relation to my suspending problem, would it?
[18:50] <Sarvatt> maybe!
[18:50] <hyperair> ..
[18:50] <hyperair> if it was, then i wasted my weekend bisecting.
[18:51] <hyperair> and contributing to local (as opposed to global) warming
[18:51] <Sarvatt> especially if you use compiz :)
[18:51] <hyperair> eh i tried suspending from gdm itself
[18:51] <hyperair> it just hung after switching ttys
[18:54] <hyperair> Sarvatt: yay my compiz has returned!
[18:56] <Sarvatt> try suspending :)
[20:31] <ripps> Is there any way to test radeon gallium in Maverick? I want to test out Unity, but it seems it relies on non_power_of_two textures and that's not supported in default mesa.
[20:36] <Sarvatt> ripps: xorg-edgers?
[20:36] <ripps> Sarvatt: I thought it was removed
[20:37] <Sarvatt> nope
[20:37] <Sarvatt> libgl1-mesa-dri-gallium
[20:37] <Sarvatt> RAOF: awesome, your llvm patch for gallium does fix builds with mesa 7.9 \o/
[20:38] <Sarvatt> funny that its only a problem with non standard llvm include paths
[20:38] <Sarvatt> because it builds fine with llvm-dev in lucid, llvm-2.7-dev puts the includes in some crazy place in /usr/lib/
[20:39] <Sarvatt> ripps: you have an r300 dont you? would you be willing to test a driver out  for me sometime? i'm working on that ati ddx patch to allow changing the dri driver name with an xorg.conf option for gallium
[20:40] <ripps> Sarvatt: okay sure.
[20:40] <Sarvatt> almost got it done, just one hiccup that i'm fudging around trying to fix
[20:40] <ripps> tell me when you get it in a ppa
[20:43] <ripps> Sarvatt: what's the hiccup?
[20:47] <ripps> Is xserver-1.9 in xorg-edgers now?
[20:49] <Sarvatt> just trying to work out the right way to add the check for the option in one spot
[20:49] <Sarvatt> nope
[20:50] <Sarvatt> still not evem branched
[20:51] <ripps> I see you've been experimenting with it in your xorg-testing ppa
[20:55] <ripps> so far 1.8 in Maverick seems to work pretty good. Although, the agp on my mobo seems to give issues. Although, it works better after setting radeon.agpmode=-1. I haven't gotten a system freeze yet
[20:55] <ripps> My suspend hasn't bee working with xserver1.8 and kernel 2.6.34/35. Although, I haven't tried since disabling agpmode
[21:02] <Sarvatt> woohoo I think I got it
[21:02] <Sarvatt> ripps: yeah suspend is broken on radeon for a lot of people with 2.6.35 last i heard from reading on dri-devel
[21:03] <Sarvatt> ripps: are you using xorg-edgers right now?
[21:03] <ripps> Sarvatt: no, I switched to maverick in order to make sure it was working.
[21:03] <ripps> Seems to work about the same as edgers though.
[21:03] <Sarvatt> can i just give you a patch for -ati to try or do ya want it on a PPA?
[21:04] <ripps> Sarvatt: I can do a patch
[21:04] <ripps> If it works, you should put it in a ppa
[21:04] <Sarvatt> mind grabbing -ati off edgers? it'll work with stock maverick stuff
[21:05] <Sarvatt> dont need gallium to test, just want to know what happens when you run it even without gallium
[21:06] <ripps> okay, give me a sec.
[21:06] <Sarvatt> can just sudo ln -s  /usr/lib/dri/r300_dri.so /usr/lib/dri/radeong_dri.so
[21:06] <Sarvatt> oh it'll be a few minutes, still compile testing it with different options
[21:06] <Sarvatt> dget -u -x https://edge.launchpad.net/~xorg-edgers/+archive/ppa/+files/xserver-xorg-video-ati_6.13.99+git20100604.f64bf0de-0ubuntu0sarvatt.dsc
[21:07] <Sarvatt> \o/ compiles with and without the option
[21:08] <ripps> does that include the patch?
[21:09] <ripps> Sarvatt: ^
[21:11] <Sarvatt> no
[21:12] <Sarvatt> thats the source the patch applies to
[21:12] <Sarvatt> http://sarvatt.com/downloads/patches/gallium.patch
[21:12] <Sarvatt> thats the patch
[21:12] <Sarvatt> you need to edit debian/rules to pass --enable-gallium to ./configure too
[21:13] <Sarvatt> play with it a bunch if you dont mind, see how you can break it :)
[21:14] <Sarvatt> it should enable gallium by default on your GPU, which wont work because /usr/lib/dri/radeong_dri.so doesnt exist, i want to know if it falls back to swrast right in that case
[21:15] <Sarvatt> and then if you sudo ln -s  /usr/lib/dri/r300_dri.so /usr/lib/dri/radeong_dri.so it should load the classic driver and say its loading radeong_dri.so in the log and such
[21:15] <ripps> okay, try this first without gallium-dri, than once with?
[21:15] <Sarvatt> you said you werent using edgers?
[21:16] <Sarvatt> no gallium-dri
[21:16] <ripps> I'm not, but I was going to install it... but I'll do it normal maverick
[21:16] <Sarvatt> yeah normal maverick works
[21:16] <Sarvatt> mesa needs changing to work with this, i'm trying to get rid of /usr/lib/dri-gallium
[21:18] <Sarvatt> if this works i'll just modify it to always disable gallium unless Option "Gallium" "True" is in xorg.conf in the device section and ship radeong_dri.so in /usr/lib/dri
[21:20] <ripps> adding it to debian/patches
[21:20] <Sarvatt> dont forget --enable-gallium in the rules
[21:27] <ripps> yep, I got that.
[21:27] <ripps> building now in pbuilder
[21:28] <ripps> btw, has anybody tried my wacom-dkms package? I suppose I'll wait until the next kernel release to see if it updates correctly. Than I'll see if upstream ubuntu/debian would like it.
[21:30] <Sarvatt> i dont have a tablet that needs it, guess i could try it on my tablets that work and see what happens
[21:31] <Sarvatt> ~ripps818/ppa?
[21:31] <Sarvatt> oh wacom
[21:31] <ripps> yesh ripps818/wacom
[21:39] <Sarvatt> installing now
[21:44] <ripps> hmm... why does xserver-xorg-video-ati-dbg depend on mach64-dbg and r128-dbg?
[21:44] <ripps> okay, I've installed the patch ati, hold on while I reset my xserver.
[21:45] <Sarvatt> why are ya installing -ati-dbg instead of -radeon-dbg?
[21:46] <Sarvatt> -ati depends on mach64 and -r128, its just a wrapper that loads the right driver
[21:48] <ripps> Sarvatt: I just did a sudo dpkg -i *.deb
[21:50] <ripps> Okay, I restarted X, and compiz doesn't work
[21:50] <ripps> OpenGL renderer string: Software Rasterizer
[21:50] <ripps> that's what you wanted, right?
[21:51] <ripps> now, if I symlink r300 to radeong, it will load normal mesa, correct?
[21:51] <Sarvatt> yeah, can you try linking r300 to radeong?
[21:51] <Sarvatt> yeah
[21:51]  * ripps is restarting X again
[21:51] <Sarvatt> then if that works try adding Option "Gallium" "False" in your xorg.conf and see if it loads r300_dri.so
[21:52] <Sarvatt> and that'll be all i need to know to go ahead with it
[21:53] <ripps> Sarvatt: okay, I now have compiz back
[21:53] <ripps> OpenGL renderer string: Mesa DRI R300 (RV350 4150) 20090101 x86/MMX+/3DNow!+/SSE TCL DRI2
[21:53] <Sarvatt> pastebin your log?
[21:55] <ripps> http://pastebin.com/Tr0NecVB
[21:56] <ripps> RADEON(0): [DRI2]   DRI driver: radeong
[21:56]  * ripps is restarting X again
[21:57] <Sarvatt> \o/
[21:57] <Sarvatt> oh log message is screwed up, whoops [ 10122.293] (II) RADEON(0): Using Gallium for DRI.(II) RADEON(0): KMS Color Tiling: enabled
[21:59] <ripps> Okay, booted with Gallium=False
[21:59] <ripps> http://pastebin.com/ep3AHcaH
[21:59] <ripps> Compiz is working
[21:59] <Sarvatt> thanks ripps, she works!
[22:00] <Sarvatt> oh wait that didnt work
[22:00] <ripps> oops, I misspelled gallium in xorg.conf, let me try that again
[22:00] <Sarvatt> oh ok
[22:01] <ripps> it worked
[22:01] <ripps> AIGLX: Loaded and initialized /usr/lib/dri/r300_dri.so
[22:02] <Sarvatt> \o/ thanks man!
[22:03] <ripps> does libgl1-mesa-galluim install radeong.dri?
[22:03] <Sarvatt> no
[22:04] <Sarvatt> you need to sudo mv /usr/lib/dri-gallium/r300_dri.so /usr/lib/dri/radeong_dri.so
[22:04] <ripps> are you gonna update it so it installs radeong?
[22:04] <Sarvatt> yeah need to work out the best way to patch the ddx up first
[22:04] <ripps> or are you gonna package galluim by default?
[22:04] <Sarvatt> not sure
[22:04] <ripps> and just leave Galluim=False by default
[22:04] <Sarvatt> making people need the xorg.conf option to use it makes more sense
[22:05] <Sarvatt> if people dont have the gallium dri driver installed they wont be able to use r300 if its default enabled
[22:06] <Sarvatt> adding a check to see if it exists before making that the driverName makes sense but i dont know how to do that
[22:09] <Sarvatt> which do you think i should do?
[22:09] <ripps> I think just package galluim and mesa together, and just have mesa be default. 
[22:10] <Sarvatt> could just ship radeong_dri.so in libgl1-mesa-dri :)
[22:10] <ripps> Nobody will know gallium was added to the package unless they add `Option "Gallium" "True"` to their xorg.conf
[22:10] <ripps> yeah, that's what I was thinking. Seems the easiest method for everybody
[22:11] <Sarvatt> yeah but people using libgl1-mesa-dri-gallium wouldn't know what happened
[22:11] <ripps> don't have to worry about silly package dependecies and symlinks
[22:11] <Sarvatt> well its a piece of cake to just make libgl1-mesa-dri-gallium ship files in /usr/lib/dri since they dont conflict anymore
[22:11] <ripps> Can't you just but an entry on the ppa and on mesa-dri's changelog noting it?
[22:11] <Sarvatt> i need to ditch -gallium anyway since thats not what we're gonna have in ubuntu
[22:12] <Sarvatt> but i cant update edgers with whats in git right now since it only builds with 7.8 :(
[22:12] <ripps> not to mention it screws with compiz
[22:12] <Sarvatt> ripps: oh y eah can you try booting with nomodeset and make sure it works normal?
[22:13] <Sarvatt> would be interested in what happens with gallium enabled in xorg.conf with dri1
[22:13] <ripps> okay, Gallium=True?
[22:13] <Sarvatt> yea
[22:14] <ripps> GRUB_CMDLINE_LINUX="nomodeset"
[22:18] <ripps> Sarvatt: hmmm... it still says I'm using dri2...
[22:18] <ripps> there might be some config somewhere that's overriding my kernel option
[22:19] <Sarvatt> /etc/modprobe.d/radeon-kms.conf exist?
[22:19] <Sarvatt> probably does
[22:19] <Sarvatt> that breaks it
[22:19] <Sarvatt> sudo update-initramfs -u after deleting it
[22:19] <ripps> yeah, it says 'option radeon modeset=1'
[22:19] <Sarvatt> yeah delete it, its not supposed to be there
[22:20] <Sarvatt> didn't get removed on a package upgrade
[22:20] <jcristau> i thought that was removed in the ubuntu package
[22:20] <jcristau> i guess not with edgers
[22:20] <Sarvatt> its an edgers problem, i'm not editing the maintainer scripts to make it remove the right ones
[22:21] <jcristau> yeah.
[22:21] <ripps> yeah, dpkg -S says it came from -radeon
[22:21]  * ripps is rebooting... again
[22:22] <Sarvatt> ok refreshed the patch a little - http://sarvatt.com/downloads/patches/radeon-gallium.patch
[22:22] <Sarvatt> now to make another where its not enabled by default
[22:25] <ripps> okay, got to gdm, but failed when I tried to login. Failsafe Gnome worked though. So compiz probably crashed my X 
[22:27] <Sarvatt> got any log of it?
[22:28] <ripps> OpenGL renderer string: Mesa DRI R300 (RV350 4150) 20090101 AGP 8x x86/MMX+/3DNow!+/SSE TCL
[22:28] <ripps> Xorg.0.log: ripps@ripps-desktop:~$ cat /var/log/Xorg.0.log |pastebinit 
[22:28] <ripps> http://pastebin.com/bKLic0Vd
[22:30] <Sarvatt> i dont see anything wrong there?
[22:32] <ripps> okay, tried to manually load compiz, and metacity -c. Both failed
[22:33] <hyperair> -c?
[22:33] <hyperair> composite?
[22:33] <ripps> hyperair: yeah
[22:33] <Sarvatt> does it work without the xorg.conf?
[22:34] <ripps> Only entry I have in it is Option "Gallium" "True"
[22:34] <ripps> which should just be a symlink to r300, but I'll try
[22:35] <Sarvatt> it doesnt use it unless you're using KMS though, and your log showed it loading r300_dri
[22:36] <Sarvatt> i only added it to the dri2 path since its required for gallium
[22:38] <ripps> Sarvatt: hmm... it's something else. I managed to get sorta working for a sec, but after it had wiped my settings. the moment I reverted my compiz settings back it crashed.
[22:38] <ripps> so one of the plugins is causing a problem
[22:39] <ripps> and when it crashes, it take X with it
[22:39] <hyperair> Sarvatt: if pm-trace says "drm card0: hash matches", which kernel paths should i filter my bisect to?
[22:42] <Sarvatt> hyperair: are you compiling your own kernel?
[22:42] <hyperair> Sarvatt: yes.
[22:42] <Sarvatt> try the ubuntu kernel?
[22:42] <Sarvatt> theres a patch thats most likely fixing your problem
[22:42] <Sarvatt> still not upstream..
[22:42] <hyperair> Sarvatt: really? what patch is that?
[22:43] <Sarvatt> https://patchwork.kernel.org/patch/80474/
[22:44] <hyperair> Sarvatt: it sounds like a different issue.
[22:44] <hyperair> Sarvatt: my issue happens with/without X, and the system hangs while attempting to suspend.
[22:44] <hyperair> it locks itself so hard that sysrq won't work.
[22:44] <ripps> okay, I got metacity -c working, I now have proper terminal transparency
[22:45] <ripps> okay, and default compiz config works
[22:45] <ripps> now.. let's see what plugin crashes it.
[22:50] <Sarvatt> hyperair: wouldn't really hurt to try it before bisecting would it? :) theres tons of other things in there, not like ya cant purge it afterwards
[22:51] <hyperair> Sarvatt: i'm almost done bisecting =\
[22:52] <hyperair> also, my boot time is abysmal
[22:52] <hyperair> it takes 5 minutes to completely boot up
[22:52] <hyperair> ridiculous. utterly ridiculous.
[22:53] <ripps> okay, I figured it out. I was the magnifier plugin. I had every other plugin enabled before I got to that one.
[22:53] <ripps> For some reason it crashes X with radeon dri1
[22:56] <ripps> and suspend works with dri1
[22:57] <ripps> hyperair: your suspend issue sounds like mine
[22:57] <hyperair> ripps: eh?
[22:57] <hyperair> ripps: brb, tell me more when i get back to compile the next kernel =)
[22:58] <Sarvatt> hyperair: ureadahead most likely, the second boot wouldnt be anywhere near that
[22:59] <ripps> hmm... since suspend works wth dri1 radeon, but not dri2. It must be locking with dri2/kms
[23:04] <bryceh> yay, https://edge.launchpad.net/~ubuntu-x-swat/+patches finally works properly
[23:05] <bryceh> bdmurray, thanks!
[23:09] <jcristau> it timed out on me :)
[23:16] <ripps> Man, I wish dri2/kms radeon still had XV Overlay. I've just realized how fast mplayer XV is here in dri1.
[23:42] <Sarvatt> it would be nice if i knew where the heck the right place to add the check is, copy and paste only gets you so far and i've spent all day going over other drivers :)
[23:52] <Sarvatt> oh dang I was making it too complicated, its not that hard at all to do