Bug 20752 - [915GM] fail to detect LVDS with new VBT code
Summary: [915GM] fail to detect LVDS with new VBT code
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: high major
Assignee: Wang Zhenyu
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 20276
  Show dependency treegraph
 
Reported: 2009-03-19 12:03 UTC by Jesse Barnes
Modified: 2009-03-30 22:24 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
rom from affected machine (64.00 KB, application/octet-stream)
2009-03-19 12:03 UTC, Jesse Barnes
no flags Details
Skip LVDS config parsing for old BDB version (891 bytes, patch)
2009-03-19 19:59 UTC, Wang Zhenyu
no flags Details | Splinter Review
ROM from my MacBook notebook (64.00 KB, application/octet-stream)
2009-03-20 16:47 UTC, João Matos
no flags Details
Xorg.log (11.18 KB, application/octet-stream)
2009-03-20 16:49 UTC, João Matos
no flags Details
dmesg log (48.00 KB, application/octet-stream)
2009-03-20 17:14 UTC, João Matos
no flags Details
disable LVDS VBT parsing (965 bytes, patch)
2009-03-24 20:26 UTC, Wang Zhenyu
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Barnes 2009-03-19 12:03:12 UTC
Created attachment 24049 [details]
rom from affected machine

Looks like the new VBT feature block parsing is a bit too trusting on my 915GM based Toshiba laptop:
Driver feature Data Block:                                                      
        Boot Device Algorithm: os default                                       
        Block display switching when DVD active: yes                            
        Allow display switching when in Full Screen DOS: no                     
        Hot Plug DVO: yes                                                       
        Dual View Zoom: no                                                      
        Driver INT 15h hook: no
        Enable Sprite in Clone Mode: no
        Use 00000110h ID for Primary LFP: no
        Boot Mode X: 1024
        Boot Mode Y: 768
        Boot Mode Bpp: 8
        Boot Mode Refresh: 60
        Enable LFP as primary: no
        Selective Mode Pruning: no
        Dual-Frequency Graphics Technology: no
        Default Render Clock Frequency: high
        NT 4.0 Dual Display Clone Support: no
        Default Power Scheme user interface: CUI
        Sprite Display Assignment when Overlay is Active in Clone Mode: secondary
        Display Maintain Aspect Scaling via CUI: yes
        Preserve Aspect Ratio: no
        Enable SDVO device power down: no
        CRT hotplug: no
        LVDS config: No LVDS
        Define Display statically: yes
        Legacy CRT max X: 0
        Legacy CRT max Y: 0
        Legacy CRT max refresh: 85
Comment 1 Wang Zhenyu 2009-03-19 19:59:11 UTC
Created attachment 24066 [details] [review]
Skip LVDS config parsing for old BDB version

Jesse, I'm still waiting for VBIOS doc on clarify this. This patch is from my local tests, which seems the best info now I can guess.
Comment 2 João Matos 2009-03-20 16:44:50 UTC
I am also affected by this (or a similar) bug. My X server with the 2.6.99.902 doesn't work, exiting with a "No suitable screens" error.

The relevant information is attached. Tell me if you need something more.
Comment 3 João Matos 2009-03-20 16:47:23 UTC
Created attachment 24099 [details]
ROM from my MacBook notebook
Comment 4 João Matos 2009-03-20 16:49:27 UTC
Created attachment 24100 [details]
Xorg.log
Comment 5 João Matos 2009-03-20 17:14:05 UTC
Created attachment 24101 [details]
dmesg log
Comment 6 João Matos 2009-03-20 17:15:46 UTC
Forgot to tell that my card is a 965GM-based Intel X3100.
Comment 7 João Matos 2009-03-21 05:37:23 UTC
By the way, I tried the patch attached by Wand, but it didn't change the output. The X didn't start anyway.
Comment 8 Gordon Jin 2009-03-22 00:14:12 UTC
increasing priority since it's considered as release blocker.
Comment 9 Wang Zhenyu 2009-03-22 08:53:19 UTC
I think LVDS config bit for eDP should be LVDS or SDVO LVDS bit in some BDB version, although bios people told us it never be used. 

