Summary: | [G35 HDMI PATCH] HDTV display is shifted to the left | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | xorg | Reporter: | Arjen <acmmailing> | ||||||||
Component: | Driver/intel | Assignee: | Wang Zhenyu <zhenyu.z.wang> | ||||||||
Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> | ||||||||
Severity: | normal | ||||||||||
Priority: | medium | CC: | michael.fu | ||||||||
Version: | unspecified | ||||||||||
Hardware: | x86 (IA32) | ||||||||||
OS: | Linux (All) | ||||||||||
URL: | http://en.wikipedia.org/wiki/EDID | ||||||||||
Whiteboard: | |||||||||||
i915 platform: | i915 features: | ||||||||||
Attachments: |
|
Description
Arjen
2008-01-31 05:26:46 UTC
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.