Bug 26833

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.

Any updates?

(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.