[00:10] <kees> 2.6.31 totally fails mode detection for me.  :( 
[00:10] <kees> well, where "totally" is "doesn't see the non-VESA modes"
[00:37] <bryce> jbarnes, :-/
[00:46] <tormod> interesting: the new karmic kernel has radeon kms by default
[00:48] <tormod> don't know if it was intentional but certainly brave
[00:52] <bryce> oh wow, really?
[00:53] <tormod> yeah I could not believe it myself and double-checked a couple of times :)
[00:58] <RAOF> I didn't think that our userspace knew how to interact with radeon kms?
[00:58] <tormod> RAOF, it doesn't really so X does its own thing and runs DRI1 etc
[00:59] <RAOF> And X tries it's own modesetting?  That's got to be a recipe for fun!
[00:59] <tormod> it actually works fine here
[01:00] <bryce> man, the .31 upload has borked a lot of X stuff for a lot of people  8-/
[01:00] <tormod> I get old-time slow VT switching to a brand-new hi-res text console
[01:01] <tormod> maybe we need a kernel-edgers team :)
[01:04] <tormod> anyway, I am refreshing the radeon-kms ppa with the corresponding user space
[01:07] <tormod> the good thing about a broken, new-version kernel is that you still have the old kernel intact
[01:10] <bryce> yep
[01:10] <bryce> hmm, good point
[01:34] <tormod> ok radeon-kms ppa is updated, will test (full) kms
[01:40] <tormod> ok radeon-kms ppa works fine, DRI2 and everything. gotta reboot a bit more though now that restarting X means restarting kernel...
[03:56] <bryce> jbarnes, if you're around, could you give me some background on cec9fc6f ("Make KMS set_resource function return TRUE") - I'm trying to understand the scope of bugs it will fix
[03:57] <jbarnes> it allows the edid to be exported in kms mode
[03:57] <bryce> if EDID is not being provided with KMS, that could explain a range of various bugs people have been reporting lately
[03:57] <jbarnes> as a randr property
[03:57] <jbarnes> it was being provided but the server was ignoring it because set_resource was returning an error
[03:57] <bryce> jbarnes, so like, if xrandr is unable to show/set non-vesa resolutions when booted in KMS?
[03:58] <jbarnes> no that's a separate bug
[03:58] <jbarnes> also fixed in git
[03:58] <bryce> ok
[03:59] <jbarnes> that was due to our kernel code not populating a full mode list for panels
[03:59] <jbarnes> like the 2d driver did
[03:59] <jbarnes> ok dinner time :)
[03:59] <bryce> probably I should just pull a new git snapshot... but it'd be interesting to know what bugs are fixed so I don't bother y'all with already-fixed ones
[05:26] <kees> jbarnes: do you have to have the commit handy for the "zomg, where did my mode go?" bug you mentioned with "< jbarnes> no that's a separate bug".
[12:56] <Craigy90> hi everyone
[12:57] <Craigy90> how should I report a bug that affects xorg only when compiz is running?
[14:29]  * hyperair grumbles about usb-storage malfunctioning on 2.6.31
[14:34] <crevette> I didn't manage to have my machine booting with 2.6.31, it kept stuck in the boot process
[15:12] <hyperair> crevette: rc1's broken with 965 machines. you'll need rc2 (when it arrives) or git
[15:21] <crevette> hyperair, thanks for information
[15:43] <hyperair> crevette: np.
[15:56]  * Ng wonders how 2.6.31 is doing on G45s. just ordered a new laptop ;)
[16:03] <hyperair> i wonder =\
[16:03] <hyperair> i'm very interested to see usb-storage actually *work* on .31 though
[16:03] <seb128> I'm interested to see xorg work on .31 ;-)
[16:04] <crevette> seb128, i965 like me IIRC :)
[16:04] <seb128> crevette, indeed
[16:05] <hyperair> seb128: wait until rc2 drops by =)
[20:21] <Sarvatt> so should we just start putting all the radeon kms stuff directly in xorg-edgers now since the kernel has radeon KMS enabled by default? :D
[20:29] <bryce> Sarvatt, yep I think so
[20:30] <bryce> btw I had a phone conversation with AMD this morning about fglrx
[20:31] <bryce> among other things, we need to be cognizant that if the radeon drm module is there, and the user installs fglrx, then something needs to cause that radeon module to not get loaded
[20:31] <bryce> similar problem will exist with -nvidia and -nouveau
[20:31] <superm1> like adding a blacklist file in modprobe.d?
[20:32] <bryce> maybe yeah
[20:32] <bryce> or some flag in initrd?
[20:32] <Sarvatt> yeah i see a problem with drm getting loaded for combined intel/radeon boards and drm needs to be unloaded for fglrx to work too, at least i think that was the problem
[20:33] <superm1> well bcmwl has to do something similar because of b43/ssb
[20:33] <superm1> ssb has a tendency to load from the initrd too, so the  blacklist file is sufficient for it
[20:33] <superm1> with someone with onboard intel and add-in fglrx that's probably a problem Sarvatt 
[20:39] <Sarvatt> i think it was just intel/radeon hybrids with the problem because onboard intel shouldnt get initalized if theres an addon card, but i would have to dig through the bug reports to verify that
[20:43] <Sarvatt> oookay pushing radeon KMS to edgers, just built the new libdrm for radeon-kms and it builds right locally but theres 4 hour queues on the PPAs
[20:43] <Sarvatt> i'm still unsure if master works correctly with KMS now though so going to just copy tormods kms-support branch ati for now
[20:44] <Sarvatt> looks like master works correctly with kms now though..
[20:47] <Sarvatt> asking over in #radeon
[20:48] <bryce> I've emailed apw and pgraner with amd's q's on this.  Also brought up the hybrid intel/ati case we should keep in mind
 Sarvatt: xf96-video-ati master should support kms now
