| Summary: | Driver lacks fallback when EDID read fails | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | Bob McElrath <bob+freedesktop> | ||||||||||||||||||||
| Component: | Driver/intel | Assignee: | Carl Worth <cworth> | ||||||||||||||||||||
| Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> | ||||||||||||||||||||
| Severity: | normal | ||||||||||||||||||||||
| Priority: | medium | CC: | michael.fu | ||||||||||||||||||||
| Version: | 7.4 (2008.09) | Keywords: | NEEDINFO | ||||||||||||||||||||
| Hardware: | x86 (IA32) | ||||||||||||||||||||||
| OS: | Linux (All) | ||||||||||||||||||||||
| Whiteboard: | |||||||||||||||||||||||
| i915 platform: | i915 features: | ||||||||||||||||||||||
| Attachments: |
|
||||||||||||||||||||||
Created attachment 28559 [details]
BAD X11 screenshot
Created attachment 28560 [details]
BAD Xorg log
Created attachment 28561 [details]
GOOD Xorg log
Created attachment 28562 [details]
xorg.conf
Created attachment 28563 [details]
BAD dmesg
Created attachment 28564 [details]
GOOD dmesg
Created attachment 28565 [details]
GOOD dmesg
Finally:
(0)<mcelrath@ziggy:~> uname -a
Linux ziggy 2.6.31-5-generic #24-Ubuntu SMP Sat Aug 1 12:48:18 UTC 2009 i686 GNU/Linux
(0)<mcelrath@ziggy:~> COLUMNS=200 dpkg -l xserver-xorg-video-intel libdrm2
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name Version Description
+++-============================================-============================================-========================================================================================================
ii libdrm2 2.4.12-1ubuntu1 Userspace interface to kernel DRM services -- runtime
ii xserver-xorg-video-intel 2:2.8.0-0ubuntu2 X.Org X server -- Intel i8xx, i9xx display driver
Let me know if there are any other files/info that would be useful.
>> I cannot precisely identify when this trouble started but it may
have been when I upgraded from driver 2.7.0 to 2.7.1
Do you still think 2.7.0 works (with >90 degrees)? But on the other side you says "I have tried every version of the driver from 2.6.3 to 2.8.0" and they all not work.
Fallback to 1024x768 when reading EDID fail seems an expected behavior in my opinion.
2.7.0 disappeared from the x-ubuntu-swat repository, so I don't have access to it anymore. I do not think it works. If this is entirely a software problem, it could only be 2.4 that did not have the problem, as it was around the upgrade to Jaunty (driver 2.6.3) that the problem started. And I did re-check 2.6.3 yesterday, and it does have the problem. And take a look at Xorg.log.0.bad. X *does* read the EDID (though get-edid fails) and properly detects the 1400x1050 resolution, and then rejects the mode anyway "exceeds panel dimensions". (This behavior is slightly different than previous driver versions, which just reported an EDID read failure) Yes, given the disaster that is this driver, I expected you to absolve yourself of responsibility for this. Did you even look at the attachments? I still have this problem with 2.9.0. I don't know why the EDID read fails but your driver doesn't allow me to do anything about it. Could you add a CustomEDID directive, as the NVIDIA driver has, which will read the EDID information from a file? This would allow users to fix problems related to buggy bioses, buggy monitors, and my problem with the unknown edid read failure. Sorry for the late response.
It seems that the issue on your box is that sometimes the EDID can't be obtained correctly. More serious is that the LVDS panel mode reported by Vbios is also different with that supported by LVDS panel when there is no EDID. In such case the system will choose the incorrect display mode for LVDS panel. Can you attach the output of vbios.dump on the two cases of good EDID and bad EDID? The vbios.dump can be obtained by using the following commands:
1. echo 1 > /sys/devices/pci0000:00/0000:00:02.0/rom
2. cat /sys/devices/pci0000:00/0000:00:02.0/rom >vbios.dump
3. echo 0 > /sys/devices/pci0000:00/0000:00:02.0/rom
At the same time you also mention one method that the driver also add a CustomEDID to read the EDID from file as what Nvidia driver has done? I am afraid that it will be difficult to add the support of curstomEDID after enabling the KMS.
Thanks.
Created attachment 33860 [details]
GOOD vbios
This is the GOOD vbios, not from the same laptop, but from an identical one. I had to purchase a new x61 tablet because of this bug. The ratio of bootup-with-wrong-resolution to bootup-with-right-resolution eventually approached 100%. I will post the other vbios in a few days -- I have to get the old laptop out of storage.
(In reply to comment #13) > Created an attachment (id=33860) [details] > GOOD vbios > > This is the GOOD vbios, not from the same laptop, but from an identical one. I > had to purchase a new x61 tablet because of this bug. The ratio of > bootup-with-wrong-resolution to bootup-with-right-resolution eventually > approached 100%. I will post the other vbios in a few days -- I have to get > the old laptop out of storage. sounds the issues is "fixed"? > sounds the issues is "fixed"?
Not unless you added a fallback for bad EDID behavior that I missed. Sorry for my delay, I have the old laptop and can get you the bad EDID tonight.
But as the summary says, this bug is about lacking a fallback. There's nothing wrong with the Intel chip or the display in this laptop. If there was a fallback to override the EDID, this would be a usable laptop.
Are you guys so opposed to some kind of IgnoreEDID directive, as the NVidia driver has?
There were some X changes to add fallback modes somewhat recently, so this may be fixed. If not, please re-open. We can forcibly add modes to a connector from the X driver, so we should be able to fix this one way or another. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Created attachment 28558 [details] BAD boot screen (uses upper left 1024x768 and splash image is repeated) Driver fails to detect or set the correct mode for the LVDS panel on a Thinkpad X61 tablet. I cannot precisely identify when this trouble started but it may have been when I upgraded from driver 2.7.0 to 2.7.1 from the ubuntu-x-swat repository. Suddenly on reboot the BIOS POST screen would come up in the upper left 1024x768 of my 1400x1050 screen (see photos). After a tremendous amount of work, I finally figured out that this is because the EDID can sometimes be read, and sometimes not. When get-edid successfully reads the edid, X will start successfully in the correct mode (regardless of whether the BIOS POST screen was correct or not). The other half of the time get-edid reports "Call failed" when reading the EDID. When the EDID cannot be read, all of (BIOS POST, KMS, and Xorg) set the wrong mode and report "edid read failed" in various ways. It seems the "magic" that causes the EDID read to fail is having the screen open more than about 90 degrees. Less than 90 degrees and get-edid will succeed. Thus, one might chalk this up to a hardware problem. (bad connection in the hinge?) At any rate, if the EDID read fails, there does not exist ANY way to force KMS or Xorg to set the correct video mode. vbetool and fbset cannot set the video mode, and the driver does not allow xorg.conf to override the non-existant EDID data. There are no kernel command line options which can set the mode. If indeed it is a hardware problem above, it is one of the SMBUS, and does not affect video in any other way, and it appears it could be fixed by better detection. I have tried every version of the driver from 2.6.3 to 2.8.0 and kernels 2.6.28 - 2.6.31 with and without kernel mode setting. I'm attaching output from 2.8.0 and 2.6.31-5-24 (both from Ubuntu Karmic). With these versions the driver actually claims to be able to read the EDID but still doesn't set the mode correctly (the conflicting description above refers to previous kernels and drivers). Previous versions claimed they couldn't read it.