Bug 10584

Summary: [945GM Mac] incorrect DPI detected
Product: xorg Reporter: Bernhard Mähr <BillyX>
Component: Driver/intelAssignee: 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 Flags
Log
none
xorg.conf
none
New log
none
fix tmds-1 output size
none
Log after installing Patch 13892
none
Log with Option "Monitor-TMDS-1" "Xoro" none

Description Bernhard Mähr 2007-04-09 13:08:14 UTC
I have one EDID-capable screen on a MacMini (i945gm) and get this situation in xf86InitialConfiguration:
(II) intel(0): Target Mode: 1920x1080 (real size 708x398, enabled 0, hasPrefered 0)
(II) intel(0): Target Mode: 1920x1080 (real size 0x0, enabled 1, hasPrefered 1)

Logging in the first loop calling "target_mode = xf86DefaultMode(...)"
Parameters:
width, height, output->mm_width, output->mm_height, enabled[o], xf86OutputHasPreferredMode (output, width, height)
Comment 1 Eric Anholt 2007-04-09 13:47:11 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.
Comment 2 Bernhard Mähr 2007-04-09 13:49:18 UTC
Created attachment 9533 [details]
Log
Comment 3 Bernhard Mähr 2007-04-09 13:49:42 UTC
Created attachment 9534 [details]
xorg.conf
Comment 4 Bernhard Mähr 2007-04-09 13:56:51 UTC
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.
Comment 5 Eric Anholt 2007-04-10 12:33:10 UTC
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).
Comment 6 Bernhard Mähr 2007-04-11 01:11:22 UTC
(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.


Comment 7 Gordon Jin 2007-08-28 02:38:59 UTC
Hi, Bernhard, does this issue still exist with the current git tip? Thanks.
Comment 8 Bernhard Mähr 2007-08-28 16:28:00 UTC
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.
Comment 9 Gordon Jin 2007-08-28 18:33:04 UTC
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.
Comment 10 Bernhard Mähr 2007-08-29 13:58:01 UTC
I don't really think the problem is solved, I just changed the sourcecode that way it works for me.
Comment 11 Gordon Jin 2007-08-30 18:42:40 UTC
then reopening it.
Comment 12 Jesse Barnes 2007-10-31 16:10:50 UTC
I think I've got the summary right...
Comment 13 Bernhard Mähr 2007-11-03 15:21:53 UTC
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.
Comment 14 Bernhard Mähr 2007-11-03 15:24:45 UTC
Created attachment 12335 [details]
New log
Comment 15 Michael Fu 2007-11-05 16:47:26 UTC
(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...
Comment 16 Hong Liu 2008-01-23 19:23:55 UTC
Created attachment 13892 [details] [review]
fix tmds-1 output size
Comment 17 Hong Liu 2008-01-23 19:25:34 UTC
Hi, Bernhard

Would you please try the attached patch? It should fix the TMDS-1 output size problem.

Thanks,
Hong
Comment 18 Bernhard Mähr 2008-01-24 14:14:29 UTC
Created attachment 13914 [details]
Log after installing Patch 13892

After the Patch: Blank Screen.
Comment 19 Hong Liu 2008-01-24 17:06:26 UTC
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)

Comment 20 Bernhard Mähr 2008-01-27 14:14:48 UTC
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.



Comment 21 Hong Liu 2008-01-29 22:24:36 UTC
(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
Comment 22 Bernhard Mähr 2008-01-30 13:38:25 UTC
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
Comment 23 Hong Liu 2008-01-30 17:44:56 UTC
(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

Comment 24 Bernhard Mähr 2008-01-31 13:28:40 UTC
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? ;-)
Comment 25 Hong Liu 2008-01-31 17:39:28 UTC
(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
Comment 26 Hong Liu 2008-02-04 17:55:09 UTC
Patch is committed (commit 11de831cb706025c003e98fef6d666d273192bcd).
Comment 27 Bernhard Mähr 2008-02-04 20:49:21 UTC
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.