[20:56]  * Sarvatt cheers
[20:56] <Sarvatt> now to wait 4 hours for libdrm to build so i can upgrade mesa and the ddx to support it
[20:57] <bryce> nice
[20:57]  * bryce wonders what to work on today
[21:00] <bryce> oh btw, one other thing amd mentioned, they've noticed how many installation-related bugs get filed and are (finally) interested in ideas for making the procedure more robust.  We're planning on talking about it in more depth in a couple weeks, meanwhile if anyone has good ideas or suggestions, lemme know
[21:00] <bryce> I'm going to mention the glx incompatibilities with -ati and -fglrx, that we've written up in our wiki
[21:05] <superm1> well definitely if tjaalton can come up with a patch that sets fglrx/nvidia as default when it's installed, i think a lot of the "problems" would go away
[21:05] <superm1> (or at least i'd like to think so)
[21:05] <bryce> you mean in xserver?
[21:06] <bryce> I think I own that task actually
[21:10] <Sarvatt> something like http://pastebin.com/m1a4a8ab9 ?
[21:11] <tjaalton> yep
[21:11] <tjaalton> very easy
[21:11] <bryce> does that cover both the with-xorg.conf and no-xorg.conf cases though?
[21:11] <tjaalton> no
[21:11] <tjaalton> only without
[21:15] <superm1> so for the "with" case, can just have the plan for jockey to enable
[21:16] <superm1> so jockey should test if it's there, and modify if so, otherwise plan on doing nothing
[21:16] <bryce> ok
[21:17] <bryce> so unless there's any other tweaks needed, I can pop Sarvatt's patch into the xserver today
[21:17] <bryce> (just working on getting new inkscape merged in at the moment; will do after)
[21:18] <superm1> Sarvatt's patch, meaning what tjaalton was referring to, or something different?
[21:18] <tjaalton> better squeeze nouveau there too
[21:18] <bryce> http://pastebin.com/m1a4a8ab9
[21:18] <Sarvatt> http://pastebin.com/d359ad54
[21:18] <tjaalton> after nvidia
[21:18] <Sarvatt> (had to update it)
[21:19] <Sarvatt> its just fedoras nouveau patch and i added nvidia in, feel free to edit more stuff in :D
[21:19] <tjaalton> Sarvatt: you replaced nouveau with nvidia, add it back :)
[21:20] <Sarvatt> wait a second, forgot some ; :D
[21:21] <Sarvatt> http://pastebin.com/md76e64e
[21:21] <Sarvatt> ?
[21:21] <tjaalton> yep, better
[21:21] <tjaalton> now the same for ati chips
[21:23] <Sarvatt> wait, still wrong lol
[21:23] <Sarvatt> http://pastebin.com/m248b9ae1
[21:23] <tjaalton> heh, right
[21:23] <Sarvatt> added nouveau for 0860 0840 devices
[21:23] <tjaalton> fix the index too :)
[21:23] <Sarvatt> oops
[21:26] <Sarvatt> ok last one http://pastebin.com/m280b5611 you can fix it up from there :D
[21:26] <Sarvatt> i dont even know if that'll work
[21:29] <superm1> so the same thing - does that work for fglrx?
[21:29] <tjaalton> sure
[21:29] <superm1> I thought it needed some extra line to declare depth or something
[21:29] <superm1> some deficiency in fglrx
[21:29] <tjaalton> ah
[21:30] <tjaalton> does it still hold true?
[21:30] <superm1> well throw the fglrx in there, and then we can have a bug for bryce to feed AMD if necessary
[21:30] <bryce> yep
[21:30] <superm1> and hopefully they can sort it out by release
[21:30] <bryce> packaging up sarvatt's patch
[21:30] <bryce> definitely want to stage this one in xorg-edgers for a bit first ;-)
[21:32] <bryce> do we have a lp# open about this?  *browse*
[21:33] <tjaalton> not on the wishlist bugs
[21:35] <bryce> huh, surprising, would have thought there'd be one
[21:35] <tjaalton> there probably was at some point
[21:37] <bryce> I see we have a newer xorg-server in edgers already, so I stuck this into my own ppa for now
[21:37] <bryce> ...and committed to git
[21:39] <bryce> ah apw is on holiday this week, that's why he's not responded to our pings lately ;-)
[21:39] <Sarvatt> it doesnt apply, did you clean it up? some characters got lost cut and pasting it to pastebin
[21:39] <Sarvatt> needs to be @@ -181,7 +181,34 @@ videoPtrToDriverList(struct pci_device *dev,
[21:39] <Sarvatt> @@ got lost
[21:40] <tjaalton> bryce: he released .31-1.14 though ;)
[21:40] <Sarvatt> even if i add it removes it on pastebin, eww
[21:42] <Sarvatt> http://sarvatt.com/downloads/178_nvidia.patch
[21:45] <Sarvatt> added it on edgers too
[21:45] <bryce> Now at patch 178_nvidia_autodetect.patch
[21:45] <bryce> successful.
[21:45] <bryce> great thanks
[21:45] <bryce> I'll update xorg-edgers with this too
[21:47] <Sarvatt> already did :D
[21:49] <Sarvatt> wont apply to master, they added openchrome autodetection after nvidia
[21:50] <tjaalton> 1.6 has it too
[21:50] <Sarvatt> does it?
[21:50] <Sarvatt>         case 0x10de: case 0x12d2:   driverList[0] = "nv";       break;
[21:50] <Sarvatt>         case 0x1106:                driverList[0] = "openchrome"; break;
[21:50] <Sarvatt>         case 0x1163:                driverList[0] = "rendition"; break;
[21:50] <Sarvatt> (on master)
[21:50] <Sarvatt>         case 0x10de: case 0x12d2:   driverList[0] = "nv";       break;
[21:50] <Sarvatt>         case 0x1163:                driverList[0] = "rendition"; break;
[21:51] <Sarvatt> on server 1.6 branch
[21:51] <tjaalton> yes but openchrome is there too
[21:51] <Sarvatt> ah its just moved around
[21:51] <tjaalton> maybe it should be numbered as 104, since I guess it'll be around some time..
[21:54] <tjaalton> hmm, the patch looks weird on cgit: http://git.debian.org/?p=pkg-xorg/xserver/xorg-server.git;a=commitdiff;h=399677d1582d4c6f1c5f4546d31ba7cb1acae746
[21:55] <tjaalton> make that gitweb
[21:55] <Sarvatt> its got an offset applying because of 103_psb adjusting the lines
[21:56] <Sarvatt> yeah silly pastebin mangles it
[21:56] <Sarvatt> http://sarvatt.com/downloads/178_nvidia.patch  is right though
[21:57] <tjaalton> no I mean the characters after every line
[21:58] <tjaalton> end of line
[21:58] <tjaalton> open it with vi :)
[22:04] <tjaalton> bryce: did you release the xserver already?
[22:04] <bryce> not yet
[22:04] <tjaalton> s/karmic/UNRELEASED/ :)
[22:05] <tjaalton> and the patch is the broken one
[22:07] <tjaalton> but I can fix those
[22:07] <bryce> ok updated in git now
[22:07] <tjaalton> heh, quick
[22:07] <bryce> will let Sarvatt update xorg-edgers
[22:07] <bryce> I'm going to hold off on pushing this out live until we've got a couple independent tests done on the patch on xorg-edgers first
[22:07] <tjaalton> sure
[22:07] <Sarvatt> did awhile go and built it locally already too
[22:08] <tjaalton> Sarvatt: how did you come up with this patch?
[22:08] <tjaalton> I mean, how did you do it
[22:08] <tjaalton> I'm just curious why the newline characters are ^M
[22:09] <Sarvatt> its because of  pastebin switching to windows encoding
[22:09] <tjaalton> can't remember what that was called..
[22:09] <tjaalton> ok
[22:09] <tjaalton> but the one on your webpage has those too
[22:09] <bryce> I'm pbuilding the git tree locally as well
[22:09] <Sarvatt> really? what the heck?
[22:09] <tjaalton> yep
[22:10] <Sarvatt> you're right, they're there in vi, i use nano
[22:11] <Sarvatt> just grab the fedora patch, add the 3 lines and adjust the offset :D i was just giving an example asking if thats what you meant to do, assumed you guys wanted to add fglrx to it too
[22:12] <Sarvatt> sorry for the trouble
[22:12] <tjaalton> np
[22:13] <Sarvatt> it still applies and works fine with ^M's there oddly
[22:14] <tjaalton> yep, and diff doesn't show them
[22:14] <Sarvatt> and i dont see the ^M's in nano 
[22:15] <bryce> I've got a dos2unix script that might strip them out
[22:16] <bryce> okay, new inkscape uploaded
[22:17] <Sarvatt> ah i saved the patch from pastebin to debian/patches then fixed the @@ it left out manually
[22:17] <bryce> hmm, not seeing any ^M's in my copy of the patch
[22:17] <tjaalton> dos2unix fixed it
[22:18] <tjaalton> bryce: which editor?
[22:20] <bryce> vim emacs gedit nano
[22:20] <tjaalton> vim shows it here
[22:21] <tjaalton> actually it doesn't, but invoked as vi does
[22:21] <tjaalton> vim tells you it has dos formatting
[22:22] <tjaalton> bryce: I'll renumber it too as 104 because I think it'll be there for a while?
[22:22] <bryce> ok
[22:27] <tjaalton> done
[22:32] <RAOF> Cool!  A new kernel that hopefully won't panic while loading drm.
[22:50] <lesshaste> hi.. do people know about this bug? https://bugs.launchpad.net/ubuntu/+bug/394691
[22:51] <Sarvatt> ok uploading mesa now, as soon as that builds the main xorg-edgers fully supports radeon KMS on karmic with the ubuntu 2.6.31-1 kernel
[23:13] <bryce> what do you think of this approach for adding fglrx support?  http://pastebin.ubuntu.com/208587/
[23:14] <Sarvatt> is there a way to get glxgears to output fps even with the disable patch? i use it as a way to tell if i'm in mutter compiz or metacity so I like it there :D
[23:14] <bryce> divide by 5 in your head?  ;-)
[23:15] <bryce> no, I removed the code entirely, there's no option to reenable it
[23:15] <Sarvatt> true :) or just start using ps to tell like i should, i just like the pretties :)
[23:15] <Sarvatt> i've got a problem enabling compiz in karmic though, for some reason its loading metacity too and that takes up 100% cpu silently
[23:16] <Sarvatt> i have to killall metacity to get the cpu usage back down
[23:16] <bryce> I'm a bit ambiguous on what pci id's specifically that fglrx supports... guess I could email them
[23:16] <Sarvatt> the highest thing in htop is gconf2 taking up around 10% cpu load but my cpus are fully loaded until i kill metacity
[23:18] <bryce> oh I guess it isn't too ambiguous... 0x791E and up
[23:19] <Sarvatt> 793F isnt it?
[23:19] <Sarvatt> looks like 791E is RS690, isnt that r500 based?
[23:20] <Sarvatt> might even be the 9400+ like you put, im not sure
[23:20] <bryce> ok so it is a tad ambiguous ;-)
[23:20] <Sarvatt> (looking at http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/tree/src/ati_pciids_gen.h)
[23:21] <Sarvatt> looking up the fglrx source now, should be in fglrxko_pci_ids.h
[23:21] <apw> bryce just for thur and fri ....
[23:21] <Sarvatt> yeah its 9400+ bryce
[23:21] <apw> but if you need something ... let me know
[23:22] <Sarvatt> lib/modules/fglrx/build_mod/fglrxko_pci_ids.h in the fglrx-installer package
[23:23] <bryce> apw, great thanks, nothing that can't wait until next week.
[23:24] <bryce> aha.  I poked around in the fgrlx-installer source but didn't spot that file
[23:24] <bryce> from that it sounds like 0x9400 and up
[23:24] <Sarvatt> http://sarvatt.com/downloads/fglrxko_pci_ids.h.txt
[23:26] <Sarvatt> they sure are nice to use device id's in order like that unlike nvidia :D i guess rs740 is r500 based as well too
[23:26] <bryce> yeah
[23:27] <bryce> guess they must be renaming them to new generations to clear out the warehouses of the old stock ;-)
[23:27] <Sarvatt> my htpc mobo just died and i'm going to replace it with one with ati integrated so i can play with this stuff too
[23:30] <Sarvatt> looks like i want something with rs690 or rs740 to mess with KMS, i have a pci-e hd2400 to play with otherwise
[23:31] <bryce> ok, fglrx autodetect stuff pushed to git
[23:31] <bryce> tjaalton, named it 105
[23:31] <Sarvatt> will be nice to move away from mediaportal/vista on that thing, i've been running ubuntu in vbox on it for my irc bouncer and other things so i can go linux directly now.
[23:31] <Sarvatt> i'll push that to edgers too
[23:32] <bryce> ok
[23:32] <bryce> same thing; will wait on upload until we get a few positive test results
[23:32] <Sarvatt> there might be a little problem with the nvidia side, at least on git master xorg its not loading the nvidia glx doing it this way
[23:32] <Sarvatt> but i dont think thats a problem on 1.6 branch
[23:34] <Sarvatt> whats wrong with -nvidia creating an xorg.conf like it does when you manually install it from nvidia binary packages?
[23:34] <Sarvatt> yeah looks like the glx problem is git master xserver specific so no worries there
[23:35] <Sarvatt> whats the deal with radeonhd also?
[23:36] <Sarvatt> would someone with a 9400+ ati device id want radeonhd instead of ati?
[23:36] <Sarvatt> as the secondary if fglrx fails in your patch
[23:38] <Sarvatt> or maybe fglrx - radeonhd - ati
[23:39] <Sarvatt> since radeonhd wouldnt always be there and just fail and move on to ati if its not
[23:44] <Sarvatt> also is the driver called ati or radeon?
[23:46] <RAOF> Um... where is libdrm being maintained in Ubuntu now?
[23:47] <Sarvatt> like this for example http://pastebin.ubuntu.com/208624/
[23:47] <RAOF> When I pull libdrm from alioth, the ubuntu branch only seems to go up to 2.4.9-2ubuntu1
[23:47] <Sarvatt> (dont use that diff because i didnt refresh the add/subtract lines)
[23:51] <Sarvatt> it just hasnt been updated on alioth RAOF
[23:51] <bryce> yeah I thought about radeonhd
[23:51] <bryce> nouveau we have plans to move to, but radeonhd not so much
[23:51] <RAOF> Sarvatt: Yes... so what git repository do I pull to get our current branch? :)
[23:51] <bryce> otoh I guess it doesn't hurt to have it in there
[23:51] <RAOF> Or is our current package not in git at all?
[23:51] <Sarvatt> yeah its just not in git at all
[23:52] <RAOF> Oh.
[23:52] <jbarnes> wow fairly hard failure in karmic today
[23:53] <jbarnes> did an update... my machine eventually crashed, and now gconfd won't start so my desktop fails massively
[23:53] <Sarvatt> hmm i havent rebooted since the GDM 2.26 update, you're scaring me about doing it now :D
[23:53] <jbarnes> might be the crash
[23:54] <RAOF> Sarvatt: Eh, gdm works.  Although it did accidentally change my VT to the new gdm screen.
[23:54] <jbarnes> yeah looks like gconf just lost its mind
[23:54] <jbarnes> the update is probably ok
[23:55] <bryce> heya jbarnes, yeah development seems to have suddenly kicked up a notch, lots of breakages getting found
[23:56] <RAOF> So, what are we doing about libdrm?  Shall I just throw another patch onto the the not-in-git package?
[23:56] <Sarvatt> theres a huge bug where starting compiz on my machine makes gconf2 use a ton of cpu (well  only 10% but I get 100% cpu usage until i killall -9 metacity)
[23:56] <bryce> RAOF, sure
[23:56] <Sarvatt> metacity is getting started starting compiz for some reason and it makes things go wonky unless i kill it
[23:58] <Sarvatt> killing it has no affect on the machine so i dont know what purpose it serves starting it is all, but its causing 100% cpu usage running at the same time
[23:59] <Sarvatt> shoot, its restarting automatically too after some time of being killed
[23:59] <Sarvatt> no wonder my battery keeps dying so fast