Ok, if we still can't get the right info before Q1 release, and consider the testing cycle, we can fallback to origin behavior for 2.7.0, then try to fix it up in 2.7.1.
Comment 10 Michael Fu 2009-03-23 18:34:31 UTC
(In reply to comment #9)
> I think LVDS config bit for eDP should be LVDS or SDVO LVDS bit in some BDB
> version, although bios people told us it never be used. 
> 

do you think the Macbook is using eDP?

Comment 11 Michael Fu 2009-03-23 20:21:11 UTC
Jesse, you should consider upgrade your bios.. see bug# 20517..
Comment 12 Jesse Barnes 2009-03-23 20:39:06 UTC
(In reply to comment #11)
> Jesse, you should consider upgrade your bios.. see bug# 20517..

This platform is pretty old, but I think I have the latest BIOS already.

I'm also of the opinion that upgrading the BIOS isn't a valid bug fix unless the hardware hasn't shipped yet.  Once the hardware ships, you may as well consider the BIOS part of the hardware platform, since most users don't have the expertise to upgrade it, and more often than not, the OEM won't even provide an easy to use update.

Ultimately, we have to work around this sort of thing in our driver, IMO.
Comment 13 Michael Fu 2009-03-23 23:49:39 UTC
I would argue to use caution to simply revert the patch if it helps 10 people but make one case fail. we need collect more test results. There must be a reason that if windows driver rely on it..

Jesse, what's the model of your Toshiba? would it be interesting for you to test if windows work on it?

It's likely that from some point when windows rely on it, OEMs would make sure the bits are correct rather than ignoring them as before. Some of them may provide bios upgrade to fix as bug# 20517 ( and, true,  some may not..)

Mac use a different BIOS, I don't know if those settings are meaningful or not. BTW, do we claim support Mac ever? :)
Comment 14 Jesse Barnes 2009-03-24 09:34:46 UTC
(In reply to comment #13)
> I would argue to use caution to simply revert the patch if it helps 10 people
> but make one case fail. we need collect more test results. There must be a
> reason that if windows driver rely on it..

Agreed.

> Jesse, what's the model of your Toshiba? would it be interesting for you to
> test if windows work on it?

Yeah, Windows works fine.  It's a Satellite M45.

> It's likely that from some point when windows rely on it, OEMs would make sure
> the bits are correct rather than ignoring them as before. Some of them may
> provide bios upgrade to fix as bug# 20517 ( and, true,  some may not..)

Right, but we've already seen that Windows parses the VBT blocks differently than we do.  So it may be correct, we just need to parse it the same way (accounting for version differences, block size changes, offset changes, etc.).

> Mac use a different BIOS, I don't know if those settings are meaningful or not.
> BTW, do we claim support Mac ever? :)

I don't think so. :)  But it would be nice to have working...
Comment 15 Wang Zhenyu 2009-03-24 20:26:04 UTC
Created attachment 24221 [details] [review]
disable LVDS VBT parsing

Jesse, how about this one?
Comment 16 Michael Fu 2009-03-30 18:49:01 UTC
(In reply to comment #12)
> (In reply to comment #11)
> > Jesse, you should consider upgrade your bios.. see bug# 20517..
> 
> This platform is pretty old, but I think I have the latest BIOS already.
> 
> I'm also of the opinion that upgrading the BIOS isn't a valid bug fix unless
> the hardware hasn't shipped yet.  Once the hardware ships, you may as well
> consider the BIOS part of the hardware platform, since most users don't have
> the expertise to upgrade it, and more often than not, the OEM won't even
> provide an easy to use update.
> 
> Ultimately, we have to work around this sort of thing in our driver, IMO.
> 

Sure about this Jesse?

http://askiris.toshiba.com/ToshibaSupportSite/search.do?cmd=displayKC&docType=kc&externalId=1305262xml&sliceId=&dialogID=75160268&stateId=1%200%2075158484

I extract the bios image out and our tool actually can parse it directly as it browse through to look for BIOS_DATA_BLOCK string, and the LVDS bits in the new bios is 01 - Integrated LVDS...
Comment 17 Wang Zhenyu 2009-03-30 22:24:32 UTC
Patch is pushed to master. Close this one, although we still need to find out right pass to LVDS config check.
commit 375b2e40fcb17e94538a75392950e2533c1bb031
Author: Zhenyu Wang <zhenyu.z.wang@intel.com>
Date:   Wed Mar 25 11:13:52 2009 +0800

    Disable LVDS config parsing from VBT for now
    
    As wider tests showed that this doesn't work for all VBIOS, so
    disable it for now and reenable it after we get reliable method.


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.