Bug 17805 - G45 display sync frequently lost via HDMI/DVI
Summary: G45 display sync frequently lost via HDMI/DVI
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: MaLing
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-09-27 08:42 UTC by Chris Jones
Modified: 2009-05-27 06:39 UTC (History)
5 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Xorg log (60.75 KB, text/plain)
2008-09-27 18:36 UTC, Chris Jones
no flags Details
Output from xrandr --verbose (4.22 KB, text/plain)
2008-10-31 10:58 UTC, André Dahlqvist
no flags Details
hi, Chris I did 3 simple patchs to try this issue, could you test them, then let us do further work. Thanks Ma Ling (474 bytes, patch)
2008-11-27 21:50 UTC, MaLing
no flags Details | Splinter Review
path2 (515 bytes, patch)
2008-11-27 21:54 UTC, MaLing
no flags Details | Splinter Review
patch 3 (474 bytes, patch)
2008-11-27 21:55 UTC, MaLing
no flags Details | Splinter Review
xrandr info (2.37 KB, text/plain)
2008-12-03 02:13 UTC, freedesktop@internetionals.nl
no flags Details
use the patch to check modeline in commnet 45 , thanks (558 bytes, patch)
2008-12-14 21:58 UTC, MaLing
no flags Details | Splinter Review
Logfile with modedebug=true and patch from comment #64 on an intel xorg driver 2.4.2 (349.90 KB, text/plain)
2008-12-15 01:24 UTC, freedesktop@internetionals.nl
no flags Details
hi Justin, I did a patch could you test on your machine ? Happy Christmas ! Thanks Ma Ling (449 bytes, patch)
2008-12-23 05:03 UTC, MaLing
no flags Details | Splinter Review
Xorg log for 2.5.1 with patch in comment #51 (68.35 KB, text/plain)
2009-01-21 23:53 UTC, freedesktop@internetionals.nl
no flags Details
please try this patch on your machine, thanks (15.79 KB, application/octet-stream)
2009-03-06 22:51 UTC, MaLing
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Jones 2008-09-27 08:42:42 UTC
I have a Gigaby EG45M-DS2H (i.e. a G45 chipset). I'm using the onboard HDMI output connected to a Sony KDL-V3000 40" TV (native res 1080p). I've also tried the onboard DVI port with the same TV (using a DVI<->HDMI cable) and seen the same problem.

Basically when X loads, it correctly detects the right resolution (1920x1080) on the HDMI port, but quite frequently the display disappears. The TV re-syncs and displays the name of the input (AV4 in this case). It doesn't happen at a regular interval, and configuring the TV to expect Video rather than Video-A makes it slightly more stable (I have no idea what that setting means, and it's possible that it just forces the TV to do a full resync to change the setting, and that makes it more stable).

I realise this report rambles a bit, but it's hard to get any good data about the problem - there are no log entries when the resync flicker happens. Most curiously, once it has started, it persists even when the xorg driver is not running (e.g. rebooting into the BIOS will then see the flicker persist in the BIOS, grub menus and subsequent VGA consoles).

That made me suspect it was a hardware fault, however, booting into Windows XP with the appropriate Intel driver there restores a perfectly stable picture. I've run tests in Windows with video playing, GL scenes running and general desktop use and not once has it resynced in Windows. Booting into Linux then makes it start whether I run a 2d or 3d desktop, having not played any video.
Comment 1 Gordon Jin 2008-09-27 18:17:28 UTC
Please provide log with driver version, according to http://www.intellinuxgraphics.org/how_to_report_bug.html.
Comment 2 Chris Jones 2008-09-27 18:36:51 UTC
Created attachment 19263 [details]
Xorg log
Comment 3 Nathan MWF 2008-10-03 12:11:52 UTC
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.
Comment 4 Chris Jones 2008-10-06 12:03:16 UTC
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.
Comment 5 Juan M Vanegas 2008-10-08 22:28:18 UTC
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.
Comment 6 Wang Zhenyu 2008-10-09 19:35:36 UTC
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.
Comment 7 Chris Jones 2008-10-10 01:54:14 UTC
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).
Comment 8 Wang Zhenyu 2008-10-10 07:02:08 UTC
I don't know about any tools available on windows for this, but your info has high value for us.
Comment 9 MaLing 2008-10-13 00:29:05 UTC
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

Comment 10 André Dahlqvist 2008-10-23 14:50:44 UTC
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?
Comment 11 Chris Jones 2008-10-23 15:36:45 UTC
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.
Comment 12 MaLing 2008-10-26 20:55:09 UTC
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
Comment 13 MaLing 2008-10-26 21:15:27 UTC
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
Comment 14 André Dahlqvist 2008-10-28 14:44:41 UTC
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;-)
Comment 15 MaLing 2008-10-28 23:45:56 UTC
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
Comment 16 André Dahlqvist 2008-10-31 10:58:55 UTC
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?
Comment 17 André Dahlqvist 2008-10-31 11:52:26 UTC
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.







