ASUS A8Jp, Mobility Radeon X1700 - DVI-connected monitor doesn't work
Hi! Tested setup is the following: - Mobility Radeon X1700, internal panel 1440x900, the external TFT monitor 1024x768 is connected before startup of the Xorg - recent git master for radeonhd After Xorg startup, the panel is initialized properly and displays login window, the TFT monitor stays black and power indicator is blinking (apparently no signal). I am attaching the full Xorg log to email (compressed as it is unusually large - see below ). Here is the only error message from the radeonhd driver in Xorg log: $grep EE Xorg.0.log | grep -i radeon (EE) RADEONHD(0): D1CRTCDisable: Failed to Unsync CRTC 1 (EE) RADEONHD(0): TMDSAVoltageControl: unhandled chipset: 0x71D5. (EE) RADEONHD(0): TMDSAVoltageControl: unhandled chipset: 0x71D5. rhd_connect output: ========================================= # ./rhd_conntest 01:00.0 rhd_conntest: v0.0.4, git branch master, commit da4783c9 Checking connectors on 0x71D5, 0x1043, 0x1242 (@01:00:00): Load Detection: RHD_OUTPUT_TMDSA HotPlug: RHD_HPD_0 DDC: RHD_DDC_1 LVDS Info: 18bits, dual link, LDI Panel found. Power Timing: 0xF9F, 0x000, 0x03, 0x20, 0x1F4 Macro: 0x0C720407, Clock Pattern: 0x0063 DDC Line[1]: Slaves: 6e a0 ========================================= Also, is it normal that Xorg.0.log is so large? I see e.g. the external monitor seems to be queried many times: ========================== $grep HMDY913757 Xorg.0.log (II) RADEONHD(0): Serial No: HMDY913757 (II) RADEONHD(0): Serial No: HMDY913757 (II) RADEONHD(0): Serial No: HMDY913757 (II) RADEONHD(0): Serial No: HMDY913757 (II) RADEONHD(0): Serial No: HMDY913757 (II) RADEONHD(0): Serial No: HMDY913757 (II) RADEONHD(0): Serial No: HMDY913757 (II) RADEONHD(0): Serial No: HMDY913757 (II) RADEONHD(0): Serial No: HMDY913757 (II) RADEONHD(0): Serial No: HMDY913757 (II) RADEONHD(0): Serial No: HMDY913757 (II) RADEONHD(0): Serial No: HMDY913757 (II) RADEONHD(0): Serial No: HMDY913757 (II) RADEONHD(0): Serial No: HMDY913757 (II) RADEONHD(0): Serial No: HMDY913757 (II) RADEONHD(0): Serial No: HMDY913757 (II) RADEONHD(0): Serial No: HMDY913757 (II) RADEONHD(0): Serial No: HMDY913757 ========================== Best regards, Kirill
On Wed, Nov 28, 2007 at 12:48:25AM +0200, Kirill Belokurov wrote:
Hi!
Tested setup is the following: - Mobility Radeon X1700, internal panel 1440x900, the external TFT monitor 1024x768 is connected before startup of the Xorg - recent git master for radeonhd
After Xorg startup, the panel is initialized properly and displays login window, the TFT monitor stays black and power indicator is blinking (apparently no signal).
I am attaching the full Xorg log to email (compressed as it is unusually large - see below ). Here is the only error message from the radeonhd driver in Xorg log:
$grep EE Xorg.0.log | grep -i radeon (EE) RADEONHD(0): D1CRTCDisable: Failed to Unsync CRTC 1 (EE) RADEONHD(0): TMDSAVoltageControl: unhandled chipset: 0x71D5. (EE) RADEONHD(0): TMDSAVoltageControl: unhandled chipset: 0x71D5.
Could you send me a copy of your bios? The tool in utils/rhd_conntest allows you to dump it.
Also, is it normal that Xorg.0.log is so large? I see e.g. the external monitor seems to be queried many times:
Yes, each and every time you do anything with RandR, it probably goes and validates a load of modes. 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
(missed the CC to list, resending) On Wednesday 28 November 2007, Luc Verhaegen wrote:
Could you send me a copy of your bios? The tool in utils/rhd_conntest allows you to dump it. Please find it in the attachment. For the record, below is the rhd_conntest output when I was dumping it (TFT monitor was disconnected this time): ============================ # ./rhd_conntest -d 01:00.0 rhd_conntest: v0.0.4, git branch master, commit da4783c9 Checking connectors on 0x71D5, 0x1043, 0x1242 (@01:00:00): Load Detection: RHD_OUTPUT_NONE HotPlug: RHD_HPD_NONE DDC: RHD_DDC_NONE LVDS Info: 18bits, dual link, LDI Panel found. Power Timing: 0xF9F, 0x000, 0x03, 0x20, 0x1F4 Macro: 0x0C720407, Clock Pattern: 0x0063 ============================
Also, is it normal that Xorg.0.log is so large? I see e.g. the external monitor seems to be queried many times:
Yes, each and every time you do anything with RandR, it probably goes and validates a load of modes. Got it, thank you.
Best regards, Kirill
On Wed, Nov 28, 2007 at 01:17:55AM +0200, Kirill Belokurov wrote:
(missed the CC to list, resending)
Please find it in the attachment. For the record, below is the rhd_conntest output when I was dumping it (TFT monitor was disconnected this time):
Got it, thank you.
Best regards, Kirill
Should be fixed in git now. Thanks, Luc Verhaegen. SUSE/Novell X Driver Developer, night shift. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Thursday 29 November 2007, Luc Verhaegen wrote:
On Wed, Nov 28, 2007 at 01:17:55AM +0200, Kirill Belokurov wrote:
(missed the CC to list, resending)
Please find it in the attachment. For the record, below is the rhd_conntest output when I was dumping it (TFT monitor was disconnected this time):
Should be fixed in git now.
No, unfortunately this didn't resolve the issue: the error mesage from the Xorg log is gone, even the TFT monitor modes are displayed now by xrandr, but the TFT monitor (attached to the DVI) still blinks as there is no signal. Trying to put it say as left to the panel via $xrandr --output DVI-D_1 --left-of PANEL blinks internal panel for a second and then Xorg thinks the TFT monitor is added, but there is still now picture on it. Output from xrandr ============================ fenikso@miracle:~$ xrandr Screen 0: minimum 320 x 200, current 1440 x 900, maximum 1440 x 900 VGA_1 disconnected PANEL connected 1440x900+0+0 0mm x 0mm 1440x900 59.9*+ TV_SVIDEO disconnected DVI-D_1 connected 1024x768+0+0 304mm x 228mm 1024x768 60.0*+ 75.1 70.1 60.0* 832x624 74.6 800x600 72.2 75.0 60.3 56.2 640x480 75.0 72.8 66.7 60.0 720x400 70.1 ============================ Output from xrandr --verbose ============================ Screen 0: minimum 320 x 200, current 1440 x 900, maximum 1440 x 900 VGA_1 disconnected (normal) Identifier: 0x43 Timestamp: -1917383291 Subpixel: unknown Clones: PANEL TV_SVIDEO DVI-D_1 CRTCs: 0 1 RANDR_OUTPUT_NUMBER: 1 (0x00000001) RANDR_CONNECTOR_NUMBER: 1 (0x00000001) RANDR_CONNECTOR_TYPE: VGA RANDR_SIGNAL_FORMAT: VGA PANEL connected 1440x900+0+0 (0x47) normal (normal) 0mm x 0mm Identifier: 0x44 Timestamp: -1917383291 Subpixel: unknown Clones: VGA_1 TV_SVIDEO DVI-D_1 CRTC: 0 CRTCs: 0 1 RANDR_OUTPUT_NUMBER: 2 (0x00000002) RANDR_CONNECTOR_NUMBER: 2 (0x00000002) RANDR_CONNECTOR_TYPE: LVDS RANDR_SIGNAL_FORMAT: LVDS 1440x900 (0x47) 88.8MHz h: width 1440 start 1488 end 1520 total 1600 skew 0 clock 55.5KHz v: height 900 start 903 end 909 total 926 clock 59.9Hz TV_SVIDEO disconnected (normal) Identifier: 0x45 Timestamp: -1917383291 Subpixel: unknown Clones: VGA_1 PANEL DVI-D_1 CRTCs: 0 1 RANDR_OUTPUT_NUMBER: 3 (0x00000003) RANDR_CONNECTOR_NUMBER: 3 (0x00000003) RANDR_CONNECTOR_TYPE: TV RANDR_SIGNAL_FORMAT: unknown DVI-D_1 connected 1024x768+0+0 (0x48) normal (normal) 304mm x 228mm Identifier: 0x46 Timestamp: -1917383291 Subpixel: unknown Clones: VGA_1 PANEL TV_SVIDEO CRTC: 1 CRTCs: 0 1 RANDR_OUTPUT_NUMBER: 4 (0x00000004) RANDR_CONNECTOR_NUMBER: 4 (0x00000004) RANDR_CONNECTOR_TYPE: TMDS RANDR_SIGNAL_FORMAT: TMDS 1024x768 (0x48) 65.0MHz -HSync -VSync h: width 1024 start 1048 end 1184 total 1344 skew 0 clock 48.4KHz v: height 768 start 771 end 777 total 806 clock 60.0Hz 1024x768 (0x49) 78.8MHz +HSync +VSync h: width 1024 start 1040 end 1136 total 1312 skew 0 clock 60.1KHz v: height 768 start 769 end 772 total 800 clock 75.1Hz 1024x768 (0x4a) 75.0MHz -HSync -VSync h: width 1024 start 1048 end 1184 total 1328 skew 0 clock 56.5KHz v: height 768 start 771 end 777 total 806 clock 70.1Hz 1024x768 (0x48) 65.0MHz -HSync -VSync h: width 1024 start 1048 end 1184 total 1344 skew 0 clock 48.4KHz v: height 768 start 771 end 777 total 806 clock 60.0Hz 832x624 (0x4b) 57.3MHz -HSync -VSync h: width 832 start 864 end 928 total 1152 skew 0 clock 49.7KHz v: height 624 start 625 end 628 total 667 clock 74.6Hz 800x600 (0x4c) 50.0MHz +HSync +VSync h: width 800 start 856 end 976 total 1040 skew 0 clock 48.1KHz v: height 600 start 637 end 643 total 666 clock 72.2Hz 800x600 (0x4d) 49.5MHz +HSync +VSync h: width 800 start 816 end 896 total 1056 skew 0 clock 46.9KHz v: height 600 start 601 end 604 total 625 clock 75.0Hz 800x600 (0x4e) 40.0MHz +HSync +VSync h: width 800 start 840 end 968 total 1056 skew 0 clock 37.9KHz v: height 600 start 601 end 605 total 628 clock 60.3Hz 800x600 (0x4f) 36.0MHz +HSync +VSync h: width 800 start 824 end 896 total 1024 skew 0 clock 35.2KHz v: height 600 start 601 end 603 total 625 clock 56.2Hz 640x480 (0x50) 31.5MHz -HSync -VSync h: width 640 start 656 end 720 total 840 skew 0 clock 37.5KHz v: height 480 start 481 end 484 total 500 clock 75.0Hz 640x480 (0x51) 31.5MHz -HSync -VSync h: width 640 start 664 end 704 total 832 skew 0 clock 37.9KHz v: height 480 start 489 end 491 total 520 clock 72.8Hz 640x480 (0x52) 30.2MHz -HSync -VSync h: width 640 start 704 end 768 total 864 skew 0 clock 35.0KHz v: height 480 start 483 end 486 total 525 clock 66.7Hz 640x480 (0x53) 25.2MHz -HSync -VSync h: width 640 start 656 end 752 total 800 skew 0 clock 31.5KHz v: height 480 start 490 end 492 total 525 clock 60.0Hz 720x400 (0x54) 28.3MHz -HSync +VSync h: width 720 start 738 end 846 total 900 skew 0 clock 31.5KHz v: height 400 start 412 end 414 total 449 clock 70.1Hz ============================ Output from rhd_connect ============================ rhd_conntest: v0.0.4, git branch master, commit 22641a17 Checking connectors on 0x71D5, 0x1043, 0x1242 (@01:00:00): Load Detection: RHD_OUTPUT_TMDSA HotPlug: RHD_HPD_0 DDC: RHD_DDC_1 LVDS Info: 18bits, dual link, LDI Panel found. Power Timing: 0xF9F, 0x000, 0x03, 0x20, 0x1F4 Macro: 0x0C720407, Clock Pattern: 0x0063 DDC Line[1]: Slaves: 6e a0 ============================ And Xorg log is in attachment. Best regards, Kirill
On Nov 30, 07 01:27:51 +0200, Kirill Belokurov wrote:
On Thursday 29 November 2007, Luc Verhaegen wrote:
On Wed, Nov 28, 2007 at 01:17:55AM +0200, Kirill Belokurov wrote:
(missed the CC to list, resending)
Please find it in the attachment. For the record, below is the rhd_conntest output when I was dumping it (TFT monitor was disconnected this time):
Should be fixed in git now.
No, unfortunately this didn't resolve the issue: the error mesage from the
Can you verify that this issue happens with
Option "NoRandr"
as well? It probably will.
If everything works you should see an image on all connected monitors
including panel.
Matthias
--
Matthias Hopf
On Friday 30 November 2007, Matthias Hopf wrote:
(missed the CC to list, resending)
Please find it in the attachment. For the record, below is the rhd_conntest output when I was dumping it (TFT monitor was disconnected this time):
Should be fixed in git now.
No, unfortunately this didn't resolve the issue: the error mesage from the
Can you verify that this issue happens with Option "NoRandr" as well? It probably will. If everything works you should see an image on all connected monitors including panel.
Unfortunately, with "noRandr" it is broken even worser: the Xorg simply doesn't start at all: (EE) RADEONHD(0): No valid modes found (EE) Screen(s) found, but none have a usable configuration. apparently, there is some issue with rejected panel modes: (II) RADEONHD(0): Rejected mode "1440x900" (1440x900:88.8Mhz): mode clock too high I am attaching the Xorg log for this case. Regards, Kirill
Kirill Belokurov wrote:
On Friday 30 November 2007, Matthias Hopf wrote:
(missed the CC to list, resending)
Please find it in the attachment. For the record, below is the rhd_conntest output when I was dumping it (TFT monitor was disconnected this time):
Should be fixed in git now.
No, unfortunately this didn't resolve the issue: the error mesage from the
Can you verify that this issue happens with Option "NoRandr" as well? It probably will. If everything works you should see an image on all connected monitors including panel.
Unfortunately, with "noRandr" it is broken even worser: the Xorg simply doesn't start at all:
(EE) RADEONHD(0): No valid modes found (EE) Screen(s) found, but none have a usable configuration.
apparently, there is some issue with rejected panel modes: (II) RADEONHD(0): Rejected mode "1440x900" (1440x900:88.8Mhz): mode clock too high
I am attaching the Xorg log for this case.
Regards, Kirill
It looks like the mode that your system tries to set up requires 88.8MHz display bandwidth, however the panel seems to report that it's max is 88MHz (interpreted as 88.0MHz I assume) meaning that your monitor is telling X that the mode that it gave to X is out-of-range. It looks like a truncation problem to me... I wonder where this is occurring. -- Coleman Kane -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
Coleman Kane wrote:
Kirill Belokurov wrote:
On Friday 30 November 2007, Matthias Hopf wrote:
(missed the CC to list, resending)
Please find it in the attachment. For the record, below is the rhd_conntest output when I was dumping it (TFT monitor was disconnected this time):
Should be fixed in git now.
No, unfortunately this didn't resolve the issue: the error mesage from the
Can you verify that this issue happens with Option "NoRandr" as well? It probably will. If everything works you should see an image on all connected monitors including panel.
Unfortunately, with "noRandr" it is broken even worser: the Xorg simply doesn't start at all:
(EE) RADEONHD(0): No valid modes found (EE) Screen(s) found, but none have a usable configuration.
apparently, there is some issue with rejected panel modes: (II) RADEONHD(0): Rejected mode "1440x900" (1440x900:88.8Mhz): mode clock too high
I am attaching the Xorg log for this case.
Regards, Kirill
It looks like the mode that your system tries to set up requires 88.8MHz display bandwidth, however the panel seems to report that it's max is 88MHz (interpreted as 88.0MHz I assume) meaning that your monitor is telling X that the mode that it gave to X is out-of-range. It looks like a truncation problem to me... I wonder where this is occurring.
-- Coleman Kane
Apply the attached patch to your latest radeonhd sources, rebuild, reinstall, re-run X, and re-send the log. This patch attempts to undo that incidental truncation that happens around line 60 of src/rhd_monitor.c. -- Coleman Kane
Coleman Kane wrote:
Coleman Kane wrote:
Kirill Belokurov wrote:
On Friday 30 November 2007, Matthias Hopf wrote:
> (missed the CC to list, resending) > > Please find it in the attachment. For the record, below is the > rhd_conntest output when I was dumping it (TFT monitor was > disconnected this time): > > > Should be fixed in git now.
No, unfortunately this didn't resolve the issue: the error mesage from the
Can you verify that this issue happens with Option "NoRandr" as well? It probably will. If everything works you should see an image on all connected monitors including panel.
Unfortunately, with "noRandr" it is broken even worser: the Xorg simply doesn't start at all:
(EE) RADEONHD(0): No valid modes found (EE) Screen(s) found, but none have a usable configuration.
apparently, there is some issue with rejected panel modes: (II) RADEONHD(0): Rejected mode "1440x900" (1440x900:88.8Mhz): mode clock too high
I am attaching the Xorg log for this case.
Regards, Kirill
It looks like the mode that your system tries to set up requires 88.8MHz display bandwidth, however the panel seems to report that it's max is 88MHz (interpreted as 88.0MHz I assume) meaning that your monitor is telling X that the mode that it gave to X is out-of-range. It looks like a truncation problem to me... I wonder where this is occurring.
-- Coleman Kane
Apply the attached patch to your latest radeonhd sources, rebuild, reinstall, re-run X, and re-send the log. This patch attempts to undo that incidental truncation that happens around line 60 of src/rhd_monitor.c.
-- Coleman Kane
Reviewing the source code a little further, the value displayed here is likely being pulled from the clock field of the EDID structure for your panel. This is an integer of whole megahertz value, in this case is 88. This is likely a bug in the panel by some naive code that originally wrote the EDID data and truncated 88.8 or 88.9 to 88MHz. I *think* the proper value should be 89. Does "IgnoreEDID" work in the driver code yet? -- Coleman Kane -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Saturday 01 December 2007, Coleman Kane wrote:
>> Please find it in the attachment. For the record, below is the >> rhd_conntest output when I was dumping it (TFT monitor was >> disconnected this time): > > Should be fixed in git now.
No, unfortunately this didn't resolve the issue: the error mesage from the
Can you verify that this issue happens with Option "NoRandr" as well? It probably will. If everything works you should see an image on all connected monitors including panel.
Unfortunately, with "noRandr" it is broken even worser: the Xorg simply doesn't start at all:
(EE) RADEONHD(0): No valid modes found (EE) Screen(s) found, but none have a usable configuration.
apparently, there is some issue with rejected panel modes: (II) RADEONHD(0): Rejected mode "1440x900" (1440x900:88.8Mhz): mode clock too high
I am attaching the Xorg log for this case.
Regards, Kirill
It looks like the mode that your system tries to set up requires 88.8MHz display bandwidth, however the panel seems to report that it's max is 88MHz (interpreted as 88.0MHz I assume) meaning that your monitor is telling X that the mode that it gave to X is out-of-range. It looks like a truncation problem to me... I wonder where this is occurring.
-- Coleman Kane
Apply the attached patch to your latest radeonhd sources, rebuild, reinstall, re-run X, and re-send the log. This patch attempts to undo that incidental truncation that happens around line 60 of src/rhd_monitor.c.
Patched, but I am getting build failure when running make: ====================== rhd_monitor.c: In function 'RHDMonitorPrint': rhd_monitor.c:59: error: implicit declaration of function 'lrintf' rhd_monitor.c:59: warning: incompatible implicit declaration of built-in function 'lrintf' ====================== Setting CFLAGS to "-std=c99" and LIBS to "-lm" as suggested in 'man lrintf' gives compile errors in different place. My compiler is: gcc (GCC) 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
Reviewing the source code a little further, the value displayed here is likely being pulled from the clock field of the EDID structure for your panel. This is an integer of whole megahertz value, in this case is 88. This is likely a bug in the panel by some naive code that originally wrote the EDID data and truncated 88.8 or 88.9 to 88MHz. I *think* the proper value should be 89.
I made few more tests and found that if I disconnect the external TFT monitor (which is not so big, just 1024x768) and start Xorg, it starts well: I have attached the logs for cases 'with/without DVI' so you can compare them. Keep in mind that it still works w/o the TFT monitor (only panel present), I suspect that this failure of Xorg to start is failed by the following: the only acceptable by the panel mode, which is 1440x900 88.75MHz has too high bandwidth which is not acceptable by TFT monitor (which according to Xorg log has bandwidth 80MHz), therefore the last possible mode is dropped and no modes remain available. Does it make sense? Separate question if this a good behavior: I would expect in this case from driver to stop trying to find the 'common mode' for panel and TFT and output at least to the panel so there will be at least one working device.
Does "IgnoreEDID" work in the driver code yet? Not sure about driver code, simple adding of this option line to the corresponding section of Xorg config didn't change the situation for the Panel+TFT configuration.
Best regards, Kirill
Kirill Belokurov wrote:
On Saturday 01 December 2007, Coleman Kane wrote:
>>> Please find it in the attachment. For the record, below is the >>> rhd_conntest output when I was dumping it (TFT monitor was >>> disconnected this time): >>> >> Should be fixed in git now. >> > No, unfortunately this didn't resolve the issue: the error mesage > from the > Can you verify that this issue happens with Option "NoRandr" as well? It probably will. If everything works you should see an image on all connected monitors including panel.
Unfortunately, with "noRandr" it is broken even worser: the Xorg simply doesn't start at all:
(EE) RADEONHD(0): No valid modes found (EE) Screen(s) found, but none have a usable configuration.
apparently, there is some issue with rejected panel modes: (II) RADEONHD(0): Rejected mode "1440x900" (1440x900:88.8Mhz): mode clock too high
I am attaching the Xorg log for this case.
Regards, Kirill
It looks like the mode that your system tries to set up requires 88.8MHz display bandwidth, however the panel seems to report that it's max is 88MHz (interpreted as 88.0MHz I assume) meaning that your monitor is telling X that the mode that it gave to X is out-of-range. It looks like a truncation problem to me... I wonder where this is occurring.
-- Coleman Kane
Apply the attached patch to your latest radeonhd sources, rebuild, reinstall, re-run X, and re-send the log. This patch attempts to undo that incidental truncation that happens around line 60 of src/rhd_monitor.c.
Patched, but I am getting build failure when running make: ====================== rhd_monitor.c: In function 'RHDMonitorPrint': rhd_monitor.c:59: error: implicit declaration of function 'lrintf' rhd_monitor.c:59: warning: incompatible implicit declaration of built-in function 'lrintf' ======================
Setting CFLAGS to "-std=c99" and LIBS to "-lm" as suggested in 'man lrintf' gives compile errors in different place. My compiler is: gcc (GCC) 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
Ah I forgot that Linux requires explicit -lm. I'm using FreeBSD w/ GCC 4.2.1.
Reviewing the source code a little further, the value displayed here is likely being pulled from the clock field of the EDID structure for your panel. This is an integer of whole megahertz value, in this case is 88. This is likely a bug in the panel by some naive code that originally wrote the EDID data and truncated 88.8 or 88.9 to 88MHz. I *think* the proper value should be 89.
I made few more tests and found that if I disconnect the external TFT monitor (which is not so big, just 1024x768) and start Xorg, it starts well: I have attached the logs for cases 'with/without DVI' so you can compare them. Keep in mind that it still works w/o the TFT monitor (only panel present), I suspect that this failure of Xorg to start is failed by the following: the only acceptable by the panel mode, which is 1440x900 88.75MHz has too high bandwidth which is not acceptable by TFT monitor (which according to Xorg log has bandwidth 80MHz), therefore the last possible mode is dropped and no modes remain available. Does it make sense?
Separate question if this a good behavior: I would expect in this case from driver to stop trying to find the 'common mode' for panel and TFT and output at least to the panel so there will be at least one working device.
Does "IgnoreEDID" work in the driver code yet?
Not sure about driver code, simple adding of this option line to the corresponding section of Xorg config didn't change the situation for the Panel+TFT configuration.
Best regards, Kirill
Attached a new patch... try this one with only adding LIBS="-lm" and not chagning the CFLAGS. The default standard used by your compiler should include C99 as well as other extensions. -- Coleman Kane
On Sat, Dec 01, 2007 at 04:18:09PM -0500, Coleman Kane wrote:
Kirill Belokurov wrote:
On Friday 30 November 2007, Matthias Hopf wrote:
Unfortunately, with "noRandr" it is broken even worser: the Xorg simply doesn't start at all:
(EE) RADEONHD(0): No valid modes found (EE) Screen(s) found, but none have a usable configuration.
apparently, there is some issue with rejected panel modes: (II) RADEONHD(0): Rejected mode "1440x900" (1440x900:88.8Mhz): mode clock too high
I am attaching the Xorg log for this case.
Regards, Kirill
It looks like the mode that your system tries to set up requires 88.8MHz display bandwidth, however the panel seems to report that it's max is 88MHz (interpreted as 88.0MHz I assume) meaning that your monitor is telling X that the mode that it gave to X is out-of-range. It looks like a truncation problem to me... I wonder where this is occurring.
Nope. This is because modevalidation now tries to find a single common mode on both outputs, and thus both monitors. The native mode of the first has too high a dotclock for the external monitor. So this is not the issue here. About validating an 88750kHz mode against an 88000kHz monitor (the panel): this is no problem as there is a 1% tolerance on this value: 88750kHz < 88880kHz Luc Verhaegen. SUSE/Novell X Driver Developer. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
Luc Verhaegen wrote:
On Sat, Dec 01, 2007 at 04:18:09PM -0500, Coleman Kane wrote:
Kirill Belokurov wrote:
On Friday 30 November 2007, Matthias Hopf wrote:
Unfortunately, with "noRandr" it is broken even worser: the Xorg simply doesn't start at all:
(EE) RADEONHD(0): No valid modes found (EE) Screen(s) found, but none have a usable configuration.
apparently, there is some issue with rejected panel modes: (II) RADEONHD(0): Rejected mode "1440x900" (1440x900:88.8Mhz): mode clock too high
I am attaching the Xorg log for this case.
Regards, Kirill
It looks like the mode that your system tries to set up requires 88.8MHz display bandwidth, however the panel seems to report that it's max is 88MHz (interpreted as 88.0MHz I assume) meaning that your monitor is telling X that the mode that it gave to X is out-of-range. It looks like a truncation problem to me... I wonder where this is occurring.
Nope.
This is because modevalidation now tries to find a single common mode on both outputs, and thus both monitors.
The native mode of the first has too high a dotclock for the external monitor.
So this is not the issue here.
Could they use a custom ModeLine with a proper dotclock with that panel then?
About validating an 88750kHz mode against an 88000kHz monitor (the panel): this is no problem as there is a 1% tolerance on this value:
88750kHz < 88880kHz
Luc Verhaegen. SUSE/Novell X Driver Developer.
So... due to the tolerance value of 1%, the above combination should or should not be working? -- Coleman Kane -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Tue, Dec 11, 2007 at 01:23:20PM -0500, Coleman Kane wrote:
Luc Verhaegen wrote: Could they use a custom ModeLine with a proper dotclock with that panel then?
Not with NoRandR, not yet that is :)
So... due to the tolerance value of 1%, the above combination should or should not be working?
The panel will accept it, the external monitor will not accept it. Luc Verhaegen. SUSE/Novell X Driver Developer. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
participants (4)
-
Coleman Kane -
Kirill Belokurov -
Luc Verhaegen -
Matthias Hopf