Hi Luc, Thanks for your answer. Le lundi 8 octobre 2007 16:01, Luc Verhaegen a écrit :
On Mon, Oct 08, 2007 at 02:58:05PM +0200, Jean Delvare wrote:
Replying to myself: I read the EDID data manually and it does _not_ include the operating frequency ranges. So where do they come from? I did not look at the code, but my guess is that the driver is computing them from the 4 standard video mode timings it got from the EDID:
Modeline "800x600" 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync Modeline "640x480" 25.20 640 656 752 800 480 490 492 525 -hsync -vsync Modeline "1024x768" 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync Modeline "1280x1024" 109.00 1280 1361 1496 1712 1024 1027 1034 1063 -hsync +vsync
The bandwith of 109 MHz comes from the last line, the minimum horizontal refresh rate of 31.5 kHz comes from the second line, etc.
So, the fix might simply be to include the custom video mode definitions when guessing the acceptable horizontal and vertical timings, rather than using only the default video modes.
Alternatively, the driver could skip the checks on EDID-provided modelines when the EDID did not include operating frequency limits.
This is some issue with my edid handling. As far as i can tell, no mode has been created for the detailed timing mode there, i can't tell why yet.
Further analysis revealed that the modes are skipped because of this test in rhd_edid.c:EDIDModeFromDetailedTiming: /* We only do seperate sync currently */ if (timing->sync != 0x03) { xf86DrvMsg(scrnIndex, X_INFO, "%s: Ignoring: We only handle seperate" " sync.\n", __func__); return NULL; } Reading the EDID manually shows that the two modes _do_ have the sync bits set to 3, so somehow the information is lost on the way. I was investigating this with Egbert at the moment.
I hope i can look into this in the evening.
Great, thanks. -- Jean Delvare Suse L3 -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org