Comment 18 MaLing 2008-11-09 07:17:23 UTC
"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


 
Comment 19 André Dahlqvist 2008-11-11 09:39:09 UTC
>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).
Comment 20 MaLing 2008-11-18 18:52:57 UTC
(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
Comment 21 André Dahlqvist 2008-11-19 14:00:39 UTC
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?
Comment 22 Chris Jones 2008-11-20 03:29:11 UTC
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?
Comment 23 André Dahlqvist 2008-11-20 15:09:54 UTC
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.
Comment 24 André Dahlqvist 2008-11-20 15:12:20 UTC
(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.
 

Comment 25 MaLing 2008-11-23 18:38:08 UTC
(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

Comment 26 MaLing 2008-11-23 18:44:27 UTC
(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 
Comment 27 MaLing 2008-11-23 18:46:45 UTC
(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
Comment 28 Chris Jones 2008-11-24 01:50:51 UTC
> 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.
Comment 29 freedesktop@internetionals.nl 2008-11-26 01:52:08 UTC
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.
Comment 30 MaLing 2008-11-27 21:14:36 UTC
(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
Comment 31 MaLing 2008-11-27 21:33:42 UTC
(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
Comment 32 MaLing 2008-11-27 21:50:52 UTC
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
Comment 33 MaLing 2008-11-27 21:54:24 UTC
Created attachment 20650 [details] [review]
path2
Comment 34 MaLing 2008-11-27 21:55:57 UTC
Created attachment 20651 [details] [review]
patch 3
Comment 35 Chris Jones 2008-11-30 15:26:04 UTC
Is it possible to apply those patches to 2.4.1? It doesn't seem to apply cleanly
Comment 36 MaLing 2008-11-30 17:12:07 UTC
(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
Comment 37 Chris Jones 2008-12-01 02:37:00 UTC
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.
Comment 38 MaLing 2008-12-02 21:35:29 UTC
(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
Comment 39 MaLing 2008-12-02 21:52:59 UTC
(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
Comment 40 freedesktop@internetionals.nl 2008-12-03 02:13:37 UTC
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.
Comment 41 freedesktop@internetionals.nl 2008-12-03 02:16:09 UTC
(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.
Comment 42 MaLing 2008-12-09 01:54:02 UTC
(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
Comment 43 MaLing 2008-12-09 02:43:26 UTC
(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

Comment 44 freedesktop@internetionals.nl 2008-12-11 00:48:09 UTC
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.
Comment 45 MaLing 2008-12-14 21:57:07 UTC
(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 ?
Comment 46 MaLing 2008-12-14 21:58:42 UTC
Created attachment 21143 [details] [review]
use the patch to check modeline in commnet 45 , thanks
Comment 47 MaLing 2008-12-14 22:03:08 UTC
(> 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 
Comment 48 freedesktop@internetionals.nl 2008-12-15 01:24:06 UTC
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....
Comment 49 Chris Jones 2008-12-15 03:04:44 UTC
(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.
Comment 50 MaLing 2008-12-16 21:45:31 UTC
(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
Comment 51 MaLing 2008-12-23 05:03:15 UTC
Created attachment 21434 [details] [review]
hi Justin, I did a patch could you test on your machine ?  Happy Christmas ! Thanks Ma Ling
Comment 52 Chris Jones 2008-12-30 00:39:49 UTC
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.
Comment 53 Chris Jones 2008-12-30 01:35:27 UTC
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).
Comment 54 MaLing 2008-12-30 01:43:08 UTC
(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
Comment 55 Chris Jones 2008-12-30 02:33:41 UTC
Ma Ling: I just tried that patch and it doesn't seem to make any difference unfortunately.
Comment 56 MaLing 2009-01-20 05:17:30 UTC
hi Chris,

Could you paste Xorg log file of driver 2.5.1 with Modedebug option ?

Thanks
Ma Ling
Comment 57 Chris Jones 2009-01-20 05:29:11 UTC
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.
Comment 58 freedesktop@internetionals.nl 2009-01-21 23:53:58 UTC
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....
Comment 59 MaLing 2009-01-22 06:42:59 UTC
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



 
Comment 60 MaLing 2009-02-05 23:33:13 UTC
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
Comment 61 David Härdeman 2009-02-12 01:06:12 UTC
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
Comment 62 ronie 2009-02-12 15:31:42 UTC
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
Comment 63 MaLing 2009-03-06 22:51:58 UTC
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
Comment 64 MaLing 2009-03-10 22:39:37 UTC
ping ~

Thanks
Ma Ling
Comment 65 Michael Gernoth 2009-03-11 01:42:18 UTC
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
Comment 66 freedesktop@internetionals.nl 2009-03-16 02:43:53 UTC
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....
Comment 67 MaLing 2009-03-16 03:22:23 UTC
(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
Comment 68 MaLing 2009-03-16 22:09:19 UTC
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>
Comment 69 matej.tyc 2009-04-14 06:30:36 UTC
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?
Comment 70 MaLing 2009-04-14 07:05:08 UTC
(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
Comment 71 matej.tyc 2009-05-27 05:13:37 UTC
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.
Comment 72 Michael Fu 2009-05-27 06:38:59 UTC
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.