Bug 11368

Created attachment 10439 [details]
xorg.conf

Created attachment 10440 [details]
Xorg.0.log

This system is probably like the other SFF systems like the mac mini which need a quirk to ignore LVDS.  Can you post the output of lspci -vn for your graphics chip?

I'm not entirely sure what parts of lspci are relevant; here's the whole output
of 'lspci -vn':

00:00.0 0600: 8086:3580 (rev 02)
        Subsystem: 8086:3580
        Flags: bus master, fast devsel, latency 0
        Memory at <unassigned> (32-bit, prefetchable)
        Capabilities: [40] Vendor Specific Information

00:00.1 0880: 8086:3584 (rev 02)
        Subsystem: 8086:3584
        Flags: bus master, fast devsel, latency 0

00:00.3 0880: 8086:3585 (rev 02)
        Subsystem: 8086:3585
        Flags: bus master, fast devsel, latency 0

00:02.0 0300: 8086:3582 (rev 02) (prog-if 00 [VGA])
        Subsystem: 8086:3582
        Flags: bus master, fast devsel, latency 0, IRQ 16
        Memory at d8000000 (32-bit, prefetchable) [size=128M]
        Memory at e8180000 (32-bit, non-prefetchable) [size=512K]
        I/O ports at e300 [size=8]
        Capabilities: [d0] Power Management version 1

00:02.1 0380: 8086:3582 (rev 02)
        Subsystem: 8086:3582
        Flags: bus master, fast devsel, latency 0
        Memory at e0000000 (32-bit, prefetchable) [size=128M]
        Memory at e8100000 (32-bit, non-prefetchable) [size=512K]
        Capabilities: [d0] Power Management version 1

00:1d.0 0c03: 8086:24c2 (rev 02) (prog-if 00 [UHCI])
        Subsystem: 8086:24c2
        Flags: bus master, medium devsel, latency 0, IRQ 16
        I/O ports at e000 [size=32]

00:1d.1 0c03: 8086:24c4 (rev 02) (prog-if 00 [UHCI])
        Subsystem: 8086:24c2
        Flags: bus master, medium devsel, latency 0, IRQ 17
        I/O ports at e100 [size=32]

00:1d.2 0c03: 8086:24c7 (rev 02) (prog-if 00 [UHCI])
        Subsystem: 8086:24c2
        Flags: bus master, medium devsel, latency 0, IRQ 18
        I/O ports at e200 [size=32]

00:1d.7 0c03: 8086:24cd (rev 02) (prog-if 20 [EHCI])
        Subsystem: 8086:24cd
        Flags: bus master, medium devsel, latency 0, IRQ 19
        Memory at e8200000 (32-bit, non-prefetchable) [size=1K]
        Capabilities: [50] Power Management version 2

00:1e.0 0604: 8086:244e (rev 82) (prog-if 00 [Normal decode])
        Flags: bus master, fast devsel, latency 0
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
        I/O behind bridge: 0000d000-0000dfff
        Memory behind bridge: e8000000-e80fffff

00:1f.0 0601: 8086:24c0 (rev 02)
        Flags: bus master, medium devsel, latency 0

00:1f.1 0101: 8086:24cb (rev 02) (prog-if 8a [Master SecP PriP])
        Subsystem: 8086:24c2
        Flags: bus master, medium devsel, latency 0, IRQ 18
        I/O ports at 01f0 [size=8]
        I/O ports at 03f4 [size=1]
        I/O ports at 0170 [size=8]
        I/O ports at 0374 [size=1]
        I/O ports at f000 [size=16]
        Memory at 10000000 (32-bit, non-prefetchable) [size=1K]

00:1f.3 0c05: 8086:24c3 (rev 02)
        Subsystem: 8086:24c2
        Flags: medium devsel, IRQ 22
        I/O ports at 0500 [size=32]

