[00:00] <jbarnes> bryce: yeah lots of bug fixing
[00:00] <Sarvatt> time to go back to not using compiz again, was only enabling it to test memory leak fixes
[00:02] <bryce> Sarvatt, ok -radeonhd added too... in git
[00:08] <superm1> bryce, in that -fglrx patch you were proposing, wouldn't the IDs that don't work, fail anyway even with -ati because of fglrx's libGL being installed?
[00:10] <bryce> yeah but I don't think that's something we can fix in this chunk of code
[00:11] <bryce> superm1, or are you thinking we should let them go ahead and try against -fglrx even if they're using an unsupported chip, just in case it does randomly work?
[00:11] <Sarvatt> yeah at least it will make fglrx be the default in any case, if they have fglrx installed they cant use ati/radeonhd but it has to be there incase they dont have fglrx installed
[00:12] <superm1> bryce, yeah, there is still a chance it would at least start up with very slow 2D due to the failed kernel module load
[00:12] <superm1> (i think)
[00:12] <bryce> *shrug* fine by me, if there are random working cases out there, no point  to force them to fail
[00:12] <bryce> I'll update git, one sec
[00:13] <Sarvatt> right as i was starting to upload it, phew :D
[00:13] <Sarvatt> is there no way to make the fglrx package refuse to install if its not supported?
[00:16] <RAOF> I think the best you could do would be prevent it from configuring, but that'll leave the dpkg in an error state.
[00:16] <Sarvatt> wonder if you can match pci ids in preinst somewhere
[00:18] <jbarnes> ouch
[00:18] <jbarnes> another random crash
[00:19] <bryce> pushed
[00:19] <bryce> er, pushed to git
[00:23] <Sarvatt> putting that on edgers
[00:32] <Sarvatt> going to reboot to see if i have any problems like jbarnes is
[00:33] <Sarvatt> oops guess i better build the new intel ddx first
[00:41] <jbarnes> I think my problems were just a bad config saved_state file
[00:42] <jbarnes> once I removed that things worked again
[00:44] <RAOF> Stupid damn quilt.
[01:00] <Sarvatt> still cant enable compiz via appearance preferences :(
[01:02] <Sarvatt> turned on metacity compositing via gconf-editor, gconf2 using the highest CPU and the old metacity process is still hanging around and cpu load shot up to 100% again
[01:02] <Sarvatt> robert@ubuntu-9{~}:ps aux | grep metacity
[01:02] <Sarvatt> robert    3813  2.9  0.7  21488 11092 ?        S    19:59   0:03 metacity --replace
[01:02] <Sarvatt> robert    4563  0.0  0.4  18868  6640 ?        R    20:01   0:00 metacity
[01:03] <jbarnes> Sarvatt: I had a similar problem the other day
[01:03] <jbarnes> seems to have fixed itself though
[01:04] <Sarvatt> which, multiple window managers running causing 100% cpu load, or not being able to start compiz from appearance preferences?
[01:05] <jbarnes> not starting compiz
[01:05] <bryce> running compiz from the command line sometimes provides useful error messages
[01:05] <Sarvatt> ahh good hope i can figure out why thats happening.. DISPLAY=:0 compiz --replace works
[01:06] <Sarvatt> it works fine from the command line so i cant figure out how to find what it is
[01:06] <Sarvatt> ~/.xsession-errors fills in under a minute from the gnome-power-manager spam
[01:11] <Sarvatt> i think its related to this main metacity process thats hanging around not reliquenshing control to compiz somehow, gotta dig through metacity git to see if there were any fixes in that regard just incase.. even if i do enable compiz (or even just metacity -c --replace) having that old metacity process around is causing 100% cpu load over time, i've seen alot of people getting that problem
[01:13] <Sarvatt> highest visible process using the cpu when its in that state and killing the plain metacity process fixes it is gconf2
[01:14] <Sarvatt> yeah tons of bugs about this https://bugs.edge.launchpad.net/ubuntu/+source/gconf2/+bug/390733
[01:14] <ubottu> Ubuntu bug 390733 in gconf2 "Process gconfd-2 causes cpu overuse and overheat" [Low,Invalid]
[01:19] <Sarvatt> i bet i can start compiz fine after killing that strangling metacity process, lets see
[01:20] <Sarvatt> yep!
[01:20] <Sarvatt> thats the problem
[01:31] <Sarvatt> i cant wait until mutter is packaged, never had good experiences with compiz and installing mutter via jhbuild loses gconf settings options. clutter 3d compositing is great
[01:36] <bryce> ooh just noticed we're upped to 5G now in xorg-edgers :-)
[01:41] <Sarvatt> woohoo!
[01:53] <Sarvatt> eww, tormods getting a segfault starting x with xorg-edgers on ati now
[01:54] <Sarvatt> he has to force vesa
[01:55] <Sarvatt> asking him to try deleting his xorg.conf to see what happens with the new changes but he went to bed
[01:58] <Sarvatt> to be sure the fglrx - radeonhd - ati ordering change even works
[02:00] <Sarvatt> going to need to be babysitting xf86-video-ati and uploading every commit to keep up with it no doubt
[02:02] <Sarvatt> cleaned up and put a new -intel on https://launchpad.net/~ubuntu-x-swat/+archive/x-updates too and am asking people to test it since its a drop in replacement on karmic and edgers uproots all of x, still getting lots of bugs about the resume from dpms off problems in the current karmic intel
[02:03] <RAOF> Sarvatt: Oooh.  And is that likely to _fix_ resume?  That'd be cool :)
[02:04] <RAOF> One nouveau-kernel-source uploaded to edgers that'll build against 2.6.31.
[02:04] <Sarvatt> nah thats a kernel fix that was added *right after* 2.6.31-rc1 most likely, this one was people not able to bring the screen back on when it goes into dpms off mode via screensaver timeout or lid close
[02:04] <RAOF> Let's switch to my nvidia-laptop, and see if the libdrm patches take.
[02:05] <Sarvatt> cheers RAOF! will test that in a bit, been neglecting my nvidia laptop since the blob stopped building post .30
[02:05] <RAOF> Oh.  So it's likely that resume will be fixed sometime in the near kernel updates.
[02:05] <Sarvatt> yep!
[02:06] <Sarvatt> fixed for *alot* of people by the suspend/resume ordering fix right after rc1
[02:06] <RAOF> Should I bother adding a 2.6.30 compat patch?  It'll either build against .30 or .31, but not both without a kver dependant patch.
[02:06] <RAOF> It's probably worth doing, I guess.
[02:06] <Sarvatt> some people with 965+ are still having problems with suspend/resume when compiz is enabled though
[02:07]  * RAOF is having problem with suspend/resume with metacity, too.
[02:07] <Sarvatt> ehh as long as it isnt there for jaunty i wouldnt bother, everyone will be on .31 here soon
[02:07] <RAOF> Right.  That was my thinking.
[02:07] <Sarvatt> not planning on updating jaunty in there to .31 anytime soon since so many things are broken by it
[02:08] <Sarvatt> maybe note in the changelog that its .31 only?
[02:08] <RAOF> Lots of nouveau drm fixes recently.  And maybe soon my nv4B will start X with kms enabled, too :)
[02:08] <Sarvatt> (if you upload again)
[02:08] <RAOF> Possibly.
[02:09] <RAOF> But the .30 compat patch really wouldn't be that hard, I think.  It might be worth it just for completeness.
[02:09] <Sarvatt> oh really? my main problem with it is the complete lack of power savings
[02:09] <Sarvatt> i only get ~1 hour on my 4 hour battery using nouveau kms.. lol
[02:09] <RAOF> Hm.  That's no good!
[02:11] <Sarvatt> does nouveau-kernel-source build on x64? i saw it was i386 only on the ppa but not sure if its just a generic thing that will pull it and build on x64
[02:11] <Sarvatt> guessing it is just generic since its just packaged source that gets built locally but wanted to be sure
[02:12] <RAOF> It's arch:all, so it only gets built on i386.
[02:13] <RAOF> For what are essentially hysterical rasins.
[02:13] <RAOF> But it's installable everywhere, even PPC!  Although it'll fail to build against our ppc headers, of course.
[02:17] <Sarvatt> building a new nouveau ddx now unless you already started on it
[02:22] <Sarvatt> uploaded
[02:40] <RAOF> Be my guest.  There's not much new there ;)
[03:10] <Sarvatt> well shoot, doesnt look like there are any mobos with builtin ati that would run KMS unless I pay more to get older tech, so much for that idea :D rs780 and rs880 run under fglrx
[03:13] <Sarvatt> hmm my ibook g4 early 2004 model has a mobility radeon 9200 that should work
[03:14] <Sarvatt> if only PPAs supported powerpc it'd be alot easier :D
[05:15] <Sarvatt> looks like we need to add an EXPORT_SYMBOL(find_task_by_vpid); to pid.c in fglrx-installer to work on 2.6.31
[05:21] <Sarvatt> but thats in the actual kernel source and i have no idea if its even possible to patch into fglrx-installer
[05:38] <Sarvatt> https://bugs.edge.launchpad.net/bugs/394985  -- its exported in 2.6.30 at least, taking a look at .31 source to see whats changed
[05:38] <ubottu> Ubuntu bug 394985 in fglrx-installer "fglrx: Unknown symbol find_task_by_vpid" [Undecided,New]
[05:38] <Sarvatt> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=17f98dcf6010a1cfd25d179fd0ce77d3dc2685c3
[05:42] <superm1> lovely
[05:49] <Sarvatt> way over my head, maybe bryce might want to bring it up with amd :D just adding the export works for people though apparently even with the change to it
[08:01] <tjaalton> hrm, no RAOF
[08:02] <tjaalton> Sarvatt: you need to apply for pkg-xorg on alioth.debian.org, so you could push the patches yourself ;)
[08:02] <tjaalton> or other changes
[08:03] <tjaalton> libdrm is syncable, but if RAOF had some patch to add, I'd add it on top of the debian version
[10:04] <tjaalton> libdrm now merged in git
[14:22] <Kano> hi, what was the url of the xorg-edgers iso, i dont find it
[18:11] <Sarvatt> eww, so I'm installing ubuntu on an old ibook g4 with a mobility radedon 9200 to play with KMS... then i find out hardy is the last release thats actually installable on an ibook because they stopped including ide-scsi modules for the cdrom to be detected :D waste of 4 cd's working down from karmic to find that out
[19:50] <Sarvatt> wow, i never noticed you guys had mutter already packaged until i just saw gnome-shell get uploaded
[19:51]  * Sarvatt cheers seb128 on!
[20:19] <Sarvatt> woohoo, works wonderfully and i can access the gconf settings unlike under jhbuild :D
[20:21] <Sarvatt> need to figure out how to get the gnome-shell window list up in the top panel, takes a bit too much space on a netbook screen and the top panel isnt hardly used for anything
[21:28] <Sarvatt> kind of sad this 12" ibook thats been in a closet for 5 years is trashing my aspire one in benchmarks :D going to take all day getting it up from 8.04 to karmic and then recompiling everything for KMS. mesa will be fun :)
[21:34]  * joumetal already had fun with blank screen in X and in virtual terminals (r100) :)
[21:35] <Sarvatt> did you try booting with nomodeset added to grub?
[21:36] <Sarvatt> maybe that should be a default option until userspace catches up like it was on intel instead of being all or nothing on :D
[21:37] <joumetal> radeon.modeset=1 gave working X.
[21:39] <Sarvatt> yeah it'd probably be a good idea to make that the default module option for now
[21:40] <Sarvatt> oh wait, modeset=1?
[21:40] <Sarvatt> and it didnt work without that?
[21:40] <joumetal> both using xorg-edgers. err modeset=0
[21:40] <Sarvatt> oh any chance you updated edgers between trying 0 and 1? i updated edgers to radeon KMS support yesterday but it took a few hours for it all to get there
[21:41] <Sarvatt> ahh ok
[21:43] <Sarvatt> the module should definitely default to 0 instead of 1 though 
[21:43] <Sarvatt> have you tried without modeset=0 today? updated stuff again, curious what error you got with edgers with kms enabled
[21:44] <Sarvatt> they told me the ddx master branch should support KMS fully now in #radeon, i dont have anything to test it on yet so i cant see where the errors are
[21:45] <joumetal> yes. default should be 0 now. do i put backtrace or xorg.0.log to pastebin?
[21:45] <Sarvatt> there was a problem with it enabling overlays in KMS stopping it from working that i updated with the fix last night
[21:46] <Sarvatt> xorg.0.log.old from the failed boot should be enough if you have it still
[21:49] <joumetal> http://paste.ubuntu.com/209284
[21:49] <Sarvatt> in drivers/gpu/drm/radeon/radeon_drv.c changing line  85 int radeon_modeset = -1; to int radeon_modeset = 0; should be enough i think?
[21:51] <Sarvatt> yeah joumetal try updating to the new stuff on edgers
[21:51] <Sarvatt> RADEONInitVideo is where the overlay setup was causing problems with KMS in the ddx
[21:53] <Sarvatt> http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=8d2f712eaf1e569fd92bbe2db5aceb43b7b367d1
[21:58] <Sarvatt> suggesting changing the default behavior for the radeon module to be modeset=0 in #ubuntu-kernel
[21:58] <Sarvatt> if they disable it completely from staging then we dont get the headers we need in linux-libc-dev to build KMS support stuff
[22:07] <Sarvatt> if you have any luck with the update let me know, tormod was also having a problem with the same backtrace in the log so it'll be good to know thats fixed :)
[22:07] <Sarvatt> if not i'll switch the ddx over to the kms-support branch so it at least works cus we know that works fine
[22:15] <Sarvatt> eww, 1.5 hours to upgrade from 8.04 - 8.10, this really is going to take all day :D i hope the powerpc kernel is the same as the x86 kernel, thought i read somewhere that they combined them
[22:24] <Sarvatt> joumetal: if you get a chance, let me know if the new DDX fixes things for you and I will revert -ati back to the older kms-support branch that at least works if not
[22:31] <Ng> sweet, 2.6.31-1 KMS works on i965
[23:23] <Sarvatt> wasnt working for you before?
[23:24] <Sarvatt> darn, looks like i'm going to have to compile my own .31 for powerpc to test kms out, none of the karmic ones compiled
[23:46] <Sarvatt> hmm, vinagre is screwing with touchpad sensitivity even after its closed
[23:49] <Sarvatt> probably an xi2 problem