Bug 13740

Created attachment 13232 [details]
Photo of corrupted screen

Created attachment 13233 [details]
X Log

Created attachment 13234 [details]
Output of lspci -vv

Created attachment 13235 [details]
X Conf

Created attachment 13236 [details]
A clearer photo

Search from the envisiondisplay.com, I found for EN9250 monitor it requires +hsync +vsync for 1280x1024 mode.

So would you please add a new mode using xrandr to your TMDS-1 output, you can use  #cvt 1280 1024 to calculate the modeline, but change the -hsync +vsync to +hsync +vsync?

Thanks,
Hong

Thank you very much for the help with this.

I suspected this might be wrong since the problem occurs on my other monitor when using the DVI, this confirms it.  The modeline you suggest makes no difference on restarting the xorg server.  This is the line I used in my monitor section:

Modeline "1280x1024_60.00"  109.00  1280 1368 1496 1712  1024 1027 1034 1063 +hsync +vsync

Another clue for you that I noticed:  The problem does not show up until the graphics card has been run for at least 1/2 to 1 full hour, and it gets worse gradually until after about 6 hours it is intolerable.  Restarting the xorg server does not impact it.

Do you think it may be faulty hardware?

(In reply to comment #7)
> Thank you very much for the help with this.
> 
> I suspected this might be wrong since the problem occurs on my other monitor
> when using the DVI, this confirms it.  The modeline you suggest makes no
> difference on restarting the xorg server.  This is the line I used in my
> monitor section:
> 
> Modeline "1280x1024_60.00"  109.00  1280 1368 1496 1712  1024 1027 1034 1063
> +hsync +vsync
> 
> Another clue for you that I noticed:  The problem does not show up until the
> graphics card has been run for at least 1/2 to 1 full hour, and it gets worse
> gradually until after about 6 hours it is intolerable.  Restarting the xorg
> server does not impact it.
> 
> Do you think it may be faulty hardware?
> 

Matt, what's the model name of "the other monitor" you tried? Is there a X.org log  file available?

"the problem occurs on my other monitor when using the DVI, this confirms it" increase the possibility that this could be a HW issue. Would you please provide more detailed info of the HW you are using? Maybe you can post it to mailing list to see if it can be reproduced by others having the same HW platform.

After a lot of experimenting with things I have found the settings that seem to work for this monitor, I see no signs of the problem anymore but I will reopen the bug if it comes back later.

        Modeline    "1280x1024" 134.72 1280 1352 1488 1728 1024 1025 1028 1084 +hsync +vsync
        HorizSync    30.0 - 83.0
        VertRefresh  55.0 - 75.0

I don't know who is responsible for setting the defaults for the devices but you might wish to communicate to them that the modeline set up by cvt doesn't work for this monitor (EN9250) nor does the default used by Xorg.

I found this modeline by googling "EN9250 xorg.conf", here is the person who noted it:
http://www.webservertalk.com/message1741902.html

After examining your xorg, I found that the detail-timing mode in EDID data block is:
(II) intel(0): clock: 135.0 MHz   Image Size:  376 x 301 mm
(II) intel(0): h_active: 1280  h_sync: 1296  h_sync_end 1440 h_blank_end 1688 h_border: 0
(II) intel(0): v_active: 1024  v_sync: 1025  v_sync_end 1028 v_blanking: 1066 v_border: 0

Which seems close to the working mode you entered, the problem is this mode is filtered out (because of vrefresh out of range)
(II) intel(0): EDID vendor "EPI", prod id 59685
(II) intel(0): Not using mode "1280x1024" (vrefresh out of range)

Would you please try to remove the following line in your xorg.conf and have a try?
        HorizSync    30.0 - 83.0
        VertRefresh  55.0 - 75.0

Thanks,
Hong

I found the reason why the detail-timing mode from EDID is filtered out.

135MHz / 1688 / 1066 = 75.02 which > 75Hz in your xorg.conf file, so this mode is filted out with your X server.

So you have several options:
1. Please update your X server to a new one, we now add a 1% tolerance to the sync range. So now this mode will not be filtered out with configed sync range in xorg.log
or
2. remove the sync range config in your xorg.log, we will use the info from EDID data by default.

If this detailed-timing mode (135MHz one) from EDID doesn't work, then I am afraid you have to stick with your hacked mode for your monitor.

Thanks,
Hong

Should be fixed now.

Please reopen it if problem still exists.

Reopening this bug as some changes have caused the driver to fail again though in a different way.  Let me know if you want it in a new bug instead.

Using driver:
2.2.1_pre20080125

This was packaged from Gentoo.  Have tried it with the same config file (including that modeline hack), also tried it with modeline and sync commented out.

Result:

the x server starts up, the 2nd monitor "Hyundai" goes into standby and the 1st monitor which needed the modeline hack "EN9250" stays on but has a black screen.  

Switching back to a terminal (ctrl+alt+f1) shows no change; the video displays are  no longer working.  Keyboard still responds to ctrl-alt-del so I can reboot.

X log shows no indication of any problems.  Let me know what can info I can provide or work I can do to help debug this.

matt, to keep the bug comments clear and focused, please open a new bug for your issue in comment# 13. I'll keep this original bug as resolved. thanks.