| Summary: | G45 display sync frequently lost via HDMI/DVI | ||
|---|---|---|---|
| Product: | xorg | Reporter: | Chris Jones <cmsj> |
| Component: | Driver/intel | Assignee: | MaLing <ling.ma> |
| Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> |
| Severity: | normal | ||
| Priority: | medium | CC: | freedesktop, ling.ma, matej.tyc, michael.fu, xorg |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | |||
|
Description
Chris Jones
2008-09-27 08:42:42 UTC
Please provide log with driver version, according to http://www.intellinuxgraphics.org/how_to_report_bug.html. Created attachment 19263 [details]
Xorg log
I saw something similar when I had the Supermicro MBD-C2SEA hooked up to a Dell 1702FP. The board is a G45/ICH10 chipset w/DDR3 and running over a 3m HDMI->DVI cable. it looks like we're getting some more reports of this at https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/275152 although I guess it's hard to be completely sure, since it's a difficult thing to accurately describe. I am seeing the same thing with my system. I have an Asus P5Q-EM with an intel X4500HD. ALthough I'm seeing this problem using the DVI port. I have Ubuntu 8.10 Beta installed. I think I've seen this once on a sharp aquas, but never saw this on another sony bravia. Not sure about if there's anything we should setup with data from EDID extension block, which currently not available in xserver. Wang: Is there some kind of debug tool I can use to dump the chip state in Windows to compare to how it is programmed in Xorg? I'm kinda assuming that it must be something to do with the way the chip is being setup if it's able to persist into the BIOS on a reboot and is only fixed by Windows loading a full graphical environment (presumably thus resetting and reprogramming the chip from scratch). I don't know about any tools available on windows for this, but your info has high value for us. hi Chris Although currently X don't support E-EDID(including corresponding HDMI configuration ), an HDMI source shall support at least one of the following video format timings: 640x480p @ 59.94/60Hz 720x480p @ 59.94/60Hz 720x576p @ 50Hz. Could you set up those video format timing by xrandr to find whether the bug still occurs? Thanks Ma Ling MaLing, I'm experiencing this on a Asus P5Q-EM when connected to my monitor via DVI. Can I still test what you suggest in comment 9, or are those values only valid for HDMI? Any hints on the xrandr command to set those? My apologies for not trying the other modes. xrand lists a 640x480@60 mode which I am testing now, but I am not sure how to construct the other modes with --newmode. hi, (assume that your output name is HDMI-1, you may use xrandr --verbose to check it) $cvt -v 640 480 640x480 59.38 Hz (CVT 0.31M3) hsync: 29.69 kHz; pclk: 23.75 MHz Modeline "640x480_60.00" 23.75 640 664 720 800 480 483 487 500 -hsync +vsync $xrandr --newmode "640x480_test" 23.75 640 664 720 800 480 483 487 500 -hsync +vsync $xrandr --addmode HDMI-1 640x480_test $xrandr --output VGA --mode 640x480_test thanks Ma Ling sorry , please modify the two below commands $xrandr --addmode HDMI-1 640x480_test $xrandr --output VGA --mode 640x480_test as follow $xrandr --addmode HDMI-1 640x480_test $xrandr --output HDMI-1 --mode 640x480_test thanks Ma Ling I have been using the 640x480 mode suggested in comment 12 and 13 for more than an hour and the bug has not occured yet. Normally it happens several times an hour, so I think we can safely say the bug does not occur using that mode. What does that tell you? Obviously I do not want to use a 640x480 resolution in the long run, so I'm hoping for a better fix;-) hi,
Based on the result and G45 chip set must be able to support 1920x1080, I suppose there may be confliction between mode and that of display really support..So could you test it by following steps ?
1. xrandr --verbose
(assume the output is like below)
HDMI-1 connected 1920x1200+0+0 (0x3d) normal (normal left inverted right x axis
y axis) 519mm x 324mm
Identifier: 0x3c
Timestamp: 7753354
Subpixel: horizontal rgb
Clones:
CRTC: 0
CRTCs: 0 1
EDID_DATA:
.
.
.
1920x1200 (0x3d) 154.0MHz +HSync -VSync *current +preferred
h: width 1920 start 1968 end 2000 total 2080 skew 0 clock 74.0KHz
v: height 1200 start 1203 end 1209 total 1235 clock 60.0Hz
1600x1200 (0x3e) 162.0MHz +HSync +VSync
h: width 1600 start 1664 end 1856 total 2160 skew 0 clock 75.0KHz
v: height 1200 start 1201 end 1204 total 1250 clock 60.0Hz
1680x1050 (0x3f) 119.0MHz +HSync -VSync
h: width 1680 start 1728 end 1760 total 1840 skew 0 clock 64.7KHz
v: height 1050 start 1053 end 1059 total 1080 clock 59.9Hz
1400x1050 (0x40) 155.8MHz +HSync +VSync
h: width 1400 start 1464 end 1784 total 1912 skew 0 clock 81.5KHz
v: height 1050 start 1052 end 1064 total 1090 clock 74.8Hz
1400x1050 (0x41) 122.0MHz +HSync +VSync
h: width 1400 start 1488 end 1640 total 1880 skew 0 clock 64.9KHz
v: height 1050 start 1052 end 1064 total 1082 clock 60.0Hz
2. then check them one by one to find appropriate mode line you need by the following command.
$xrandr --output HDMI-1 --mode XID (.e.g 0x3d)
Thanks
Ma Ling
Created attachment 19978 [details]
Output from xrandr --verbose
As can be seen in the attached output from xrandr, the following two entries are printed for the resolution 1600x1200. This is the resolution I normally run, so I dediced to test them with your suggesed command.
1600x1200 (0x3e) 162.0MHz +HSync +VSync +preferred
h: width 1600 start 1664 end 1856 total 2160 skew 0 clock 75.0KHz
v: height 1200 start 1201 end 1204 total 1250 clock 60.0Hz
1600x1200 (0x3f) 161.0MHz -HSync +VSync *current
h: width 1600 start 1704 end 1880 total 2160 skew 0 clock 74.5KHz
v: height 1200 start 1201 end 1204 total 1242 clock 60.0Hz
I then followed your advise and tried running:
xrandr --output HDMI-1 --mode 0x3e
and
xrandr --output HDMI-1 --mode 0x3f
Nothing was printed to the console for either of those invocations, but the following was printed to the Xorg.0.log file (identical output on both invocations). The screen went black for a second or so, but I'm guessing that's normal because of the mode switch.
(WW) EDID preferred timing clock 162.00MHz exceeds claimed max 160MHz, fixing
(II) intel(0): EDID vendor "SNY", prod id 19456
(II) intel(0): Using hsync ranges from config file
(II) intel(0): Using vrefresh ranges from config file
(II) intel(0): Printing DDC gathered Modelines:
(II) intel(0): Modeline "1600x1200"x0.0 162.00 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (75.0 kHz)
(II) intel(0): Modeline "800x600"x0.0 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz)
(II) intel(0): Modeline "640x480"x0.0 25.20 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz)
(II) intel(0): Modeline "720x400"x0.0 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz)
(II) intel(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz)
(II) intel(0): Modeline "1600x1200"x60.0 160.96 1600 1704 1880 2160 1200 1201 1204 1242 -hsync +vsync (74.5 kHz)
(II) intel(0): Modeline "1280x1024"x60.0 108.88 1280 1360 1496 1712 1024 1025 1028 1060 -hsync +vsync (63.6 kHz)
(II) intel(0): Modeline "1280x960"x60.0 102.10 1280 1360 1496 1712 960 961 964 994 -hsync +vsync (59.6 kHz)
(II) intel(0): EDID vendor "SNY", prod id 19456
(WW) EDID preferred timing clock 162.00MHz exceeds claimed max 160MHz, fixing
(II) intel(0): EDID vendor "SNY", prod id 19456
(II) intel(0): Using hsync ranges from config file
(II) intel(0): Using vrefresh ranges from config file
(II) intel(0): Printing DDC gathered Modelines:
(II) intel(0): Modeline "1600x1200"x0.0 162.00 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (75.0 kHz)
(II) intel(0): Modeline "800x600"x0.0 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz)
(II) intel(0): Modeline "640x480"x0.0 25.20 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz)
(II) intel(0): Modeline "720x400"x0.0 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz)
(II) intel(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz)
(II) intel(0): Modeline "1600x1200"x60.0 160.96 1600 1704 1880 2160 1200 1201 1204 1242 -hsync +vsync (74.5 kHz)
(II) intel(0): Modeline "1280x1024"x60.0 108.88 1280 1360 1496 1712 1024 1025 1028 1060 -hsync +vsync (63.6 kHz)
(II) intel(0): Modeline "1280x960"x60.0 102.10 1280 1360 1496 1712 960 961 964 994 -hsync +vsync (59.6 kHz)
(II) intel(0): EDID vendor "SNY", prod id 19456
Are those the modelines you talked about? Or should they be printed elsewhere? Why is idendical output appended to this log with both 0x3e and 0x3f?
Anyway, is the warning "preferred timing clock 162.00MHz exceeds claimed max 160MHz" of interest? I noticed that 162 appears in the modeline for 1600x1200 in that output:
Modeline "1600x1200"x0.0 162.00 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (75.0 kHz)
Should that be 160 instead?
I noticed something interesting. Here is the modline printed from cvt: $ cvt -v 1600 1200 # 1600x1200 59.87 Hz (CVT 1.92M3) hsync: 74.54 kHz; pclk: 161.00 MHz Modeline "1600x1200_60.00" 161.00 1600 1712 1880 2160 1200 1203 1207 1245 -hsync +vsync Notice that this modline is different from both of the 1600x1200 modlines that appeared in my Xorg.0.log (as shown in comment 16): (II) intel(0): Modeline "1600x1200"x60.0 160.96 1600 1704 1880 2160 1200 1201 1204 1242 -hsync +vsync (74.5 kHz) (II) intel(0): Modeline "1600x1200"x0.0 162.00 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (75.0 kHz) By the way, when I use the Vesa driver in X, I do not experience this blanking of the screen. I'll try to investigate what modline is used in that case. "Are those the modelines you talked about? Or should they be printed elsewhere? Why is idendical output appended to this log with both 0x3e and 0x3f?" because you use xrandr --output HDMI-1 --mode 0x3e and xrandr --output HDMI-1 --mode 0x3f respectively, they are appended into mode list. " Anyway, is the warning "preferred timing clock 162.00MHz exceeds claimed max 160MHz" of interest? I noticed that 162 appears in the modeline for 1600x1200 in that output: Modeline "1600x1200"x0.0 162.00 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (75.0 kHz) Should that be 160 instead?" The information from display device includes pereferred modes and dispaly range, if preferred modes exceeds the range, worning message will be printed, but the range will be changed by preferred mode clock. " $ cvt -v 1600 1200 # 1600x1200 59.87 Hz (CVT 1.92M3) hsync: 74.54 kHz; pclk: 161.00 MHz Modeline "1600x1200_60.00" 161.00 1600 1712 1880 2160 1200 1203 1207 1245 -hsync +vsync Notice that this modline is different from both of the 1600x1200 modlines that appeared in my Xorg.0.log (as shown in comment 16): (II) intel(0): Modeline "1600x1200"x60.0 160.96 1600 1704 1880 2160 1200 1201 1204 1242 -hsync +vsync (74.5 kHz) (II) intel(0): Modeline "1600x1200"x0.0 162.00 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (75.0 kHz) " They are considered another version of the same video timing with that in Xorg.0.log with slightly different pixel clock frequencies. According to modes from xrandr --verbose, do you find the appropriate mode to fix the problem? Thanks Ma Ling >According to modes from xrandr --verbose, do you find the appropriate mode to
>fix the problem?
Neither of the two 1600x1200 modes fixed the problem; I have to use a lower resolution to get a stable output. If I remember correctly, 1024x768 worked (obviously not an optimal solution).
(In reply to comment #19) > >According to modes from xrandr --verbose, do you find the appropriate mode to > >fix the problem? > Neither of the two 1600x1200 modes fixed the problem; I have to use a lower > resolution to get a stable output. If I remember correctly, 1024x768 worked > (obviously not an optimal solution). please use cvt -v -r 1600 1200 60 to generate corresponding mode line, then make it as your current mode. thanks Ma Ling Thanks for your tip Ma. I did the following: $ cvt -v -r 1600 1200 60 # 1600x1200 59.92 Hz (CVT 1.92M3-R) hsync: 74.01 kHz; pclk: 130.25 MHz Modeline "1600x1200R" 130.25 1600 1648 1680 1760 1200 1203 1207 1235 +hsync -vsync $ xrandr --newmode "1600x1200_test" 130.25 1600 1648 1680 1760 1200 1203 1207 1235 +hsync -vsync $ xrandr --addmode HDMI-1 1600x1200_test $ xrandr --output HDMI-1 --mode 1600x1200_test So far the display has been completely stable using this mode. I need some more time before I can confirm that it really fixes the problem. If this turns out to be a working mode, can this information be used to add a quirk or something to the Intel driver? Or do I need to just "live with it" and add the mode to my xorg.conf file? I tried a cvt mode, but it my TV was unable to display it: -(cmsj@tenshu)-(~)- cvt -v -r 1920 1080 60 # 1920x1080 59.93 Hz (CVT 2.07M9-R) hsync: 66.59 kHz; pclk: 138.50 MHz Modeline "1920x1080R" 138.50 1920 1968 2000 2080 1080 1083 1088 1111 +hsync -vsync -(cmsj@tenshu)-(~)- xrandr --newmode "1920x1080cvt" 138.50 1920 1968 2000 2080 1080 1083 1088 1111 +hsync -vsync -(cmsj@tenshu)-(~)- xrandr --addmode HDMI-1 "1920x1080cvt" -(cmsj@tenshu)-(~)- xrandr --output HDMI-1 --mode 1920x1080cvt -(cmsj@tenshu)-(~)- xrandr Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 1920 x 1920 VGA disconnected (normal left inverted right x axis y axis) HDMI-1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 1600mm x 900mm 1920x1080 60.0 + 1680x1050 60.0 1600x1024 60.2 1400x1050 60.0 1280x1024 60.0 1440x900 59.9 1280x960 60.0 1360x768 60.0 59.8 1152x864 60.0 1024x768 60.0 800x600 60.3 56.2 640x480 60.0 59.9 1920x1080cvt 59.9* HDMI-2 disconnected (normal left inverted right x axis y axis) possibly because it's not actually 60Hz? I've given this some more testing, and I can not safely say that the mode found using the steps in comment 21 has resolved the issue for me. (In reply to comment #23) > I've given this some more testing, and I can not safely say that the mode found > using the steps in comment 21 has resolved the issue for me. Sorry, 'not' was a typo. What I meant to say was: I can NOW safely say that the mode found using the steps in comment 21 has resolved the issue for me. (In reply to comment #21) > Thanks for your tip Ma. I did the following: > $ cvt -v -r 1600 1200 60 > # 1600x1200 59.92 Hz (CVT 1.92M3-R) hsync: 74.01 kHz; pclk: 130.25 MHz > Modeline "1600x1200R" 130.25 1600 1648 1680 1760 1200 1203 1207 1235 +hsync > -vsync > $ xrandr --newmode "1600x1200_test" 130.25 1600 1648 1680 1760 1200 1203 1207 > 1235 +hsync -vsync > $ xrandr --addmode HDMI-1 1600x1200_test > $ xrandr --output HDMI-1 --mode 1600x1200_test > So far the display has been completely stable using this mode. I need some more > time before I can confirm that it really fixes the problem. > If this turns out to be a working mode, can this information be used to add a > quirk or something to the Intel driver? Or do I need to just "live with it" and > add the mode to my xorg.conf file? Thanks for your suggestion, we will do some investigation about whether to add quirks on it. But please add the modeline to your xorg.conf like the bellow Section "Monitor" Identifier "Your SONY" Modeline "1600x1200R" 130.25 1600 1648 1680 1760 1200 1203 1207 1235 +hsync -vsync Option "PreferredMode" "1600x1200R" ... ... EndSection Section "Screen" Identifier "HDMI Screen" Monitor "Your SONY" ... ... EndSection Section "ServerLayout" Identifier "HDMI Layout" Screen "HDMI Screen" ... ... EndSection (In reply to comment #22) > I tried a cvt mode, but it my TV was unable to display it: > -(cmsj@tenshu)-(~)- cvt -v -r 1920 1080 60 > # 1920x1080 59.93 Hz (CVT 2.07M9-R) hsync: 66.59 kHz; pclk: 138.50 MHz > Modeline "1920x1080R" 138.50 1920 1968 2000 2080 1080 1083 1088 1111 +hsync > -vsync > -(cmsj@tenshu)-(~)- xrandr --newmode "1920x1080cvt" 138.50 1920 1968 2000 2080 > 1080 1083 1088 1111 +hsync -vsync > -(cmsj@tenshu)-(~)- xrandr --addmode HDMI-1 "1920x1080cvt" > -(cmsj@tenshu)-(~)- xrandr --output HDMI-1 --mode 1920x1080cvt > -(cmsj@tenshu)-(~)- xrandr > Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 1920 x 1920 > VGA disconnected (normal left inverted right x axis y axis) > HDMI-1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) > 1600mm x 900mm > 1920x1080 60.0 + > 1680x1050 60.0 > 1600x1024 60.2 > 1400x1050 60.0 > 1280x1024 60.0 > 1440x900 59.9 > 1280x960 60.0 > 1360x768 60.0 59.8 > 1152x864 60.0 > 1024x768 60.0 > 800x600 60.3 56.2 > 640x480 60.0 59.9 > 1920x1080cvt 59.9* > HDMI-2 disconnected (normal left inverted right x axis y axis) > possibly because it's not actually 60Hz? So far I guess the issue is from hardware, because reduced blanking only reduce bandwidth for modern monitor, and EDID from monitor should not provide modelines over it's capability. Please use lower resolution(reduced bank or not) to resolve above problem again. thanks Ma Ling (In reply to comment #24) > (In reply to comment #23) > > I've given this some more testing, and I can not safely say that the mode found > > using the steps in comment 21 has resolved the issue for me. > Sorry, 'not' was a typo. What I meant to say was: I can NOW safely say that the > mode found using the steps in comment 21 has resolved the issue for me. So we can close the issue now ? Thanks Ma Ling > So far I guess the issue is from hardware, because reduced blanking only reduce
> bandwidth for modern monitor, and EDID from monitor should not provide
> modelines over it's capability. Please use lower resolution(reduced bank or
> not) to resolve above problem again.
What do you mean the issue is from hardware?
FWIW I have verified that the mode X selects is the mode provided by the EDID from the monitor.
Once the flickering has started, changing to a lower resolution does not help, which leads me to believe that this is not a bandwidth issue, but as I have suggested previously, an issue with the way the G45 chip is being set up.
To confirm again - in Windows I can use 1920x1080 with absolutely no flickering ever. If you can provide me with information or tools to dump the resolution or chip registers, for comparison, I will be glad to obtain the information.
I do not believe this issue can be closed, it is not resolved.
I have a Intel motherbord DQ45CB and also had this problem. The solution as suggested in comment #21 (in combination with #25) also helped resolve this problem for me. I'll track this bug in case more information is necessary from different users. (In reply to comment #19) > >According to modes from xrandr --verbose, do you find the appropriate mode to > >fix the problem? > Neither of the two 1600x1200 modes fixed the problem; I have to use a lower > resolution to get a stable output. If I remember correctly, 1024x768 worked > (obviously not an optimal solution). Hi, Could you test the following two modes by from Comment #16 by xrandr 1600x1200 (0x3e) 162.0MHz +HSync +VSync +preferred h: width 1600 start 1664 end 1856 total 2160 skew 0 clock 75.0KHz v: height 1200 start 1201 end 1204 total 1250 clock 60.0Hz 1600x1200 (0x3f) 161.0MHz -HSync +VSync *current h: width 1600 start 1704 end 1880 total 2160 skew 0 clock 74.5KHz v: height 1200 start 1201 end 1204 total 1242 clock 60.0Hz but please use "+hsync -vsync", instead of "+HSync +VSync" and "-HSync +VSync " by the way, your chipset is G35, or G45, if you don't know could you upload your X log file with ModeDebug option? Thanks Ma Ling (In reply to comment #28) > > So far I guess the issue is from hardware, because reduced blanking only reduce > > bandwidth for modern monitor, and EDID from monitor should not provide > > modelines over it's capability. Please use lower resolution(reduced bank or > > not) to resolve above problem again. > What do you mean the issue is from hardware? > FWIW I have verified that the mode X selects is the mode provided by the EDID > from the monitor. > Once the flickering has started, changing to a lower resolution does not help, > which leads me to believe that this is not a bandwidth issue, but as I have > suggested previously, an issue with the way the G45 chip is being set up. > To confirm again - in Windows I can use 1920x1080 with absolutely no flickering > ever. If you can provide me with information or tools to dump the resolution or > chip registers, for comparison, I will be glad to obtain the information. > I do not believe this issue can be closed, it is not resolved. I will give you 4 patchs to try this issue. thanks Ma Ling Created attachment 20649 [details] [review] hi, Chris I did 3 simple patchs to try this issue, could you test them, then let us do further work. Thanks Ma Ling Created attachment 20650 [details] [review] path2 Created attachment 20651 [details] [review] patch 3 Is it possible to apply those patches to 2.4.1? It doesn't seem to apply cleanly (In reply to comment #35) > Is it possible to apply those patches to 2.4.1? It doesn't seem to apply > cleanly hi, Your issue may be from sync polarity, so could you try the 3 patchs respectively, after that we can do further actions. thanks Ma Ling Ma Ling: Sorry if I wasn't clear - I am trying to apply the patches, but they do not apply cleanly to the source for the driver I am running, which is 2.4.1. If I need to test a newer version of the driver, so be it, but I understand that it is quite complex to get the newer code running on 2.6.27, since it requires GEM, newer libdrm, newer mesa and newer xorg. Please provide more information about how I can test this for you. (In reply to comment #37) > Ma Ling: Sorry if I wasn't clear - I am trying to apply the patches, but they > do not apply cleanly to the source for the driver I am running, which is 2.4.1. > If I need to test a newer version of the driver, so be it, but I understand > that it is quite complex to get the newer code running on 2.6.27, since it > requires GEM, newer libdrm, newer mesa and newer xorg. > Please provide more information about how I can test this for you. hi Chris, Sorry for my obscure description,the following is patch & test step on your code. before action plese ensure the mode at first. 1920x1200 (0x3d) 154.0MHz +HSync -VSync *current +preferred h: width 1920 start 1968 end 2000 total 2080 skew 0 clock 74.0KHz v: height 1200 start 1203 end 1209 total 1235 clock 60.0Hz 1) $patch -p1 < patch1 2) if patch1 succeed, run & test your issue. 3) if the issue still occur, $patch -R < patch1 and $patch -p1 < patch2 4) if patch2 succeed, run & test your issue 5) if the issue still occur, $patch -R < patch2, $patch -p1 < patch3 6) if patch3 succeed, run & test your issue after above steps if the issue still occure, let us do further work ! thanks Ma Ling (In reply to comment #29) > I have a Intel motherbord DQ45CB and also had this problem. The solution as > suggested in comment #21 (in combination with #25) also helped resolve this > problem for me. I'll track this bug in case more information is necessary from > different users. hi Justin, because now I guess the problem occur on sync polarity, Could you modify your sync polairty of problem modeline, for example assume the original problem mode line is Modeline "1600x1200_60.00" 161.00 1600 1712 1880 2160 1200 1203 1207 1245 -hsync +vsync we modify sync polarity respectively as +hsync -vsync, -hsync -vsync, +hsync +vsync , then change modified mode line to current mode by xrandr one bye one. if the problem is fixed that means sync polarity is root cause! thanks Ma Ling Created attachment 20759 [details] xrandr info (In reply to comment #39) Hi Ma Ling, I've tried all variants of the "official" modes. 0x3f and 0x40 are autodetected 0xa1 and 0xa2 are manually added as variants 0x3e is the artificially created one based on comment #21 All of 0x3d 0x40 0xa1 and 0xa2 result in short screen blanks. Only 0x3e makes the displays rocksolid in my case. I haven't tried other variants for this modeline. (In reply to comment #40) That should have been: All of 0x3f 0x40 0xa1 and 0xa2 result in short screen blanks. Only 0x3e makes the displays rocksolid in my case. I haven't tried other variants for this modeline. (In reply to comment #41) > (In reply to comment #40) > That should have been: > All of 0x3f 0x40 0xa1 and 0xa2 result in short screen blanks. Only 0x3e makes > the displays rocksolid in my case. I haven't tried other variants for this > modeline. hi Justin, Thanks for your help! from your test result, (In reply to comment #22) > I tried a cvt mode, but it my TV was unable to display it: > -(cmsj@tenshu)-(~)- cvt -v -r 1920 1080 60 > # 1920x1080 59.93 Hz (CVT 2.07M9-R) hsync: 66.59 kHz; pclk: 138.50 MHz > Modeline "1920x1080R" 138.50 1920 1968 2000 2080 1080 1083 1088 1111 +hsync > -vsync > -(cmsj@tenshu)-(~)- xrandr --newmode "1920x1080cvt" 138.50 1920 1968 2000 2080 > 1080 1083 1088 1111 +hsync -vsync > -(cmsj@tenshu)-(~)- xrandr --addmode HDMI-1 "1920x1080cvt" > -(cmsj@tenshu)-(~)- xrandr --output HDMI-1 --mode 1920x1080cvt > -(cmsj@tenshu)-(~)- xrandr > Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 1920 x 1920 > VGA disconnected (normal left inverted right x axis y axis) > HDMI-1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) > 1600mm x 900mm > 1920x1080 60.0 + > 1680x1050 60.0 > 1600x1024 60.2 > 1400x1050 60.0 > 1280x1024 60.0 > 1440x900 59.9 > 1280x960 60.0 > 1360x768 60.0 59.8 > 1152x864 60.0 > 1024x768 60.0 > 800x600 60.3 56.2 > 640x480 60.0 59.9 > 1920x1080cvt 59.9* > HDMI-2 disconnected (normal left inverted right x axis y axis) > possibly because it's not actually 60Hz? hi Chris by latest version driver and xorg , we can easily set mode line we need based on my test,I still suggest you to set modeline from cvt -r -t 1920 1080 60 by xrandr in order to check the issue ? by the way I touched one SONY TV(KLV-40x200A), manufacturer said they didn't guaranteed mode under HDMI, so possibly you need to ensure the KDL-V3000 40 will support HDMI completely. Thanks Ma Ling (In reply to comment #41) > (In reply to comment #40) > That should have been: > All of 0x3f 0x40 0xa1 and 0xa2 result in short screen blanks. Only 0x3e makes > the displays rocksolid in my case. I haven't tried other variants for this > modeline. hi Justin Thanks for your help! To narrow down the issue could you set the mode line $ cvt (In reply to comment #41) > (In reply to comment #40) > That should have been: > All of 0x3f 0x40 0xa1 and 0xa2 result in short screen blanks. Only 0x3e makes > the displays rocksolid in my case. I haven't tried other variants for this > modeline. hi Justin Thanks for your data ! I studied the data, so could you test the modeline from $cvt -v 1680 1050 50 ? Thanks Ma Ling Hello Ma Ling, (In reply to comment #43) Sorry for the late response. I've tested the other variants of the 'cvt -v -r 1680 1050 60' version and tested the variants of the 'cvt -v 1680 1050 50' version. Below are the "results": ## All variants seemed to work fine without blanks xrandr --newmode "1680x1050R" 119.00 1680 1728 1760 1840 1050 1053 1059 1080 +hsync -vsync xrandr --newmode "1680x1050R1" 119.00 1680 1728 1760 1840 1050 1053 1059 1080 -hsync -vsync xrandr --newmode "1680x1050R2" 119.00 1680 1728 1760 1840 1050 1053 1059 1080 +hsync +vsync xrandr --newmode "1680x1050R3" 119.00 1680 1728 1760 1840 1050 1053 1059 1080 -hsync +vsync ## All variants produced: "Input not supported" message from monitor xrandr --newmode "1680x1050_50.00" 119.50 1680 1776 1944 2208 1050 1053 1059 1083 -hsync +vsync xrandr --newmode "1680x1050_50.001" 119.50 1680 1776 1944 2208 1050 1053 1059 1083 +hsync +vsync xrandr --newmode "1680x1050_50.002" 119.50 1680 1776 1944 2208 1050 1053 1059 1083 -hsync -vsync xrandr --newmode "1680x1050_50.003" 119.50 1680 1776 1944 2208 1050 1053 1059 1083 +hsync -vsync Hope this helps. (In reply to comment #44) > Hello Ma Ling, > (In reply to comment #43) > Sorry for the late response. I've tested the other variants of the 'cvt -v -r > 1680 1050 60' version and tested the variants of the 'cvt -v 1680 1050 50' > version. Below are the "results": > ## All variants seemed to work fine without blanks > xrandr --newmode "1680x1050R" 119.00 1680 1728 1760 1840 1050 1053 1059 1080 > +hsync -vsync > xrandr --newmode "1680x1050R1" 119.00 1680 1728 1760 1840 1050 1053 1059 > 1080 -hsync -vsync > xrandr --newmode "1680x1050R2" 119.00 1680 1728 1760 1840 1050 1053 1059 > 1080 +hsync +vsync > xrandr --newmode "1680x1050R3" 119.00 1680 1728 1760 1840 1050 1053 1059 > 1080 -hsync +vsync > ## All variants produced: "Input not supported" message from monitor > xrandr --newmode "1680x1050_50.00" 119.50 1680 1776 1944 2208 1050 1053 1059 > 1083 -hsync +vsync > xrandr --newmode "1680x1050_50.001" 119.50 1680 1776 1944 2208 1050 1053 > 1059 1083 +hsync +vsync > xrandr --newmode "1680x1050_50.002" 119.50 1680 1776 1944 2208 1050 1053 > 1059 1083 -hsync -vsync > xrandr --newmode "1680x1050_50.003" 119.50 1680 1776 1944 2208 1050 1053 > 1059 1083 +hsync -vsync > Hope this helps. hi Justin, I think we narrow down the issue based on your test (In reply to comment #44) > Hello Ma Ling, > (In reply to comment #43) > Sorry for the late response. I've tested the other variants of the 'cvt -v -r > 1680 1050 60' version and tested the variants of the 'cvt -v 1680 1050 50' > version. Below are the "results": > ## All variants seemed to work fine without blanks > xrandr --newmode "1680x1050R" 119.00 1680 1728 1760 1840 1050 1053 1059 1080 > +hsync -vsync > xrandr --newmode "1680x1050R1" 119.00 1680 1728 1760 1840 1050 1053 1059 > 1080 -hsync -vsync > xrandr --newmode "1680x1050R2" 119.00 1680 1728 1760 1840 1050 1053 1059 > 1080 +hsync +vsync > xrandr --newmode "1680x1050R3" 119.00 1680 1728 1760 1840 1050 1053 1059 > 1080 -hsync +vsync > ## All variants produced: "Input not supported" message from monitor > xrandr --newmode "1680x1050_50.00" 119.50 1680 1776 1944 2208 1050 1053 1059 > 1083 -hsync +vsync > xrandr --newmode "1680x1050_50.001" 119.50 1680 1776 1944 2208 1050 1053 > 1059 1083 +hsync +vsync > xrandr --newmode "1680x1050_50.002" 119.50 1680 1776 1944 2208 1050 1053 > 1059 1083 -hsync -vsync > xrandr --newmode "1680x1050_50.003" 119.50 1680 1776 1944 2208 1050 1053 > 1059 1083 +hsync -vsync > Hope this helps. (In reply to comment #44) > Hello Ma Ling, > (In reply to comment #43) > Sorry for the late response. I've tested the other variants of the 'cvt -v -r > 1680 1050 60' version and tested the variants of the 'cvt -v 1680 1050 50' > version. Below are the "results": > ## All variants seemed to work fine without blanks > xrandr --newmode "1680x1050R" 119.00 1680 1728 1760 1840 1050 1053 1059 1080 > +hsync -vsync > xrandr --newmode "1680x1050R1" 119.00 1680 1728 1760 1840 1050 1053 1059 > 1080 -hsync -vsync > xrandr --newmode "1680x1050R2" 119.00 1680 1728 1760 1840 1050 1053 1059 > 1080 +hsync +vsync > xrandr --newmode "1680x1050R3" 119.00 1680 1728 1760 1840 1050 1053 1059 > 1080 -hsync +vsync > ## All variants produced: "Input not supported" message from monitor > xrandr --newmode "1680x1050_50.00" 119.50 1680 1776 1944 2208 1050 1053 1059 > 1083 -hsync +vsync > xrandr --newmode "1680x1050_50.001" 119.50 1680 1776 1944 2208 1050 1053 > 1059 1083 +hsync +vsync > xrandr --newmode "1680x1050_50.002" 119.50 1680 1776 1944 2208 1050 1053 > 1059 1083 -hsync -vsync > xrandr --newmode "1680x1050_50.003" 119.50 1680 1776 1944 2208 1050 1053 > 1059 1083 +hsync -vsync > Hope this helps. hi Justin, Thanks for your data! Would you like to use the modeline Modeline "1680x1050_50.001" 119 1680 1776 1944 2208 1050 1053 1059 1083 +hsync +vsync by patch in comment 46 I upload, then paste your xorg.log file with Modebug option ? Created attachment 21143 [details] [review] use the patch to check modeline in commnet 45 , thanks (> hi Justin, > Thanks for your data! > Would you like to use the modeline > Modeline "1680x1050_50.001" 119 1680 1776 1944 2208 1050 1053 > 1059 1083 +hsync +vsync by patch in comment 46 I upload, > then paste your xorg.log file with Modebug option ? hi Justin sorry, please paste your xorg.log file with Modedebug option in xorg.conf after you test the Modeline "1680x1050_50.001" 119 1680 1776 1944 2208 1050 1053 1059 1083 +hsync +vsync with patch in comment 46 Thanks Ma Ling Created attachment 21161 [details] Logfile with modedebug=true and patch from comment #64 on an intel xorg driver 2.4.2 Hi Ma Ling, (In reply to comment #47) I build a new driver (based on 2.4.2 + your patch). And tried setting the modeline using 'xrandr', but my monitors couldn't display it. The 1680x1050R still worked correctly, though. Regards, justin.... (In reply to comment #38) Ma Ling: I know how to apply patches thanks. What I am telling you is that the patches to not apply to 2.4.1, so I cannot test them without you telling me which version to test them against. (In reply to comment #42) Ma Ling: Of course the TV supports HDMI completely. I use a Sony PS3 with it and the display is perfect. I have also said at least twice that using Windows on this PC displays perfectly via HDMI (and I have installed no Sony drivers for the TV in Windows, just the Intel display drivers). It's only the Linux driver which causes the display to re-sync. (In reply to comment #22) > I tried a cvt mode, but it my TV was unable to display it: > -(cmsj@tenshu)-(~)- cvt -v -r 1920 1080 60 > # 1920x1080 59.93 Hz (CVT 2.07M9-R) hsync: 66.59 kHz; pclk: 138.50 MHz > Modeline "1920x1080R" 138.50 1920 1968 2000 2080 1080 1083 1088 1111 +hsync > -vsync > -(cmsj@tenshu)-(~)- xrandr --newmode "1920x1080cvt" 138.50 1920 1968 2000 2080 > 1080 1083 1088 1111 +hsync -vsync > -(cmsj@tenshu)-(~)- xrandr --addmode HDMI-1 "1920x1080cvt" > -(cmsj@tenshu)-(~)- xrandr --output HDMI-1 --mode 1920x1080cvt > -(cmsj@tenshu)-(~)- xrandr > Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 1920 x 1920 > VGA disconnected (normal left inverted right x axis y axis) > HDMI-1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) > 1600mm x 900mm > 1920x1080 60.0 + > 1680x1050 60.0 > 1600x1024 60.2 > 1400x1050 60.0 > 1280x1024 60.0 > 1440x900 59.9 > 1280x960 60.0 > 1360x768 60.0 59.8 > 1152x864 60.0 > 1024x768 60.0 > 800x600 60.3 56.2 > 640x480 60.0 59.9 > 1920x1080cvt 59.9* > HDMI-2 disconnected (normal left inverted right x axis y axis) > possibly because it's not actually 60Hz? hi Chris Sorry I don't recognize your setting has been valid, " 1920x1080cvt 59.9* " means it has been used. your problem still occur, right ? Maybe we have do more test on it. thanks Ma Ling Created attachment 21434 [details] [review] hi Justin, I did a patch could you test on your machine ? Happy Christmas ! Thanks Ma Ling re comment #50: MaLing: yeah that mode didn't fix anything. Also, I still can't apply your patches - they do not apply to 2.4.1 or 2.5.1 - I have asked you which version of the intel driver I should be testing, but you haven't replied with that information yet. Ma Ling: I applied the changes from your three patches by hand to 2.5.1 and the problem still occurs with all three (using the default 1920x1080 mode). (In reply to comment #53) > Ma Ling: I applied the changes from your three patches by hand to 2.5.1 and the > problem still occurs with all three (using the default 1920x1080 mode). Hi Chris, Happy new year :). sorry, I forget it. Based on Justing's test, I think the patch can't resolve the problem completely. Could you test the patch in comment 51 , it should apply to 2.5.1. thanks Ma Ling Ma Ling: I just tried that patch and it doesn't seem to make any difference unfortunately. hi Chris, Could you paste Xorg log file of driver 2.5.1 with Modedebug option ? Thanks Ma Ling Ma Ling: Sure, I'll try and get that for you tonight. Also, as another useful datapoint, I was able to reproduce exactly the same issue with an Asus P5Q-VM motherboard. I also replaced the PSU in the computer with a 500W one, to make sure it wasn't that. Created attachment 22147 [details] Xorg log for 2.5.1 with patch in comment #51 Hello Ma Ling, Happy new year ;-) After the Christmas holidays it was a bit busy here so I didn't have some spare time to test your patch. Yesterday I compiled it and it's running now. Attached is the Xorg.log with ModeDebug. I currently have a solid left screen and the right was blanking again. (Yesterday afternoon it blanked very infrequent, but today after unlocking the system it was blanking furiously). I don't know if the left screen is really stable (since it's the same mode as the right screen) or that is is accidentally stable. If time permits I'll reboot my system now and again to see if it remains stable. Regards, justin.... hi Chris, I did experiment on our SHARP Aquos TV, and found the similar symptom as your descrition, Could you tell me whether they are the same with yours. 1) I can use 1024x768 or other lower resolutions normally, they can work fine. 2) when I using 1920x1080, the output of TV become black randomly, but they can recover again, repeat black -> recover -> black ->recover ... aperiodically. 3) under 1920x1080 case, besides symptom of case 2 the output picture exceed range of TV screen, which means I can't see the whole desktop, such as toolbar on the top of desktop except for center part of desktop. you can see the entire desktop picture? Thanks Ma Ling hi Chris, Could you answer my question on comment #59, because this issue is very strange, it is better for me to produce on our Aquos TV. Meanwhile please upload the Xorg log file with Modedebug option. Thanks Ma Ling I'm not Chris but I'll butt in anyway...I'm seeing the same problems using a Intel DG45FC motherboard (with onboard G45 chipset), both on a Sharp Aquos LC46XD1E (which I don't have access to any more) and a Samsung LE55A959D1 LCD TV (connected via a 2m HDMI cable). (In reply to comment #59) > 1) I can use 1024x768 or other lower resolutions normally, they can work fine. Haven't tried this yet > 2) when I using 1920x1080, the output of TV become black randomly, but they > can recover again, repeat black -> recover -> black ->recover ... > aperiodically. That describes my problems exactly...it happens quite infrequently though. > 3) under 1920x1080 case, besides symptom of case 2 the output picture exceed > range of TV screen, which means I can't see the whole desktop, such as toolbar > on the top of desktop except for center part of desktop. you can see the > entire desktop picture? I think that depends on the TV settings. On my Sharp Aquos the default was to overscan (even with a 1080p@60Hz signal). Try using the "Wide modes" button (on my remote it is the button with two vertical lines and arrows pointing left and right, located under a hatch at the bottom of the remote between the "OPC" and "Sleep" buttons) while watching a 1920x1080 HDMI signal and select the "Underscan" mode for pixel-perfect mapping (not very good name for that mode). Regards, David Hi Ma Ling,
I'm having the same issue. Asus P5Q-EM motherboard (G45 chipset), connected with a HDMI cable to a Sony 40W4500 TV.
The blanking occurs very infrequently, most of the times it only happens once an hour or even less. What i did notice is that it does happen quite often just after starting X (within 30 sec. or so).
> 3) under 1920x1080 case, besides symptom of case 2 the output picture exceed
> range of TV screen, which means I can't see the whole desktop, such as toolbar
> on the top of desktop except for center part of desktop. you can see the entire
> desktop picture?
I'm also missing the top part of my desktop if i run at 1920x1080@50HZ.
When running at 1920x1080@60HZ (preferred mode) or 1920x1080@24HZ the whole desktop is shown like it should be.
If i connect a monitor (Acer X222W) using a DVI cable, i also experience the blanking (1680x1050@60Hz). But in this case i was able to work around this by creating a custom modeline with reduced blanking.
Cheers,
ronie
Created attachment 23603 [details]
please try this patch on your machine, thanks
hi Chris, justin, David and ronie
sorry for slow reponse because we have been tring to find the root cause about it. this patch intends to find best precise clock for this issue, I have tried it on our Sharp Aquos, and resolve it, please try on your machine for G4x chipset.
(The patch is based on our latest version, please update your driver from master tree before compiling)
Thanks
Ma Ling
ping ~ Thanks Ma Ling Hi Ma Ling, I had the same problem with an Intel DG45FC mainboard and a Sony KDL-32W4000 television when using a resolution of 1920x1080 via HDMI. Your patch fixes the problem for me and the picture is now rockstable. Thanks & Regards, Michael Hello Ma Ling,
Last week my son was born, so I won't have much time to test this at work the next couple of weeks. So it may take a while for me to verify this fix. But I'll do my best to find some time soon..
Regards,
justin....
(In reply to comment #66) > Hello Ma Ling, > Last week my son was born, so I won't have much time to test this at work the > next couple of weeks. So it may take a while for me to verify this fix. But > I'll do my best to find some time soon.. > Regards, > justin.... hi Justin, Congradulation on your son's birth! Thanks Ma Ling close the issue, please update your driver. Thanks Ma Ling commit 7c94227dd4fa2164bebb36234958053bf1d26c12 Author: Ma Ling <ling.ma@intel.com> Date: Tue Mar 17 10:33:15 2009 +0800 Use best PLL timing values for G4X platform construct function to find precise parameters from internal spreadsheet table on G4X platform. Signed-off-by: Ma Ling <ling.ma@intel.com> Hello, I use Intel drivers v. 2.6.3 and they still have this issue. Is it expected and there is another new version or is something unexpected wrong? (In reply to comment #69) > Hello, > I use Intel drivers v. 2.6.3 and they still have this issue. > Is it expected and there is another new version or is something unexpected > wrong? v 2.6.3 is old and not merged with the patch, please update your driver from master tree. Thanks Ma Ling Back again, this blinking behavior returns for me when using KMS on the 2.6.29.4 kernel with 2.7.1 intel drivers. The KMS with the 2.6.29.3 kernel was buggy in other ways, but there was no blinking... Again, using UXA without KMS on the same hardware with the same drivers and kernel is all right. matej, yours probably a different issue. would you please open a new bug with your specific configurations, rather than open this one? thanks. please refer to http://intellinuxgraphics.org/how_to_report_bug.html |
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.