Hi all, I am testing the radeonhd driver again and this time it almost works. That's very promising. The only remaining issue I have is that the driver gives me a resolution of 1280x1024 when my LCD has a resolution of 1400x1050. I investigated a bit and here are my findings. The driver manages to get monitor information from the EDID: (II) RADEONHD(0): Found DDC on line 2: (II) RADEONHD(0): Manufacturer: LEN Model: 4022 Serial#: 0 (II) RADEONHD(0): Year: 2006 Week: 35 (II) RADEONHD(0): EDID Version: 1.3 (II) RADEONHD(0): Digital Display Input (II) RADEONHD(0): Max H-Image Size [cm]: horiz.: 29 vert.: 21 (II) RADEONHD(0): Gamma: 2.20 (II) RADEONHD(0): DPMS capabilities: StandBy Suspend Off; RGB/Color Display (II) RADEONHD(0): First detailed timing is preferred mode (II) RADEONHD(0): redX: 0.610 redY: 0.330 greenX: 0.300 greenY: 0.530 (II) RADEONHD(0): blueX: 0.150 blueY: 0.130 whiteX: 0.313 whiteY: 0.329 (II) RADEONHD(0): Supported VESA Video Modes: (II) RADEONHD(0): 640x480@60Hz (II) RADEONHD(0): 800x600@60Hz (II) RADEONHD(0): 1024x768@60Hz (II) RADEONHD(0): Manufacturer's mask: 0 (II) RADEONHD(0): Supported Future Video Modes: (II) RADEONHD(0): #0: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 (II) RADEONHD(0): Supported additional Video Mode: (II) RADEONHD(0): clock: 108.0 MHz Image Size: 287 x 215 mm (II) RADEONHD(0): h_active: 1400 h_sync: 1448 h_sync_end 1560 h_blank_end 1688 h_border: 0 (II) RADEONHD(0): v_active: 1050 v_sync: 1051 v_sync_end 1054 v_blanking: 1066 v_border: 0 (II) RADEONHD(0): Supported additional Video Mode: (II) RADEONHD(0): clock: 90.0 MHz Image Size: 287 x 215 mm (II) RADEONHD(0): h_active: 1400 h_sync: 1448 h_sync_end 1560 h_blank_end 1688 h_border: 0 (II) RADEONHD(0): v_active: 1050 v_sync: 1051 v_sync_end 1054 v_blanking: 1066 v_border: 0 (II) RADEONHD(0): LTD141EN9B (II) RADEONHD(0): Monitor "LEN-4022" connected to "PANEL LCD1": Bandwidth: 109MHz Horizontal timing: 31.5 - 63.7kHz Vertical timing: 59.9 - 60.3Hz Allows reduced blanking. Uses Fixed Modes. Attached modes: 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 One problem I see here is that the two additional video modes (both 1400x1050) do _not_ fit in the timings. For the first one, the horizontal frequency is 63.98 kHz, which is above the maximum of 63.7 kHz. For the second one, the vertical frequency is 50 Hz, which is below the minimum of 59.9 Hz. I'm surprised, as the video modes come from the LCD itself, it really doesn't make sense that they do not fit. Does this mean that the EDID data is bogus, or that the driver fails to properly extract either the video modes or the timing limits? As a comparison point, when using the vesa driver, the horizontal timing is 30 - 68 kHz and the vertical timing is 50 - 60 kHz. Then I tried adding a suitable modeline by myself: Modeline "1400x1050" 118.42 1400 1488 1640 1860 1050 1051 1054 1061 This one fits in the timings, but still no luck, I get the same error in the logs: (II) RADEONHD(0): Generating Modeline for "1400x1050" (II) RADEONHD(0): Rejected mode "1400x1050" (1400x1050): hsync out of range From the logs, it seems that this additional modeline is attached to the Monitor section in my configuration file, while the driver insists on using its own autodetected monitor. I can't seem to be able to add a custom modeline to that autodetected monitor. Is it possible at all? I'm attaching Xorg.0.log together with my configuration file in case it is useful. Thanks, -- Jean Delvare Suse L3
Le lundi 8 octobre 2007 14:26, Jean Delvare a écrit :
(II) RADEONHD(0): Monitor "LEN-4022" connected to "PANEL LCD1": Bandwidth: 109MHz Horizontal timing: 31.5 - 63.7kHz Vertical timing: 59.9 - 60.3Hz Allows reduced blanking. Uses Fixed Modes. Attached modes: 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
One problem I see here is that the two additional video modes (both 1400x1050) do _not_ fit in the timings. For the first one, the horizontal frequency is 63.98 kHz, which is above the maximum of 63.7 kHz. For the second one, the vertical frequency is 50 Hz, which is below the minimum of 59.9 Hz. I'm surprised, as the video modes come from the LCD itself, it really doesn't make sense that they do not fit.
Does this mean that the EDID data is bogus, or that the driver fails to properly extract either the video modes or the timing limits? As a comparison point, when using the vesa driver, the horizontal timing is 30 - 68 kHz and the vertical timing is 50 - 60 kHz.
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. -- Jean Delvare Suse L3 -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Mon, Oct 08, 2007 at 02:58:05PM +0200, Jean Delvare wrote:
Le lundi 8 octobre 2007 14:26, Jean Delvare a ?crit?:
(II) RADEONHD(0): Monitor "LEN-4022" connected to "PANEL LCD1": Bandwidth: 109MHz Horizontal timing: 31.5 - 63.7kHz Vertical timing: 59.9 - 60.3Hz Allows reduced blanking. Uses Fixed Modes. Attached modes: 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
One problem I see here is that the two additional video modes (both 1400x1050) do _not_ fit in the timings. For the first one, the horizontal frequency is 63.98 kHz, which is above the maximum of 63.7 kHz. For the second one, the vertical frequency is 50 Hz, which is below the minimum of 59.9 Hz. I'm surprised, as the video modes come from the LCD itself, it really doesn't make sense that they do not fit.
Does this mean that the EDID data is bogus, or that the driver fails to properly extract either the video modes or the timing limits? As a comparison point, when using the vesa driver, the horizontal timing is 30 - 68 kHz and the vertical timing is 50 - 60 kHz.
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.
-- Jean Delvare Suse L3
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. I hope i can look into this in the evening. Thanks, Luc Verhaegen. SUSE/Novell X Driver Developer. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
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
Le lundi 8 octobre 2007 16:34, Jean Delvare a écrit :
Le lundi 8 octobre 2007 16:01, Luc Verhaegen a écrit :
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.
Egbert and myself finished the investigation this evening and it happens to be a bug in the X server itself (remember that I'm on SLED10 SP1 which still has X 6.9). The sync flags are not properly reported to the drivers, there're shifted by one to the right so 0x03 shows as 0x01 (the LSB is lost.) I hacked the radeonhd driver locally to test for sync == 0x01 and now I get 1400x1050 working just fine :) So there's nothing to fix in the radeonhd driver, sorry for the noise. Thanks, -- Jean Delvare Suse L3 -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
participants (2)
-
Jean Delvare
-
Luc Verhaegen