[07:49] <superm1> bryce, i'm starting to think it makes sense to include some type of patch that would force fglrx to be the active graphics driver when installed given bulletproofx is entirely shot and you can't use radeon/radeonhd when it's installed..
[07:52] <tjaalton> radeon should work, just not with DRI
[07:53] <superm1> well the majority of people won't know to put NoDRI or what not in xorg.conf tho
[07:53] <bryce> tjaalton: I couldn't get radeon to work at all as long as fglrx was installed
[07:53] <bryce> although I didn't try NoDRI
[07:53] <tjaalton> ok
[07:53] <tjaalton> weird
[07:53] <bryce> I've been spotting various bug reports (including one where the guy deleted libdri.o to get radeonhd working again)
[07:54] <tjaalton> maybe the kernel module is hostile
[07:54] <bryce> maybe
[07:54] <superm1> well radeon and fglrx's kernel modules can't be loaded simultaneously afaik
[07:55] <tjaalton> so radeon doesn't work at all without it then
[07:57] <superm1> oh how about adding modprobe options to radeon to rmmod fglrx 
[07:57] <superm1> if its loaded 
[07:58] <tjaalton> it should be unloaded before the server starts
[07:58] <tjaalton> so where exactly?-)
[08:01] <superm1> gah, that's unfortunate
[08:08] <bryce> one user thinks we should ship two versions of xorg with each ubuntu release, so we can retain backwards compatibility for an older fglrx that supports their r3xx card
[08:10] <superm1> oh that would be fun
[08:10] <bryce> tjaalton: what's the status of the vblank stuff?  I've been seeing some scattered error messages mentioning vblank, is that just a stray warning?
[08:10] <bryce> superm1: I laughed.  They didn't appreciate it though.
[08:11] <superm1> bryce, yeah from their perspective i suppose it looks like "ubuntu is breaking fglrx" rather than "fglrx isn't supporting the latest releases"
[08:12] <tjaalton> bryce: yes, it's disabled by default in the dri driver
[08:13] <tjaalton> we'll all be laughing a year from now ;)
[08:13] <RAOF> When nouveau is the default nvidia driver, and radeon{,hd} supports all cards with 3d?
[08:14] <bryce> RAOF: that'll be an enjoyable day
[08:14] <bryce> RAOF: of course by then everyone will be owning GMA500's and wanting -psb working
[08:16] <tjaalton> RAOF: even I am not that optimistic, meant that r6xx-> should be supported by the dri driver by then ;)
[08:16] <tjaalton> bryce: hehe
[08:17] <bryce> tjaalton: noticed most recently on https://bugs.edge.launchpad.net/ubuntu/jaunty/+source/xorg/+bug/345714/
[08:17] <bryce> Mar 19 22:42:15 laptop kernel: [ 4495.802798] [drm:gm45_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 0
[08:19] <tjaalton> I don't think the message is related, but best ask upstream what they think
[08:20] <tjaalton> related to the crash..
[08:20]  * bryce nods
[08:21] <bryce> I'll shoot it upstream next week.  Just need a bit more info from robbie.
[08:21] <bryce> I hate upstreaming to Intel with incomplete info, they always nitpick
[08:23] <tjaalton> :)
[09:27] <maco> anything change in -intel lately to explain why i cant enable compositing in kwin?
[09:32] <bryce> 2.6.3
[09:33] <maco> er...string to go with those numbers?  "new upstream version" or some such?
[09:33] <bryce> yep
[09:35] <maco> was that in the last month?
[09:35] <tjaalton> this week
[09:35] <maco> oh, im not that far behind then
[09:36] <maco> ya know, on finding out a chunk of functionality just disappeared
[09:36] <tjaalton> which chip?
[09:36] <tjaalton> try with a new user first
[09:37] <maco> i965
[09:37] <maco> Subsystem: 1043:8265
[09:38] <maco> ok
[09:38] <tjaalton> compiz works on mine
[09:38] <tjaalton> so doubt it's the driver at fault
[09:38] <maco> i did try "reset to defaults" on the kwin settings
[09:38] <maco> the message that came up said to check the X config
[09:39] <maco> and the compositing type
[09:40] <tjaalton> sure, "blame someone else" ;)
[09:44] <tjaalton> check the x log if dri is enabled
[09:45] <tjaalton> glxinfo should reveal it too
[09:46] <maco> fails on a new user too
[09:46] <maco> direct rendering: Yes
[09:47] <maco> (i assume thats what you mean?)
[09:47] <tjaalton> yes
[09:47] <maco> i dont have uxa explicitly enabled anymore, but the default is to not enable uxa, isnt it? so that should make no difference?
[09:48] <tjaalton> shouldn't
[09:51] <RAOF> Won't the software renderer _also_ return 'direct rendering: Yes' in Jaunty?
[09:52] <maco> well my xorg.conf currently looks like what dexconf outputs, except that it has a commented out 'Option "AccelMethod" "uxa"' line
[09:52] <RAOF> I suppose that check can pick up partially working, but broken.
[09:52] <bryce> look at OpenGL renderer string to see if software rendering is going on 
[09:53] <tjaalton> maco: just try compiz next :)
[09:53] <maco> darn, people that know i still have gnome installed
[09:53] <maco> :P
[09:55] <tjaalton> I didn't, but apt-get works :)
[09:56] <maco> "desktop effects could not be enabled"
[09:57] <maco> lately all the whining ive done while testing has been of the "good for you gnome-only people, but that totally breaks for people using kde and gnome!" variety
[09:58] <crdlb> my new general-purpose 3d checker is glxinfo | egrep 'direct|software' :)
[09:59] <maco> crdlb: no lines matched for software
[09:59] <tjaalton> try a daily live-cd, if it doesn't work, then I'll believe there's something wrong in the driver :) 
[09:59] <maco> note that the last few days' live cds have been over 700mb...
[10:00] <tjaalton> too bad
[10:00] <crdlb> did you look at the compiz output to see exactly what failed?
[10:00] <maco> no i just tried the appearances window that i hate...will switch consoles
[10:00] <maco> though i should point out: vt switching is broken more weirdly now
[10:00] <tjaalton> compiz --replace in a terminal
[10:01] <maco> from the kdm screen on which the other user was logged in, i cant ctrl+alt+f7 back to here. it just keeps refreshing kdm. cant get from there to a tty either. even when i do it twice in a row
[10:01] <tjaalton> uh
[10:01] <tjaalton> you don't have dri in the second sessionä
[10:02] <tjaalton> -ä
[10:02] <tjaalton> so you need to try it in the primary session
[10:03] <maco> software rasterizer detected: abortingaborting, falling back to /usr/bin/metacity
[10:04] <maco> i thought it just couldnt be in use in two sessions at once
[10:04] <tjaalton> right, what I said :)
[10:04] <crdlb> oops, I forgot -i :)
[10:05] <maco> oh ok well that works...compiz does run
[10:05]  * maco glares at kwin for lying
[10:05] <crdlb> what happened to multi-master drm?
[10:05] <maco> ah! who made the compiz window switcher so busy?!
[10:06] <tjaalton> crdlb: WIP
[10:06] <maco> hrm well then i guess i should go ask in #kubuntu-devel
[10:07] <tjaalton> probably so
[10:07] <crdlb> tjaalton: heh, it just seems like it should have gotten in by now
[10:10] <tjaalton> there's a wikipage on wiki.x.org about it
[10:10] <tjaalton> iirc
[10:15] <maco> ctrl+c'ing compiz didnt bring kwin back. and plasma died. and my keyboard stopped working.  adding "use compiz inside kde" to the list of things i shouldnt do
[10:17] <tjaalton> there's a wikipage on wiki.x.org about it
[10:19] <maco> well i dont think the kbd was the window manager's fault
[10:19] <maco> that happens from time to time
[10:19] <tjaalton> uh
[10:20] <RAOF> Heh.
[10:20] <tjaalton> the previous comment was an error
[10:20] <tjaalton> put the phone in my pocket
[10:20] <maco> ?
[10:20] <maco> the "uh" or the wiki.x.org comment?
[10:21] <tjaalton> wiki
[10:28] <RAOF> OK.  There's a nouveau-kernel-source package that'll build a drm module that's compatible with the driver in Jaunty in bzr.  Tomorrow shall be FFe filing time :/.
[19:35] <maco> wont work
[19:35] <maco> bah wrong channel
[19:35] <maco> my mouse missed
[21:15] <jcristau> tormod: thanks for filing the savage bug.  uploaded to stable-p-u now.
[21:15] <tormod> jcristau: great
[21:16] <tormod> jcristau: btw, why didn't you use debian/patches?
[21:16] <jcristau> git cherry-pick -x is faster :)
[21:16] <jcristau> for stuff that's upstream, i tend to just do that
[21:17] <jcristau> and use debian/patches/ for stuff that either is debian specific or we need to keep longer term
[21:25] <tormod_> oops, solid lock-up on RV410 (compiz+googleearth)
[21:26] <tormod_> jcristau: ok make sense. I wondered if it be helpful to post a debdiff, but figured you would use git anyway.
[21:27] <jcristau> tormod_: yeah with a bug to point the RMs at, it was just a matter of cherry-picking your patch, writing a changelog entry, waiting for an ack, and building the package :)
[21:27] <jcristau> (and the ack came very fast, so.)
[21:28] <tormod_> jcristau: yes, I was impressed how fast that went! I thought SRU on Debian would take months :)
[21:30] <jcristau> tormod_: actually including it in stable will take more time, since that only happens at the point release. but the next one is scheduled for april 4th, so pretty soon too.
[21:31] <tormod_> let's see how long it takes in Ubuntu, with beta freezes and all that ;)
[22:13] <bryce> tormod_: which bug is this?
[22:14] <bryce> tormod_: if it's the pci by default bug, it's already in
[22:15] <tormod_> bryce: no, it's another
[22:15] <tormod_> bryce: just assigned it to you tonight: bug 294899
[22:21] <bryce> tormod_: uploaded
[22:24] <bryce> ok, I'm supposed to be off work today so am going to try to spend the day away from the computer ;-)
[22:24] <tormod_> bryce: cool, as fast as Debian :)
[22:25] <bryce> tormod_: touch base with slangasek on beta freeze permission (I already mentioned it to him) but I think this one should sail through fine
[22:25] <tormod_> bryce: I see. go away from screen
[22:26] <tormod_> bryce: just want to congratulate you (and tjaalton and others) for getting such an up to date xorg stack in Jaunty! rocks