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