[00:00] :) [00:12] http://sarvatt.com/downloads/patches/radeon-gallium-default-off.patch [00:13] there we go, adds support for enabling using radeong_dri.so instead of r300_dri.so with an xorg.conf option, only allows it on supported ones and defaults off [00:13] tell me when you have everything configured in th PPA. I'll gladly test [00:14] it'll be awhile before i redo mesa packaging.. [00:15] want to get it to the point where i can use debian/ from git, i've got so many changes [00:15] it's almost there, just need to figure out all this egl/opengles crap for 7.9 [00:16] gotta think of the best way to remove dri-gallium on upgrade [00:16] oh guess i could make libgl1-mesa-dri-experimental provide it? [00:18] hope i'm using xf86ReturnOptValBool correct in that patch [00:31] whoops, CHIP_FAMILY_R500 doesn't exist [00:32] oh why did I change that, r500 uses r300 [00:36] dunno where to send the patch to [00:41] heh just noticed that wacom module had 586 in the vermagic, kind of silly the i386 kernels are still compiled for 586 when the rest of maverick went 686 [00:42] going to update the man for ati and try to upstream that patch [01:09] ripps: ok uploaded ati with my patch to edgers, you'll have to move /usr/lib/dri-gallium/r300_dri.so to /usr/lib/dri/radeong_dri.so manually though for now [01:12] ripps: if you could test it sometime that'd be sweet, will send it to the lists if it works - http://sarvatt.com/downloads/patches/radeon-gallium-default-off.patch [01:16] so swrast and i915 gallium drivers are the only problems now [01:17] i915 because it has the same name as the classic mesa driver so cant go in /usr/lib/dri as is [01:28] Sarvatt: sorry, I was out. [01:29] no worries, not in any rush :) trying to figure out mesa [01:29] you want me to test the patch? is that patch for -radeon or mesa [01:31] radeon, it's in xorg-edgers too [01:31] oh, well I'll just install xorg-edgers then [01:31] i just haven't uploaded a mesa with radeong_dri.so in it yet [01:32] Is there an easy way to switch between dri1 and dri2 without rebooting (just restarting Xserver) [01:32] nope gotta disable/enable KMS [01:38] guess i could just go the easy route and throw radeong_dri.so in libgl1-mesa-dri for now and can test by not installing libgl1-mesa-dri-gallium and using the xorg.conf option [01:39] Sarvatt: shouldn't it be possible to reload the radeon module with a different modeset? [01:39] you can try but i'm 99% sure it's not going to work [01:40] Actually, this seems like something switcheroo was designed for [01:43] switcheroo requires vgaarb which requires KMS I believe [01:44] uploading mesa now, can just purge libgl1-mesa-dri-gallium once its done building and try the xorg.conf option [01:45] all of this is going to change in a few weeks, sorry for the trouble while i work out how the heck to do it [01:46] radeong_dri.so is only in libgl1-mesa-dri right now because of how i build crap, once i resync with git it'll change to libgl1-mesa-dri-experimental [01:47] switching from dri1 to dri2 worked. [01:48] let's try the other way around [01:50] are you moving /usr/lib/dri-gallium/r300_dri.so to /usr/lib/dri/radeong_dri.so to test gallium out? [01:52] Xv on Nvidia doesn't seem to be in very good shape in Maverick [01:52] cheese says The error was 'BadMatch (invalid parameter attributes)'. [01:52] (Details: serial 77 error_code 8 request_code 133 minor_code 19) [01:53] Sarvatt: not yet, I'll do that now. [01:54] It seems I'm unable to unload radeon module with kms, even if there is no X running. Is it because the VT's are using it? [01:54] fbcon probably [01:54] its built into the kernel now [01:54] johanbr: you can thank gtk for that one not nvidia :) [01:55] oh :) [01:55] is this related to the csd changes? [01:55] yep [01:56] if cheese worked at all for me i'd test it but it doesn't see my webcam anymore, only crashed before when the webcam was going [01:57] weird... [01:57] for what it's worth, empathy video calls also crash :) [01:57] but I guess cheese not seeing your webcam is probably kernel-related [01:58] probably anything using the webcam at all crashes the same way :) [01:59] Sarvatt: that'll probably have to bring fbcon out of the kernel if Ubuntu ever wants to implement switcheroo. [02:03] johanbr: try XLIB_SKIP_ARGB_VISUALS=1 cheese in a terminal [02:03] yep, that works [02:04] ripps: whys that? i dont think it unloads any modules, just does some sysfs magic to power down the extra one? like i said it requires vgaarb and only works with kms last i checked [02:04] johanbr: thats the magic env variable to make everything work in maverick with this csd stuff :D [02:04] oh, I thought it actually unloaded modules here and there. [02:05] Sarvatt, alright... thank you! :) [02:06] * ripps updated wacom-dkms, uses dkms kernelver instead of uname -r [02:06] i still haven't gone inside to dig out a tablet :( [02:07] johanbr: you can probably just change it to not use Xv for the webcam in system-preferences-multimedia systems selector too [02:08] the error was in Xv for me [02:08] alright [02:08] for some reason "mplayer -vo xv" works, without setting any variables [02:11] its not displaying it in a gtk window :) [02:11] i need to figure out what package provides that multimedia systems selector because i dont have it anymore [02:12] any chance ya could tell me what the actual app is called in the shortcut? [02:18] ahh looks like its a gstreamer package [02:20] dpkg says its in gnome-media which i already had installed, installing a bunch of gstreamer stuff fixed it though.. [02:24] is this gstreamer-properties you're talking about? [02:49] hmm, libv4l-0 is an empty package, only docs in it [02:51] really? seems to contain libraries for me [02:51] such as /usr/lib/libv4l1.so.0 [02:53] oh whoops did dpkg -S libv4l-0 instead of dpkg -L [02:54] darn webcam is dead to the world [02:54] uvcvideo even stopped getting loaded [02:55] hw problem? [02:57] probably [02:58] it was just showing a green screen for a few months there, now its dead to the world :) [03:09] just finished upgrading to xorg-edgers, I see radeong_dri in libgl1-mesa-dri :) [03:12] yeah remove libgl1-mesa-dri-gallium :) [03:12] (for now) [03:12] guess it doesnt matter actually, it wont use r300_dri.so from /usr/lib/dri-gallium if you have the xorg.conf option [03:18] hmm... [03:18] OpenGL renderer string: Mesa DRI R300 (RV350 4150) 20090101 x86/MMX+/3DNow!+/SSE TCL DRI2 [03:18] still not gallium [03:22] RADEON(0): [DRI2] DRI driver: r300 [03:22] Option "Gallium" "True" [03:22] hmm... not loading radeong_dri [03:23] oh wait, do I have to wait for a patched xserver? [03:28] Sarvatt: the gallium patch isn't working. Option "Gallium" "True/False" does nothing. It's still loading only r300_dri [03:31] ok so my patch is wrong, thanks for the heads up ripps :) [03:31] the one you gave me earlier worked... [03:32] yeah its different [03:32] lessee [03:32] can you send me your log? [03:32] there should be other messages [03:33] Sarvatt: http://pastebin.com/0HSAMZds [03:33] whats the ati version? [03:33] i havent looked if it even built [03:34] (WW) RADEON(0): Option "Gallium" is not used [03:34] yeah looks like it failed to build? [03:34] you using ati from today? [03:35] yes [03:35] no it built, hmm [03:35] oh dont tell me [03:35] i friggin patched it with --dry-run [03:37] lol [03:38] new one uploading [03:40] no patch system so i just patched it manually, but i did a dry-run first to see if it applied to current ati since i made the patch on the 0604 checkout and forgot to apply it for real :( [03:41] what? no quilt? [03:41] I can sleep at night without my quilt [03:42] s/can/can't [03:43] would have taken 30 seconds to add that but that was still 10x longer than just doing it by hand :) [03:43] phew though, still a chance the patch might work [03:43] I try to keep good practices practices ;) [03:44] s/package/practices [03:44] okay, it's getting late, I'm constantly mistyping my words [03:52] Holy! The -radeon in xorg-edgers fixed my XV tearing issue! That has been bugging me for ages [03:59] hasnt really been any changes that would fix that in quite some time.. [04:00] sure you arent using r300g? :) [04:00] oh Xv nevermind [04:01] oh could be the xserver update [04:12] or maybe it's because I explicitly set radeon.agpmode=8. So it's actually running at fullspeed [04:12] Although, with my luck that'll me it'll lock my computer up in a few minutes [04:13] are you using textured video? [04:17] Sarvatt: that's the only xv radeon kms has [04:48] new ati should be up there now [04:49] Sarvatt: OpenGL renderer string: Gallium 0.4 on RV350 [04:49] :) [04:50] woohoo [04:50] now to figure out where to send the patch upstream to :) [04:52] wouldn't dri-devel be a good place? [05:02] Well, the compiz crashing issue is back. [05:17] do you have a /usr/lib/dri-gallium/r300_dri.so still? [05:17] or is it just the same dri1 problem you had before? [05:34] Sarvatt: I don't know, but it happens whenever I open gnome-mplayer... [05:34] I don't have a dri-gallium/ [05:35] say anything in ~/.xsession-errors when it happens? [05:36] I don't know, I already disabled gallium and restarted X [05:37] I tried to get a backtrace, but it would always say the previous frame is identical and that the stack is corrupt [05:37] So I'm guessing gallium is screwing something [05:39] gnome-mplayer doesnt even work here [05:40] I've been using a wrapper with gnome-mplayer because it incorrectly uses argb with it's video window, making it translucent with the maverick gtk. [05:41] I know compiz crashes on other programs, but gnome-mplayer is the only one I can get it to crash consistently. You think the argb stuff is what's crashing it? [05:42] s/can/can't [05:45] you should be able to figure out why it's crashing pretty easily, just start compiz from a VT with DISPLAY=:0 compiz --replace >/path/to/log.txt 2>&1 [05:45] i mean is it taking down X or just compiz crashing? [05:46] if its just compiz it'll say why in that log === 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 [06:13] yeah xserver 1.8.99 for sure isn't ready for edgers :) [06:13] way too easy to crash this, i forgot how annoying the sigquit when you press enter deal with plymouth was too [06:15] have to press escape to get off the splash or disable splash entirely to not hang, the xserver always starts on :1 [06:20] not having any luck finding any bugs with compiz on r300g that aren't already fixed, no idea whats up ripps === Bernardo is now known as Bernardo|Away === Bernardo|Away is now known as Bernardo [06:23] oh! we have a GTK_RGBA_DISABLE_APPS env variable now! [06:29] Sarvatt: how do you use GTK_RGBA_DISABLE_APPS? [06:30] is it like a rbga application blacklist? [06:38] yeah === Bernardo is now known as Bernardo|Away [06:38] http://git.gnome.org/browse/gtk+/commit/?h=client-side-decorations&id=68a12cf28c12778942690d58d7d83b86286ece52 [06:38] seperate the app names with : === Bernardo|Away is now known as Bernardo === Bernardo is now known as Bernardo|Away === Bernardo|Away is now known as Bernardo [12:24] what's with the xserver-xorg-video-6 package? [18:54] anyone around that is using edgers on ati? [18:57] tormod looked over my patch and is saying he thinks the if (info->useGallium && !galliumAllowed) { hunk will still show the using gallium message if it's disabled in xorg.conf or on non R300 cards - http://sarvatt.com/downloads/patches/radeon-gallium-default-off.patch === Bernardo is now known as Bernardo|Away === Bernardo|Away is now known as Bernardo === Bernardo is now known as Bernardo|Away [19:24] ah yeah he's right [19:31] RAOF: we going to build mesa in origin/ubuntu against libdrm 2.4.21? want me to add the patch that makes it work if so? === Bernardo|Away is now known as Bernardo [20:04] RAOF: oh nevermind, I see you already added it :) === Bernardo is now known as Bernardo|Away [20:32] darnit, radeon doesn't work headless? [20:33] on the plus side i see my fglrx package in x-updates works fine === Bernardo|Away is now known as Bernardo [20:47] The following NEW packages will be installed: [20:47] baobab gnome-dictionary gnome-screenshot gnome-search-tool gnome-session-common gnome-system-log libprotobuf6 libprotoc6 libx11-xcb1 [20:47] libxcb-dri2-0 linux-headers-2.6.35-2 linux-headers-2.6.35-2-generic linux-image-2.6.35-2-generic nvidia-current nvidia-settings [20:47] on a machine with maverick alpha 1+fglrx installed doing a dist-upgrade [20:48] nvidia-current.. [20:48] you'd have to take provides: xserver-xorg or whatever it is out of the control file [20:50] Provides: ${xviddriver:Provides} [20:51] think i'm going to do that on the PPA, whenever it finally gets a rebuild in maverick it's going to have the same problem :( [20:51] aptitude why nvidia-current [20:51] i fglrx Depends xserver-xorg-core [20:51] p xserver-xorg-core Depends xserver-xorg [20:51] p xserver-xorg Depends xserver-xorg-video-all | xserver-xorg-video-7 [20:51] p nvidia-current Provides xserver-xorg-video-7 [20:53] might as well hack around the busted modaliases too since i cant manage to fix the extraction script, will just install the old ones from the last that worked [21:04] nvidia-current packaging gives me nightmares [21:08] noticed that it ships 2 tls libs and nvidia-installer does a check to see which to use but we skip that and force everyone to use one specific one? [21:21] hopefully theres no magic in jockey checking the abi provided in nvidia or something, package built fine and i uploaded it with hardcoded modaliases and no abi [21:21] blargh. it seems mainline's vanilla kernel suspends fine, and i did a 12-step bisect of the kernel for nothing >_> [21:30] \o/ http://cvs.fedoraproject.org/viewvc/F-13/xorg-x11-server/xserver-1.8-no-connected-outputs.patch?view=markup [22:15] even with the abi provides dropped nvidia-current is getting offered [22:15] The following NEW packages will be installed: [22:15] baobab gnome-dictionary gnome-screenshot gnome-search-tool gnome-session-common gnome-system-log libprotobuf6 libprotoc6 libx11-xcb1 [22:15] libxcb-dri2-0 linux-headers-2.6.35-2 linux-headers-2.6.35-2-generic linux-image-2.6.35-2-generic nvidia-current nvidia-settings [22:16] run the why command again [22:16] can't find a reason now [22:17] i think it might have something to do with fglrx's hard dependency on xserver-xorg-core [22:19] oh i must have screwed up the modaliases install, hmm [22:20] ah nevermind its fine [22:20] i just have the old ones cus i havent upgraded yet [22:28] fglrx-installer should be depending on xserver-xorg instead of xserver-xorg-core though.. [22:30] hah, i like the 1:9-12-1 changelog entry in debian - http://packages.debian.org/changelogs/pool/non-free/f/fglrx-driver/fglrx-driver_10-5-1/changelog [22:41] if i remove ubuntu-x-swat nvidia-current doesn't get installed, but thats only because the one in the archives breaks xserver-xorg-core [22:43] hesitant to actually upgrade so i can test out fixes but i need to test this radeon stuff on that machine :( [22:51] to make it even weirder, dropping ubuntu-x-swat and adding edgers doesn't try to install nvidia-current on dist-upgrade [23:18] Sarvatt: That no-connected-outputs patch is in for 1.9 I believe. [23:18] yeah found it after i fixed up the fedora one to apply :D [23:18] it works good on 1.8.1.901 [23:43] I was just going to wait until 1.9; we're going to get that _anyway_.