Bug 13877 - DPI and screen size incorrectly computed, resulting in huge fonts
Summary: DPI and screen size incorrectly computed, resulting in huge fonts
Status: RESOLVED INVALID
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/General (show other bugs)
Version: 7.3 (2007.09)
Hardware: x86 (IA32) FreeBSD
: medium normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-12-31 13:11 UTC by Chris BeHanna
Modified: 2018-06-12 18:43 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
logfile that shows workaround described in bug (38.00 KB, text/x-log)
2007-12-31 13:11 UTC, Chris BeHanna
no flags Details
My .xserverrc, showing -dpi 62 as the workaround for this bug (60 bytes, text/plain)
2007-12-31 13:12 UTC, Chris BeHanna
no flags Details

Description Chris BeHanna 2007-12-31 13:11:14 UTC
This bug possibly explains bug 12219 and other similar bugs.

I have a 21" Samsung Syncmaster 213T, which I typically use in 1600x1200 mode.  This gives a dpi of about 96.

I have an old Radeon card in my FreeBSD 6.2 box.  When I start X, the modes from the monitor and the card are probed, and result in this list:

1600x1200
1280x1024
1024x768
800x600
640x480

My xorg.conf specified my screen dimensions in mm, as

     DisplaySize      423   317 # mm

Everything would be fine, EXCEPT that X starts in 1024x768 and then (via XRandR?) switches to 1600x1200 once I'm into KDE:

(II) RADEON(0): Output VGA-0 using initial mode 1024x768
after xf86InitialConfiguration

Here's where it gets fun.  Using 1024x768 and the 96 dpi setting that I had tried forcing (both in KDE and via the -dpi 96 flag in my .xserverrc), X COMPLETELY IGNORES the display size that I specified in my xorg.conf, and computes that my display is actually 270mm x 203mm (as reported in xdpyinfo), then it switches to 1600x1200 and uses the above-incorrect size to compute a new dpi of 150,151 (again, as reported in xdpyinfo).  BAM--huge fonts.

Commenting out the display size in xorg.conf and deleting the -dpi 96 setting in my .xserverrc (to attempt to allow everything to be computed dynamically, "naturally" if you will) had the same result.

What I hit upon to work around this is to trick X into computing the correct monitor size when it starts in 1024x768 mode, and then use that size to compute the dpi needed when it switches to 1600x1200 mode.

My monitor is actually 420mm x 317mm, so it turns out that if I specify the dpi that it would have if I were running in 1024x768 mode, then everything will scale correctly:

1024/(420/25.4) ~= 62
768/(317/25.4) ~= 62

So, I put "-dpi 62" into my .xserverrc.  Now, when X starts in 1024x768 mode, it sees a dpi of 62 and uses that to correctly calculate the size of my monitor.  When it switches to 1600x1200, it then correctly recalculates the dpi setting, and my fonts look normal.

This was, needless to say, not very intuitive, nor was it documented anywhere.  I think the crux of the problem is that X starts in an unexpected display mode AND it ignores the DisplaySize directive in xorg.conf, then it incorrectly uses the initial display mode and the .xserverrc dpi settings to get the wrong answer for the display size, which results in the incorrect re-computed dpi setting when a new display mode is selected:

SUMMARY:

wrong mode (1024x768) + intended dpi setting in 1600x1200 => X computes the wrong display size (270mm x 203mm instead of the actual 420mm x 317mm), completely ignoring the size that was specified in xorg.conf.

switch to new display mode (1600x1200), X uses the incorrect display size from the previous step to compute an incorrect dpi setting

X uses the new, incorrect dpi setting to scale the fonts => HUGE fonts
Comment 1 Chris BeHanna 2007-12-31 13:11:59 UTC
Created attachment 13437 [details]
logfile that shows workaround described in bug
Comment 2 Chris BeHanna 2007-12-31 13:12:29 UTC
Created attachment 13438 [details]
My .xserverrc, showing -dpi 62 as the workaround for this bug
Comment 3 Adam Jackson 2018-06-12 18:43:01 UTC
Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please file a new report if you continue to experience issues with a current server.


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.