[17:48] <bryce> morning
[17:48] <jbarnes> bryce: hi
[17:49] <jg> hi bryce
[17:50] <Q-FUNK> I'm wondering whether backporting or SRU would be most appropriate to push a more recent -geode into Hardy?
[17:50] <hyperair> backport
[17:50] <hyperair> it isn't in karmic, is it?
[17:51] <jg> bryce: you recommend I try the stable updates for this ATI box I have, and the bleeding edge on Koala to for the Intel?
[17:51] <bryce> jg, yep, how's that worked out?
[17:51] <Q-FUNK> hyperair: it's already in karmic.  
[17:52] <bryce> Q-FUNK, we have an x-updates PPA that is appropriate for such backports
[17:52] <jg> bryce: just starting now; it took a while to convert all those flac's to mp3's yesterday.  I'll try the ati first (not on my main laptop, strangely...).
[17:52] <bryce> Q-FUNK, https://edge.launchpad.net/~ubuntu-x-swat/+archive/x-updates/
[17:52] <hyperair> Q-FUNK: what's the package name?
[17:52] <bryce> hyperair, xserver-xorg-video-geode
[17:53] <hyperair> $ apt-cache policy xserver-xorg-video-geode
[17:53] <hyperair> W: Unable to locate package xserver-xorg-video-geode
[17:53] <Q-FUNK> bryce: GX2 support is just so hopelessly broken in Hardy that we'd pretty much need to push something 2.11.* to Hardy to make -geode usable on LTSP.
[17:53] <bryce> $ apt-cache madison xserver-xorg-video-geode
[17:53] <bryce> xserver-xorg-video-geode |   2.11.3-1 | http://archive.ubuntu.com karmic/main Sources
[17:54] <bryce> Q-FUNK, well good luck with that ;-)
[17:55] <Q-FUNK> I'd rather wait until we have 2.11.4 out, since it changes the acceleration default to XAA for GX, which has been long requested.  
[17:55] <Q-FUNK> we should have 2.11.4 out later this week, at which point I'd push it into Karmic, followed by either SRU or backport into jaunty, intrepid and hardy.
[17:56] <Q-FUNK> bryce: yeah, I remember the last SRU for -geode.  the horror, the horror.
[17:56]  * bryce nods
[17:57] <bryce> one of the many reasons that motivated me to set up x-updates, so we have a place *we* control for such things
[17:57] <Q-FUNK> required too much cherry-picking of individual git commits.  that's why I'm pondering whether backport might be a beter route.
[17:57] <bryce> Q-FUNK, btw you're welcome to join ubuntu-x so you can put updates of -geode into x-updates directly
[17:57] <Q-FUNK> bryce: oh, that sounds good
[17:58] <bryce> I've also reconfigured ubuntu-x to not innundate you with bug mail if you don't want (it's now sent to a mailing list you can opt in/out of)
[17:59] <Q-FUNK> oops! i think I just added myself to the list too.
[17:59] <Q-FUNK> how do I backtrack that ?
[18:01] <Q-FUNK> nice collection of PPA
[18:01] <bryce> there's a check box near your team subscription info
[18:02] <Q-FUNK> ok
[18:02] <Q-FUNK> well, let's see what the moderator says about our application :)
[18:08] <jg> bryce: seems to work ok on the laptop panel.  I've got this external CMO 1680x1200 panel, though.  What do I do to get it to run at that resolution? The usual virtual display subsection added to the screen section?
[18:09] <bryce> jg, yes; the Display configuration applet in System should take care of setting that up for you (YMMV tho)
[18:10] <jg> bryce: didn't seem to detect the higher resolution....
[18:11] <jg> So it didn't configure a wide enough size...
[18:12] <bryce> jg, if you reboot with the monitor attached, it'll detect it properly.  Then use the Display tool to set the Virtual res and you should be good.
[18:12] <bryce> jg, or just shortcut it by writing the xorg.conf yourself if that's more comfortable
[18:13] <jg> bryce: I'm anal: I'll try the reboot, just to see if it works right....
[18:14] <bryce> jg, X for some reason sets things up based on the largest resolution it sees at time of boot, and doesn't resize on the fly.  This is better with KMS, but even in Karmic we don't have KMS for -ati in place yet (proving a bit buggy still).
[18:15] <jg> bryce: even at boot, it doesn't detect the full resolution of the CMO display; the biggest it sees is 1440x900...
[18:16] <Q-FUNK> incoming = ~ubuntu-x-swat/x-updates/ubuntu/
[18:16] <Q-FUNK> correct?
[18:17] <bryce> Q-FUNK, correct
[18:17] <bryce> jg, odd, now that is sounding buggy.
[18:18] <jg> bryce: yup....
[18:18] <bryce> jg, pastebin your Xorg.0.log someplace?
[18:26] <jg> bryce: http://pastebin.com/d25c5dd9b
[18:30] <bryce> ok it's definitely seeing 1680x1050
[18:30] <bryce> oh you need 1680x1200
[18:30] <jg> that's the 
[18:31] <jg> IIRC, the CMO may be x1050...
[18:31] <jg> Let me check the model number
[18:32] <bryce> EDID vendor "AUO", prod id 33044
[18:33] <bryce> AUO has been infamous for putting in invalid EDID into their monitors; we've got a bunch of quirks against it
[18:34] <bryce> but that may not be the issue here
[18:34] <bryce> it looks like it's picking 1280x800 as the highest common resolution between the two monitors
[18:36] <jg> its a A220Z1-G/1
[18:37] <jg> excuse me, a A220Z1-G01
[18:37] <jg> that's 1680x1050
[18:38] <bryce> jg, what's your 'xrandr' output show?  Does it list the 1680x1050 resolution as available on the CMO?
[18:39] <jg> now that I've adjusted the virtual, yes.... and on the gnome applet.  Only at 60hz though.
[18:40] <jg> bryce: which is probably bandwidth topping out...
[18:41] <bryce> #
[18:41] <bryce> (II) RADEON(0): #5: hsize: 1680  vsize 1050  refresh: 60  vid: 179
[18:41] <bryce> 60 may be the best it can do
[18:41] <bryce> does the hardware docs suggest otherwise?
[18:41] <jg> yup.
[18:41] <jg> no.
[18:41] <bryce> ok
[18:42] <jg> the Intel driver seems to deal with it (slightly better, anyway), in terms of id'ing the mode properly.
[18:43] <bryce> so you should be able to force it to what you want via 'xrandr --output VGA-0 --mode 1680x1050 --left-of --output DVI-0 --mode 1280x800'
[18:44] <bryce> or tweak as suits your exact circumstances
[18:45] <bryce> it's possible to hardcode that in your xorg.conf (see https://wiki.ubuntu.com/X/Config) or just put the correct xrandr line in your ~/.xstartup
[18:46] <jg> bryce: it may be the driver is doing "the right thing" as I'm seeing some video artifacts when it is driving at that resolution.  There may not be enough bandwidth in the laptop's driver...
[18:47] <bryce> ah
[18:48] <jg> bryce: the cursor has some funny artifacts.
[18:48] <jg> I betcha it's just barely out of bandwidth....
[18:48] <bryce> jg, hmm, at this point agd5f would be the guy to talk to
[18:48] <bryce> oh wait
[18:48] <bryce> yeah that's an issue others have reported
[18:49] <bryce> I think it's a general bug.  I had it too in jaunty, but it seems to be gone in Karmic fwiw
[18:49] <bryce> we've a newer -ati backport for jaunty available at https://edge.launchpad.net/~ubuntu-x-swat/+archive/x-updates
[18:50] <bryce> I don't know if that version has the fix or not, but should be quite safe to try
[18:52] <jg> bryce: ah, fresh crack....
[18:54] <jg> bryce: should I just try the driver, or go for bleeding edge 7.5 builds?
[18:54] <bryce> I'd try the driver first
[18:55] <bryce> if you want to go more bleeding edge, we've got a git snapshot package at https://edge.launchpad.net/~xorg-edgers/+archive/ppa
[18:55] <jg> bryce: the ati driver?
[18:55] <bryce> yeah
[18:56] <bryce> the 6.12.2 driver has been amply tested and should be reasonably safe
[19:05] <jg> bryce: the cursor still has the funny artifacts.