Summary: | [945GM Mac] incorrect DPI detected | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | xorg | Reporter: | Bernhard Mähr <BillyX> | ||||||||||||||
Component: | Driver/intel | Assignee: | Hong Liu <hong.liu> | ||||||||||||||
Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> | ||||||||||||||
Severity: | normal | ||||||||||||||||
Priority: | medium | CC: | alexm | ||||||||||||||
Version: | git | ||||||||||||||||
Hardware: | Other | ||||||||||||||||
OS: | All | ||||||||||||||||
Whiteboard: | |||||||||||||||||
i915 platform: | i915 features: | ||||||||||||||||
Bug Depends on: | |||||||||||||||||
Bug Blocks: | 10582, 13027, 13493 | ||||||||||||||||
Attachments: |
|
Description
Bernhard Mähr
2007-04-09 13:08:14 UTC
I'm sorry, this bug report doesn't make any sense. You'll have to describe the actual problem you're seeing with an unmodified driver, what versions of the driver and server you're using, and attach the Xorg.0.log and xorg.conf. Created attachment 9533 [details]
Log
Created attachment 9534 [details]
xorg.conf
The problem is: The method xf86DefaultMode is entered in the second iteration of of the loop (because enabled is 0 in the first). xf86DefaultMode uses the height 0 instead of 398 and then uses the hardcoded default. With this value the dpi for the screen is calculated wrong and a wrong resolution is choosen. I used xserver and the intel driver latest from git. I assume that the mixing of the values happens in the intel driver but it can also happen in the xserver part. OK, I think I've got this figured out despite the lack of requested information (again, that included driver version, server version, and user-visible problem). So, you're getting a non-native mode chosen on your TMDS output, and additionally the DPI is being reported as unknown (0x0) instead of what it should be. You appear to be running an old prerelease X Server, which is missing DDC fixes. That (hopefully) is what is causing EDID to not be probed on your TMDS output, and thus the driver guessing at a mode that might work, and accurately reporting that it doesn't know the DPI. In that case, you need to either update to a current server to get the fixes, or hard-code the monitor configuration as documented in xorg.conf(5) of a recent X Server (see the stuff with notes about RandR 1.2). (In reply to comment #5) > OK, I think I've got this figured out despite the lack of requested information > (again, that included driver version, server version, and user-visible > problem). Again, I told that I used the latest version (HEAD) from git (ok, now it is perhaps not the latest version but it was the latest version on the 07.04.2007). > So, you're getting a non-native mode chosen on your TMDS output Yes > and > additionally the DPI is being reported as unknown (0x0) instead of what it > should be. No. I have an enabled output with wrong values for mm_height and mm_width (0) and a disabled output with the correct values. > You appear to be running an old prerelease X Server, which is missing DDC > fixes. It is a prerelease, but not old. Its the version I get on 08 April 2007 from git. > That (hopefully) is what is causing EDID to not be probed on your TMDS > output As you see in the log the EDID is probed. ANd the values are also correct, but they are stored at the disabled output. > and thus the driver guessing at a mode that might work, and accurately > reporting that it doesn't know the DPI. In that case, you need to either > update to a current server to get the fixes Is the newest > or hard-code the monitor > configuration as documented in xorg.conf(5) of a recent X Server (see the stuff > with notes about RandR 1.2). This doesn't work as I reported in an other bug-report. Hi, Bernhard, does this issue still exist with the current git tip? Thanks. Sorry, what is a "git tip"? I have stopped updating the source from git because it seemed to me no one was really interested to try to fix the bugs and it was every time a lot of work for me to merge my hardcoded workarounds into the source and get it to compile succesfully. So I'm using the code from git at 16th of June with my hardcoded "defaults" which works without problems for me. If you want to try to find the bug and fix it, I can try to test it. If you just want to close the bug, close it, it is not important for me anymore. by "git tip" I mean the latest code on git. It's good to know the problem has already gone away. I'm closing it. I don't really think the problem is solved, I just changed the sourcecode that way it works for me. then reopening it. I think I've got the summary right... After several days of work I finally got git head to compile. I just tested it and the problem is not solved. One more correction: Mac Mini has only on video connector -> no dual head setup. Created attachment 12335 [details]
New log
(In reply to comment #13) > After several days of work I finally got git head to compile. > > I just tested it and the problem is not solved. > > One more correction: Mac Mini has only on video connector -> no dual head > setup. > remove "in dual head setup" from the bug summary line... Created attachment 13892 [details] [review] fix tmds-1 output size Hi, Bernhard Would you please try the attached patch? It should fix the TMDS-1 output size problem. Thanks, Hong Created attachment 13914 [details]
Log after installing Patch 13892
After the Patch: Blank Screen.
Several questions: 1. Could you please attach your hardcoded workaround? 2. Which mode is the working mode? I see the preferred mode in EDID data is Modeline "1280x720"x60.0 74.25 1280 1390 1430 1650 720 725 730 750 +hsync +vsync (45.0 kHz) But due to the configured virtual space 1920x1080 and the probe physical size 708x398, we chose 1280x1024 and configured the TMDS-1 port which is not supported. (II) intel(0): SDVO: W: 16 10 0B D0 B4 20 90 31 10 (SDVO_CMD_SET_OUTPUT_TIMINGS_PART1) (II) intel(0): SDVO: R: (Not supported) I have changed default height (mm_height) of the screen in xf86DefaultMode from 203 to 285 and ignored the preferred flag. I also added 1920x1080 to extramodes. 1920x1080 is the correct resolution but at least sometimes i got 1280x1024 working. (In reply to comment #20) > I have changed default height (mm_height) of the screen in xf86DefaultMode from > 203 to 285 and ignored the preferred flag. > I also added 1920x1080 to extramodes. > > 1920x1080 is the correct resolution but at least sometimes i got 1280x1024 > working. > I am still not very clear about what is the problem now? After my patch, we apply the probed EDID data to the TMDS-1 output, so now the TMDS-1 output has the correct physcial size set (708mm x 398mm). If 1920x1080 is the preferred mode, then the EDID data we probed is totally broken. It set 1280x720 as the preferred mode. And the max pixclock is only 110MHz which filters out 1920x1080 modes you entered. To make 1920x1080 mode work, you need to add Section "Device" ... Option "Monitor-TMDS-1" "Xoro" ... EndSection Section "Monitor" ... Option "maxclock" "140MHz" Option "PreferredMode" "1920x1080" ... EndSection Thanks, Hong Of course my screen reports wrong settings but it should be possible to configure the correct which is not possible. Your patch fixed the mixing of values: (II) intel(0): Output VGA disconnected (II) intel(0): Output TMDS-1 connected (II) intel(0): Output TV disconnected (II) intel(0): Target Mode: 1920x1080 (real size 0x0, enabled 0, hasPrefered 0) (II) intel(0): Target Mode: 1920x1080 (real size 708x398, enabled 1, hasPrefered 1) (II) intel(0): Target Mode: 1920x1080 (real size 0x0, enabled 0, hasPrefered 0) The Option "PreferredMode" "1920x1080" was already there, the Option "MaxClock" "150MHz" doesn't change anything. (II) intel(0): Output VGA using monitor section Xoro (**) intel(0): Option "PreferredMode" "1920x1080" (**) intel(0): Option "MaxClock" "150MHz" After your patch I have much less modes: With patch: (II) intel(0): Not using default mode "1920x1080"(60.0 Hz 67.5 kHz 148500 Clock, bad mode clock/interlace/doublescan) Without patch: (II) intel(0): Modeline "1920x1080"x60.0 148.50 1920 1960 2016 2200 1080 1082 1088 1125 -hsync +vsync (67.5 kHz) Also the PreferredMode is still ignored: (II) intel(0): Mode 1280x720: preferred 1 dpi 45 (In reply to comment #22) > Of course my screen reports wrong settings but it should be possible to > configure the correct which is not possible. > I was trying to add options to Xorg.conf to make the driver select the correct mode. > The Option "PreferredMode" "1920x1080" was already there, the Option "MaxClock" > "150MHz" doesn't change anything. > > (II) intel(0): Output VGA using monitor section Xoro > (**) intel(0): Option "PreferredMode" "1920x1080" > (**) intel(0): Option "MaxClock" "150MHz" Increasing the maxclock is supposed to remain the 1920x1080 mode, which will be filtered out because the edid data has only 110MHz clock. It seems your Xoro monitor section is associtated with the VGA output. Would you please remove *Monitor "Xoro"* in your Screen section and add Option "Monitor-TMDS-1" "Xoro" to you Device section to associate Xoro monitor with your TMDS-1 output? You can verify it to see if "Output TMDS-1 using monitor section Xoro" in your xorg log. > After your patch I have much less modes: > With patch: > (II) intel(0): Not using default mode "1920x1080"(60.0 Hz 67.5 kHz 148500 > Clock, bad mode clock/interlace/doublescan) Yes, it is expected as I explained before, "bad mode clock" means clock too high. > Also the PreferredMode is still ignored: > (II) intel(0): Mode 1280x720: preferred 1 dpi 45 > I've checked X server source. It seems we will select the mode with preferred bit set as the highest priority. So which X server version are you using? And have you removed your hack (i.e removing the preferred bit) on X server when trying my patch? Thanks, Hong Created attachment 14060 [details]
Log with Option "Monitor-TMDS-1" "Xoro"
Ok, this was a step forward, my monitor displays 1920x1080 without my patch.
Is your patch to be included in the next release?
I had Option "Monitor-LVDS" "Xoro" and replaced it with Option "Monitor-TMDS-1" "Xoro" in the section Device.
But there are still some interesting things:
(WW) intel(0): Option "PreferredMode" is not used
(WW) intel(0): Option "MaxClock" is not used
Why this?
(II) intel(0): Output VGA disconnected
(II) intel(0): Output TMDS-1 connected
(II) intel(0): Output TV disconnected
(II) intel(0): Target Mode: 1920x1080 (real size 0x0, enabled 0, hasPrefered 0)
(II) intel(0): Target Mode: 1920x1080 (real size 708x398, enabled 1, hasPrefered 1)
(II) intel(0): Mode 1920x1080: preferred 2 dpi 68
(II) intel(0): Mode 1280x720: preferred 1 dpi 45
(II) intel(0): Mode 1600x1024: preferred 0 dpi 65
(II) intel(0): Mode 1400x1050: preferred 0 dpi 67
(II) intel(0): Mode 1280x1024: preferred 0 dpi 65
Prefered 2 times? ;-)
(In reply to comment #24) > Is your patch to be included in the next release? > Yes, I think so :) > I had Option "Monitor-LVDS" "Xoro" and replaced it with Option "Monitor-TMDS-1" > "Xoro" in the section Device. > > But there are still some interesting things: > > (WW) intel(0): Option "PreferredMode" is not used > (WW) intel(0): Option "MaxClock" is not used > Why this? > Not sure why you want to associate Xoro with LVDS (which is not existed on your machine)? And one monitor configure can only be associated to one output. > (II) intel(0): Output VGA disconnected > (II) intel(0): Output TMDS-1 connected > (II) intel(0): Output TV disconnected > (II) intel(0): Target Mode: 1920x1080 (real size 0x0, enabled 0, hasPrefered 0) > (II) intel(0): Target Mode: 1920x1080 (real size 708x398, enabled 1, > hasPrefered 1) > (II) intel(0): Mode 1920x1080: preferred 2 dpi 68 > (II) intel(0): Mode 1280x720: preferred 1 dpi 45 > (II) intel(0): Mode 1600x1024: preferred 0 dpi 65 > (II) intel(0): Mode 1400x1050: preferred 0 dpi 67 > (II) intel(0): Mode 1280x1024: preferred 0 dpi 65 > Prefered 2 times? ;-) > User preferred mode gets 2 points (mode preferred in xorg.conf) which is higher than the EDID preferred mode, this ensures the user preferred mode will always be selected. Thanks, Hong Patch is committed (commit 11de831cb706025c003e98fef6d666d273192bcd). Thank you for taking the time to resolve it! |
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.