|
Description
Vance
2009-12-23 20:04:05 UTC
Created attachment 32274 [details]
Xorg log when 1 display connected
Created attachment 32275 [details]
xrandr output with 2 displays connetced
Created attachment 32276 [details]
Xorg log with 2 displays attached
xorg-server version used was 1.6.5. Will you please add the boot option of "drm.debug=0x06" on the 2.6.32.2 kernel and attach the output of dmesg? thanks. ykzhao, SLE11-SP1 Beta1 has still Kernel 2.6.32 (not sure if SLE11-SP1 will ship Kernel 2.6.32.2). I've seen the following commits to drivers/gpu/drm/i915 between 2.6.32.1 and 2.6.32.2 (no commits below this directory between 2.6.32 and 2.6.32.1). drm/i915: Set the error code after failing to insert new offset into mm ht. drm/i915: Add the missing clonemask for display port on Ironlake drm/i915: Fix sync to vblank when VGA output is turned off drm/i915: Avoid NULL dereference with component_only tv_modes drm/i915: PineView only has LVDS and CRT ports drm/i915: Fix LVDS stability issue on Ironlake Do you believe any of these commits addresses that issue? Otherwise I suggest to go ahead testing with 2.6.32 kernel of SLE11-SP1. 2.6.32 kernel is fine too, please attach the dmesg with drm.debug=0x06 kernel parameter added. thanks. Created attachment 32339 [details]
dmesg with drm.debug=0x06 option on 2.6.32 kernel
Hi, any updates on this? Let me know if more information is required. (In reply to comment #6) > ykzhao, SLE11-SP1 Beta1 has still Kernel 2.6.32 (not sure if SLE11-SP1 will > ship Kernel 2.6.32.2). I've seen the following commits to drivers/gpu/drm/i915 > between 2.6.32.1 and 2.6.32.2 (no commits below this directory between 2.6.32 > and 2.6.32.1). > drm/i915: Set the error code after failing to insert new offset into mm ht. > drm/i915: Add the missing clonemask for display port on Ironlake > drm/i915: Fix sync to vblank when VGA output is turned off > drm/i915: Avoid NULL dereference with component_only tv_modes > drm/i915: PineView only has LVDS and CRT ports > drm/i915: Fix LVDS stability issue on Ironlake > Do you believe any of these commits addresses that issue? Otherwise I suggest > to go ahead testing with 2.6.32 kernel of SLE11-SP1. Hi, Stefan The issue on Vance's box is not related with the above commit. And there is no difference even when the above commit is applied. Anyway, thanks for pointing out the difference between 2.6.32.1 and 2.6.32.2. thanks. (In reply to comment #8) > Created an attachment (id=32339) [details] > dmesg with drm.debug=0x06 option on 2.6.32 kernel Hi, Vance Thanks for the testing. From the dmesg log it seems that it reports the following info when detecting whether the external monitor is connected with the SDVO card. >[drm:intel_sdvo_detect], SDVO response 0 0 In such case it will be thought that no external monitor is connected. Will you please double check whether the external monitor is connected? Can you try the 2.6.33-rc3 kernel and attach the output of dmesg after the system is booted? (The boot option of "drm.debug=0x06" is required. BTW: the external monitor had better be connected before booting). Thanks. Created attachment 32490 [details]
xrandr output with two displays connected on boot
Hi, I have compiled and installed the 2.6.33rc3 kernel and extracted the xorg log with the drm.debug=0x06 kernel option and xrandr output with two displays connected to the video adapter. Both displays were already connected on boot.
Seems like xrandr is still detecting only one VGA1 output when both displays are connected. When only one display is connected on boot, there will be a VGA1 and a TV1 output listed.
Created attachment 32491 [details]
dmesg with drm.debug=0x06 option
Is the provided information sufficient? Created attachment 32620 [details] [review] try the debug patch which detects the S-video after SDVO-RGB Sorry that I forget to attach the patch. Will you please try the debug patch on 2.6.33-rc3 kernel and attach the output of dmesg? (the boot option of "drm.debug=0x06" is required). Thanks. Yakui. Created attachment 32649 [details]
dmesg
Hi, I've compiled the 2.6.33-rc3-0.6.8 kernel after applying the patch and now xrandr is able to detect correctly the second connected display at VGA2. Dual display modes are also found to be working. This is great. Will the patch be applicable to earlier versions of the kernels like 2.6.32? Thanks.
(In reply to comment #15) > Created an attachment (id=32620) [details] > try the debug patch which detects the S-video after SDVO-RGB ykzhao, are you planning to submit this patch also to Linus kernel tree? gregkh is asking since usually never accepts a patch for the SUSE kernel, which isn't scheduled to upstream kernel as well. Intel Michael/YZ we look forward to you respond to the question posted in comment#16. Will the patch be applicable to earlier versions of the kernels like 2.6.32? If yes, could you submit it to upstream? Novell needs to pick up from there for it to be included in SUSE kernel release. (In reply to comment #18) > Intel Michael/YZ > > we look forward to you respond to the question posted in comment#16. > Will the patch be applicable to earlier versions of the kernels like 2.6.32? > > If yes, could you submit it to upstream? Novell needs to pick up from there for > it to be included in SUSE kernel release. Now I am trying to find the proper solution for this issue. After this is finished, I will attach it. thanks. > Thank you YaKui for you status update. Roughly when can you finish and attached it to upstream? Hi, any further developments? Thanks. official fix will be sent out in this week. thanks. Created attachment 32863 [details] [review] Detet SDVO-VGA before SDVO-TV for multi-function SDVO card This is the workaround patch and it can fix this issue on such multi-function SDVO card. Thanks. Thanks for the updated patch, I have compiled it on a 2.6.32 kernel and dual display is working properly. Have this patch been committed, and if not when do you intent to commit it? Thanks. (In reply to comment #24) > Thanks for the updated patch, I have compiled it on a 2.6.32 kernel and dual > display is working properly. Have this patch been committed, and if not when do > you intent to commit it? Thanks. The patch is already sent to intel-gfx mailing list. And we will wait for some time before it can be commited. Will you please attach the vbios.dump on your box? The vbios.dump can be obtained by using the following command: > echo 1 > /sys/devices/pci0000:00/0000:00:02.0/rom > cat /sys/devices/pci0000:00/0000:00:02.0/rom >vbios.dump > echo 0 > /sys/devices/pci0000:00/0000:00:02.0/rom thanks. (In reply to comment #24) > Thanks for the updated patch, I have compiled it on a 2.6.32 kernel and dual > display is working properly. Have this patch been committed, and if not when do > you intent to commit it? Thanks. > Will you please also attach the output of dmidecode on your box? thanks. Yakui Created attachment 32988 [details]
vbios dump
Created attachment 32989 [details]
dmidecode
The logs as you requested.
Vance, is the second VGA connector provide by a pluggable card or built on the motherboard directly? thanks. Hi Michael, the secondary display port is built on the motherboard. Created attachment 33021 [details] [review] Use the dmi quirk to initialze some SDVO card as SDVO-VGA Thanks for the confirmation that it is built on the motherboard. Will you please try the attached patch and see whether it can work for you? Thanks. Yakui Hi, this is to be applied on the original intel_sdvo.c and not the one patched with the previous patch right? Thanks. Created attachment 33022 [details] [review] Use the dmi quirk to initialze some SDVO card as SDVO-VGA Will you please try the updated patch and see whether the issue can be fixed? thanks (In reply to comment #32) > Hi, this is to be applied on the original intel_sdvo.c and not the one patched > with the previous patch right? Thanks. > yes. thanks. Hi, I tried out this patch. Something weird happened though, the secondary port is still detected correctly as VGA2 but using the same xorg configuration I used previously, I couldn't get extended desktop to work. The secondary display is blank and the primary display is only running a single normal desktop. I'm attaching a few logs here so you can see if anything went wrong. Created attachment 33046 [details]
Xorg.log
Created attachment 33047 [details]
xorg.conf
Created attachment 33048 [details]
dmesg.log with drm.debug
(In reply to comment #35) > Hi, I tried out this patch. Something weird happened though, the secondary port > is still detected correctly as VGA2 but using the same xorg configuration I > used previously, I couldn't get extended desktop to work. The secondary display > is blank and the primary display is only running a single normal desktop. I'm > attaching a few logs here so you can see if anything went wrong. > vance, if without the xorg.conf at all, can you get something on the second display by default when the system boot up? thanks. After removing the xorg.conf, there is still nothing on the secondary display. I tried using xrandr to set the extended mode but nothing happened. (In reply to comment #38) > Created an attachment (id=33048) [details] > dmesg.log with drm.debug > From the dmesg log in comment #37 it seems that the driver doesn't set the corresponding mode for VGA-2 output device.(For the VGA-1 we can find the following info in dmesg and we can know that it sets the correct mode. But we can't find the corresponding info for VGA-2). >[drm:drm_crtc_helper_set_config], setting connector 5 crtc Will you please confirm whether the VGA-2 can work by using following command after X is started? > xrandr --output VGA-2 --mode 1024x768 It will be great if you can do the test on 2.6.33-rcX kernel.(Of course the patch in comment #33 is still required). Thanks. Yakui (In reply to comment #41) > (In reply to comment #38) > > Created an attachment (id=33048) [details] [details] > > dmesg.log with drm.debug > > > From the dmesg log in comment #37 it seems that the driver doesn't set the > corresponding mode for VGA-2 output device.(For the VGA-1 we can find the > following info in dmesg and we can know that it sets the correct mode. But we > can't find the corresponding info for VGA-2). > >[drm:drm_crtc_helper_set_config], setting connector 5 crtc > > > Will you please confirm whether the VGA-2 can work by using following command > after X is started? > > xrandr --output VGA-2 --mode 1024x768 > do you mean VGA2 instead of VGA-2? > It will be great if you can do the test on 2.6.33-rcX kernel.(Of course the > patch in comment #33 is still required). > > Thanks. > Yakui > Yes. It should be VGA2 instead of VGA-2. Sorry that I mix the output name with that in kernel driver.
thanks.
>
Created attachment 33052 [details] [review] redefine the clonemaks for SDVO-VGA and VGA Will you please also try the attached patch and see whether it is helpful? The patch in comment #33 is still required. Thanks. Yakui Hi, thanks for the updates. I tried the patch from comment34 but I got the following error: patching file drivers/gpu/drm/i915/intel_crt.c Hunk #1 succeeded at 537 (offset -3 lines). patching file drivers/gpu/drm/i915/intel_sdvo.c patch unexpectedly ends in middle of line Hunk #1 FAILED at 2357. 1 out of 1 hunk FAILED -- saving rejects to file drivers/gpu/drm/i915/intel_sdvo.c.rej /match> The same error was observed on both the 2.6.33-rc3 and 2.6.22 kernels. This patch was applied after applying the patch from comment 33. Created attachment 33053 [details]
intel_sdvo.c.rej
Without the latest patch, running xrandr --output VGA2 --mode 1024x768 returns xrandr: cannot find crtc for output VGA2 (In reply to comment #47) > Without the latest patch, running xrandr --output VGA2 --mode 1024x768 returns > xrandr: cannot find crtc for output VGA2 > Can you attach the output of dmesg on 2.6.33-rc3 kernel after running the following command? (the boot option of "drm.debug=0x04" is added). a. xrandr -q --verbose b. xrandr --output VGA2 --mode 1024x768 --crtc 1 The output of xrandr -q --verbose is also needed. Thanks. Yakui Created attachment 33085 [details] [review] redefine the clonemaks for SDVO-VGA and VGA I update the patch on 2.6.33-rc3. Please try it. thanks. Hi Yakui, I used your patch on a 2.6.33-rc3 kernel after applying the patch in comment 33. The dual outputs are detected correctly and the extended desktop is displayed properly as well. I'm attaching the dmesg and xrandr logs for you to verify. Created attachment 33089 [details]
xrandr
Created attachment 33090 [details]
dmesg
(In reply to comment #50) > Hi Yakui, I used your patch on a 2.6.33-rc3 kernel after applying the patch in > comment 33. The dual outputs are detected correctly and the extended desktop is > displayed properly as well. I'm attaching the dmesg and xrandr logs for you to > verify. > so, even without patch in comment# 49, right? Previously, you tested the same patch in comment# 33 in .32 kernel, right? So looks like there is something changed between .32 and .33 that makes the patch didn't work in .32... thanks for the testing, Vance! Created attachment 33099 [details] [review] Add some debug info related with the crtc/output Hi, Vance Thanks for the testing. I agree with what Michael said in comment #53. The SDVO-card can work on 2.6.33-rc3 kernel. But it can't work on 32.kernel. Will you please try the attached patch on 32 kernel and attach the output of dmesg, xrandr -q --verbose? (Please still add the boot option of "drm.debug=0x04". And the patch in comment #33 is still needed). Thanks. Hi Michael and Yakui, my results in comment#50 came from applying both the patches from comment #33 and #49 to the 2.6.33 kernel. I have not tried both patches on a 32 kernel. I'll go ahead and test both patches on the 32 kernel and report back here. (In reply to comment #55) > Hi Michael and Yakui, my results in comment#50 came from applying both the > patches from comment #33 and #49 to the 2.6.33 kernel. I have not tried both > patches on a 32 kernel. I'll go ahead and test both patches on the 32 kernel > and report back here. > Vance, could you pls confirm _without_ patch in comment# 49 but just the patch in comment# 33, will it work? In comment# 24, you said applying the patch in comment# 23 on 2.6.32 kernel, and it works. In comment# 38, you attached a dmesg which is 2.6.32.5 with only patch in comment# 33 applied. it breaks. technically, patch in comment# 23 and comment# 33 really makes no difference but just skip the SDVO-SVIDEO detection. so we are wondering why patch in comment# 33 doesn't work in .32 kernel while patch in comment# 23 does... yakui's latest debug patch in comment# 54 is just prink, so please apply it in your test and give us dmesg. I'll appreciated if you can state exactly what patche(s) are applied on which version of kernel in your later test, it'll help us figure this out sooner. thanks! HI, Vance
Will you please do the test as suggested in comment #56?
Please apply the patch in comment #33 and #54 on .32 kernel and attach the output of dmesg.
Please only apply the patch in comment #33 on 2.6.33-rc3 kernel and see whether the second VGA can work. Please attach the output of dmesg.
BTW: The boot option of "drm.debug=0x04" had better be added in your test.
thanks.
Created attachment 33151 [details] dmesg log I have retested using only the patch in comment 33 on a 2.6.32 kernel and it is working fine in extended dual display mode. The secondary output is also correctly detected. Either I had compiled the kernel wrongly the first time round or I had used the patch in comment 31 instead. Please help to commit this patch upstream as soon as you can. Thanks for working so closely on resolving this issue. Hi Yakui, any updates on whether the upstream kernel has accepted this patch? Thanks. Sorry for the delay, Vance. Last word I had from Yakui on this patch was "This patch still has some problems. Please ignore this patch" back on the 8th. However, since it's working for you, and the risk to others is low, I've cleaned it up and pushed it for drm-intel-next, which means it should land in a 2.6.33 update shortly. commit bfee3e822746f26395a10602a3a7c3baac107972 Author: Zhao Yakui <yakui.zhao@intel.com> Date: Mon Feb 8 21:35:12 2010 +0800 drm/i915: Use a dmi quirk to skip a broken SDVO TV output. This IBM system has a multi-function SDVO card that reports both VGA and TV, but the system has no TV connector. The TV connector always reported as connected, which would lead to poor modesetting choices. https://bugs.freedesktop.org/show_bug.cgi?id=25787 Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Tested-by: Vance <liangghv@sg.ibm.com> Cc: stable@kernel.org Signed-off-by: Eric Anholt <eric@anholt.net> Hi, I have another machine using the 915GM video chipset that appears to have similar secondary output detection issue as raised in this thread. The secondary output is detected as a TV output instead of a VGA output. I tried to use the patch provided here but it looks like the patch is targeted specifically at the G45 chipset and on the 4800-784 machine. Should I open a separate bug for this issue? Thanks. Created attachment 33682 [details] [review] intel encoder/connector rework for multifunction SDVO support Vance, could you help to test if this patch works for you? yeah, it's large. And if you have problem to apply it onto previous Yakui's quirk patch, you may first revert that patch as well. thanks. (In reply to comment #62) > Created an attachment (id=33682) [details] > intel encoder/connector rework for multifunction SDVO support > > Vance, could you help to test if this patch works for you? yeah, it's large. > And if you have problem to apply it onto previous Yakui's quirk patch, you may > first revert that patch as well. > > thanks. > Hi Zhenyu, does this latest patch require Ya kui's patch to resolve this issue? I tried patching it on a 2.6.32 kernel but there are a number of failed chunks even without Ya Kui's patch. I will try again with the latest 33 kernel. Also with regards to my previous question where I have another chipset facing what I believe is a similar issue, will this patch work for that chipset as well? Thanks. 1. no need for yakui's quirk patch 2. yes, it should fix the issue on your other platform as well, if everything work as expected. Created attachment 33704 [details]
xrandr output
Hi, I've given the patch a try on a 2.6.33 kernel but it seems like the secondary VGA port is detected as not connected. I'll be attaching the relevant logs here. Is this latest patch going to replace the one proposed by Ya Kui that has already been committed to the kernel tree?
Created attachment 33705 [details]
Xorg.0.log
Created attachment 33706 [details]
dmesg
Hi, any updates on this? Thanks. (In reply to comment #68) > Hi, any updates on this? Thanks. Will you please try the updated patch in the following and see whether it works for you? >http://lists.freedesktop.org/archives/intel-gfx/2010-March/006063.html thanks. > Hi Yakui, I tested the latest patch from http://lists.freedesktop.org/archives/intel-gfx/2010-March/006063.html on the 2.6.33 kernel and the secondary VGA output is detected and working correctly. Are there any logs you like to see? Hi Yakui, as this patch http://lists.freedesktop.org/archives/intel-gfx/2010-March/006063.html been successfully committed into the upstream kernel? Also has the previous patch been reverted up stream as well? Looking at this site( http://git.kernel.org/?p=linux/kernel/git/anholt/drm-intel.git;a=commit;h=6070a4a928f8c92b9fae7d6717ebbb05f425d6b2), I can't see whether it's been acknowledged. Thanks. (In reply to comment #71) > Hi Yakui, as this patch > http://lists.freedesktop.org/archives/intel-gfx/2010-March/006063.html been > successfully committed into the upstream kernel? Also has the previous patch > been reverted up stream as well? Looking at this site( > http://git.kernel.org/?p=linux/kernel/git/anholt/drm-intel.git;a=commit;h=6070a4a928f8c92b9fae7d6717ebbb05f425d6b2), > I can't see whether it's been acknowledged. Thanks. The patch is not commited to the upstream kernel. And the commit(6070a4a928f8c92b9fae7d6717ebbb05f425d6b2) is not reverted, either. Thanks. > Hi Yakui, thanks for the reply. If this is the case, I need to know which patch is the intended fix that will be submitted upstream to fix this issue. Novell is waiting to integrate this patch into their kernel but they will only do it once it's been committed and accepted upstream. We have a narrow window for them to include this fix into their kernel so appreciate if you could help us clarify and/or expedite the process. Thanks. |
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.