I have a Asus P5E-VM-HDMI mainboard with Intel G35 chipset. I've a Toshiba 37Z3030 (fullhd) TV connected to it using the HDMI-output. Although it more or less works, the image displayed on the TV is shifted about 35 pixels to the left and 15 pixels to the top (i.e. the upper left corner of the image is behind the upper left corner of the bezel of the screen) and on the right and bottom side I have blank pixels. This happens with Ubuntu Linux 710 Gutsy (Xorg-core 1.3 and intel driver 2.1.1), the current Hardy version (Intel 2.2.0+git20080107 and Xorg 1.4.1~git20080118) and today's git-checkout of the Intel driver with Hardy's Xorg. And using 32bits or 64bits didn't matter, although currently I'm using 32bits. I have currently no modelines or resolution configurations in my xorg.conf, nor did specifying any help. I couldn't really find earlier mail in the archive about this issue, except for some remarks that it was supposedly fixed in 2.2.0/1.4.0. As a sidenote I can't seem to get the screen working with 1920x1080 at 60Hz, X only detects 1920x1080 at 0Hz (and 720x576 and 640x480) and refuses to operate with any other modeline. The detected frequencies seem to indicate it operates at 50Hz. In windows I was able to select 24, 25, 30, 50 and 60 Hz for 1920x1080 and the image is correctly positioned on the display. This is the output of xrandr --verbose: Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 1920 x 1920 TMDS-1 connected 1920x1080+0+0 (0x5c) normal (normal left inverted right x axis y axis) 708mm x 398mm Identifier: 0x5b Timestamp: 2042559 Subpixel: horizontal rgb Clones: CRTC: 0 CRTCs: 0 1 EDID_DATA: 00ffffffffffff005262050100000000 0011010380693b780a0dc9a057479827 12484c20000001010101010101010101 010101010101023a80d072382d40102c 4580c48e2100001e8c0ad09020403120 0c405500c48e21000018000000fc0054 4f53484942412d54560a2020000000fd 00173d0f440f000a202020202020013b 1920x1080 (0x5c) 148.5MHz +HSync +VSync h: width 1920 start 2448 end 2492 total 2640 skew 0 clock 56.2KHz v: height 1080 start 1084 end 1089 total 1125 clock 50.0Hz 720x576 (0x5d) 27.0MHz -HSync -VSync h: width 720 start 732 end 796 total 864 skew 0 clock 31.2KHz v: height 576 start 581 end 586 total 625 clock 50.0Hz 640x480 (0x5e) 25.2MHz -HSync -VSync h: width 640 start 656 end 752 total 800 skew 0 clock 31.5KHz v: height 480 start 490 end 492 total 525 clock 60.0Hz
Is xrandr pulling the 2nd EDID block? I only see one in your --verbose output. The next to last byte in the EDID block is "01", indicating that the display has another EDID block with more supported modes and detailed timings defined. See the "CEA EDID Timing Extension Version 3 data format" section of for details. This may not directly affect the shift to the left and up (the timings specified in the first EDID block are Consumer Electronics Association standards for 1080p 50Hz and should work properly), but probably indicates why Windows can detect extra resolutions and X does not.
(In reply to comment #1) > See the "CEA EDID Timing Extension Version 3 data format" section of for > details. Sorry, apparently URLs are unwelcome. My line above should have said "the Wikipedia entry for EDID".
That output is all I get, and I don't see any option to indicate to xrandr that it should try to do so.
I have indeed the same bug on a different display (Sharp 42xd1e) Image shifted to the left by about 30 pixels. Using hardy (xserver-xorg 1:7.3+10ubuntu, kernel 2.6.24.7-generic) xrandr --verbose Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 1920 x 1920 VGA disconnected (normal left inverted right x axis y axis) Identifier: 0x4b Timestamp: 18750 Subpixel: unknown Clones: CRTCs: 0 1 TMDS-1 connected 1920x1080+0+0 (0x4d) normal (normal left inverted right x axis y axis) 1152mm x 648mm Identifier: 0x4c Timestamp: 18750 Subpixel: horizontal rgb Clones: CRTC: 0 CRTCs: 0 1 EDID_DATA: 00ffffffffffff004d10e80f01010101 00100103807341782a1bbea25534b326 144a5200000001010101010101010101 010101010101023a80d072382d40102c 458080884200001e023a801871382d40 582c450080884200001e000000fc0053 484152502048444d490a2020000000fd 00313d0f4b11000a2020202020200159 1920x1080 (0x4d) 148.5MHz +HSync +VSync h: width 1920 start 2448 end 2492 total 2640 skew 0 clock 56.2KHz v: height 1080 start 1084 end 1089 total 1125 clock 50.0Hz 1920x1080 (0x4e) 148.5MHz +HSync +VSync h: width 1920 start 2008 end 2052 total 2200 skew 0 clock 67.5KHz v: height 1080 start 1084 end 1089 total 1125 clock 60.0Hz
Could you attach xorg.conf in use and xorg log?
Created attachment 15475 [details] Current xorg config file Here is the requested xorg.conf, its mostly auto-detect.
Created attachment 15476 [details] Last X.org log file Here is the most recent log file for X
Created attachment 16921 [details] [review] enable sdvo hdmi output Please try the attached patch to see if SDVO-HDMI is working.
I've compiled a git-checkout of the Intel driver with your patch applied. With that, the image seems to be on the right place of the TV, no black borders exist below or besides the image anymore. It still doesn't detect all those other modes my TV supports (like 1280x720 and several other variants of 1920x1080), but that may be a different issue.
(In reply to comment #9) > I've compiled a git-checkout of the Intel driver with your patch applied. > > With that, the image seems to be on the right place of the TV, no black borders > exist below or besides the image anymore. > > It still doesn't detect all those other modes my TV supports (like 1280x720 and > several other variants of 1920x1080), but that may be a different issue. > Thanks for trying the patch, I will look at the modeline problem later.
zhenyu, would you please take over the patch in comment# 8? If it's accepted into master, we can mark this bug as fixed. modeline issue will be tracked in another bug. thanks.
Hong's patch has already merged upstream and be in 2.4.0, so close this one.
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.