00:1f.5 0401: 8086:24c5 (rev 02)
        Subsystem: 16f3:4720
        Flags: bus master, medium devsel, latency 0, IRQ 22
        I/O ports at e500 [size=256]
        I/O ports at e600 [size=64]
        Memory at e8201000 (32-bit, non-prefetchable) [size=512]
        Memory at e8202000 (32-bit, non-prefetchable) [size=256]
        Capabilities: [50] Power Management version 2

01:03.0 0c00: 11c1:5811 (rev 61) (prog-if 10 [OHCI])
        Subsystem: 6010:1100
        Flags: bus master, medium devsel, latency 32, IRQ 21
        Memory at e8000000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: [44] Power Management version 2

01:08.0 0200: 8086:1039 (rev 82)
        Subsystem: 8086:1039
        Flags: bus master, medium devsel, latency 32, IRQ 20
        Memory at e8001000 (32-bit, non-prefetchable) [size=4K]
        I/O ports at d000 [size=64]
        Capabilities: [dc] Power Management version 2

could you please try the latest driver to see if this bug still exist?

Is driver version 2.1.1-4 from Debian sid an acceptable definition of "latest"?

Sounds like we'll need to quirk around LVDS detection this system.

to do a quirk, we seems need a dmidecode info for this machine. Could you please run that command and attach the output here? thanks.

Created attachment 12375 [details]
Output of dmidecode on my system

Okay, it's now attached.

