[00:00] <bryce> esr, in several examples of this class of bug, it's shown an edid-fail error.  Not sure what's up with that but possibly a strong clue.
[00:00] <esr> OK.  Running get-edid | parse-edid yields well-formed output...
[00:01] <bryce> esr, traditionally on -intel, these bugs have been caused by the need for monitor quirks.  E.g. edid shows 0mmx0mm physical dimensions, or invert X and Y or mixes up mm with cm
[00:01] <bryce> we quirked a lot of that in X, so in theory some of those could have been lost going to KMS.  However of the bugs I looked into only a few fit that classification.
[00:01] <esr> It got horiz and vert frequencies correct, but generated only one modeline - 1280x1024.
[00:02] <bryce> mm
[00:02] <esr> Sure looks like my guess was correct.
[00:02] <esr> EDID ain't delivering.
[00:02] <bryce> also compare with xrandr --verbose - that has different edid parsing code (same as is used in xserver)
[00:02] <esr> Trying...
[00:03] <esr> Now that's interesting.
[00:03] <bryce> get-edid pretty much bypasses X, so if you see an issue with that, it means something pretty far down the stack is not working right
[00:04] <bryce> ddcprobe is the third tool but that's hardly useful anymore
[00:05] <esr> OK, xrandr verbose generate a boatload of modelines but they top out at 1280x1024 too.
[00:06] <esr> I think out problem is right down at EDID level.
[00:06] <bryce> yeah
[00:06] <bryce> this is why I'm suspecting something at or just above the kernel level
[00:06] <bryce> booting an earlier kernel would rule out the kernel itself
[00:07] <esr> (Note: I maintained the XFree86 Video Timings HOWTO so this stuff isn't exactly alien to me.)
[00:07] <bryce> great
[00:07] <esr> (That's whyn I figured I could help you guys diagnose.)
[00:08] <esr> What do you recommend as a next diagnostic?
[00:08] <bryce> yeah I've so far been unable to reproduce the issue (and tied up with other priorities) so having someone that is clueful is quite helpful
[00:08] <bryce> well, we need to have a better understanding of the edid pipeline.  What components are involved
[00:08] <bryce> and then vary those to identify which component has broken
[00:08] <esr> Agreed.
[00:09] <bryce> so booting a different kernel would probably be the next easiest step
[00:09] <bryce> e.g. if you have the jaunty kernel around
[00:10] <esr> I've got a stock 9.10 freshly installed here. I don't think I still have a 9.04 kernel but let me look at grub.conf 
[00:11] <esr> Er, there is no grub.conf
[00:11] <bryce> you want /boot/grub/menu.lst
[00:11] <esr> Hm, I've got a vmliinuz.old.  That *might* be the 9.04 kernel
[00:12] <kees> fresh 9.10 will use /boot/grub/grub.cfg
[00:12] <kees> you can add the jaunty repositories and install an old kernel by version, too.
[00:12] <esr> I shouldn't have said "fresh"; I upgraded.
[00:13] <bryce>  get-edid uses a VESA VBE 2 interrupt service routine request to read a 
[00:13] <bryce>  128 byte EDID version 1 structure from your graphics card, which retrieves 
[00:13] <bryce>  this information from the monitor via the Data Display Channel (DDC).  
[00:13] <bryce> so what provides the VESA VBE 2 interrupt service ?
[00:13] <esr> That I never learned.
[00:14] <bryce> "real-mode x86 instructions on i386"
[00:14] <bryce> yeah me neither.  I assume it's the kernel but maybe some other lib
[00:14] <bryce> kees, you'd know?
[00:18] <sconklin> bryce: I only have a few minutes.
[00:18] <bryce> heya sconklin
[00:19] <bryce> sconklin, do you have a pointer to that timing patch you mentioned?
[00:19] <sconklin> so where does the EDID coem from? The kernel driver reads it, at least in some cases, maybe all.
[00:19] <bryce> we're trying to figure out why edid seems to be coming through incomplete on karmic compared with jaunty
[00:19] <sconklin> huh, lemme look
[00:20] <sconklin> That patch was supposed to be only for a limited set of intel hardware, and after the last email you sent me about it I'm not sure it's related
[00:21] <bryce> ah ok, hmm.  Still would be worth looking at
[00:21] <esr> My graphics chip is an Intel 965.
[00:21] <esr> Is that in the "limited set"?
[00:22] <bryce> weird, I also have 965 and haven't seen this problem
[00:22] <sconklin> it was supposed to be limited to the arrandale chipsets, but I think that's a lot of common code with the 945, not the 965
[00:23] <esr> lspci sez: 00:02.0 VGA compatible controller: Intel Corporation 82Q963/Q965 Integrated Graphics Controller (rev 02)
[00:23] <bryce> esr, ahh Q965 is a different variant
[00:23] <sconklin> sorry, iron lake
[00:23] <esr> Lovely :-(
[00:23] <bryce> sconklin, oh
[00:24] <sconklin> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-karmic.git;a=commit;h=6a8ea128b38f4f0d3798bb09df4618c50d832c7c
[00:24] <sconklin> that's the one I was thinking of
[00:24] <sconklin> looks like only for new steppings, so I think that's not it
[00:25] <sconklin> sorry
[00:25] <esr> See why I didn't want to just drop aa bug report on the tracker?  I had a feeling it was gonna be this kind of swamp...
[00:27] <sconklin> http://kernel.ubuntu.com/git?p=ubuntu%2Fubuntu-karmic.git&a=search&h=HEAD&st=commit&s=edid some edid-related patches were committed in august
[00:28] <bryce> drm/edid: fixup detailed timings like the X server.
[00:28] <bryce> that sounds interesting
[00:28] <sconklin> exactly what I was looking at - hold on a sec
[00:28] <sconklin> I have arlied's tree here
[00:29] <bryce> whoa
[00:29] <bryce> interesting this is in drivers/gpu/drm/
[00:30] <bryce> so that suggests this patch applies to all hardware not just intel
[00:30] <bryce> however I'm not sure this would explain -nvidia... they kind of do their own thing
[00:30] <bryce> but maybe
[00:30] <bryce> wait no, I bet this is KMS-specific code
[00:31] <esr> I'm willing to test a custom kernel build if you guy can figure out a way to package it so I can install it.
[00:32] <esr> Advantage: For me this is 100% reproducible.  get-edid fails every time.
[00:33] <sconklin> there's another patch that eliminates some entries in the edid based on hsync/vsync==0 or sync beyond blank
[00:34] <sconklin> when it does it emits a DRM_DEBUG_KMS message
[00:35] <sconklin> I can probably get a kernel built if we know what we need to test. I'm supposed to be off for the rest of the week so it may not be prompt
[00:35] <sconklin> I'm still browsing patches.
[00:36] <bryce> sconklin, it would be great to get a kernel ppa with some/all of the edid patches tossed in there
[00:36] <sconklin> bryce: you mean those patches removed?
[00:36] <esr> And then bisect the patch set...
[00:37] <sconklin> when was the first bug opened for this
[00:37] <sconklin> ?
[00:37] <esr> I haven't opened one yet.  Wanted to screen for bogons first ;-)
[00:37] <bryce> sconklin, it's really hard to pinpoint I only noticed the surge of reports at release time
[00:38] <sconklin> ok, that could just be release
[00:38] <bryce> yeah
[00:38] <sconklin> bryce: by the way I'm working on getting a test kernel with the moblin patches to you
[00:39] <bryce> oh I see, we already have these patches in place, so it's a matter of identifying which to disable
[00:39] <sconklin> yeah, let me also pull the latest and see if there are any fixes or reverts
[00:40] <sconklin> Wait, that was drm-next, and may not have all hit linus's tree yet.
[00:40] <bryce> looks like several fixes are in linus' tree on top of this
[00:40] <sconklin> give me a few minutes to get this straight in my head
[00:41] <esr> I'm not going anywhere.
[00:41] <sconklin> haha, neither am I as it turns out
[00:41] <bryce> heh
[00:42] <bryce> sconklin, I'm looking through these upstream changes and they're really basic fixes... even *I* know these are needed to work around known edid problems
[00:42] <sconklin> I haven't seen anything that didn't look basically sane
[00:43] <bryce> wow, I am really surprised they didn't port this from the xserver, all this logic has been known for quite some time
[00:44] <bryce> sconklin, also I bet there are more in the fedora kernel
[00:44] <sconklin> the symptoms are that you get a wrong set or subset of what the monitor should support?
[00:44] <esr> Yup.
[00:44] <bryce> sconklin, that's correct
[00:46] <bryce> esr, can you pastebin your edid someplace?
[00:46] <bryce> I can probably figure out exactly which patch solves your issue
[00:46] <bryce> however this is proving my original suspicion correct - it's not just one bug but a whole bunch of separate ones because the kernel isn't carrying the quirks that the xserver had
[00:47] <esr> bryce Sure, will do
[00:47] <sconklin> that's pretty ugly
[00:47] <bryce> in theory, booting with i915.modeset = 0 (i.e. turning off KMS) would result in fixage
[00:48] <esr> http://pastebin.com/m274c46a1
[00:48] <esr> That what you wanted?
[00:48] <bryce> sconklin, ok so we are going to need pretty much all of these edid patches.  Plus more I think.  There are a lot more quirks I know of, that aren't covered here.
[00:48] <sconklin> it looks like there are no further patches with "edid" in the comment queued for linus - they all landed in the last window
[00:49] <bryce> esr, let's see the xrandr --verbose too
[00:49] <esr> Hold on...
[00:49] <sconklin> bryce: ok, I'd be happy to work with you on making sure they're all in there and upstreamed.
[00:49] <bryce> sconklin, great
[00:50] <sconklin> can it wait until next week? Is the level of breakage high enough to make this urgent?
[00:50] <esr> http://pastebin.com/d1f70504e
[00:50] <esr> xrandr output
[00:51] <esr> I've got the problem solved for *me*...it just looks really bad that this got out in a release.
[00:51] <sconklin> esr: no question about that
[00:51] <bryce> sconklin, well, better to take time to do it right than roll out something that will cause worse problems
[00:52] <esr> Hard for me to tell people Linux is ready for end-users when we fuck up stuff this basic.
[00:52] <bryce> sconklin, I am also going to be gone thurs/fri anyway
[00:52] <esr> I repeat my offer to advance-test the fix.
[00:53] <bryce> esr, well these are highly monitor-specific things
[00:53] <sconklin> bryce: ok, let's make a review of what you know is broken, collect all the upstream patches and those in fedora, and then assemble them and upstream anything that needs to go.
[00:53] <esr> And you know as well as I do that end users don't buy those excuses.
[00:55] <bryce> esr, settle down
[00:55] <bryce> esr, hmm, neither of those showed the monitor model
[00:55] <bryce> by chance is it a 226BW or 225BW?
[00:55] <bryce> or 205BW
[00:56] <sconklin> hahaha my boys are in the next room talking about jailbreaking phones
[00:56] <bryce> esr, technically most users haven't bought anything ;-)
[00:56] <esr> bryce: Not sure how to tell, all that's on the bezel is SyncMaster 1100DF
[00:57] <bryce> esr, ok should say in the Xorg.0.log - mind posting that as well?
[00:57] <bryce> heh, we should have just had you file a bug originally, then all this would be there
[00:57] <sconklin> there are six patches upstream that are obviously edid related, and arrived after karmic
[00:57] <esr> Hold on...
[00:59] <esr> http://pastebin.com/d25e8244d
[00:59] <bryce> feh, I wish there were 3 of me
[01:00] <esr> Looking for monitor subtype.  No match on "BW".
[01:00] <bryce> https://wiki.ubuntu.com/X/Quirks - monitor quirks section
[01:01] <bryce> Samsung SyncMaster's have required quirking before
[01:01] <bryce> one needed quirk_detailed_sync_pp, two needed quirk_prefer_large_60
[01:01] <sconklin> great reference Bryce
[01:01] <bryce> thanks
[01:01] <bryce> sconklin, we need to update it for doing kernel quirks, but it'll give us a starting point
[01:02] <esr> Er. Product id 109?
[01:02] <bryce> btw, for reference all the X quirks are in hw/xfree86/modes/xf86EdidModes.c
[01:02] <bryce> we'll want to ensure all those get ported over to the kernel
[01:02] <bryce> esr, thanks
[01:03] <bryce> esr, ok yours is different.  But I'd wager you need one of these quirks.
[01:03] <esr> I wouldn't be surprised if I did.
[01:04] <esr> quirk_prefer_large sounds suspiciously applicable.
[01:05] <bryce> getting called away to dinner.  bbl
[01:05] <sconklin> later
[01:05] <esr> You guys need anything else from me?
[01:06] <albert23> esr: x log says: Using hsync ranges from config file
[01:06] <sconklin> esr: I don't think so. Thanks
[01:06] <albert23> esr: are you sure you are not blocking high res modes in xorg.conf?
[01:06] <esr> Yeah, that's because I had toi hand-hack the X config to get hight resolution.
[01:07] <esr> When I first saw the problem there was no custom stuff in it at all.
[01:07] <esr> I hand-patched in hsync/vsync and a mode line.  Now it works.
[07:44] <ara> hey morning all! 
=== ripps_ is now known as ripps
[09:30] <ara> nvidia no longer discovers my external monitor (it shows as crt-0), any ideas?
[16:16] <MsMaco> i had a backup of /etc to avoid having to re-set-up everything and just restored it since i reinstalled. this /etc worked on amd64, but my new install is i386. does X get not-happy when this happens? i get kicked back out of X immediately on attempted login
[16:17] <MsMaco> i tried "dpkg-reconfigure xserver-xorg" in case it was something to do with the arch in /etc, but that doesnt seem to have helped any
[16:20] <MsMaco> (intel 965, karmic, dunno what else would be useful)
[16:21] <Ng> what does /var/log/Xorg.0.log say?
[16:22] <MsMaco> failed to load module i810 (module does not exist)
[16:23] <MsMaco> that and soething about virtual kbd are the only EE lines
[16:23] <Ng> the i810 error is fine
[16:23] <MsMaco> it should be -intel not -i810 though, i think
[16:23] <jcristau> it tries both
[16:23] <Ng> :)
[16:24] <jcristau> so the i810 error is expected
[16:24] <MsMaco> ok
[16:24] <Ng> a reasonable test is to log into a console, stop gdm and just run X, see if it's X or the gdm stuff on top of it
[16:25] <jcristau> sharing /etc across archs could make any number of things go wrong though.  not particularly with X.
[16:26] <MsMaco> Ng: startx works. so something's bonkers with kdm
[16:26] <MsMaco> jcristau: yeah i never tried doing it across arch before, just across installs of the same arch because reconfiguring stuff is annoying
[16:27] <MsMaco> thanks for your time. sorry to bug you
[16:41] <kees> bryce: I'd like to copy xorg-server from the security-proposed PPA to -proposed, is that ok by you?  https://edge.launchpad.net/~ubuntu-security-proposed/+archive/ppa/+sourcepub/868253/+listing-archive-extra
[16:50] <jcristau> kees: that reminds me i should apply your patch..
[16:51] <kees> jcristau: heh, yes please!  :)
[16:55] <jcristau> http://git.debian.org/?p=pkg-xorg/xserver/xorg-server.git;a=commit;h=81e2cbb3dea9ca293d22a3dfc56724513350cfbb
[17:08] <bryce> kees, fine by me
[17:08] <kees> bryce: okay
[17:09] <kees> jcristau: \o/  thanks :)
[17:09] <jcristau> kees: thanks for the patch :)
[17:09] <kees> jcristau: np :)
=== Ng__ is now known as Ng
=== wgrant_ is now known as wgrant