[00:11] <Sarvatt> nice, gnome display properties shows display names instead of just "Unknown" under KMS now
[00:18] <virtuald> i activate changes in display properties no more
[00:18] <virtuald> can't
[00:18] <virtuald> with radeon-kms ppa
[00:19] <virtuald> Method "ApplyConfiguration" with signature "" on interface "org.gnome.SettingsDaemon.XRANDR" doesn't exist
[00:21] <Sarvatt> does xrandr say anything when you run it in terminal?
[00:21] <virtuald> it works normally i think
[00:21] <virtuald> xrandr --output DVI-0 --auto set my resolution to 1600x1200 as it should
[00:23] <Sarvatt> try sudo apt-get update && sudo apt-get instal gnome-desktop on the livecd?
[00:23] <Sarvatt> install rather
[00:24] <Sarvatt> https://lists.ubuntu.com/archives//karmic-changes/2009-June/002780.html
[00:25] <Sarvatt> oh sorry, its gnome-desktop-data
[00:27] <Sarvatt> 10 minutes left on the nouveau KMS livecd upload
[00:27] <virtuald> o.o
[00:59] <Sarvatt> http://sarvatt.com/downloads/xorg-edgers-0.10-nouveaukms-i386.iso
[06:58] <Sarvatt> radeon KMS merged in linux-2.6 :)
[07:48] <crevette> hey Sarvatt 
[07:49] <crevette> thanks for the reply on https://bugs.edge.launchpad.net/bugs/388032 the method I used is described in the wiki KMS page
[08:54] <Sarvatt> heyo crevette, ahh thats you?
[08:54] <crevette> yep
[08:54] <crevette> still up?
[08:56] <Sarvatt> yep, i should have looked at your logs more last night, thats a really common problem right now :D we need that bad-fbdev-thats-mine patch for xserver or else everyone using KMS without an xorg.conf has that problem :(
[08:58] <Sarvatt> actually i'll just put it up for karmic with that patch on edgers, dunno why i didnt do that
[09:01] <crevette> Sarvatt, I don't know why re you refering to jaunty in https://bugs.edge.launchpad.net/ubuntu/+source/xorg/+bug/388032/comments/4
[09:01] <crevette> I'm using karmic
[09:01] <Sarvatt> yeah I apologized for that right after
[09:01] <crevette> :)
[09:01] <crevette> no problemo
[09:02] <crevette> I was just confused after; so can I use the i915.modeset=1 on karmic? becasue I don't want to have it loaded automcatically now, as my laptop is also used by my wife. 
[09:07] <Sarvatt> try adding what I said to /etc/X11/xorg.conf, you might be able to going by your logs.
[09:14] <Sarvatt> any luck?
[09:14] <crevette_> Sarvatt, were you talking to me?
[09:14] <Sarvatt> yeah
[09:14] <crevette_> sorry I've been disconnected, I can test that tonight once I back to home
 try adding what I said to /etc/X11/xorg.conf, you might be able to going by your logs.
