jbarnes asked me to file the vbios dumps of machines affected by the bogus LVDS1 issue. They will be attached in this bug.
Created attachment 25319 [details] vbios dump from Disklessworkstations.com 1520 Atom + i945 video thin client http://www.disklessworkstations.com/cgi-bin/web/200118.html This machine has a VGA and DVI port. LVDS should never be used, but it is erroneously detected by KMS as connected.
Created attachment 25320 [details] vbios dump from Devon TC5 Atom + i945 video thin client This client has two DVI ports. It exhibits the bogus LVDS1 connected issue if you plug your monitor only into the first DVI port. If you plug your monitor into the second DVI port, it behaves properly because that port actually is LVDS1.
did you see the same issue in UMS? If yes, do you mind attaching a xorg.log with ModeDebug option turns on in xorg.conf in UMS? it probably can provide us more information to do debugging... thanks. And, btw, what's in your /sys/class/power_supply directory of the two machines?
(In reply to comment #3) > did you see the same issue in UMS? If yes, do you mind attaching a xorg.log > with ModeDebug option turns on in xorg.conf in UMS? it probably can provide us > more information to do debugging... thanks. > And, btw, what's in your /sys/class/power_supply directory of the two machines? ping ~
> did you see the same issue in UMS? No issues with nomodeset. > And, btw, what's in your /sys/class/power_supply directory of the two machines? Empty on both machines.
(In reply to comment #5) > > did you see the same issue in UMS? > > No issues with nomodeset. nomodeset? what does this mean? > > And, btw, what's in your /sys/class/power_supply directory of the two machines? > > Empty on both machines. > Thanks for the input.. this may provide some hints for us to determine the solution of LVDS detection.
"nomodeset" kernel parameter boots with kernel modesetting disabled. The intel driver falls back to EXA and sets the mode itself. I assume this is what you meant by UMS?
(In reply to comment #7) > "nomodeset" kernel parameter boots with kernel modesetting disabled. The intel > driver falls back to EXA and sets the mode itself. I assume this is what you > meant by UMS? hi Warren Plase set i915.modeset=0 at boot time, your machine will disable KMS(kernel mode setting), and start xorg in UMS( user mode setting), then upload log file with modedebug option on. Thanks Ma Ling
It seems that nomodeset and i915.modeset=0 do the same thing. Attaching logs.
Created attachment 26227 [details] Xorg log with KMS
Created attachment 26228 [details] Xorg log with UMS and modedebug
(In reply to comment #11) > Created an attachment (id=26228) [details] > Xorg log with UMS and modedebug yes, our driver incorrectly think non-existed lvds as connected, we will completely resolve it soon. A workaround is to ignore LVDS by modify xorg.conf as below Section "Device" ... Option "monitor-LVDS" "LVDS" ... EndSection ... Section "Monitor" Identifier "LVDS" Option "Ignore" "True" EndSection Thanks Ma Ling
Will you please attach the output of acpidump, dmidecode? The acpidump tool(pmtools) can be found in: >http://www.lesswatts.org/projects/acpi/utilities.php Thanks.
Created attachment 26554 [details] oops, wrong attachment http://www.disklessworkstations.com/cgi-bin/web/200118.html This machine has a VGA and DVI port. LVDS should never be used, but it is erroneously detected by KMS as connected.
Created attachment 26555 [details] acpidump from Devon TC5 Atom + i945 video thin client This client has two DVI ports. It exhibits the bogus LVDS1 connected issue if you plug your monitor only into the first DVI port. If you plug your monitor into the second DVI port, it behaves properly because that port actually is LVDS1.
Created attachment 26556 [details] acpidump from Disklessworkstations.com 1520 Atom + i945 video thin client http://www.disklessworkstations.com/cgi-bin/web/200118.html This machine has a VGA and DVI port. LVDS should never be used, but it is erroneously detected by KMS as connected.
Created attachment 26665 [details] [review] Use the LID device to decide whether the LVDS device should be initialized Will you please try the patch on the latest kernel and see whether the issue still exists? Thanks.
I have not tested your patch, but this seems wrong. You cannot depend on the LID device in a general sense. The two examples I have supplied are both devices without LID, however LVDS is legitimately used on one of the two DVI ports on the Devon TC5. How is it that UMS can detect a disconnected LVDS port while KMS cannot?
(In reply to comment #18) > I have not tested your patch, but this seems wrong. You cannot depend on the > LID device in a general sense. The two examples I have supplied are both > devices without LID, however LVDS is legitimately used on one of the two DVI > ports on the Devon TC5. General speaking there exists the LID device on most laptops. And it can be used to put the system into suspend/resume while the LID is closed/reopened. If there is no LID device, we can say that this is not for the mobile laptop. So IMO we can check the LID device to decide whether the LVDS device should be initialized. Will you please attach the xorg log/conf using UMS mode on the Devon TC5? > > How is it that UMS can detect a disconnected LVDS port while KMS cannot? Are you sure that LVDS is disconnected in UMS mode? Will you please double check whether LVDS is skipped by using xorg configuration? thanks.
(In reply to comment #18) > I have not tested your patch, but this seems wrong. You cannot depend on the > LID device in a general sense. The two examples I have supplied are both > devices without LID, however LVDS is legitimately used on one of the two DVI > ports on the Devon TC5. There is no relationship between LVDS and DVI port. For me it seems that there is no LVDS device on Devon TC5. Right? > > How is it that UMS can detect a disconnected LVDS port while KMS cannot? > Anyway, please try the debug patch on the Eric's drm-intel-next tree and see whether the LVDS is still connected? (In KMS mode). Thanks.
<warren> Haven't we already gone through, you can't use LID to determine if you should ignore the LVDS1. <anholt> someone just needs to parse the bios tables correctly and use them. <anholt> zhenyuw posted patches that didn't quite work out; they need to be finished. <warren> anholt: is what I am being asked to do reasonable? <anholt> warren: there's only one useful thing to do related to lvds detection: finish the bios parsing patch. ignore anything else but doing that.
(In reply to comment #21) > <warren> Haven't we already gone through, you can't use LID to determine if you > should ignore the LVDS1. > <anholt> someone just needs to parse the bios tables correctly and use them. > <anholt> zhenyuw posted patches that didn't quite work out; they need to be > finished. > <warren> anholt: is what I am being asked to do reasonable? > <anholt> warren: there's only one useful thing to do related to lvds detection: > finish the bios parsing patch. ignore anything else but doing that. > Do you mean that the LID device is not a good way for LVDS detection? Yes. The LVDS detection can be done by parsing Vbios. But it seems that it is not reliable for some laptops. And on some boxes the Mobile chipset is used while there is no LVDS device. Even some vendors don't change the VBIOS. In such case how can we detect LVDS correctly? It seems ugly that the LID device is used for LVDS detection. But it can work for the box that use the mobile chipset while it is used as desktop(there is no LID device). Thanks.
UMS X.org somehow correctly detects that the LVDS is disconnected and ignores it automatically. Why can't KMS do it properly like UMS seems to do? The above mentioned Devon TC5 as noted above somehow uses LVDS1 as one of it DVI ports. The other DVI port is recognized as DVI1. There is no LID on this machine. Using LID alone was considered months ago and rejected for other reasons I don't know personally.
(In reply to comment #23) > UMS X.org somehow correctly detects that the LVDS is disconnected and ignores > it automatically. Why can't KMS do it properly like UMS seems to do? Does there exist the LVDS panel on the Devon TC5 box? How is LVDS ignored automatically in UMS mode? By adding "option ignore false" for LVDS in xorg.conf? > > The above mentioned Devon TC5 as noted above somehow uses LVDS1 as one of it > DVI ports. The other DVI port is recognized as DVI1. There is no LID on this > machine. Using LID alone was considered months ago and rejected for other > reasons I don't know personally. Several months ago the UMS driver uses the LID state to decide whether the LVDS is connected/disconnected. That means that the LVDS will be disconnected if the LID state is closed. Right? This can work well on most laptops. But some boxes will be affected as the initial LID state is incorrect. Do you mean that LVDS1 is used as one of DVI port on Devon TC5? Sorry that I don't understand what you said. How can the LVDS be used as one of DVI port? There is no relationship between LVDS and DVI port. Will you please describe it more clearly? Thanks >
> Do you mean that LVDS1 is used as one of DVI port on Devon TC5? Sorry that I > don't understand what you said. > How can the LVDS be used as one of DVI port? There is no relationship between > LVDS and DVI port. > Will you please describe it more clearly? Devon TC5 has two DVI ports. DVI(first) is seen as DVI1 by the operating system. DVI(second) is seen as LVDS1 by the operating system. With UMS, single monitor plugged into either port works just fine. The other interface is detected disconnected, and disabled automatically without any xorg.conf options. With KMS, single monitor plugged into DVI(second) works, because DVI(first) as DVI1 is properly automatically detected as disconnected. You however have problems if you plug a single monitor into DVI(first). DVI(second) as LVDS1 thinks it is connected, improperly modesets and causes spanning. The TC5 has no LID yet it somehow uses LVDS1 as one of its DVI ports.
(In reply to comment #25) > > Do you mean that LVDS1 is used as one of DVI port on Devon TC5? Sorry that I > > don't understand what you said. > > How can the LVDS be used as one of DVI port? There is no relationship between > > LVDS and DVI port. > > Will you please describe it more clearly? > > Devon TC5 has two DVI ports. > DVI(first) is seen as DVI1 by the operating system. > DVI(second) is seen as LVDS1 by the operating system. > > With UMS, single monitor plugged into either port works just fine. The other > interface is detected disconnected, and disabled automatically without any > xorg.conf options. > > With KMS, single monitor plugged into DVI(second) works, because DVI(first) as > DVI1 is properly automatically detected as disconnected. You however have > problems if you plug a single monitor into DVI(first). DVI(second) as LVDS1 > thinks it is connected, improperly modesets and causes spanning. > > The TC5 has no LID yet it somehow uses LVDS1 as one of its DVI ports. Why is LVDS used as one of its DVI port ? IMO there is no relationship between LVDS and the DVI port. There are two possible types of LVDS. One is based on integrated LVDS and another is based on SDVO(DVI port), which is also called SDVO-LVDS. In my patch the LID device is to decide whether the integrated LVDS is initialized. Will you please confirm whether there exists the integrated LVDS on the Devon TC5? Thanks.
You are not listening.
Hi, Warren There are two boxes in this bug. One is from Disklessworkstation 1520 and the other is from Devon TC5. a. Disklessworkstation 1520 The issue is the bogus LVdS detection. From the VBIOS and product description we know that the mobile chipset is used on this box. And the integrated LVDS will be detected on mobile chipset in KMS mode. So it will get the bogus LVDS dection on this box. The patch in comment #17 can solve the issue on this box. On this box there is no LID device. b. Devon TC5 This box is also based on 945GME mobile chipset. And we can know that there is no LID device from the acpidump. In such case we had better ignore the the integrated LVDS dection. At the same time I am looking forward to know whether it can solve the issue on this box. I also want to confirm whether there exists the physical integrated LVDS panel on this box. If there exists the integrated LVDS panel, the patch can't work. And we can do the further work on this patch. For example: Add this box to the quirk table on which the LVDS detection can't be ignored when there is no LID device. But unfortunately there is no test result. thanks.
You continue to not listen. It is a BAD IDEA to use the presence of a lid to determine if you should ignore LVDS. The lead developers on the Intel X driver and Red Hat's X engineers both agree this is a bad idea. Adding this particular box to a quirk table is also a bad idea, because this box exhibits the bogus LVDS issue if you are plugged into only the other port. Note Comment #21. Is there no way to do real detection if the LVDS is connected to anything?
OK, I apologize. Upon further discussion in #intel-gfx it seems I have been misinformed and wrong. * Despite Comment #21, anholt is now not sure if BIOS parsing can detect if LVDS is actually connected. * airlied says you cannot detect if LVDS is connected because it lacks connection pins. He says you might be able to load detect LVDS, but not via software. He says you might be able to DDC over LVDS, but DDC cannot reliabl tell you if there isn't a device connected. * Ultimately these boxes were improperly built. They took reference boards and did not properly rewrite the BIOS to disable LVDS if they are not using it. This is a flaw in the DisklesssWorkstation 1520 BIOS. In the case of the Devon TC5 it is impossible for them to have fixed the BIOS to make the LVDS both optional and automatic. Based upon these points, it is it impossible to detect if LVDS is connected. airlied says maybe we should disabling LVDS if LID is not present. We will then have to quirk strange boxes like the Devon TC5. Unfortunately some boards might be identical between vendors because of laziness and unique quirking wouldn't be possible. It would be the vendor's own fault and there is nothing the software can do about it. I will test your patch on Tuesday when I return. airlied and mjg59 say that quirking could be done with either PCI subvendor ID's or DMI.
(In reply to comment #29) > You continue to not listen. It is a BAD IDEA to use the presence of a lid to > determine if you should ignore LVDS. The lead developers on the Intel X driver > and Red Hat's X engineers both agree this is a bad idea. What is a good idea to decide whether the LVDS detection should be ignored? By the VBIOS? It is not reliable. So I don't add it to the LVDS detection again. In fact the VBIOS on the Devon TC5 tells us that there exists the integrated LVDS. LVDS config: Integrated LVDS > > Adding this particular box to a quirk table is also a bad idea, because this > box exhibits the bogus LVDS issue if you are plugged into only the other port. Have you confirmed that there exists the integrated LVDS panel on the Devon TC5? I also point out several times that there is no relationship between the integrated LVDS and DVI port. > > Note Comment #21. > > Is there no way to do real detection if the LVDS is connected to anything? AFAIK we can't do the real detection. If we can get the EDID for all the integrated LVDS, it will be good choice to detect whether the LVDS is connected by getting the EDID. But it is also correct that the EDID can't be obtained on some laptops. So it seems that we can't do the real detection. Thanks. >
Thanks for the understanding. Will you please try the updated patch in http://lists.freedesktop.org/archives/intel-gfx/2009-July/003137.html? If the Devon TC5 can't wok after applying the patch, please attach the output of dmidecode and lspci -vxxx. thanks.
Now in drm-intel-next: commit e99da35f060f9a3407f7def474a1df31f3b8643a Author: Zhao Yakui <yakui.zhao@intel.com> Date: Fri Jun 26 09:46:18 2009 +0800 drm/i915: Check the LID device to decide whether the LVDS should be initialized The expectation is that this will fix the first 3 machines reported.
Eric, why not putting this fix into qa-branch? I feel this LVDS detection improvement for KMS is important for Q2 release.
BTW, how does X.org without KMS manage to properly detect if something is connected to LVDS1? It seems to work just fine with KMS disabled.
(In reply to comment #35) > BTW, how does X.org without KMS manage to properly detect if something is If the LVDS is initialized in UMS mode, it will be detected as "connected". > connected to LVDS1? It seems to work just fine with KMS disabled. Do you mean that the Devon TC5 box can't work well in KMS mode after applying the patch? Thanks. >
I don't know how UMS X.org does it, but it works just fine autodetecting if a display is connected to the DVI port that is really LVDS1. I am unable to test your patch at the moment, hopefully next week. =(
(in reply to ykzhao) > Do you mean that the Devon TC5 box can't work well in KMS mode after applying > the patch? Confirmed, DVI2 (connected to LVDS) is entirely broken on the Devon TC5 now. BTW, even if we quirk this, it will make it behave just as bad as before. Why is nobody answering the question, UMS was somehow able to successfully detect if LVDS1 was connected. How was it doing that?
(In reply to comment #38) > (in reply to ykzhao) > > Do you mean that the Devon TC5 box can't work well in KMS mode after applying > > the patch? > Confirmed, DVI2 (connected to LVDS) is entirely broken on the Devon TC5 now. > BTW, even if we quirk this, it will make it behave just as bad as before. Why > is nobody answering the question, UMS was somehow able to successfully detect > if LVDS1 was connected. How was it doing that? Do you mean that this issue still exists on Devon TC5 box? Do you mean that there exist two DVI port on Devon TC5 box? Please double check it again. And there is no relationship between integrated LVDS and DVI port. Will you please enable the modedebug option in xorg.conf and attach the xorg log with KMS disabled? Please also attach the output of reg_dump. BTW: please do it on Devon TC5 and also attach the xorg.conf. Thanks.
Created attachment 28707 [details] lspci -vxxx from Devon TC5
Created attachment 28708 [details] dmidecode from Devon TC5 Turning off KMS no longer seems to work. I was told earlier that latest versions of the intel driver no longer support UMS? In any case please just quirk this machine. I have no time to work further on this.
ykzhao, please add a quirk for this machine?
(In reply to comment #41) > Created an attachment (id=28708) [details] > dmidecode from Devon TC5 > Turning off KMS no longer seems to work. I was told earlier that latest > versions of the intel driver no longer support UMS? Do you mean that the LVDS is still detected as connected under KMS mode for the Devon TC5? From the acpidump we can know that there is no LID device. In such case the LVDS detection will be skipped. > In any case please just quirk this machine. I have no time to work further on > this. Do you expect that the LVDS detection is also skipped under UMS mode? If so, then it is not related with this bug. Of course we can add this box into the quirk table. Thank.
Warren, you don't need to disable KMS anymore as Eric has picked up the patch in comment# 33. no quirk should be needed after parsing the acpidump. please submit a xorg.log _with_ KMS and dmesg. thanks.
Michael, you misunderstand. The patch from Comment #33 completely broke one of the two DVI ports on this particular box when running with KMS enabled.
please provide more description of the symptom , and xorg.log and dmesg. thanks.
Warren, would you please provide the logs? without them , we can't tell why one of your the other DVI doesn't work...
I have explained repeatedly why the other DVI port doesn't work. It is connected to LVDS1, while this device has no LID since it is a thin client. http://bugs.freedesktop.org/attachment.cgi?id=26227 This earlier attachment was from this machine, with KMS, a bit prior to the patch that disables LVDS1 when there is no LID. I will try to get fresh logs but I can't guarantee when.
(In reply to comment #48) > I have explained repeatedly why the other DVI port doesn't work. It is > connected to LVDS1, while this device has no LID since it is a thin client. > ok. I see. in terms of detection, we could even have a better way than quirk to handle this case, but I'm not sure other situation such as , can your converter support LVDS single/dual channel case? when the Hsize is > 1280, LVDS need to switch to dual channel. from our driver's point of view, we have to treat this as LVDS device. > http://bugs.freedesktop.org/attachment.cgi?id=26227 > This earlier attachment was from this machine, with KMS, a bit prior to the > patch that disables LVDS1 when there is no LID. > > I will try to get fresh logs but I can't guarantee when. >
The curious thing about this, UMS somehow does detect that the other port is disconnected. According to what I hear from mjg59 and airlied this is supposed to be electrically impossible with the LVDS connector.
(In reply to comment #50) > The curious thing about this, UMS somehow does detect that the other port is > disconnected. According to what I hear from mjg59 and airlied this is supposed > to be electrically impossible with the LVDS connector. > actually, I question the feasibility the solution could work as well.. in terms of detection, if the they properly connected the DDC pins from the LVDS port to DVI (converter), the detection in UMS can work. We can do the same thing in KMS, but again I think there are other issues , too , besides the detection problem..
KMS (before this LID patch disabled the LVDS-DVI port) demonstrates that it does successfully DDC to detect the resolution of a connected DVI LCD monitor. It doesn't successfully detect if a monitor is disconnected though.
(In reply to comment #52) > KMS (before this LID patch disabled the LVDS-DVI port) demonstrates that it > does successfully DDC to detect the resolution of a connected DVI LCD monitor. > It doesn't successfully detect if a monitor is disconnected though. > correct, because there are many LVDS panels that doesn't have DDC, thus we couldn't say disconnected because no EDID was found. However, if there is EDID, it's sure there is a connection. In reference design, LVDS connection is set once the machine is built ( you can't take your laptop panel away...). This information is provided in bios via signs such as if lid device exist or not. Apparently, this thin client design is using LVDS in a heterogeneous way. I can't think of any solution to successfully detect the "disconnected" case, without impacting normal LVDS design. I tend to WONTFIX this, sorry.
I am not asking to detect a monitor plugged into this LVDS. I am asking to quirk this machine so that port is not disabled by default. It will behave just as poorly as before the LID patch, but that's better than disabled.
rather than introducing quirk, a feature called "port always on" that Jesse has been working on can help.
It's been a long time, assuming this is fixed now.
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.