|
Description
Tormod Volden
2008-10-10 07:29:19 UTC
Created attachment 19563 [details]
log when "Ignore" is used on LVDS and TMDS-1
Created attachment 19564 [details]
xrandr output using minimal xorg.conf
It will be good if you could try 2.5 driver. 2.5.0 will be released in few days. Before that happens, you could try xf86-video-intel-2.5 branch or master branch. I believe the "non-existing LVDS" should have been fixed in 2.5. And Zhenyu changed DVI-I code in 2.5. The remaining issue seems to be that the LCD resolution (1680x1050) doesn't show up if TMDS-1 ignored. I'm not sure if Zhenyu's DVI-I change fixed this. You should ignore your LVDS or provide us pci info (lspci -v) so we can quirk it out. Your problem is monitor EDID got from TMDS-1 DVI part on DVI-I port instead of VGA part on DVI-I. This has been fixed in current git master and 2.5 branch hopefully. If TV is also connected, initial modes might not be what you like, but that's xserver problem instead of driver's. zhenyu, Jesse has a patch for LVDS detection on barebone system. we need to make sure this machine is an exception according to what Jesse said in bug#11368c#58. ould you please verify Tormod's bios is broken? Hi, thanks for the feedback. > It will be good if you could try 2.5 driver. I only have hands-on access to this machine until tonight, and I can not risk screwing it up from its stable Ubuntu 8.04 setup... I will see how far I can get with live CDs and if I can get a git build done somewhere. > You should ignore your LVDS or provide us pci info Yes, as I said in my bug report, that's what I've done to be able to use it at all. I supposed this was a separate problem so I just reported it to Ubuntu so far, anyway here's the info: 00:02.1 Display controller [0380]: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller [8086:2792] (rev 04) Subsystem: AOPEN Inc. Unknown device [a0a0:0589] We have LVDS quirks for all Aopen 945GM/965GM, we may add for 915GM too. I guess the LVDS quirks may be not necessary now with Jesse changed LVDS detection logic (with VBIOS data) in 2.5 driver. I got latest git built (resulting Ubuntu packages that might be of interest to others: https://launchpad.net/~xorg-edgers/+archive) and tested it out with a recent drm and xserver 1.5.1/mesa 7.2. Unfortunately the system froze solid when X started up. In one case it initialized half of the screen, so maybe that's an indication that the output was enabled, but I can't be sure. Now there can be months before I will be hands-on at this system again, but I'll let you know how it goes. (In reply to comment #9) > I got latest git built (resulting Ubuntu packages that might be of interest to > others: https://launchpad.net/~xorg-edgers/+archive) and tested it out with a > recent drm and xserver 1.5.1/mesa 7.2. Unfortunately the system froze solid > when X started up. In one case it initialized half of the screen, so maybe > that's an indication that the output was enabled, but I can't be sure. Could you file a new bug for this? We would like to track issues on your machine with new code. would you please attach your vbios rom? you can get it via: # cd /sys/devices/pci0000\:00/0000\:00\:02.0/ # echo 1 > rom # cat rom > /tmp/rom.bin # echo 0 > rom thanks. Created attachment 20583 [details]
gzipped rom dump
Here's the vbios rom.
Testing out 2.5 and filing proper bugs for the new issues will have to wait until I am hands-on again, in about a month's time.
(In reply to comment #12) > Created an attachment (id=20583) [details] > gzipped rom dump > > Here's the vbios rom. > > Testing out 2.5 and filing proper bugs for the new issues will have to wait > until I am hands-on again, in about a month's time. > got any time to add "ModeDebug" "True" to driver section and give us the log? please use the minimal xorg.conf...not ignore LVDS and TMDS-1... thanks. Created attachment 20593 [details] [review] Add LVDS GPIO pin check in CRT This is test for your CRT resolution problem, CRT uses LVDS GPIO pin instead of GPIOA. We may parse this info from VBT tables, but here's a simple test patch to try. Patch is against git master. Created attachment 20594 [details] [review] LVDS quirk patch This one should be ready to push. Thanks again for all your attention to this. I only have sporadic ssh access to the machine, and I can't risk breaking anything that would need local interaction to get sorted out. So for instance git master with all its dependencies will have to wait. I can maybe fish out a ModeDebug log but can't promise anything until next month. Thanks for the patches, I am looking forward to trying them out. Meanwhile we could hope someone else running xorg on these machines could jump in. Tormod, haven't got a hand on the machine? :) We're not interested to know if VGA can work right on this hardware, actually via DVI-to-VGA adapter. If you could have a chance with it, please help us to get Xorg log with ModeDebug option on. Thanks a lot! (In reply to comment #17) > We're not interested to know if VGA can work right on this hardware, actually via DVI-to-VGA adapter. If you > could have a chance with it, please help us to get Xorg log with ModeDebug > option on. Thanks a lot! > not->now... (In reply to comment #17) > Tormod, haven't got a hand on the machine? :) We're not interested to know if > VGA can work right on this hardware, actually via DVI-to-VGA adapter. If you > could have a chance with it, please help us to get Xorg log with ModeDebug > option on. Thanks a lot! > the original report was using a DVI-to-VGA converter. What we want to prove is connect to the monitor using the DVI cable directly to see if VGA will be mis-detected as connected in this case... thanks, Michael Michael, thanks a lot for fix my wrong words. ;) My SDVO DVI-I detect patch is on #18124, or https://bugs.freedesktop.org/attachment.cgi?id=20804 Comment on attachment 20594 [details] [review] LVDS quirk patch I've pushed LVDS detect patch to git master, please help to test it, which should obselete quirk patch. Created attachment 21019 [details]
Only commented out monitor bindings
Here are the ModeDebug results. First, I just added ModeDebug and commented out the 4 monitor bindings from the Device section. But it seems the Monitor sections still were picked up somehow...
Created attachment 21020 [details]
modedebug log from the commented-out monitor bindings
Created attachment 21021 [details]
Stripped down xorg.conf
So I stripped down the xorg.conf to the default one, just adding ModeDebug.
Created attachment 21022 [details]
modedebug log from minimal conf
Michael said:
> the original report was using a DVI-to-VGA converter. What we want to prove is
connect to the monitor using the DVI cable directly to see if VGA will be
mis-detected as connected in this case...
I am not sure I understand this. The monitor only have a VGA socket, so it has to go through the adapter. So I can't help test this I guess.
In about two weeks time I will be hands-on at the machine and can test more seriously. Can you please clarify which patches and which combinations I should then try? I see git master now needs drm 2.4.2. Is this only the libdrm library? Can I use a stock (well, Ubuntu) 2.6.28 kernel?
If you want me to try some patches against 2.5.1 that's fine too. For this I think dependencies will be easier to sort out.
I have been building packages in the launchpad archive I mention above, but haven't tested them myself of course and other people have mixed results with different combinations of drm, libdrm, mesa, 2.5.1, 2.6...
(In reply to comment #27) > Michael said: > > the original report was using a DVI-to-VGA converter. What we want to prove is > connect to the monitor using the DVI cable directly to see if VGA will be > mis-detected as connected in this case... > > I am not sure I understand this. The monitor only have a VGA socket, so it has > to go through the adapter. So I can't help test this I guess. OK, never mind then. > > In about two weeks time I will be hands-on at the machine and can test more > seriously. Can you please clarify which patches and which combinations I should > then try? I see git master now needs drm 2.4.2. Is this only the libdrm > library? Can I use a stock (well, Ubuntu) 2.6.28 kernel? > > If you want me to try some patches against 2.5.1 that's fine too. For this I > think dependencies will be easier to sort out. > > I have been building packages in the launchpad archive I mention above, but > haven't tested them myself of course and other people have mixed results with > different combinations of drm, libdrm, mesa, 2.5.1, 2.6... > Tormod, your machine actually have several problems we need to fix. Literally we should track them in seperate bugs to avoid mess things up, but ..anyway. 1) LVDS is mis-detected as connected. As said in comment# 22, Zhenyu have pushed a patch and hopefully we can fix it. Please have a test of the driver in git repository to see if you still have LVDS detected. if you can't play with git, please let us know. 2) Your CRT doesn't seem using the default GPIO pins to get DDC from the attached monitors, it can't get EDID from your LCD monitor, thus you see the display is not good on your LCD. Zhenyu has a patch in comment# 14. Please try to see if it can 3) Your TMDS is also mis-detected as connected when you actually connect to a analog VGA monitor. Zhenyu has a patch in bug# 18124. Here is the link to the patch (https://bugs.freedesktop.org/attachment.cgi?id=20804). Please try to see if it fixed this problem for you, too. You can test the above issues one by one, and let us know the result via attach xorg.log with modedebug turns on. > we should track them in seperate bugs > it can't get EDID from your LCD monitor Are the three issues really unrelated? I guess you also noticed that the EDID from the LCD monitor is indeed picked up, it's just attributed to the LVDS instead of the VGA output. For me (understanding much less than you guys) it looks like two pins have been swapped. Thanks for the patch overview. I have no problem building drivers, I am just concerned about hidden dependencies on drm versions, git drm vs in-kernel drm, libdrm vs drm modules versions etc. I meant "attributed to the TMDS-1 output". Building current driver only depends on newer libdrm, that hasn't been released, so you have to get it from git, try git clone git://anongit.freedesktop.org/git/mesa/drm, then ./autogen.sh --prefix=xxx; make; make install Tormod Volden, any test update? thanks. Created attachment 21470 [details]
from trunk Dec 20th
As planned, I have now at the machine and can do some testing. First I tried a build from git Dec 20th, with minimal xorg.conf. Pretty much as before, so I think (1) above was not successful here.
Created attachment 21471 [details]
added the 2 patches "gpio" and "svdo"
Added these two patches:
0001-Add-LVDS-GPIO-pin-check-in-CRT-detect.patch
0001-SDVO-use-EDID-digital-info-for-detect-in-TMDS-outpu.patch
I now get a picture, but not the correct resolution.
Created attachment 21514 [details]
only the "gpio" patch
I also tested with only the "gpio" patch applied. This gives a black screen (see log) unless I ignore the TMDS-1 output (and the LVDS output).
Created attachment 21515 [details]
both patchs, TV connected
I tried again with both patches, and since this time the TV was connected and turned on, the computer screen got black. It seems LVDS and TV each got a pipe, and VGA not. Whereas in my first try, TV was off, so VGA and LVDS got the pipes. Nothing new I guess, just attaching the log for completeness.
Zhenyu, about issue (1) it seems like SWF14_LID_SWITCH_EN is not reliable on this computer (and I have no /proc/acpi/button/lid), SWF14 is either 0xc0820000 or 0xc0000000. If you have other suggestions, patches or test cases for any of the issues, I will be happy to try them out, but I only have a few days more of access. Tormod, It seems that Issue (3) has been fixed by 0001-SDVO-use-EDID-digital-info-for-detect-in-TMDS-outpu.patch. For Issue (2) , the debug patch doesn't work. looks like your CRT port doesn't have EDID link to monitor. Would you please rerun your test in comment# 33 and attach the log? To turn on modedubug, add Option "ModeDebug" "True" to the device section. thanks. (In reply to comment #37) > Zhenyu, about issue (1) it seems like SWF14_LID_SWITCH_EN is not reliable on > this computer (and I have no /proc/acpi/button/lid), SWF14 is either 0xc0820000 > or 0xc0000000. > yeah, so I've pushed LVDS quirk for this. > If you have other suggestions, patches or test cases for any of the issues, I > will be happy to try them out, but I only have a few days more of access. > Use fresh git master and apply https://bugs.freedesktop.org/attachment.cgi?id=20804, first try without TV connected. Created attachment 21547 [details] debug log, with minimal xorg.conf and TV disconnected Thanks for getting back to me so quickly. Here is the log from latest git master with the svdo patch applied. If the ModeDebug option needs "True" you should maybe fix it in the driver, because it is usually enough to use the option name alone. man xorg.conf: Boolean options may optionally have a value specified. When no value is specified, the option’s value is TRUE. > looks like your CRT port doesn't have EDID link to monitor. As you can see in http://bugs.freedesktop.org/attachment.cgi?id=21022 the EDID information is retrieved, but is attributed to the wrong port. >
> > looks like your CRT port doesn't have EDID link to monitor.
>
> As you can see in http://bugs.freedesktop.org/attachment.cgi?id=21022 the EDID
> information is retrieved, but is attributed to the wrong port.
>
yeah, that's what I mean. DVI-I port should have EDID pins connected to both VGA and DVI-D, but the log shows that only the DVI-D port have connections to retrieve the EDID.
Could this be the fault of the DVI-to-VGA adapter? I can not test anything else but I can measure on the adapter pins. Seems like the manufacturers have done a good job at obfuscating the hardware. Ironically these PCs were once touted as the Linux answer to MacMini: http://www.linuxdevices.com/news/NS8464432110.html I wonder if for instance Linspire patched the drivers. Let's move on with this bug. So, issue 1) and 3) has been fixed according to comment# 39 and comment# 38. Tormod Volden, you can try to see if change a DVI-to-VGA adapter would help to eliminate the possibility. i think we are ready to close this bug. thanks. Michael, it may be months before I can test anything on this system. BTW, the DVI-to-VGA adapter was delivered with the machine (from Aopen). From looking at http://en.wikipedia.org/wiki/Digital_Visual_Interface I have the impression there is only one pair of DDC pins, corresponding with this: DVI-6 DDC clock <> VGA-15-SCLK DVI-7 DDC data <> VGA-12-SDATA (pasted from http://pinouts.ru/forum/index.php?PHPSESSID=f233163f80ed9cade196a902eb6be056&topic=286.msg642#msg642) I can verify these connections on the adapter itself, but the computer is indeed receiving DDC, so I am not sure what the adapter can do wrong. The wikipedia page says also "If a display supports both analog and digital signals in one input, each input can host a distinct EDID. If both receivers are active, analog EDID is used." but that is about the monitor and not the computer side. Anyone knows how this is supposed to work? Tormod Volden, you're right. actually, I didn't expect that it's the adapter's fault. Likely, it's because the machine vendor didn't connect the DDC pin on the DVI port to GPIO pins that VGA can reach. You can use a modeline to workaround this. Thanks. Yes, I have been using a modeline (and Ignore's) since the start, except when doing tests for you. Would it be possible to add a hardware specific quirk for this? I don't know if for instance Windows drivers get this right, but I would guess so. I am happy to provide more testing and debugging, but as I said, it will have to wait for months. Anyway, thanks for all the improvements! We have at least got rid of the black screens, which was really a newbie-blocker for Xorg on these machines. yeah, in fact, "fix" to this bug is to quirk it, but basically the quirk is to steal EDID from TMDS to VGA. Rather doing that, maybe a modeline is easier solution for such HW issue.. :) Patch for issue 3 has also been pushed. So close this one. thanks. commit 37c67088a887e6380571e6eec8a8f058e3e24717 Author: Zhenyu Wang <zhenyu.z.wang@intel.com> Date: Wed Feb 11 15:15:27 2009 +0800 SDVO: check EDID info for DVI-I For SDVO DVI-I, check EDID info for digital output, otherwise mark it to be disconnected as analog output is driven by VGA then. Created attachment 27640 [details]
dmidecode (reference for KMS quirk)
Created attachment 27674 [details]
acpidump output (WRONG)
Created attachment 27685 [details]
acpidump output
|
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.