[09:15] <Sarvatt> ah alrighty
[09:15] <crevette_> I'm
[09:21] <Sarvatt> oh boy, libdrm-radeon1 added to mesa/drm master now, i'll leave packaging that till tomorrow so I dont screw something up due to lack of sleep :)
[10:14] <tjaalton> yeah, the -9 kernel is a disaster :/
[10:15] <tjaalton> compared to -8 at least
[10:16] <Ng> for what?
[10:18] <tjaalton> Ng: blank screen after a while
[10:18] <tjaalton> intel & kms
[10:19] <Ng> tjaalton: like a dpms off screensaver event you can cancel with input?
[10:21] <tjaalton> Ng: right, but in this case I can't
[10:22] <tjaalton> did you have the same?
[10:25] <Ng> I've had recoverable, erroneous dpms off events since I installed karmic, and I've had a couple of unrecoverable dpms events which co-incided with suspend/resume since yesterday (which happened to be when I rebooted to get -9, but someone else saw very similar OOPses with -8)
[10:25] <Ng> I suspect this might be several bugs looking the same, dpms events shouldn't be related to kernel oopses, I would have thought
[10:47] <Sarvatt> tjaalton: are you on karmic?
[10:47] <tjaalton> Sarvatt: yep
[10:47] <tjaalton> no problems with -8
[10:47] <Sarvatt> gnome-power-manager is horrible about dpms handling right now, there are some fixes upstream not in ours yet
[10:48] <Sarvatt> ah
[10:50] <Sarvatt> lets see what was changed between rc8 and release then, hmm
[10:50] <Ng> yeah we need gpm 2.27.2 afaik
[10:51] <Ng> but I've not wanted to waste seb's time asking about it, I'm quite sure he has a plan
[10:51] <Sarvatt> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c9fb15f60eb517c958dec64dca9357bf62bf2201
[10:52] <Sarvatt> i've got a deb here of gpm 2.27.2 if you just want to test it out https://edge.launchpad.net/~sarvatt/+archive/ppa/+sourcepub/654048/+listing-archive-extra
[10:53] <tjaalton> ok thanks
[10:54] <Ng> aha
[10:54] <Sarvatt> that commit was between -8 and -9, looks like that might be where the problems coming from
[10:58] <Ng> talking of gpm, is anyone else seeing a very default gnome looking icon for it?
[10:59] <tjaalton> the battery with blue on it?
[10:59] <Ng> yeah
[10:59] <Ng> it doesn't look like the icon in jaunty, it looks more like a default gnome icon would
[11:00] <tjaalton> maybe the name got changed
[11:00] <Sarvatt> i saw something about that in the changelogs i think, patch that changed it didnt apply on the new ones or something
[11:00] <Ng> although with the sarvatt package I just installed, the icon is /!\ ;)
[11:00] <Ng> I think because it doesn't understand the state my battery is in. it's not full, but not charging and gpm is telling me it's confused
[11:01] <Sarvatt> did you restart gpm?
[11:03] <Ng> yeap
[11:03] <Sarvatt>   * Drop 04-battery-low-icon-change.patch; it does not apply at all any more,
[11:03] <Sarvatt>     and wasn't sent upstream.  Icons for 2.26 changed a lot, thus this needs
[11:03] <Sarvatt>     some more work anyway. This reopens LP #344886 for Karmic.
[11:04] <Ng> TI:11:03:42	TH:0x1afcd00	FI:gpm-devicekit.c	FN:gpm_devicekit_get_object_icon,161 - nothing matched, falling back to default icon
[11:04] <Sarvatt> thats what i was thinking of, maybe it wasnt all of the icons
[11:04] <Ng> which may be related to:
[11:04] <Ng> TI:11:03:42	TH:0x1afcd00	FI:gpm-devicekit.c	FN:gpm_devicekit_get_object_summary,275 - in an undefined state we are not charging or discharging and the batteries are also not charged
[11:05] <Sarvatt> http://git.gnome.org/cgit/gnome-power-manager/commit/?id=651cd63cfd5e1d47bd9c625a904d57e744284292
[11:05] <Sarvatt> (post 2.27.1 change)
[11:07] <Sarvatt> hopefully they fix that before the 2.27.2 release
[11:13] <Ng> huh
[15:50] <tjaalton> Sarvatt: the new gpm didn't help, it froze just the same
[18:31] <crevette> is there a way to generate a xorg.conf from the running X configuration for someone without xorg.conf?
[18:36] <bryce> jbarnes: https://bugs.freedesktop.org/show_bug.cgi?id=22336 seems fairly serious.  Mind taking a look when you get a chance?  Maybe there's already a patch somewhere for that.
[18:36] <Ng> aha, that looks like it might be a dupe of the one I filed yesterday
[18:37] <jbarnes> bryce: yeah that might be a dupe of the vblank sync bug
[18:37] <Ng> (but I'd dupe mine to mdz's, since he's way better at it than me ;)
[18:37] <jbarnes> when we turn off a display there's a chance we'll hang
[18:38] <jbarnes> yeah looks related
[18:38] <Ng> that would match with what I've seen, all of the hangs have been related to screensaver/dpms type events
[18:46] <halfline> crevette: it puts the xorg.conf in /var/log/Xorg.0.log
[18:48] <crevette> halfline, hey halfline, what are you doing on ubuntu chan ? :thanks for the tips
[18:49] <halfline> SPYING
[18:49] <crevette> tsss
[18:49] <crevette> :)
[18:49] <crevette> actually mclasen is idling on #ubuntu-desktop :)
[18:50]  * halfline sees federico1 here too
[18:50] <crevette> Sarvatt, the fix you adviced in the bug https://bugs.edge.launchpad.net/bugs/388032 fixed the problem
[18:52] <federico1> halfline: hey
[20:05] <bryce> jbarnes: regarding the vblank sync bug, we pulled in 120_fix_dri2_vblank_syncing_segfault.patch (commit b8e360bf2b77d28559d15a7c0f9c766848eb6ced) to fix that one, which iirc listed a backtrace in Xorg.0.log.  This one is a bit different in that it oops in dmesg.  But is there another patch we need for the vblank bug?
[20:10] <bryce> jbarnes: I poked around on fdo but didn't spot an obvious open or closed vblank bug that matches these reports; do you have a bug id or patch I should look at?
[20:13] <tjaalton> Sarvatt thinks it's because of this change that got in after 2.6.30 rc8 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c9fb15f60eb517c958dec64dca9357bf62bf2201
[20:13] <tjaalton> -8 works fine, -9 doesn't
[20:13] <tjaalton> at least on my box
[20:14] <jbarnes> tjaalton: turning of the pipes & plls would cause the vblank counter to stop
[20:14] <jbarnes> so would leave us open to hangs related to vblank waits (as is done in xv and dri2 now)
[20:14] <jbarnes> bryce: lemme see...
[20:15] <tjaalton> jbarnes: ok..
[20:15] <jbarnes> bryce: I was thinking of this one: https://bugs.freedesktop.org/show_bug.cgi?id=22318
[20:16] <bryce> jbarnes: yeah... anholt unduped it though
[20:16] <tjaalton> hmm, maybe I should try to get a dump
[20:17] <jbarnes> bryce: yeah saw that... I'm just guessing it's related to the vblank stuff
[20:17] <jbarnes> it may not be
[20:17] <jbarnes> --- a/src/i830_dri.c
[20:17] <jbarnes> +++ b/src/i830_dri.c
[20:17] <jbarnes> @@ -299,7 +299,7 @@ I830DRI2CopyRegion(DrawablePtr pDraw, RegionPtr pRegion,
[20:17] <jbarnes>      ValidateGC(dst, pGC);
[20:17] <jbarnes>  
[20:17] <jbarnes>      /* Wait for the scanline to be outside the region to be copied */
[20:18] <jbarnes> -    if (pixmap_is_scanout(get_drawable_pixmap(dst))) {
[20:18] <jbarnes> +    if (pixmap_is_scanout(get_drawable_pixmap(dst)) && 0) {
[20:18] <jbarnes>         BoxPtr box;
[20:18] <jbarnes>         BoxRec crtcbox;
[20:18] <jbarnes>         int y1, y2;
[20:18] <jbarnes> if it's a vblank wait causing the hang that patch would prevent it
[20:18] <bryce> jbarnes: btw we now have an apport script to collect all this stuff on freezes - https://bugs.edge.launchpad.net/ubuntu/+source/xorg/+bug/388467 - now we just need something in X to trigger it when the gpu hangs and we'll be golden
[20:18] <jbarnes> yay
[20:19] <bryce> although it seems every time we find a freeze anholt comes up with a unique new way to collect debug info :-P
[20:35] <Ng> is intel-gpu-dump somewhere nicer than a git tree I have to compile? ;)
[20:36] <tjaalton> apt-get away
[20:36] <tjaalton> intel-gpu-tools
[20:36] <Ng> oh duh, I guess command-not-found doesn't know about it yet, I'm too used to that telling me what to install ;)
[20:36] <Ng> ta :)
[20:36] <tjaalton> apt-file works better ;)
[20:37] <Ng> yeah yeah :)
[20:40] <bryce> Ng: yeah merged it into karmic a bit ago.  Still lives in universe fwiw.  Doubt that matters tho.
[21:15] <Sarvatt> heyo tormod, just copyed everything for nouveau KMS over https://edge.launchpad.net/~xorg-edgers/+archive/nouveau
[21:15] <Sarvatt> oops, radeon-kms ppa out of space
[21:16] <tormod> hi Sarvatt! these kernels fill them up fast :)
[21:21] <Sarvatt> could you take a look at this libdrm if you get a chance? https://edge.launchpad.net/~sarvatt/+archive/ati
[21:21] <tormod> what's that kms6 kernel anyway? I was waiting for a mainline snapshot now :)
[21:22] <Sarvatt> want to update libdrm with libdrm-radeon1 on edgers so we can bring apw's kernels in with the drm-intel-next stuff in it without breaking ati for everyone using it since its got kms on default :D
[21:22] <Sarvatt> dunno, he made it 2 days ago, guess its a bit newer than 5
[21:22] <tormod> seems like the kms6 kernel only added intel support, so maybe not so useful for radeon-kms PPA :P
[21:23] <Sarvatt> 5 had the intel stuff too!
[21:25] <tormod> hmm the kms5 and kms6  changelogs look identical
[21:25] <Sarvatt> theres so many new kernel options in .31 right now, wouldnt be surprised if it'll be awhile till we get one of those :)
[21:27] <Sarvatt> i dont know, just saw higher number in his PPA and copied it
[21:27] <tormod> maybe apw changed something without updating the changelog
[21:28] <tormod> it's strange the ppa is full, it has only 5 packages
[21:28] <tormod> guess there is a lot of cruft in the file reop
[21:28] <tormod> *repo
[21:28] <Sarvatt> its the old 400MB kernel that hasnt been deleted yet
[21:29] <Sarvatt> just copied it like 15 minutes ago
[21:29] <tormod> the kms5 ?  there are still some kms1 files also
[21:30] <tormod> you want to put the kms kernel into xorg-edgers?
[21:30] <Sarvatt> hmm, maybe it bugged out when you uploaded that one that failed and it didnt ever remove the one previous to that
[21:33] <Sarvatt> well he's pulling drm-intel-next into it and some people want to use it for that but the whole radeon KMS enabled by default part of it kept me from copying it over, seemed like it might be ok to do it now?
[21:33] <tormod> I have seen that nomodeset does not work for radeon, is there a way to disable KMS?
[21:33] <Sarvatt> seems to be a consensus that KMS/DRI2 radeon-rewrite is a crapload more stable than UMS/DRI1 radeon-rewrite is all :D
[21:33] <crevette> hey Sarvatt
[21:34] <Sarvatt> heyo!
[21:35] <tormod> DRI2 seems slower than DRI1 in many situations, which is not surprising
[21:35] <tormod> first it gets usable, then stable, then they work on performance
[21:36] <tormod> I would like to have the possibility to test out DRI1 in xorg-edgers for still some time
[21:36] <tormod> unless it gets too complicated - intel always complicates things :)
[21:38] <tormod> my biggest problem with DRI2 is that suspend and hibernation is broken
[21:38] <tormod> s/DRI2/kms I guess
[21:38] <tjaalton> bryce: are you going to add the new script to 'xorg', or can you wait until I've finished the merge? :)
[21:38] <Sarvatt> could that be because pm-utils doesnt have the quirk handling for radeon KMS?
[21:39] <tormod> doesn't it? isn't it just no quirks at all?
[21:39] <bryce> tjaalton: I can wait
[21:39] <tjaalton> bryce: won't take long anymore
[21:39] <tormod> (only the cosmetic no-switch-vt quirk)
[21:39] <bryce> tjaalton: in fact we cannot use it until apport supports running as root anyway, and won't actually function until we have the trigger stuff from jesse
[21:40] <tjaalton> bryce: ah, ok
[21:41] <tormod> Sarvatt: would it be an idea to have intel optimized stuff in ~intel-gfx-testing, or is it too many ppas to maintain?
[21:42] <Sarvatt> naaaaah too many darn PPAs as it is and that'd just be for the kernel unless we pulled in all the dri2 swapbuffer stuff
[21:42] <Sarvatt> http://cgit.freedesktop.org/pm-utils/tree/pm/sleep.d/98smart-kernel-video?id=a79d16300c662080caf1775f1cf68f1be4049716
[21:43] <Sarvatt> thats what i was referring to, intel needs special handling there that radeon might as well
[21:45] <Sarvatt> speak of the devil
[21:45] <Sarvatt> http://cvs.fedoraproject.org/viewvc/rpms/pm-utils/F-11/pm-utils-1.2.2.1-radeon-kms.patch?revision=1.1&view=markup
[21:48]  * tormod just had a DRI1 crash again
[21:52] <tormod> Sarvatt: the intel special handling is only for old kernels, right?
[21:53] <Sarvatt> nah apw is pulling drm-intel-next with fixes that take up to 3 weeks sometimes to make it down to the ubuntu kernel into the radeon KMS kernel
[21:53] <tormod> if have_kms succeeds the have_smart_intel is not even run
[21:53] <Sarvatt> #define ABI_XINPUT_VERSION SET_ABI_VERSION(7, 0)
[21:53]  * Sarvatt cries.
[21:55] <tormod> I see. so we definitely want a special kernel for intel.
[22:03] <Sarvatt> 3rd xserver input ABI bump in 2 weeks, think thats my queue to let it settle a bit more before rebuilding all input drivers yet again :D
[22:12] <Sarvatt> anyway no point updating it now, i was only doing it because of the radeom KMS/intel kernel thing but you're right, it would be better to have dri1 in edgers
[22:13] <Sarvatt> intel people were asking me about putting a drm-intel-next kernel in edgers is why i was looking at it
[22:14] <Sarvatt> we've got the intel driver people telling people to use edgers and singing its praises on their blogs now :D
[22:14] <Sarvatt> did you see this? http://cworth.org/intel/driver_stability/
[22:15] <bryce> sweet :-)
[22:16] <jbarnes> yeah I mentioned it in my internal uds status report too
[22:16] <jbarnes> edgers kicks ass
[22:18] <tormod> jbarnes: thanks! but of course the -intel stuff is sarvatt's effort
[23:45] <tjaalton> bryce: ok, xorg merge pushed to git
[23:46] <bryce> yay
[23:46] <tjaalton> I've retained the changes to dexconf, although I don't think they hold much value anymore
[23:48] <tjaalton> the failsafeDexconf needs a surgery too, since all the debconf stuff is gone
[23:49] <tjaalton> jcristau: looks like the bus_id stuff should be ripped out as well?