Created attachment 18524 [details] Xorg.0.log for 2.4.1-r1 (failure) System environment: -- chipset: 855GM -- system architecture: i686 -- xf86-video-intel/xserver/mesa/drm version: -- xf86-video-intel: 2.4.1-1 -- xorg-server: 1.4.99.906 -- mesa: 7.1_rc3 -- libdrm: 2.3.1 -- x11-drm: 20080710 -- kernel version: 2.6.26-gentoo -- Linux distribution: Gentoo -- Machine or mobo model: Fujitsu-Siemens T3010 Laptop (Convertible TabletPC) -- Display connector: Built-in LCD (VGA?) 3) Reproduce steps. Install xf86-video-intel 2.4.1 or 2.4.1-r1 and start Xorg. Xorg refuses to start and the following can be found in Xorg.0.log: (II) intel(0): using SSC reference clock of 66 MHz Fatal server error: Couldn't find PLL settings for mode! It works fine with xf86-video-intel 2.4.0 even though it complains about: (II) intel(0): using SSC reference clock of 66 MHz (WW) intel(0): Chosen PLL clock of 66.5 Mhz more than 2% away from desired 64.2 Mhz 4) Additional info: After upgrading to xf86-video-intel 2.4.1 or 2.4.1-r1 (Gentoo version for 2.4.1 plus xf86-video-i810-2.4.1-0001-Fix-reverted-LVDS-bios-capability-dword- definition.patch) Xorg refuses to start. Downgrading to 2.4.0 makes Xorg start again. Please let me know, if I can provide any further info to track this issue down. Thank you for your high quality open source driver. P.S. Is XvMC on pre-i9xx chipsets going to happen or are they considered obsolete? 5) Attachments: The following files are provided. -- Xorg.0.log (for xf86-video-intel 2.4.1-r1 and 2.4.0) -- xorg.conf
Created attachment 18526 [details] Xorg.0.log for 2.4.0 (success)
Created attachment 18527 [details] xorg.conf
Can you attach your VBIOS rom file as well? $ cd /sys/bus/pci/devices/0000\:00\:02.0/ $ echo 1 > rom $ cat rom > /tmp/rom.bin $ echo 0 > rom Sounds like I may have busted the VBIOS parsing code on your machine.
Created attachment 18536 [details] VBIOS rom for Fujitsu-Siemens T3010 VBIOS rom provided as requested. Thank you, Jesse, for your quick response. :-) Please let me know, if I can provide any further information to track down my problem.
Sorry for asking (don't want to seem impatient), but how's the work on this bug progressing? I fear that the version of the intel driver working for me, may be obsoleted. Is there any further info I can provide to help?
Sorry I've been travelling and not paying attention to bugs as much as I ought to. :/ I got your VBIOS though (thanks), hopefully I'll have a chance to wade through things in detail in the next couple of weeks (though next week I'll be travelling too, so I'm not sure how much I'll get done).
No worries. I just appreciate the fact, that you still have time to care about my problem. :-)
Oh funky... Looks like we're getting a weird LFP entry back for your machine: (II) intel(0): Output LVDS using initial mode 518x256 This matches what I see in your VBIOS. But maybe your VBTs are laid out differently... I'm looking at the VBIOS source now to see how that might be...
Ugg, in your case the VBT LFP_DATA section is inaccurate, but the LFP_DATA_PTRS seems to give us the right info. Now to see if there's a way to tell which one we should use...
Created attachment 19109 [details] [review] Use LFP data pointers instead of array LFP data is stored as both a set of offsets into the VBT and as an array of panel data (for some reason). This patch makes the BIOS parsing code use the pointer data rather than the array, which seems to be at least as accurate on the few VBIOS images I've tested, and in your case more accurate. Can you give it a try?
I will try your patch as soon as I get a bit of free time (I have a 3 week and a 4 year old daughter, that both require a fair amount of time ;-). It might not be until the day after tomorrow. Which driver version is the patch for? My distribution is at version 2.4.2-r1 (http://packages.larrythecow.org/?v=search&s=i810). Thanks again.
Created attachment 19124 [details] Xorg.log for 2.4.2-r1 w/ LFP data pointer patch (success) I found time to try your patch and it works. :-) Thank you very much, now I can use the latest driver again. I hope this fix can make it into future versions of your excellent open source driver. I've attached the X.org log in case you can gain any useful info from it.
It's against git master, but it should apply fairly easily to 2.4.1 as well... Let me know if you need help. Gordon, it would be good if we could get some test coverage with this patch applied on all the machines we have that use VBT data for getting LFP timing (it won't affect laptops that have EDID), I want to make sure we don't regress anyone...
Jesse, there are no regression with this patch on my 2 machines using VBT data: 855GM: Toshiba Satellite M20 915GM: ThinkPad R52
Fix pushed as fa2586a40f20e73ec7420466638e8f595e0da987. Cross your fingers that this doesn't cause regressions.
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.