Created attachment 33678 [details] dmesg with drm.debug=0x04 boot parameter ---Problem Description--- Secondary display detected as TV out instead of VGA on Intel 915GM video chipset. Contact Information = Vance/liangghv@sg.ibm.com ---uname output--- 2.6.32.8-0.3-pae Machine Type = 4810-340 ---Debugger--- A debugger is not configured ---Steps to Reproduce--- Install SLED 11 SP1 Beta 5 on the machine. Use Xrandr to see the available video outputs
Created attachment 33679 [details] lspci
Created attachment 33680 [details] Xorg log
Reassign as this is related to bug#25787
Created attachment 33882 [details] dmesg with drm.debug=0x04 boot parameter Hi, I've tested the patch from http://lists.freedesktop.org/archives/intel-gfx/2010-March/006063.html which is supposed to provide multifunction SDVO output support based off bug 25787. It worked for the G45 chipset but did not work for this 915GM chipset. I'm attaching the usual logs. Appreciate if you can take a look at this. Thanks.
Created attachment 33883 [details] Xorg log
Created attachment 33886 [details] xrandr output
(In reply to comment #4) > Created an attachment (id=33882) [details] > dmesg with drm.debug=0x04 boot parameter > > Hi, I've tested the patch from > http://lists.freedesktop.org/archives/intel-gfx/2010-March/006063.html which is > supposed to provide multifunction SDVO output support based off bug 25787. It > worked for the G45 chipset but did not work for this 915GM chipset. I'm > attaching the usual logs. Appreciate if you can take a look at this. Thanks. Can you also try the patch from http://lists.freedesktop.org/archives/intel-gfx/2010-March/006063.html on the laptop based on 915gm chipset? It seems that the attached log in comment #4 doesn't use the patch. thanks. >
Please use 'drm.debug=6' in boot param for more debug info. This looks strange, drm connector sysfs add failed because of same connector name. But in this case we should have VGA-2 for SDVO VGA, and VGA-1 for integrated VGA...
oh, sorry, I mean 'drm.debug=7'.
Hi Yakui, you're right, the machine wasn't running the patch because I loaded the wrong kernel. I have since tested with the latest 33 kernel with the patch http://lists.freedesktop.org/archives/intel-gfx/2010-March/006063.html. The secondary display is now correctly detected as VGA2. But the weird thing is that the desktop would black out after a while, leaving only the cursor still visible and movable. The OS isn't hung as I can still execute commands and ctl-alt-F1 out into the console and the console is visible. The only way to correct this is to do a reboot or to restart X. I will test again with the default 33 kernel without this patch to see whether the patch caused it. In the meantime are there any other information I can provide? Thanks.
Hi, I have retested the SDVO multifunction patch on the 33 kernel and I'm still seeing the issue in extended desktop mode where both desktops blank out after logging in. I have not been able to replicate this in dual twin mode. Should I open this issue up in a separate bug thread? I'll attach the logs for you to gauge if it is related to the patch. Thanks.
Created attachment 33932 [details] xorg log
Created attachment 33933 [details] dmesg with drm.debug=0x07 boot parameter
(In reply to comment #11) > Hi, I have retested the SDVO multifunction patch on the 33 kernel and I'm still > seeing the issue in extended desktop mode where both desktops blank out after > logging in. I have not been able to replicate this in dual twin mode. Should I > open this issue up in a separate bug thread? I'll attach the logs for you to > gauge if it is related to the patch. Thanks. > Please don't use the extended desktop and see whether the issue still exists. thanks.
If this is 915G, then that's a known issue with hardware render target limit of 2048 width. Not sure what composite manager openSUSE uses, e.g you may try to disable compiz, in gnome disable System->Preferences->Appearance->Visual Effects, and try extended desktop again.
It appears this problem only happens on extended mode, if I remove the secondary display configuration then I can't reproduce it. As mentioned in the previous comment, I also wasn't able to reproduce it in Dual Twin/Clone mode. Hi Zhenyu, I've tried out your suggestion and disabling compiz does allow the machine to work in extended mode. Is this the only option we have that will allow extended desktop to work on the 915 chipset, or is this being worked on by some party? By the way, I was using 1024x768 on both displays so the virtual desktop resolution shouldn't exceed the 2048 limit. Thanks.
Vance, this is bug #23718. And we now have a fix in mesa 7.7 stable release. I think this bug could be closed now. Thanks for testing!
Hi Zhenyu, the distribution I'm testing on is already using mesa 7.7 which includes the fix but I am still seeing the screen blanking issue. Should I open up the issue in a new bug? Also do you have a time frame when you will commit this SDVO multifunction patch into the upstream kernel? We'll need to pick it up from there to include into the distribution we are using. Thanks.
Any updates?
Hi Yakui, Zhenyu, appreciate if I can get some feedback on my question in comment 18. Thanks.
Vance, sorry for late reply. I'm not quite sure if the mesa fix has been in 7.7, or have you tried mesa 7.8 release? You'd better ask Ian or Gordon on which release to pick up. I've sent new patch set for resolve multifunction SDVO issue, but our maintainer is on vocation now, so review and commit process may be delayed. I'm not sure what's your target kernel version to include this?
Hi Zhenyu, thanks for the reply. The fix is already in mesa 7.7 in the distribution we are using now. I got that confirmation from novell. Should I raise a separate bug for this issue? The kernel we will need to include the multifunction sdvo patch is 2.6.32. Any idea when your maintainer will be back? We really need to pick up this patch asap. Thanks.
(In reply to comment #22) > Hi Zhenyu, thanks for the reply. The fix is already in mesa 7.7 in the > distribution we are using now. I got that confirmation from novell. Should I > raise a separate bug for this issue? I think this should be fixed by commit f23d01e726a57cd6b8e31f1049ee5853773df7ea Author: Ian Romanick <ian.d.romanick@intel.com> Date: Tue Dec 15 12:14:04 2009 -0800 intel: Fallback to software if drawable size is > MaxRenderbufferSize This prevents the mystery blank window if, for example, glxgears is resized larger than 2048 wide on 915. Since the Intel drivers in Mesa 7.6 lack GTT mapped fallbacks, the performance is a slideshow at best. On Mesa 7.7 and later the performance is much better. But if you still see issue on Pineview, feel free to open new bug. > > The kernel we will need to include the multifunction sdvo patch is 2.6.32. Any > idea when your maintainer will be back? We really need to pick up this patch > asap. Thanks. > I have my patch set pushed to my personal git tree at http://cgit.freedesktop.org/~zhen/drm-intel 'encoder-rework' branch. It's not finally acked by maintainer yet. And I don't think we have plan to backport this to 2.6.32 kernel...You can pull it and see if it could be applied ok to .32 kernel.
Hi Zhenyu, thanks for posting up the patch. However, novell will not pick it up until it has been accepted into the mainstream kernel. So we will need your assistance to push this patch through. As for the the 32 kernel, I have tried the patch on this kernel before but encountered a few chunks in the patch that couldn't be applied. Those failed chunks will have to be manually patched in. But we will need the patch to be upstream before novell will attempt that. Thanks.
(In reply to comment #24) Hi, Vance Sorry for the late response. Now the patch set in http://cgit.freedesktop.org/~zhen/drm-intel 'encoder-rework' branch is already in Eric's drm-intel-next. Maybe it will hit the upstream kernel very soon. thanks Yakui
Hi, Vance Do you have an opportunity to try the Eric's drm-intel-next tree and double check whether the issue can be fixed? the Eric's drm-intel-next tree can be obtained by using the following commands: git clone git://git.kernel.org/pub/scm/scm/linux/kernel/git/anholt/drm-intel.git git branch -r git checkout -b origin/drm-intel-next Thanks.
Hi Yakui, good to hear from you again. Unfortunately I am away from work this week. I can try out the patch from Eric's tree next week. However, if the patch hasn't changed then I'm pretty sure it will work. I will update this thread again. Also please let us know once the patch is upstream, thanks.
Hi Yakui, I tried pulling the patch from eric's tree at http://git.kernel.org/?p=linux/kernel/git/anholt/drm-intel.git;a=commit;h=14571b4c1ac9c109f5d6d6e95cfdb92339151fe0. This patch seems quite different from the one I last tested at http://lists.freedesktop.org/archives/intel-gfx/2010-March/006063.html. I tried applying the patch from eric's tree and 22 out of 33 hunks failed on the 2.6.33 kernel. Does the patch require any previous patches to work? I tried your command: git clone git://git.kernel.org/pub/scm/scm/linux/kernel/git/anholt/drm-intel.git but got the error fatal:could not create work tree dir 'drm-intel': Input/output error. Please advise.
(In reply to comment #29) > Any updates? Sorry for the late response. Sorry for the typo(One scm is redundant). It should be : git clone git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel.git The patch set in Eric's tree can't be applied directly on 2.6.33 stable kernel. Before the patch set is applied, a lot of other patch set are applied. In fact the updated patch set has the same idea with the previous patch set. The difference is that some structures are changed a little and patch order is rearranged. Will you please the updated command and get the Eric's tree? After getting the Eirc's drm-intel-next tree, you can compile it directly on it. Thanks.
Hi Yakui, good to hear from you. This may pose as a challenge because we need novell to integrate this fix into their kernel and they will need to know the specific patches upstream required to make this work. It would help us immensely if you can help us pinpoint those patches instead of just updating all the patches in the tree. Thanks.
What specific patch (or patches) solves this problem?
Hi Yakui, please advice on my previous question about which are the required patches. Thanks.
Hi, can anyone help us answer the previous question as to which are the specific patches upstream that is relevant to the SDVO multifunction fix for this issue? Thanks.
Have you found the right patches for this yet?
*** Bug 25115 has been marked as a duplicate of this bug. ***
Hi, I'm coming from Bug 25115 (https://bugs.freedesktop.org/show_bug.cgi?id=25115), and, following the instructions there, I installed ppa xordg-edgers, but the problem stays the same: - booting with 'nomodeset': xrandr does NOT recognize any outputs - booting with external monitor disconnected: when connected, gets the TV output, and max resolution of 1360x768 while its resolution is 1920x1600 - booting with external monitor connected: detected as VGA1, but with low resolution, and xrandr commands don't work when trying to set correct resolution Just as a reminder, when using linux 9.04, it was working OK booting with nomodeset option. Regards.
commit 14571b4c1ac9c109f5d6d6e95cfdb92339151fe0 Author: Zhenyu Wang <zhenyuw@linux.intel.com> Date: Tue Mar 30 14:06:33 2010 +0800 drm/i915: implement multifunction SDVO device support With new intel_encoder/intel_connector structure change, each supported connector type on SDVO device will be created as a new 'intel_connector', and all attached to one 'intel_encoder' for its SDVO port. The SDVO encoder will handle SDVO protocol stuff, and each connector does its own part of work now, like detection is only to check if current active output is itself, etc. Update since last submit: - Fixed SDVO TV property creation failure by incorrect set target output cal Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> commit b1083333de5357577c5ec55df6c7efa17bee41c7 Author: Adam Jackson <ajax@redhat.com> Date: Fri Apr 23 16:07:40 2010 -0400 drm/i915: Fix DDC bus selection for multifunction SDVO Multifunction SDVO cards stopped working after 14571b4, and would report something that looked remarkably like an ADD2 SPD ROM instead of EDID. This appears to be because DDC bus selection was utterly horked by that commit; controlled_output was no longer always a single bit, so intel_sdvo_select_ddc_bus would pick bus 0, which is (unsurprisingly) the SPD ROM bus, not a DDC bus. So, instead of that, let's just use the DDC bus the child device table tells us to use. I'm guessing at the bitmask and shifting from VBIOS dumps, but it can't possibly be worse. cf. https://bugzilla.redhat.com/584229 Signed-off-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Eric Anholt <eric@anholt.net> commit 149c36a346f63fa4be7d1432d7b1b3095a95bf47 Author: Adam Jackson <ajax@redhat.com> Date: Thu Apr 29 14:05:18 2010 -0400 drm/i915: Be extra careful about A/D matching for multifunction SDVO If we're both RGB and TMDS capable, we'll have set up one connector for each. When determining connectivity, require analog/digital state in the EDID block to match analog/digital support in the connector. Otherwise, both DVI and VGA will appear to be connected. Signed-off-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Eric Anholt <eric@anholt.net> and quite a few supporting commits should have fixed this ;-) If you can see it in current bits, can you please upload a fresh drm.debug dmesg.
Hi, what do you mean by "If you can see it in current bits," ? Please, I really want this issue solved, so I'll do any testing required; I'm an experienced programmer, but not in he xorg area, so it's new for me all his wording, so I'd appreciate more description and instructions on what output do you want. Regards
Sorry, I meant if you could sanity check that you are running the latest kernel, preferably 2.6.35-rc6, add drm.debug=0x4 to your boot parameters and then upload the dmesg. Thanks. In another report a non-existent S-Video connection is still occasionally being detected, so it will be useful to check if this is a similar problem.
Created attachment 37351 [details] dmesg with external monitor connected at boot
Created attachment 37352 [details] dmesg with drm.debug=0x4 and external monitor disconnected at boot
Hi, I've done the required tests; please see the attached dmesgs. I'm running latest ubutnu kernel: Linux lb-u 2.6.32-24-generic #38-Ubuntu SMP Mon Jul 5 09:22:14 UTC 2010 i686 GNU/Linux Also, when external monitor is connected at boot, xrandr gives: Screen 0: minimum 320 x 200, current 800 x 600, maximum 4096 x 4096 VGA1 connected 800x600+0+0 (normal left inverted right x axis y axis) 0mm x 0mm 1360x768 59.8 1024x768 60.0 800x600 60.3* 56.2 848x480 60.0 640x480 59.9 59.9 LVDS1 connected 800x600+0+0 (normal left inverted right x axis y axis) 0mm x 0mm 1024x600 59.9 + 800x600 85.1 72.2 75.0 60.3* 56.2 640x480 85.0 72.8 75.0 59.9 720x400 85.0 640x400 85.1 640x350 85.1 but I cannot make xrandr work at all, all commands fail. But when booting with the external monitor disconnected, I get: Screen 0: minimum 320 x 200, current 1024 x 600, maximum 4096 x 4096 VGA1 disconnected (normal left inverted right x axis y axis) LVDS1 connected 1024x600+0+0 (normal left inverted right x axis y axis) 0mm x 0mm 1024x600 59.9*+ 800x600 85.1 72.2 75.0 60.3 56.2 640x480 85.0 72.8 75.0 59.9 720x400 85.0 640x400 85.1 640x350 85.1 TV1 disconnected (normal left inverted right x axis y axis) ** AFTER CONNECTING THE EXTERNAL MONITOR ** $ xrandr Screen 0: minimum 320 x 200, current 1360 x 768, maximum 4096 x 4096 VGA1 disconnected (normal left inverted right x axis y axis) LVDS1 connected (normal left inverted right x axis y axis) 1024x600 59.9 + 800x600 85.1 72.2 75.0 60.3 56.2 640x480 85.0 72.8 75.0 59.9 720x400 85.0 640x400 85.1 640x350 85.1 TV1 connected 1360x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm 1360x768 59.8* 1024x768 60.0 800x600 60.3 56.2 848x480 60.0 640x480 59.9 59.9 An xrandr works as expected, but with bad resolution of the monitor; should be 1900x1200, and VGA1 Thanks for your help.
The patches I want to check are not in 2.6.32-24-generic. You should be able to find a recent kernel from either from the mainline testing repo (or Maverick) or from ppa:xorg-edgers.
Hi, good news: following your instructions, I installed a new kernel and now it works, the monitor works at full resolution and very sharp !! Here's the info: $ uname -a Linux lb-u 2.6.36-020636rc2-generic #201008230905 SMP Mon Aug 23 10:17:47 UTC 2010 i686 GNU/Linux bad news: xrandr gives a starnge output, detecting 2 VGA and 2 TV outputs instead of one: $ xrandr Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 4096 x 4096 LVDS1 connected (normal left inverted right x axis y axis) 1024x600 59.9 + 800x600 85.1 72.2 75.0 60.3 56.2 640x480 85.0 72.8 75.0 59.9 720x400 85.0 640x400 85.1 640x350 85.1 VGA1 disconnected (normal left inverted right x axis y axis) TV1 disconnected (normal left inverted right x axis y axis) TV2 disconnected (normal left inverted right x axis y axis) VGA2 connected 1920x1200+0+0 (normal left inverted right x axis y axis) 519mm x 324mm 1920x1200 60.0*+ 1600x1200 60.0 1680x1050 60.0 1280x1024 75.0 60.0 1152x864 75.0 1024x768 75.1 60.0 800x600 75.0 60.3 640x480 75.0 60.0 720x400 70.1 So many thanks for your help !!
Thanks for the update.
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.