Summary: | [915GM] VBIOS parsing fails to account for varying LVDS data block size | ||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | xorg | Reporter: | Nuzhdin Urii <vzorvat> | ||||||||||||||||||||||||||||||||||||||||
Component: | Driver/intel | Assignee: | Jesse Barnes <jbarnes> | ||||||||||||||||||||||||||||||||||||||||
Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> | ||||||||||||||||||||||||||||||||||||||||
Severity: | major | ||||||||||||||||||||||||||||||||||||||||||
Priority: | medium | CC: | bryce, jbarnes, martin1404, michael.fu, rofmeister | ||||||||||||||||||||||||||||||||||||||||
Version: | unspecified | Keywords: | NEEDINFO | ||||||||||||||||||||||||||||||||||||||||
Hardware: | x86 (IA32) | ||||||||||||||||||||||||||||||||||||||||||
OS: | Linux (All) | ||||||||||||||||||||||||||||||||||||||||||
Whiteboard: | |||||||||||||||||||||||||||||||||||||||||||
i915 platform: | i915 features: | ||||||||||||||||||||||||||||||||||||||||||
Attachments: |
|
Description
Nuzhdin Urii
2009-01-08 04:00:58 UTC
reassign to Jesse as the error info is like #17310. patch from bug #17310 didn't help,because i use 2.5-r1 version of video driver,wich already includes that patch test's show that 2.5* versons causes this error,and 2.4 versons show one big full-screen artefact have same problem with that driver asus r2h Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller configs in attachment another one report: http://bugs.gentoo.org/show_bug.cgi?&id=208358 ps work fine with vesa Created attachment 21981 [details]
xorg.conf
Created attachment 21983 [details]
xorg.0.log
Created attachment 22011 [details]
Xorg log with 2.6.0 driver
Created attachment 22012 [details]
Xorg conf i used to start with 2.6.0 driver
I have tested 2.6.0 driver,it didn't work too pls get rid of your xorg.conf and retest. (In reply to comment #9) > pls get rid of your xorg.conf and retest. hi Nuzhdin Urii, when you test comment #9, please paste Xorg log file with Modedebug option. Thanks Ma Ling Created attachment 22244 [details]
Here Xorg.log with ModeDebug enabled
Sorry for so long whait,here is log of Xorg server
i tryed remove Xorg.conf,Xorg didn't started with same error
how to enable modedebug without xorg.conf i don't know (am i stupid?)
Hi Nuzhdin Urii, Could you describe what 's your evironment configuration, such as external displays and output ports, I find driver detect TV output. If your laptop actually doesn't connect TV, please use the following option to ignore it, then restart your Xorg ,and paste log file. Section "Device" Identifier "videocard" Option "monitor-TV" "TV" ... EndSection ... Section "Monitor" Identifier "TV" Option "Ignore" "True" EndSection Thanks Ma Ling Created attachment 22511 [details]
xorg log with tv output configured
videocard installed into ASUS R2H umpc
it have video out port via additional device
i made recommended changes to Xorg,log attached
Hi Nuzhdin Urii, From the log file, I find the reasone may be from too high pixel clock, 388.04MHZ of initial mode 2048x1536 exceed our scope. please try use lower resolution and pixel rate, then paste your log file, which are configured in xorg.conf as follow. Section "Device" Identifier "videocard" Option "monitor-TV" "TV" Option "monitor-LVDS" "LVDS" ... EndSection Section "Monitor" Identifier "LVDS" Modeline "1280x1024_60.00" 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync Option "PreferredMode" "1280x1024_60.00" EndSection Thanks Ma Ling Created attachment 22660 [details]
xorg log
Created attachment 22661 [details]
xorg conf
here my conf ang log
by the way,R2H has 800x480 screen,may be this is a problem?
(In reply to comment #14) > Hi Nuzhdin Urii, > > From the log file, I find the reasone may be from too high pixel clock, > 388.04MHZ of initial mode 2048x1536 exceed our scope. > > please try use lower resolution and pixel rate, then paste your log file, which > are configured in xorg.conf as follow. > > Section "Device" > Identifier "videocard" > Option "monitor-TV" "TV" > Option "monitor-LVDS" "LVDS" > > ... > EndSection > > Section "Monitor" > Identifier "LVDS" > Modeline "1280x1024_60.00" 108.00 1280 1328 1440 1688 1024 1025 1028 > 1066 +hsync +vsync > Option "PreferredMode" "1280x1024_60.00" > EndSection > > > Thanks > Ma Ling > ling, for LVDS, timging info for all modes are "fixed up" to the fixed modes in fixup func, so chaning modeline may not help...maybe we can try to dump out more info about the fixed mode the device use (it must be a broken modeline I think ) Created attachment 22746 [details] [review] please try the patch on your machine, thanks. Hi Nuzhdin Urii, Could you try the patch which can help us narrow down the issue, and paste log info again? thanks Ma Ling Created attachment 22870 [details]
with extra debug info
seems like there is no modline for 800x480
i will try to start with other resolutions later,but it is not sollution of problem
Created attachment 22890 [details]
please try the patch on your machine, thanks.
Hi Nuzhdin Urii,
the log shows the clock of fixed mode is 0! It can't work, based on your mode list from Xorg, I re-construct another fixed mode, please try.
Thanks
Ma Ling
Created attachment 22908 [details]
it started
xorg started but image very bad
Created attachment 22932 [details] [review] please try it on your machine, thanks Hi Nuzhdin Urii, In order not to impact your work, the new patch intends to make better image. Thanks Ma Ling Created attachment 22972 [details] [review] please try the patch on your machine, thanks. Hi Nuzhdin Urii, The patch is our latest one, because we have no corresponding HW, could you try it besides that on comment #22 Thanks Ma Ling Created attachment 22980 [details] [review] working patch still bad in cause of wrong resolution i changed your patch to this one,it works good Created attachment 23000 [details] [review] working patch still bad in cause of wrong resolution i changed your patch to this one,it works good (In reply to comment #25) > Created an attachment (id=23000) [details] > working patch > > still bad in cause of wrong resolution > i changed your patch to this one,it works good > have you tried ma ling's patch in comment# 23? we are looking for a generic fix, though I agree this bug is because your HW is broken... where do you get those parameters in your patch? (In reply to comment #26) > (In reply to comment #25) > > Created an attachment (id=23000) [details] [details] > > working patch > > > > still bad in cause of wrong resolution > > i changed your patch to this one,it works good > > > have you tried ma ling's patch in comment# 23? we are looking for a generic > fix, though I agree this bug is because your HW is broken... > where do you get those parameters in your patch? ping Nuzhdin Urii ~ Thanks Ma Ling (In reply to comment #27) > (In reply to comment #26) > > (In reply to comment #25) > > > Created an attachment (id=23000) [details] [details] [details] > > > working patch > > > > > > still bad in cause of wrong resolution > > > i changed your patch to this one,it works good > > > > > have you tried ma ling's patch in comment# 23? we are looking for a generic > > fix, though I agree this bug is because your HW is broken... > > where do you get those parameters in your patch? > > ping Nuzhdin Urii ~ > Thanks > Ma Ling > sorry :) patch from comment# 23 didn't work parameters was found in google (In reply to comment #28) > (In reply to comment #27) > > (In reply to comment #26) > > > (In reply to comment #25) > > > > Created an attachment (id=23000) [details] [details] [details] [details] > > > > working patch > > > > > > > > still bad in cause of wrong resolution > > > > i changed your patch to this one,it works good > > > > > > > have you tried ma ling's patch in comment# 23? we are looking for a generic > > > fix, though I agree this bug is because your HW is broken... > > > where do you get those parameters in your patch? > > > > ping Nuzhdin Urii ~ > > Thanks > > Ma Ling > > > > sorry :) > > patch from comment# 23 didn't work > parameters was found in google > There are only two ways we can find the correct fixed timing that is suitable for the panel this device use - either from the BIOS, or from the EDID. DDC fails, and no EDID returns. Apparently the modes read from BIOS is also broken.. I think the patch in general is ok for sanity check purpose, so should send to mailing list for RFC. Nuzhdin Urii, you need to report this to the HW vendor of your device... >There are only two ways we can find the correct fixed timing that is suitable >for the panel this device use - either from the BIOS, or from the EDID. DDC >fails, and no EDID returns. Apparently the modes read from BIOS is also >broken.. but why i810 worked fine with that device ? http://www.xs4all.nl/~sozonko/asus_r2h_howto/index.html#32 please provide the vbios dump via: # cd /sys/devices/pci0000\:00/0000\:00\:02.0/ # echo 1 > rom # cat rom > /tmp/rom.bin # echo 0 > rom then submit the rom.bin here. thanks. also, pls try if Option "NoDDC" "True" will help, without the patch. Pls attach xorg log as well. Created attachment 23145 [details]
rom dump
(In reply to comment #33) > Created an attachment (id=23145) [details] > rom dump Thanks for you help, whould you please append option LVDSFixedMode "true" into xorg.conf as follow Section "Device" Identifier "MY Video Device" driver "intel" ... Option "LVDSFixedMode" "true" EndSection Thanks Ma Ling *** Bug 20327 has been marked as a duplicate of this bug. *** root cause of this is a HW issue that the panel report modes that it can't support at all. I think NoDDC option should fix this, if it works in console mode. not working with Option "NoDCC" "true" and Option "LVDSFixedMode" "true" Are we sure this isn't our bug? It looks like the rom Dmitry posted has a mostly correct modeline: * panel type 02: 800x480 clock 27000000 info: LVDS: 0x40000300 PP_ON_DELAYS: 0x025907d1 PP_OFF_DELAYS: 0x01f507d1 PP_DIVISOR: 0x00270f05 PFIT: 0x00000668 timings: 800 808 904 900 480 482 484 500 27000.00 (BAD!) only the vtotal vs vsyncend is broken (as we've seen before). The mode pointer table is busted though: LVDS timing pointer data: Number of entries: 3 panel type 02: 0x3072 It sounds like the EDID might be broken, but we're trying to use it anyway? What happens if we just use the VBT mode unconditionally, rather than assuming the EDID data is right? Maybe once we get more VBIOS info we'll be able to figure out what data to trust better... (In reply to comment #38) > It sounds like the EDID might be broken, but we're trying to use it anyway? > What happens if we just use the VBT mode unconditionally, rather than assuming > the EDID data is right? > > Maybe once we get more VBIOS info we'll be able to figure out what data to > trust better... > if we can get a mode from vbt, it actually override any mode from EDID via fix_up call in LVDS. It seems even though the VBT has a mode that is correct, the VBT didn't point it to us, and rather point us a wrong one. Apparently this is wrong. that's why I say it's notourbug. unfortunately, any modeline setting in conf will also be overrided by the fixed mode as well, thus we don't have a way to correct this. My wild guess is windows driver has a way to override it maybe using a inf file, but that's just my guess.. But one of the VBT modes looked ok, which is why I thought it's probably our bug. There's some versioning magic we're missing in our VBT parsing; on some platforms we need to use the BDB_LVDS_LFP_DATA block, while on others we need to use the BDB_LVDS_LFP_DATA_PTRS block. Apparently on this platform needs to use the former. I don't know how we can tell which one will be accurate though... actually could this bug just a dup of bug# 17292? so, even bios indicator 800x480 is the preferred, and we use it to override EDID modes, but since its DTD is "wrong", the screen is still blank... we didn't notice the HTotal vs Hsync issue before and didn't double check with the bug reporter about this.. Jesse, I think the BDB_LVDS_LFP_DATA and BDB_LVDS_LFP_DATA_PTRS should be the same thing, while one is pointers and the other is datum. Driver is preferred to use BDB_LVDS_LFP_DATA_PTRS , rather than visit BDB_LVDS_LFP_DATA directly, even though we can...But, I did some Hex editing and noticed that all pointers in BDB_LVDS_LFP_DATA_PTRS are busted, as you said, and are set 4 bytes ahead of the correct value. Not only DVO_Timing, but also LFP_PARAMs, PnPIDs. I further checked out and noticed that BDB_LVDS_OPTIONS is unexpected 4 bytes longer than it should be of its BDB version ...The correct size is 4 ( excluding bdb header/size ) , but in this rom, it's 8. From a document I have, it is valid to have this size but it's only in later version, not 1.26. It looks like someone tucked 4 extra bytes of information to block BDB_LVDS_OPTIONS and just updated its size ( thus each block can still be parsed out correctly ), while forget the offset values in following blocks.. Googling around of this platform, it seems i810 or vesa driver need the hint of 800x480 to pick up the correct timing as well. I guess they use BDB_LVDS_LFP_DATA directly... (In reply to comment #42) > Jesse, I think the BDB_LVDS_LFP_DATA and BDB_LVDS_LFP_DATA_PTRS should be the > same thing, while one is pointers and the other is datum. Driver is preferred > to use BDB_LVDS_LFP_DATA_PTRS , rather than visit BDB_LVDS_LFP_DATA directly, > even though we can...But, > > I did some Hex editing and noticed that all pointers in BDB_LVDS_LFP_DATA_PTRS > are busted, as you said, and are set 4 bytes ahead of the correct value. Not > only DVO_Timing, but also LFP_PARAMs, PnPIDs. I further checked out and noticed > that BDB_LVDS_OPTIONS is unexpected 4 bytes longer than it should be of its BDB > version ...The correct size is 4 ( excluding bdb header/size ) , but in this > rom, it's 8. From a document I have, it is valid to have this size but it's > only in later version, not 1.26. Oh, nice debugging Michael, thanks for checking it out. So do you think it's possible to add a version check that accounts for this in our VBT parsing code? Sounds like 1.26 wouldn't work but maybe something earlier? Or we could check the BDB_LVDS_OPTIONS size instead since that seems correct, and use that to determine how to handle the DATA_PTRS offsets. Created attachment 25420 [details] [review] Add LVDS LFP data quirk Can you give this patch a try? I'll need the output from lspci -vn on your machine to make it more specific. Created attachment 25750 [details] [review] LVDS data fetch fix Here's another one to try too. It uses the goofy offset calculation used by the Windows driver, so it seems to pick up the size on your panel correctly at least. *** Bug 21641 has been marked as a duplicate of this bug. *** Fix pushed, putting together the kernel side now. commit 15af8ea6ab6998bbab9f4eeda227565c409da229 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Mon Jun 22 11:11:06 2009 -0700 Fix LFP data block fetch |
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.