[10:13] <jms> why would the display config screen in jaunty not offer resolutions over 1600x1200 on my external (vga) monitor?
[10:14] <RAOF> Could you pastebin the output of "xrandr -q"?
[10:16] <jms> http://paste.debian.net/44661/
[10:22] <RAOF> Ok, so that's why the display config screen won't offer higher resolutions :).
[10:22] <RAOF> It looks like it should only be offering up to 1024x768; is that what it's offering?
[10:25] <jms> it's offering 1024x768
[10:25] <jms> i think it's misinformed
[10:26] <RAOF> Probably.  I'd guess that your monitor doesn't provide correct DDC information.
[10:26] <jms> RAOF: well, yeah, except hwinfo is rather better informed
[10:28] <jms> and so is ddcprobe for that matter
[10:28] <jms> although... hm, interesting
[10:29] <RAOF> Hm?
[10:29] <jms> what's the difference between "timing", "ctiming" and "dtiming"?
[10:29] <RAOF> Do idea.
[10:29] <RAOF> No idea :)
[10:32] <jms> ddcprobe shows a max timing of:
[10:32] <jms> timing: 1024x768@75 Hz (VESA)
[10:32] <jms> but it also shows the correct maximum of:
[10:32] <jms> ctiming: 1600x1200@60
[10:32] <jms> so whatever voodoo nonsense xrandr uses to determine available modes, it ought to be offering the ctiming ones but isn't
[10:33] <RAOF> That'd be a driver issue.
[10:34] <RAOF> You should probably file a bug against the driver.
[10:34] <jms> (II) intel(0): Printing DDC gathered Modelines:
[10:34] <jms> (II) intel(0): Modeline "1600x1200"x0.0  162.00  1600 1664 1856 2160  1200 1201 1204 1250 +hsync +vsync (75.0 kHz)
[10:34] <jms> pretty sure the driver knows about the mode too
[10:36] <jms> hm, Bug #395140
[10:37] <jms> nope, similar but unrelated i think
[10:37] <RAOF> jms: I'd guess that the intel driver is filtering that out; it seems to suggest a refresh rate of 0.0Hz, which I wouldn't be surprised if the driver filtered out as obviously wrong.
[10:38] <hyperair> hmm? external monitor? it usually works for me, very well
[10:39] <tjaalton> what card is it?
[10:40] <tjaalton> jms: ^^
[10:40] <jms> tjaalton: intel
[10:40] <tjaalton> model?
[10:40] <hyperair> intel produces many cards.
[10:40] <jms> 00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
[10:41] <jms> (II) intel(0): Integrated Graphics Chipset: Intel(R) Mobile Intel® GM45 Express Chipset
[10:42] <tjaalton> are you using clone mode?
[10:42] <jms> no
[10:42] <jms> the two displays don't have the same mode. and i'd be happy if vga-only worked as expected really
[10:43] <tjaalton> ok
[10:51] <jms> brb, rebooting
[11:05] <directhex> simultaneously fighting getting a TPM chip working with the 1600x1200 problem
[11:05] <directhex> hence reboots
[15:00] <jg> bryce: ping
[16:43] <AndyB> Hi, i am trying to install this https://edge.launchpad.net/~ubuntu-x-swat/+archive/xserver-no-backfill package so i can use desktop effects with my ati card. I have added the software sources but it does not say what do to next. Any advice?
[21:10] <mdz> bryce, I had a crash this morning which looked very much like bug 343528
[21:11] <mdz> bryce, but I'm quite certain I was running 1:2.2.2-1ubuntu2
[21:13] <bryce> hmm
[21:16] <bryce> mdz, and you see 	pEvdev = (EvdevPtr) 0x0  in the #0 call in your backtrace?
[21:22] <jg> bryce: I "up"graded to koala on this intel laptop: but it is a bit exciting, from the display point of view.  If I try the gnome display preferences program and enable the cmo panel, my screen goes almost entirely black (a few lines at the top seem to survive).
[21:23] <bryce> mdz, weird.  I rebuilt the package and verified the patch is getting applied properly and so on.  To my knowledge, it may still crash since we're papering over what is probably some deeper bug, however it should *not* produce the exact same backtrace.  i'd like to look at your trace if you still have it handy.
[21:24] <jg> bryce: and the X server has crashed at least once while playing around....
[21:24] <bryce> jg, bummer, does the same thing happen if you use only the xrandr tool?  (Gnome's implementation of the Xrandr stuff has proven to be incorrect in the past.)
[21:26] <jg_> bryce: to answer your question, xrandr is just as exciting.  typing xrandr<cr> does the same thing.
[21:26] <bryce> wow
[21:26] <jg_> definitely dramatic.
[21:26] <jg_> downright cool...
[21:26] <bryce> indeed
[21:27] <bryce> something is really bad on your system
[21:27] <bryce> can you post your Xorg.0.log.old somewhere?  (Or file a bug via `ubuntu-bug xorg`)
[21:28] <bryce> I have never yet seen a bug where running xrandr crashes the system.
[21:29] <jg_> bryce: didn't crash the system.
[21:30] <jg_> just screwed up the video on the panel entirely.
[21:30] <bryce> ohhh
[21:30] <jg_> (on the built in panel; all I did was type xrandr, no arguments.
[21:30] <jg_> quite fun, acutally.
[21:33] <jg_> bryce: exactly repeatable; plug the panel in, type xrandr, and the same thing happens again.
[21:36] <mdz> bryce, I couldn't retrace it, because it didn't leave a crash report behind (it is actually the crash which inspired my mail to -devel about apport)
[21:37] <mdz> bryce, the trace from the X server log is at http://pastebin.com/f1424d503
[21:41] <bryce> mdz, ok my guess here is that maybe it's crashing now due to something other than a null pointer
[21:43] <jg> bryce: anything you'd like me to try?
[21:43] <bryce> jg, well if you're game, we do have some debugging tools to use for cases like this, let me grab a link
[21:44] <bryce> jg, https://wiki.ubuntu.com/X/Troubleshooting/Freeze
[21:44] <jg> I'm game....  
[21:44] <bryce> jg, what anholt will want is that batchbuffer dump
[21:44] <jg> bryce: the thing is, it isn't a freeze.
[21:44] <jg> Cursor still responds, and changes....
[21:44] <bryce> jg, changes?
[21:45] <jg> shape changes as to underlying windows.
[21:45] <bryce> hmm
[21:46] <bryce> ok, then maybe it can be treated as a blank screen issue
[21:46] <jg> so the server is still alive; the screen mostly dark, but a few lines on the top clearly come from someplace real (part of a panel).
[21:46] <bryce> https://wiki.ubuntu.com/X/Troubleshooting/BlankScreen - go to the section 'Register Dumps for -intel'
[21:47] <superm1> bryce, regarding bug 341898, what's in 529d1d72 ? did upstream mesa finally acknowledge it's a mesa bug?
[21:47] <bryce> hmm, well what you describe doesn't fall neatly into one of the known failure cases.  But my guess is that upstream would like either the register dumps or the batchbuffer dump
[21:47] <bryce> jg, maybe jbarnes can give some advice here?
[21:48] <jg> yeah, I've not seen anything quite like this bug in > 25 years of messing with video cards....
[21:49] <jg> bryce: I agree the register dumper is the place to start....
[21:49] <bryce> superm1, your comment on the upstream bug indicated that patch fixed it - https://bugs.freedesktop.org/show_bug.cgi?id=20843#c4
[21:50] <superm1> bryce, oh, that only fixed it for -vesa
[21:50] <bryce> superm1, maybe that bug report has become an aggregation of various unrelated issues?
[21:50] <superm1> yeah
[21:50] <bryce> :-(
[21:51] <superm1> well it's two issues that aggregated on there with similar symptoms
[21:51] <superm1> one of them was on -vesa and the other on -ati
[21:51] <jbarnes> jg, bryce: well the probe path is clearly doing *something* bad :)
[21:51] <superm1> the remaining open item was on -ati
[21:51] <jbarnes> jg: what chipset?
[21:51] <jg> jbarnes: Intel 945, IIRC.
[21:51] <bryce> superm1, it really makes it hard to determine the current status on a bug report, when it involves multiple unrelated issues on differing hardware. 
[21:51] <superm1> as soon as we have new mythbuntu disks rolled for karmic (ttf-bitstream-vera is the end of me right now), we've got trunk builds of mythtv with QT4, which I heard don't exhibit these situations
[21:52] <jbarnes> jg: any reg dump differences before & after?
[21:52] <superm1> bryce, i agree.  i'll try to update the status of it and the description after I can have this data point with mythtv 0.22 / QT4
[21:52] <jg> jbarnes: I'm collecting data now.
[21:52] <bryce> superm1, because the bug is targeted to karmic, I'm getting management asking me for status on the bug
[21:53] <bryce> superm1, ah, so it is a QT bug?
[21:55] <superm1> bryce, well that depends on who you talk to :)
[21:55] <superm1> the mesa folks say its a QT bug, the mythtv folks say it's a mesa bug, and QT3 isn't developed anymore
[21:55] <jg> jbarnes: lots of differences...
[21:55] <superm1> i'm really hoping it just goes away with QT4 like I have heard.  if not, then at least QT4 people can weigh in on it too
[21:58] <jbarnes> jg: can you file a bug at fdo with the dumps attached?
[21:58] <jg> bryce, jbarnes: looks like 11 registers differ
[21:58] <jg> jbarnes: sure.
[21:58] <jbarnes> thanks
[21:58] <jbarnes> are they the mode timing regs by chance?
[21:58] <jg> jbarnes: what all do you want exactly?
[21:58] <jbarnes> (H_TOTAL etc)
[21:59] <bryce> superm1, ok thanks
[21:59] <jbarnes> jg: usual stuff, driver kernel x mesa versions
[21:59] <jbarnes> dmesg & x log
[21:59] <jbarnes> reg dumps from before & after
[21:59] <bryce> superm1, it would be wonderful if we could split the bug up into its constituent bugs, but if you think you'll be able to get the bug closed soonish it may not matter
[22:00] <superm1> bryce, yeah as soon as all of ttf-bitstream-vera's rdepends are cleaned up, I can verify it myself whether it's fixed
[22:00] <bryce> superm1, great thanks
[22:00] <jg> jbarnes: they are ADPA DSPACNTR DSPABASE PIPEACONF PIPEACONF PIPEASTAT DPLL_A DSPBSTRIDE DSPBBASE FENCE 3 FENCE 4 and FENCE 5
[22:00] <superm1> if it's not, then splitting it up is probably the next step and getting more updated data etc
[22:00] <bryce> superm1, we also have a newer mesa git build in xorg-edgers that could be tested
[22:01] <jbarnes> jg: oh hm
[22:01] <jg> lots of fun registers....
[22:01] <bryce> jbarnes, pipea bug?
[22:01] <superm1> bryce, okay good to know.  hopefully dont need to go down that route :)
[22:01] <jbarnes> jg: unless the pipe config got messed up or we're pointing at a different base I don't see why those would mess up your panel
[22:01] <jbarnes> bryce: that usually leads to hard hangs
[22:25] <jg> jbarnes, bryce: bug 23429
[22:29] <jcristau> clearly ubottu needs some more brains. :)
[22:30] <bryce> fdo #23429 ?
[22:30] <bryce> freedesktop bug #23429 ?
[23:29] <Ng> bryce: hrm, not sure those anti-random-power-event patches helped any :/
[23:29] <bryce> Ng, no?
[23:30] <bryce> Ng, I'd assumed they were confirmed to fix it
[23:31] <Ng> I updated this morning and got a new xserver core. set all my power management settings back from "never do anything" this afternoon and this evening I was just browsing the web and my laptop suspended
[23:31] <Ng> I wonder if there were associated changes to g-p-m
[23:32] <Ng> I also badly wish that syslog mentioned pm events and what triggered them
[23:34] <bryce> yeah
[23:34] <bryce> that's what I was just thinking myself...  if the fixes aren't fixing it, at least give us better debugging tools
[23:35] <Ng> I've just stabbed g-p-m and will leave it running in a terminal with --verbose, but I'm going to be really really offline for most of the next week
[23:43] <bryce> Ng, ironically my monitors just now blanked ;-)
[23:43] <bryce> (however I've not yet rebooted this box into the "fixed" xserver
[23:43] <bryce> +)
[23:45] <Ng> heh
[23:46] <bryce> Ng, maybe there are multiple bugs that result in the same symptom
[23:46] <bryce> so maybe the patches have helped, but they're just not sufficient to eliminate it entirely
[23:47] <Ng> yeah
[23:47] <Ng> or my laptop just hates my freedom ;)
[23:49] <bryce> Ng, is it screaming, "Put windoze on me pleeaaaseee..."?  :-)
[23:49] <Ng> haha
[23:50] <Ng> I ripped off its vista sticker, so it had better not!