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
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.
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.
Created attachment 24099 [details] ROM from my MacBook notebook
Created attachment 24100 [details] Xorg.log
Created attachment 24101 [details] dmesg log
Forgot to tell that my card is a 965GM-based Intel X3100.
By the way, I tried the patch attached by Wand, but it didn't change the output. The X didn't start anyway.
increasing priority since it's considered as release blocker.
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.
(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?
Jesse, you should consider upgrade your bios.. see bug# 20517..
(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.
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? :)
(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...
Created attachment 24221 [details] [review] disable LVDS VBT parsing Jesse, how about this one?
(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...
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.