One note -- my question above about whether 2.1.1-4 is recent enough was serious; it wasn't a sarcastic way of saying that that was the version I was running.  I've downgraded to the old i810 driver, since there are some other bugs in the new intel driver (especially #12393) which make it painful for me to upgrade, but I can upgrade temporarily to check a new driver if this issue is believed fixed in a new version.

Thanks.

Yes, 2.1.1-4 is an acceptable new version.

This bug still exists in Debian version 2.1.1-4 of the driver, yes.  I can post the log with the new driver version if that will help at all.

hong, are you able to help do the quirk using the dmidecode output?

Created attachment 12650 [details]
Log from driver version 2.2.0-1

With driver version 2.2.0-1 from Debian sid, this seems to have gotten worse.  I can now no longer switch to 1280x1024 resolution using xrandr (it says, "Size 1280x1024 not found in available modes"), so I can't ignore the problem anymore :-(.  I'm not sure that this is related to LVDS, of course, but that workaround was okay with the older versions of the intel driver.

If it looks like that's a separate bug, please let me know and I'll file it separately.

Thanks!

(In reply to comment #14)
> Created an attachment (id=12650) [details]
> Log from driver version 2.2.0-1
> 

Would you please turn on the modedebug option in the device section of your xorg.conf and reattach the xorg log?

Thanks,
Hong

Created attachment 12758 [details]
Log with driver version 2.2.0-1 and ModeDebug

Created attachment 12759 [details]
Configuration for driver version 2.2.0-1

Okay, done.  Incidentally, upgrading the rest of my Debian system (which included upgrading the X server to version 1.4.1~git20071119-1) solved the problem of being unable to switch to 1280x1024 mode.  The problem of starting in 1024x768 mode with a broken DPI (severely broken, so that my fonts are comically large; I don't remember if that was a problem previously) still occurs.

Thanks.

What is the output of xrandr and xdpyinfo?

Created attachment 12776 [details]
Output of xrandr

Created attachment 12777 [details]
Output of xdpyinfo

Would you please remove you DisplaySize option in your xorg.conf file and have a try?

When I remove DisplaySize (and do not fix up resolution and DPI by hand in .xinitrc), I get a 1024x768 display with a 72x128 DPI.  The fonts look about like you'd expect 72dpi fonts to look on a modern monitor :-).

Cheers.

can we igore the LVDS from a config file? Hong to add an example...

re-title.

(In reply to comment #24)
> can we igore the LVDS from a config file? Hong to add an example...
> 

from comment #0 "In any case, I've now got a configuration that works acceptably for me", I think the reporter already has a workable xorg.conf.

" Nonetheless this problem did not exist with i810 driver 1.7.2 and earlier." still makes me feel that there is room to improve on the LVDS detection... I'll mark this bug as resolved later then. thanks..

I do not have a workable xorg.conf -- my resolution comes up wrong when I start X, and I use xrandr to fix it (and the DPI) to the correct value in .xinitrc.  That's a workable solution for me, but it still seems that X's behavior in this instance is wrong, since I shouldn't have to do that (and as I said, I didn't have to do that with the old i810 driver).

What I meant by "I have a workable solution" was simply that I had found a workaround for this bug, so it wasn't actively causing me any pain.  I've actually  downgraded to the i810 driver because of a variety of other showstopper bugs in the new intel driver, FWIW, which is an even more effective workaround :-).

Thanks.

So what exactly does "RESOLVED LATER" mean for this bug?

Sorry, Andrew, we thought you've got a workaround. Hong can help you to compose a Xorg.conf to ignore the phantom LVDS.

Later means we will only have time to look at this in the next development cycle to see how to improve the LVDS detection code...

It just seems that "RESOLVED LATER" is sort of a silly state.  "Bug is currently occurring and should be fixed but we're marking it RESOLVED to indicate it's not going to be solved soon."  Why not just leave the bug open, if everyone agrees that the current behavior should be improved?  (FWIW, the bugzilla developers seem to agree; see https://bugzilla.mozilla.org/show_bug.cgi?id=13534)

Maybe some history will explain why I'm so unenthusiastic: In the 6-8 months since I started reporting the bugs I found in the new intel driver, people have told me my bugs don't exist, told me my hardware is probably broken, closed the bugs without asking me, and marked the bugs as NEEDINFO because I said I would poke around in the code when I got time.  None of the bugs, as far as I know, have actually been _fixed_, leaving me (as of my last testing) with an intel driver that starts in the wrong resolution, can't play movies, sometimes seg faults, and frequently requires a reboot when I exit X (bug #12393, bug #12391, bug #13316, and bug #13369).

I actually run the i810 driver again now, since the new intel driver is basically unusable for me (or was last time I tested).  I'm perfectly happy with that situation, actually, except for the fact that I keep volunteering my time to give detailed bug reports about the version I _don't_ use and my bugs keep getting these odd, brush-off-ish responses.

Let me ask you this: Are you working on this bug as part of your official duties as an Intel employee?

Mass reopen.  The "LATER" resolution is lame, I'm deleting it.  Consider LATER to have arrived.

Zhenyu, would you please add a DMI quirk for this machine?

Thanks,
Hong

We should know what dmi info fields can we use for this machine, to express it solely compared with other versions. Andrew?

Yes?  What information are you asking me for?

Our driver now can use dmibios info for quirks.

From your dmidecode result, I want to know which field I can use in the quirk code  for your machine, bios_version? board_name? etc.

e.g you can see current i830_quirks.c, Lenovo laptop's bios_version is used to tell which is the real model. So how about yours?

Why would I know the answer to that question better than you?  Looking over the dmidecode output, I don't see any information that would be useful for that approach (since my manufacturer apparently didn't bother filling in the chassis information).  You might be able to get a better answer from the manufacturer.

It sounds like a good alternative might be to allow configuring which output(s) the driver will use in xorg.conf; that would enable me to configure it only to output on VGA, solving my problem, and it would also have other uses (e.g. running one X server on VGA and a separate one on LVDS).

(In reply to comment #37)
> Why would I know the answer to that question better than you? 
> You might be able to get a better answer from the manufacturer.

ok, but I don't think it'll happen any time soon.

> 
> It sounds like a good alternative might be to allow configuring which output(s)
> the driver will use in xorg.conf; that would enable me to configure it only to
> output on VGA, solving my problem, and it would also have other uses (e.g.
> running one X server on VGA and a separate one on LVDS).
> 

man xorg.conf 
We have already supported what you want.

Section "Monitor"
Identifier "LVDS"
Option "Ignore" "true"
EndSection

Section "Device"
...
Driver "intel"
Option "monitor-LVDS" "LVDS"
EndSection

Not happening soon is fine for me; I've got a working configuration.  I filed this bug to do you a favor and help make X better.  If you'd rather ignore the bug, go for it.

I do see the documentation in xorg.conf(5) on how to associate monitors with outputs; that hadn't been there when I filed this bug.  Thanks!

Actually, putting the lines that you specify into my xorg.conf gives me a configuration that starts in 1280x768, rather than 1280x1024 (my monitor's physical resolution).  I'll attach my current config and log.

Created attachment 14875 [details]
Log with driver version from git (2008-02-25) and X from git (2008-01-31 via Debian)

Created attachment 14876 [details]
Config with driver version from git (2008-02-25) and X from git (2008-01-31 via Debian)

Glad you've got a workaround for LVDS, though I wish we could figure out how to properly quirk it off (no, I *really* wish that we had a way to load-detect it in hardware).

Would it be possible to get you to add Option "ModeDebug" "TRUE" to your driver section, so we can see why you're not getting the expected resolution?  My offhand guess would be the hardcoded configuration for your monitor you've got in the config file, since EDID should be giving you all the right information.  But if the EDID is wrong, ModeDebug will give us what we need to fix it.

Also, my sincere apologies for the use of RESOLVED -> LATER earlier.

Nope, removing the monitor configuration does not solve the problem.  I'll attach my most recent config, log, and xdpyinfo output -- note that I get 58x160 DPI, which doesn't look quite right :-).

This is with xorg server version 1.4.1~git20080131-1 from Debian sid, and the intel driver from git (commit 66cdccb021a4748b2af41e415c36ed58ca808df6 from 2008-02-25).

Re: RESOLVED LATER, no worries.  All of the showstopper bugs for me are actually fixed now, which if nothing else makes it a boatload easier for me to provide information about bugs like this one, because I don't have to keep switching back and forth between driver versions.

Cheers.

Created attachment 14950 [details]
Log with ModeDebug TRUE

Created attachment 14951 [details]
xorg.conf that produced attachment #14950 [details]

Created attachment 14952 [details]
xdpyinfo output when 1280x768 mode is chosen

Well, it seems I spoke too soon :-).  It looks like the EDID identification is wrong, yes, and I actually need to go back to the i810 driver to get a correct resolution again now.

Starting in the intel driver, with or without monitor configuration, gives me an X session that won't go any higher than 768 height (actually, width, since all of this is on a rotated monitor).

Starting in the old i810 driver with no explicit monitor configuration gives me an X session that won't go higher than 640x480 (!).

Starting in the old i810 driver with an explicit monitor configuration gives me an X session that will go to 1280x1024.

So it sounds like something changed in the core X server that broke EDID for me (which I foolishly assumed was because I'd removed the monitor configuration lines , while at the same time I upgraded the core server)... right?  Should I be filing an additional bug against the core server?  I've tried rolling back to a backed-up copy of my configuration file from before I upgraded the core server to 2008-01-31, and it still gives me a 1280x768 screen whether or not I specify a monitor configuration or try to reset the resolution with xrandr.

Thanks.

Okay, I've now upgraded my core server to version 1.4.1~git20080131-2 (which is apparently based on the server-1.4-branch as of March 14th), and am now running the intel driver version 2.2.1-1 (both from Debian sid).  With those versions, I'm able to switch to 1280x1024 mode using xrandr, but my X server still _starts_ in 1280x768 mode when I use the configuration from attachment #14951 [details].

Cheers!

Okay, I should be a bit more complete in my testing.  With core server version 1.4.1~git20080131-2 and intel driver version 2.2.1-1, I still do need to specify my monitor parameters, not specify LVDS, and use xrandr in .xinitrc in order for things to work.

   * If I do those three things, I get a 1280x1024 screen.
   * If I do not specify my monitor parameters (e.g. HorizSync), I get a screen which xrandr will refuse to take above 1024x768.
   * If in addition to not specifying monitor parameters, I specify separate monitor sections for LVDS and VGA (as in attachment #14951 [details]), I get a screen which xrandr will refuse to take above 1280x768, and on which the DPI is horribly wrong.

Let me know if there are any specific configurations you'd like me to test.

Cheers!

Hmm, we're not getting any EDID data from DDC for your VGA-attached monitor at all.  If you've got any other video cards in use on other machines, could you try the monitor on one of those to see if they get DDC, to tell if it's our driver or the monitor at fault? (xprop -root | grep EDID would show it on a non-randr-1.2 driver, or xrandr --verbose on a randr 1.2 driver).

By default without DDC, we fake up a monitor that does 1024x768 for safety.

Does it also default to 58x160 DPI for safety? :-)

The EDID information gets read fine from a laptop running Debian sid with a Radeon card.  I'll attach the output of xrandr --verbose.

Cheers.

Created attachment 16145 [details]
Output of xrandr --verbose on a different machine, same monitor on VGA

assign to zhenyu for LVDS load-detection. For EDID issue, Andrew, if it still exist, please open a new bug to track it. thanks.

Thank god!  Wang Zhenyu is on the case again.  The sum total of his action on this bug back in March, when it was assigned to him before, was to request that _I_ figure out a way to implement the LVDS quirk.  He also curtly explained that documentation exists (having been created in the time I've been waiting for this bug to get addressed) that describes how to work around the behavior.  He lapsed into so-far-permanent silence when I pointed out that the workaround doesn't actually, with the current intel driver, work.  I can't wait to see what he does this time.

I'm also still curious whether you (Michael Fu) are volunteering your time, as I am, or if someone is paying you for this.

I've created bug #16932 for the EDID misdetection.

Cheers.

I believe Jesse would like to put this into 2.5 release.

There have been many comments in this bug. But in short, the problem is our driver  doesn't have LVDS detection, and (wrongly) assume LVDS always available for mobile chipset. The current workaround is disable LVDS in xorg.conf. But we need truly fix it.

*** Bug 17038 has been marked as a duplicate of this bug. ***

Created attachment 18421 [details] [review]
add "no lvds" quirk for slimpro pc

Depending on the machine we may or may not be able to do good LVDS detection.  The latest git bits have improved LVDS detection (if the VBIOS doesn't list a panel we assume there's no LFP connected), but I've seen buggy VBIOSes that list LFP info even when none is present.  If your machine is like that you may need the attached patch.

Reporters, Jesse has improved LVDS detection in xf86-video-intel master branch. Can you give it a try to see if it resolves your problem? If it still doesn't work, please try the additional patch in comment#58.

Andrew, we need your response.

You're going to have to wait.  Caring for my xorg bugzilla bugs has fallen into the "when I get some free time and feel like it" priority, and I've been pretty busy recently.  You folks squandered the first 8 or 9 times I took some time to investigate and give you back detailed answers or test new versions; then I had some free time to donate, but just at the moment I don't.

I suppose a year and a quarter is quite awhile to wait for a bug fix, so I don't blame you.

If you could find time in the next couple of weeks to test the patch, that would be especially good, since then we'd be able to include it in the 2.5 release for you.  It may not solve some of the other issues you reported in this bug but will hopefully at least address the LVDS detection part.

If you don't have time for awhile yet, that's ok too; I haven't heard many other reports of this problem so hopefully it's not too widespread.

The delay isn't a problem; I've got bugs in the Debian bug tracker that are coming up on 5 years old :-).  As I say, I've got a working solution; I just like to see bugs get fixed and consider it my responsibility to report them so that that can happen.  The only irritating part is constantly having Intel engineers pop up, shuffle the bug's metadata, ask me (or, in Gordon's case just now, simply order me) to do some investigation for them, and then disappear without either fixing anything or responding to any questions I might have posed to them.

The simple fact, though, is that I'm not neglecting this bug for any other reason than that I don't have time.  I know it's frustrating to check in a fix and not be able to find out whether what you've checked in fixes a bug it was supposed to address.  The issue is that I've just started a new job, and I'm trying to start a business, and I'm trying to spend enough time with my sweetie that she doesn't forget what I look like.  My xorg bugs just aren't far enough up on the list.

I'm clearing the "blocking 2.5 release" mark, since Jesse's LVDS detection improvement patch has been in, which should resolve generic issue. And this bug is just for the specific hw now.

But it would have looked so nice next to the "blocking 2.2 release" mark and the "blocking 2.3 release" mark :-).

Pushed the fix as 10909d9b665864bda2b1654de009d556cd068726.  Please re-open if it doesn't solve the problem (no hurry).

Thanks,
Jesse

I removed Jesse's quirk as it breaks another IBM 855GM machine with same ids and does have LVDS. I've pushed LVDS detect patch to git master, please help to test it.

Okay.  I'm not able to test master at the moment, because Debian doesn't have libdrm 2.4.2 yet, but once it's in I'll retest.

Nope, it still doesn't work.  Disabling LVDS in xorg.conf gives me an 1152x864 display (which is a separate problem, I believe related to bug #16932), but letting the driver do its thing without explicitly disabling LVDS gives me 1024x768.  My monitor is 1280x1024.  So it seems that the LVDS connection is still forcing the display to 1024x768.

This is with driver version 2.6.1-1 from Debian experimental.

It still irritates me that you guys close bugs without checking whether they're actually fixed or not, saying "reopen if it's not fixed."  For one thing, it makes it a PITA to find the bugs that I need to retest, because I have to pull up a list of all my bugs (closed or not), and dig out of my memory which ones are actually fixed and which ones you're waiting for me to test.

In any case, I have my computer at my house again now, and it has a monitor, so it's gotten a lot easier to test changes again.  The downside is that now I want X to actually work again, which is still a big challenge for it apparently :-).

(In reply to comment #69)
> 
> This is with driver version 2.6.1-1 from Debian experimental.
> 

zhenyu's patch is checked in after 2.6 branch is created. maybe it's easier for zhenyu to just post the patch here and you apply on your driver and test...

Please test with current git _master_, I think that's what I have asked you to
try. 2.6.1 doesn't contain recent fixes.

If we believe in our patch has fixed the problem, we'll close the bug as we
don't want to hold on and wait, also a reminder for user that he might test for
new patch and reported back if issue still exists. Just wait for a OSV release
for keep an might-fixed bug open doesn't make sense to me, and normally that'll
lag behind intel's release. We'll want to integrate current fix on master to
next Q1 stable 2.7 release, you can help us to verify if current master fixed
this or not, that's what we care. Thanks.

I'm not able to test master right now, because it depends on libdrm 2.5, which isn't in Debian.  I saw that 2.6 was packaged in January, after Wang Zhenyu's fix went in, and assumed that it contained the fix (since I wasn't aware of the release branch situation).  I can test the fix once a new enough version of libdrm gets packaged, then, or when 2.7 releases and gets packaged.

(In reply to comment #69)
> It still irritates me that you guys close bugs without checking whether they're
> actually fixed or not, saying "reopen if it's not fixed."  For one thing, it
> makes it a PITA to find the bugs that I need to retest, because I have to pull
> up a list of all my bugs (closed or not), and dig out of my memory which ones
> are actually fixed and which ones you're waiting for me to test.

You can simply find those bugs pending on your verification by searching bugs with status = RESOLVED not VERIFIED. I think you know why bugzilla is designed to have these two separate status.

That's actually a very good idea -- I don't see bugs get moved to the VERIFIED state very often at all, but there's no reason I can't just do it for bugs that I've verified are actually fixed for me.  That almost sounds like things working the way they're intended to work :-).

/me gets to work marking several old bugs VERIFIED

Thanks!

Created attachment 23897 [details] [review]
LVDS quirk based on dmi info

Please test this patch, which adds quirk for your LVDS based on dmi info.

*** This bug has been marked as a duplicate of bug 19529 ***