Font sizes in Gutsy are affected by bad X.org DPI detection

Bug #118745 reported by Martin Pitt on 2007-06-05
216
Affects Status Importance Assigned to Milestone
X.Org X server
Fix Released
Medium
compiz (Ubuntu)
Undecided
Unassigned
firefox (Ubuntu)
Undecided
Unassigned
libgnome (Ubuntu)
Medium
Ubuntu Desktop Bugs
xorg-server (Ubuntu)
Medium
Bryce Harrington

Bug Description

In Gutsy, Gnome switched to using the X server's screen DPI detection, which means that fonts can easily appear to be too large or too small, depending on your screen setup. The old approach was to use 96 DPI by default, but the new one can result in widely differing DPI values. We need to improve the detection, or give people an easy way to tweak these values so that the result looks good on their system.

Jun 01 14:06:38 <seb128> pitti: in case fonts turn to be too small (which happened to several people after upgrade) you might want to modify libgnome schemas to change Sans
10 to 11
Jun 01 14:07:02 <pitti> seb128: do we have a bug about it?
Jun 01 14:07:06 <seb128> just edit debian/libgnome2-common.gconf-defaults
Jun 01 14:07:29 <seb128> pitti: I think so, let me look
Jun 01 14:08:21 <pitti> seb128: if that affects everyone, we should milestone it
Jun 01 14:08:33 <seb128> well, not easy to know
Jun 01 14:08:49 <pitti> well, but that only affects upgrades anyway, right?
Jun 01 14:08:50 <seb128> gnome-settings-daemon uses the screen DPI now
Jun 01 14:09:12 <pitti> if it affects fresh installs, too, then we should do something about it
Jun 01 14:09:15 <seb128> but I'm not sure if that means we should change the default or if the fonts are only too small when xorg is not correctly configured or something
Jun 01 14:09:28 <pitti> ok, let's look into that during CD testing
Jun 01 14:10:15 <seb128> right, that was my point
Jun 01 14:10:39 <seb128> if that happens on desktop CD and you want to workaround it just modify libgnome debian/libgnome2-common.gconf-defaults to change the default deskto
p font

Related branches

Martin Pitt (pitti) on 2007-06-05
Changed in libgnome:
importance: Undecided → Medium
status: Unconfirmed → Confirmed
Martin Pitt (pitti) on 2007-06-05
Changed in libgnome:
assignee: nobody → pitti
status: Confirmed → In Progress
Martin Pitt (pitti) on 2007-06-05
Changed in libgnome:
assignee: pitti → desktop-bugs
Martin Pitt (pitti) wrote :

BTW, for Tribe-1 I uploaded

libgnome (2.18.0-4ubuntu2) gutsy; urgency=low
 .
   * debian/libgnome2-common.gconf-defaults: Increase font size of Sans from 10
     to 11 for the desktop and document default fonts. gnome-settings-daemon
     now uses the screen DPI for font size calculation, the new default
     mitigates the resulting size changes. (LP: #118745)

which already helped a bit, but e. g. the Terminal font is still too small.

Alexander Jones (alex-weej) wrote :

Er, I don't get this. 10pt is massive enough already.

11pt is just huge. I think anyone who is finding font sizes to be too small must have incorrect DPI settings.

Please consider reverting to 10pt.

Sebastien Bacher (seb128) wrote :

Alex, for lot of users the fonts are tiny with 10, if you read the bug you will notice that's a workaround and not a fix, your comment is not really bringing anything to it

Alexander Jones (alex-weej) wrote :

OK, here's a better workaround for now - change /desktop/gnome/font_rendering/dpi to 96, and leave the font sizes as they were.

Sebastien Bacher (seb128) wrote :

It makes it no respect the dpi, how is that a better workaround?

Alexander Jones (alex-weej) wrote :

Because most people's panels are 96 dpi. You can unset it when the auto-detected DPI is fixed in Xorg.

Sebastien Bacher (seb128) wrote :

where did you get your information that most configuration are using 96 dpi? We received other bugs indicating that's not that evident, have clear datas on the subject would be nice

Alexander Jones (alex-weej) wrote :

Do you have any clear data to suggest that screen DPI is being systematically undercalculated at 91% (10/11) of its real value?

Anyway, as long as leaving the default font size as 11pt is not intended for the final release, then it's really not worth locking horns over this. Let's just agree to disagree. :)

Hi,

Alex Jones [2007-06-17 16:01 -0000]:
> Because most people's panels are 96 dpi. You can unset it when the auto-
> detected DPI is fixed in Xorg.

Please don't ever rely on that value. For many monitors it is simply
not possible to detect the DPI and other settings.

How has the DPI setting been handled before? Was it just fixed to 96
DPI? (or whichever value).

Alex, that's ridiculous, nobody claimed the "DPI is being systematically undercalculated at 91% (10/11) of its real value", we did that because 10 was looking tiny for most people and we needed a workaround

Tim Hull (thully) wrote :

On my system (13 inch MacBook - dual-boot installed w/Boot Camp), this appears to detect the DPI correctly. as being 112 dpi.
However, the resulting fonts, when using my display's native 1280x800 resolution, are huge. I think the issue may not necessarily be the
wrong DPI being detected - it's that the font is a bad size with the right DPI selected! In the meantime, I've reverted to the Feisty settings
(96 dpi, 10 pt font in Gnome), and everything looks normal again.

Martijn vdS (martijn) wrote :

Tim, you should try to set the font to the right size, while keeping the DPI the same, calculated value. The DPI is getting more and more important as high-pixel-density monitors appear (I have a 150dpi laptop here), as people usually don't want to read 5 pixel high fonts on those screens. If we get more programs to cope with DPI properly, we won't have to solve this problem in the future, when all panels are >150dpi.

The bug I filed is that if I do this - set the DPI to the calculated size -
the fonts are gigantic.
That is why I don't have it set that way...

On 6/26/07, Martijn van de Streek <email address hidden> wrote:
>
> Tim, you should try to set the font to the right size, while keeping the
> DPI the same, calculated value. The DPI is getting more and more
> important as high-pixel-density monitors appear (I have a 150dpi laptop
> here), as people usually don't want to read 5 pixel high fonts on those
> screens. If we get more programs to cope with DPI properly, we won't
> have to solve this problem in the future, when all panels are >150dpi.
>
> --
> default desktop/panel menu font sizes too small
> https://bugs.launchpad.net/bugs/118745
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Just an update about the current status: DPI is detected correctly on my production system upgraded from feisty to latest gutsy, but when I boot the current live CD, I get an autodetected DPI of 67. It should be 86, that's why fonts are so small.

So this is ultimately an Xorg bug. Bryce, is that known to fail sometimes and going to be fixed? Or can it at least tell us if it was able to detect the DPI? If not, we might need to revert to the hardcoded 96 DPI we had so far.

Changed in xorg-server:
assignee: nobody → bryceharrington
importance: Undecided → Medium
description: updated

Hi,

Mark Shuttleworth [2007-06-28 17:33 -0000]:
> - since gutsy, font sizes are too small.
> + In Gutsy, Gnome switched to using the X server's screen DPI detection,
> + which means that fonts can easily appear to be too large or too small,
> + depending on your screen setup. The old approach was to use 96 DPI by
> + default, but the new one can result in widely differing DPI values. We
> + need to improve the detection, or give people an easy way to tweak these
> + values so that the result looks good on their system.

I agree. At the moment, changing the DPI value in the Appearance
dialog doesn't have any effect at least on my installed system.

In my experience, changing the DPI does have an effect . However, what I'm finding is that even with the *correct* DPI values, the fonts can be way too big.
In my case, using the correct value (112 dpi) causes my MacBook to have fonts that are intolerably large. 96 dpi, on the other hand, results
in fonts that are of a more reasonable size. I have a separate bug open to this effect - though some systems are certainly detecting the wrong DPI, I'm finding the fonts are bad even with the *right* DPI!

Nick_Hill (nick-nickhill) wrote :

I have a switch box. The switch box doesn't appear to send DDC signals through, whether or not the monitor is live when X starts.

If I start X with the monitor connected directly to the computer, X sets DPI at 95, 96 . If the monitor is not connected, it sets the DPI at 75. At 75dpi, the fonts are usually intolerably small.

The most common screen resolutions/sizes tend to be (appx) :
Diagonal Width Height ResolutionWxH DPI
14.1" 11.28 8.46 1024X768 90.5 90.5
15" 12 9 1024x768 85 85
17" 13.25 10.65 1280x1024 97 96
19" 14.8 11.85 1280x1024 86 86

The most common resolution today is probably 17" 1280x1024. for desktops, and something close to 14.1" 1024x768 for laptops. The weighted average is probably around 92dpi.

We must assume that it is not always possible to determine the monitor's characteristics - any of them. Screen size, H/V sync, max resolution, DPI.

Where no information is available, we need to set sensible defaults so that the user can at least get something on screen to make initial changes..

If the user has not set preferences (ie all fields are on autodetect in the attached example) and we have no DDC information whatsoever, AND no settings have been put in xorg.conf, then 800x600,60Hz75dpi is a sensible default.

However, if a resolution has been set and a DPI has not been set, I suggest we have an automatic DPI mapping based on the highest resolution axis as follows:
<700 56dpi (eg 640x480)
<950 75dpi (eg 800x600)
<1200 85dpi (eg 1024x768)
<1400 95dpi (eg 1280x1024)
>1400 100dpi. (eg 1440x1024)

Whenever display settings changes are made within Gnome, I suggest we also store the mtime for file /etc/X11/xorg.conf. If xorg.conf exists, and the time stamp differs, then all settings in Gnome should be re-set to Autodetect / default. Otherwise, Gnome settings should take precedence.

This way, if the user does dpkg-reconfigure xserver-xorg, the settings will take precedence. If the user then logs into Gnome then changes settings, they then take precedence.

So we have an order of precedence for each parameter Res, Freq, DPI:

Resoution
1) The most recently changed of Gnome or xorg.conf
2) DDC
3) 800x600

Frequency (refresh rate)
1) The most recently changed of Gnome or xorg.conf
2) DDC
3) 60Hz

DPI:
1) The setting in Gnome
2) DDC
3)
<700 56dpi (eg 640x480)
<950 75dpi (eg 800x600)
<1200 85dpi (eg 1024x768)
<1400 95dpi (eg 1280x1024)
>1400 100dpi. (eg 1440x1024)

John Vivirito (gnomefreak) wrote :

Rejecting firefox task as it is not a firefox issue.

Changed in firefox:
status: New → Invalid
Nick_Hill (nick-nickhill) wrote :

As an update to my suggestion to have the DPI settable in a Gnome interface,

I suggest replacing the DPI drop-down box that I previously suggested, with a screen size drop-down box. And add two fields for width and height. If anything other than user defined is selected, the width and height boxes are greyed/inactive and display the current auto-detected width and height, or the width and height associated with the option manually selected. If "User Defined" is selected, the width and height boxes are black, activated and editable. User can change those values to any sensible value.

I'd suggest
AutoDetect
12"
14"
14" widescreen
15"
15" widescreen
17"
17" widescreen
19"
19" widescreen
User Defined

How do we handle situations where the user has not selected either a resolution or screen size, and no detection information is available?

Normally, we would want to assume the user is using the most common screen size of the day which is 17”.

We need to consider whether this would work when a user is trying to install a system using a 'fall-back' resolution such as 640x480 or 800x600 whether or not screen size info is available.

We are faced with several competing factors:
1)Will the font sizes be readable with default settings?
2)Will the system be installable with default settings?
3)Will the screen be set to the “correct” size?

I suggest that when we are set to a fall-back resolution, 3 doesn't matter. Readability and installability are the prime factors. The user can set his or her preferences later, once installed.

We also need to ensure the ubiquity installer is usable with fall-back resolutions, at least, 800x600. I therefore suggest that if the screen resolution detected via DDC is 800x600 or less, we should ignore the screen size reported by DDC if less than 14” and assume 14”. (We don't want high DPI values at 800x600 resolution as this will often lead to the ubiquity application window growing too large for the screen, and other applications growing ungainly).

I have made a flowchart which demonstrates logical steps to end up with a resolution, refresh rate and screen size from xorg.conf, gnome settings and DDC as outlined above.

Tim Hull (thully) wrote :

Well, at least in my case the correct DPI seems to have been detected in Tribe 2. However, 11 pt system font is too big at my actual system DPI - though 10 pt (the original setting) is perfectly fine.

Hi i confirm this problem on a fresh install of tribe 2.
Fonts are too small. following Nick_Hill post, i set dpi to 85 and all is ok now.
Tell me if you need more specific informations.

Nick_Hill (nick-nickhill) wrote :

Hello Patrice

How did you sett he DPI for your system?

For my 17" TFT monitor, I set screen size and hence DPI in xorg.conf like:
Section "Monitor"
        Identifier "Generic Monitor"
        Option "DPMS"
        HorizSync 30-65
        VertRefresh 50-75
        DisplaySize 340 270
EndSection

However, Bryce Harrington has been making excellent progress with bullet proof X, which should autodetect all relevant settings, which could ultimately eliminate the need for xorg.conf on most machines.

I installed Ubuntu Gutsy T2 on a 2.5" hard drive, deleted xorg.conf then swapped it between 8 very different laptops. On all systems, I had a screen which was potentially usable to at least install the system and manually configure the resolution etc (once the front end will accommodate higher than fall-back settings in fall-back situations).

I have logged info from these laptops including lspci -v, xorg.0.log, /proc/bus, dmesg, lsmod. If anyone knows how this information can best be used, please let me know!

Stephan7 (sshsteph007) wrote :

I noticed in this discussion that firefox is removed from this issue,
however "Bug #121738 in firefox (Ubuntu)" is makred a duplicate of this
and it shows a difference between firefox menu font (not its contents)
with the gnome menus.

I have that same problem that the firefox menu font is too small, see attachment.
No matter which DPI I choose (in system->Pref->Appearance->Font->detail) it
won't influence font sizes in my situation: I have a beamer connected and I want
larger than default as I'm watching it from several metres away.
So I prefer the system font at 14pts, but as firefox shows fonts too small I need
to set it up to 18pts.

So don't forget that there are also users with beamers using Ubuntu.

John Vivirito (gnomefreak) wrote :

Firefox was removed from this issue because firefox isnt causing this problem it is affected by it.

Andreas Färber (afaerber) wrote :

I would like to point out that this issue touches on personal taste. I liked the "small" menu font size in Tribe 2 whereas I do not like the 11pt at 96dpi setting I suddenly had after today's updates. Please reconsider imposing that on all users without asking.

Nick_Hill (nick-nickhill) wrote :

Hello Andreas

Presumably your fonts scaled to 75dpi but displayed on your 96dpi screen. They were therefore not displayed as an 11pt font but instead displayed as an 8.5pt font. Now the dpi is presumably detected correctly, it is displayed, as set, at 11pt.

As you rightly say, there is a matter of taste how big you would like to see your fonts on screen. But having the system set up so that it does not "know" the resolution of your screen is not a good way to achieve the desired result. Putting it another way, if your screen were really 75dpi, you would probably again find the fonts too big.

Once screen dpi is correctly detected and set on the majority of systems, if users find the fonts are then too big, bugs can be filed against Gnome/KDE for more appropriate default font sizes.

In the meantime, you can adjust your menu font sizes to your preferred size in the control panel.

Bryce Harrington (bryce) on 2007-08-01
Changed in xorg-server:
status: New → Confirmed
Mike Richards (mrmikerich) wrote :

What is the name of the control panel app that lets you change font sizes? I have a non-standard Ubuntu install, so I need to know the name of the app to launch it from the command line. Thanks.

Marius Gedminas (mgedmin) wrote :

Mike: it's gnome-font-properties.

Now that /usr/share/gconf/defaults/10_libgnome2-common is setting some fonts at 11dpi, my desktop looks like a carnival of big and small fonts.

I "fixed" things on my computer this way:

First I changed /etc/gdm/gdm.conf-custom and added this lines to the end:

[server-Standard]
command=/usr/bin/X -br -audit 0 -dpi 96

It's lovely that Gnome is able to change it's font size to suit whatever resolution my system is reporting. But it only makes sense really if EVERYTHING scales accordingly, I mean icons, and panels, toolbars, widgets, etc. if only fonts are scaled, the desktop doesn't look quite right, it gets distorted. So I don't care much about autodetected DPI, and I leave it as 96 dpi which seems to give the least distorted output for the desktop and most applications.

[server-Standard]
command=/usr/bin/X -br -audit 0 -dpi 96

I then changed the two libgnome fonts (document font and inteface font) to be back at 10 dpi, if I leave them as 11 dpi and use a monospace 11dpi, Nautilus 11dpi and a Metacity 11dpi font, then fonts inside Firefox will look too small compared to the rest. This I fixed changing /usr/share/gconf/defaults/10_libgnome2-common so all text reading "Sans 11" would now read "Sans 10". Then I ran update-gconf-defaults.

I also added a value to the end of this same file:
/desktop/gnome/font_rendering/hinting full

And ran update-gconf-defaults again. This last setting fixes the problems with font weight with gnome-terminal and OpenOffice.org.

I hope this serves the developers.

Not sure if bug #107320 (that itself have duplicates) is related and or duplicate of this one.

Jonathan Riddell (jr) wrote :

When X can pick any random DPI there's no right answer as to what the default font size should be. I recommend adopting the guidance-restore script which sets up a sane DPI. Install kde-guidance and restart the X server to test. It can easily be moved to guidance-backends.

Ned (nedwilliamson) wrote :

I don't know if this is the same problem, but on the latest update, text pretty much everywhere got really small.
I have a screenshot of the problem attached.

Alexander Jones (alex-weej) wrote :

How big is your screen? (Physically)

Ned (nedwilliamson) wrote :

It's about 11 1/2 inches horizontally and 8 1/2 inches vertically not including the border around the edges.
It's a Dell Latitude D610 laptop.

I have a 40 inch 1920*1080 display attached (Approximately 55 dpi according to my calculations). Xorg.log says it detects a DPI value of 304, 304.

I get *GIGANTIC* fonts and Icons and am unable to install gutsy tribe 4 or change anything because hardly nothing fits on
my screen !

Fwiw, bulletproof-x is just a failsafe mode for X, and wouldn't have any bearing on this issue.

It sort of sounds like the issue here is that Gnome is guessing the correct dpi by looking at the refresh rates. Unfortunately, in most cases the refresh rates are themselves just guesses done by the xorg postinstall script when xresprobe fails to detect the card (which happens a lot). If this is indeed the case, then basing a guess on top of a guess is bound to lead to rather unpredictable failures.

In talking with seb128 about this, it sounds like the best option for now is to go back to a hardcoded dpi setting.

Assuming my hypothesis is correct, a couple workarounds to try would be to a) try running with no xorg.conf. b) try fixing the HorizSync and VertRefresh settings in the Monitor section of your xorg.conf (see your monitor for correct settings). No guarantees that this would fix things in all circumstances, but if they fix it in at least some, then that is added evidence that the core issue here is mis-detected refresh rates (which is bug 3731).

What's this thing about guessing? When the live-cd boot screen appears you can select your screen size from there. How come the boot graphics aren't the same as the normal graphics? Can't X use a default dpi based on the screen size you selected at boot time? Of course there's some abstraction involved but I think this would lead xorg from betting the dpi a little more realistic.

Alexander Jones (alex-weej) wrote :

We don't have resolution independence yet in GNOME. As such, the only thing that is affected by screen DPI are the fonts. Proportionality between text and other graphical elements, particularly icons, is of primary concern for most users. The only way that proportionality looks "right", is with 13 1/3 pixel text (10pt @ 96dpi) with 24 pixel menu icons.

It is my opinion that we should just set the default DPI to 96 and revert the font sizes for now until:

a) We have a more reliable way of setting/detecting actual screen DPI; and
b) We actually have some level of resolution independence

Anthony S (aaaantoine) wrote :

Pardon my curiosity, but what is the significance of the OS knowing the PPI of the screen? Consider the following scenarios:

Screen #1 is an independent monitor: a 19" LCD with native 1280x1024 resolution. The PPI is approx. 85. The user sits between 3 and 5 feet away from this screen.

Screen #2 is a laptop panel: a 14.1" LCD with native 1280x800 resolution. The PPI is approx. 105. The user sits between 1 and 2 feet away from this screen.

When the GUI scales everything by the DPI of the monitor, it will scale everything according to what the "real" size of the graphics should be. This means that Screen #1 will display more information on it than Screen #2, regardless of resolution. However, the smaller size of the graphics on Screen #1 causes the user to strain at his usual sitting distance from the monitor, while the relatively large graphics on Screen #2 suffocate him with their sheer size.

I guess what I'm asking is, wouldn't it make more sense to have a GUI scaling tool that lets you resize all graphics (independent of resolution) rather than autosize everything according to the monitor's PPI?

Bryce Harrington (bryce) on 2007-08-17
Changed in xorg-server:
status: Confirmed → Triaged
description: updated
Changed in libgnome:
status: In Progress → Fix Released
Bryce Harrington (bryce) on 2007-09-17
Changed in xorg-server:
status: Triaged → Fix Released
32 comments hidden view all 112 comments

I think this is something in the server as the driver does not mess with the dpi anywhere.

Alex, I am not sure if I can agree with last comment: on Ubuntu Gutsy, which is running xserver 1.3, panel size (and consequently DPI) is properly detected with ATI driver 1:6.6.193-1ubuntu1, but it does not get detected with ati driver with xrandr (this was regression identified with my early testing of xrandr branch and is still there in 1:6.7.192-1ubuntu2).
Since it looks like driver is reporting proper size in log file, but later does not use it properly, is it possible that this get somehow mangled in the driver before passing further?

Saivann Carignan (oxmosys) wrote :

Maybe we should give some attention to bug #119990 which relate to similar problems with QT programs, it's still not fixed and worst ever.

I can confirm comment #9 on Debian. Actually, I can confirm this whole report letter for letter down to the solution. :)

(In reply to comment #9)
> Alex, I am not sure if I can agree with last comment: on Ubuntu Gutsy, which is
> running xserver 1.3, panel size (and consequently DPI) is properly detected
> with ATI driver 1:6.6.193-1ubuntu1, but it does not get detected with ati
> driver with xrandr (this was regression identified with my early testing of
> xrandr branch and is still there in 1:6.7.192-1ubuntu2).
> Since it looks like driver is reporting proper size in log file, but later does
> not use it properly, is it possible that this get somehow mangled in the driver
> before passing further?
>

The old driver implemented it's own dualhead system (mergedfb) right in the driver. The old driver DID mess with the dpi because it handled the randr type functionality itself. With randr all of that moved to the server. The server should be doing the right thing. If it's broken for radeon, it's also broken for intel or mga or whatever other randr driver you are using. The drivers shouldn't be duplicating dpi fixups.

John Vivirito (gnomefreak) wrote :

The fix failed to fix it here i had to set fonts to 12 this is with libgnome2-common 2.20.0-1ubuntu2
I use 1600X1200 and the fonts are way too small still if i run xdpyinfo i get:

xdpyinfo | less shows dimensions: 1600x1200 pixels
 (323x252 millimeters) resolution: 126x121 dots per inch

shouldnt that be more like 100X100 DPI?
there is no way that i found to change that setting even with DPI set in apperance to 96

John Vivirito (gnomefreak) wrote :

This was working fine before i reinstalled feisty and upgraded to gutsy without installing packages thani ran into this issue it happened yesterday after upgrading to fixed dpkg

I installed a system with Tribe 5, and its fonts were somewhat large. After
further updates, I saw the regression with gnome-terminal that others
reported (fonts too small to see). With the latest updates in Gutsy,
everything is working fine, with appropriate font sizes both in the terminal
and elsewhere.

--
 - mdz

Alexander Jones (alex-weej) wrote :

On Wed, 2007-09-19 at 23:21 +0000, John Vivirito wrote:
> The fix failed to fix it here i had to set fonts to 12 this is with libgnome2-common 2.20.0-1ubuntu2
> I use 1600X1200 and the fonts are way too small still if i run xdpyinfo i get:
>
> xdpyinfo | less shows dimensions: 1600x1200 pixels
> (323x252 millimeters) resolution: 126x121 dots per inch
>
> shouldnt that be more like 100X100 DPI?
> there is no way that i found to change that setting even with DPI set in apperance to 96

The DPI setting in "appearance" only affects font rendering, not your X
server.

John Vivirito (gnomefreak) wrote :

Where would i find the dpi setting to change to fix this if not in apperance>fonts?

New driver is out but doesn't fix this issue.

Linux 2.6.23git, glibc 2.6.1, i686, Thinkpad Z60m with ATI Mobile X600,
xorg-xserver-server 1.4-3, xorg-driver-video-ati 6.7.193, Mesa 7.0.1.

By default driver calculates very wrong panel size:
  dimensions: 1680x1050 pixels (444x277 millimeters)
  resolution: 96x96 dots per inch

The correct one is DisplaySize 330 210 (mm).

I'm attaching my config, x log and xdpyinfo output.

Created an attachment (id=11657)
xdpyinfo output

Created an attachment (id=11658)
Xorg log

Created an attachment (id=11659)
xorg.conf

Alexander Jones (alex-weej) wrote :

Section "Monitor"
  DisplaySize x y
EndSection

Where x and y are your actual, real-world screen dimensions in mm.

Alexander Jones (alex-weej) wrote :

Sorry, I should add that you need to put that DisplaySize bit inside your "Monitor" section in your X configuration file: /etc/X11/xorg.conf

Created an attachment (id=11726)
New log, xserver 1.4, ati 6.7.194, linux, thinkpad z60m

Changed in xorg-server:
status: Unknown → Confirmed

This is fixed for me with recent uprage to 6.7.194-1ubuntu1tv version of ati driver.
SW: Kubuntu Gutsy
HW: HP nw8240 with ATI FireGL V5000 PCIE

does 6.7.194-1ubuntu1tv carry any patches beyond what's in the stock 6.7.194 or ati git?

It is vanilla source from git.

The "tv" package is practically the same as the Debian 6.7.194-1 package, which has no changes to the source files (only packaging and makefiles etc).

OTOH the xorg-server in Ubuntu Gutsy is a bastard 1.3 with lots of 1.4 backports.

Doesn't work with newly released ati driver 6.7.195. Alex Deucher tells that this is probably xserver issue and not ati driver one: http://lists.freedesktop.org/archives/xorg/2007-September/028627.html. Unfortunately xserver devs didn't respond to that so this is still unknown.

If you are xserver dev and could help to track down this I'm ready to test your ideas, debug things and so on. Very nasty issue preventing any few randr 1.2 drivers from being usable :-/

1 comments hidden view all 112 comments

In my case resolution is 1680x1050 and this code in hw/xfree86/modes/xf86RandR12.c is executed:
                /*
                 * Otherwise, just set the screen to 96dpi
                 */
                mmWidth = width * 25.4 / 96;
                mmHeight = height * 25.4 / 96;

width is 1680, height 1050 and that ends up as dimensions: 1680x1050 pixels (444x277 millimeters).

I assume that the standard code path that this driver shoud follow is:
if (crtc && crtc->mode.HDisplay && output->mm_width && output->mm_height)

Unfortunately the problem is that mm_width and mm_height are zero so that code path is never executed. Don't know yet where these come from - I assume radeon driver fills these. Digging.

I'm guessing that my problems are related to "(WW) RADEON(0): Unknown DDCType 6 found" like not found => no ddc query => panel dimensions unknown. Is my guessing correct?

"Unknown DDCType 6 found" was the main problem here. Without handling it DDC/EDID didn't work so X didn't know panel dimensions and other stuff. Thanks to airlied git commit 0b03a73b7dcb4aa192c42f2a4c842d324c358122 the isue is solved for me.

Bartosz logs also show the same issue so I guess he will be fine with this patch, too.

Tim Hull (thully) wrote :

The issue still isn't fully fixed for me. On my MacBook (13.3", 1280x800, intel graphics), the fonts for the user id on the login screen and for application title bars are still gigantic. However, the rest of the fonts are OK, and restarting X once after booting up will resolve the issue with the title bars until the system is rebooted again. Seems like a different DPI is being used when X is started through the init process as opposed to through gdm AFTER the init process. Could someone fix this? It is a tad annoying...

Changed in xorg-server:
status: Fix Released → New

(In reply to comment #23)

>
> I assume that the standard code path that this driver shoud follow is:
> if (crtc && crtc->mode.HDisplay && output->mm_width && output->mm_height)
>
> Unfortunately the problem is that mm_width and mm_height are zero so that code
> path is never executed. Don't know yet where these come from - I assume radeon
> driver fills these. Digging.

mm_width and mm_height should be filled in either by the edid (xf86OutputSetEDID()), or by hardcoding them in a monitor section in your config. If you hardcode the settings, the server should parse the monitor section of your config assigned to that output and fill in the values, but it does not. That's the bug.

>
> I'm guessing that my problems are related to "(WW) RADEON(0): Unknown DDCType 6
> found" like not found => no ddc query => panel dimensions unknown. Is my
> guessing correct?
>

In your case, yes, but lots of laptops do not provide an edid for the panel. Without an edid, there is no way to know what the physical size of the screen is. We are able to determine the size of the panel in pixels based on the panel bios tables, but not the physical size.

I'm bothered by seeing this kind of thing in Xorg.0.log using 845G on Mandriva 2008 and OpenSUSE 10.3 (where DPI always comes out to 96 no matter what resolution or screen size is used):

...
(**) intel(0): Display dimensions: (361, 270) mm
(**) intel(0): DPI set to (144, 192)
...

See:
https://bugzilla.novell.com/show_bug.cgi?id=331609
http://qa.mandriva.com/show_bug.cgi?id=33935

bug 10304 has fix for xserver (not tested by me but looks fine)

Tim Hull (thully) wrote :

I have figured out that the current font problem is limited to Compiz, so adding that as a package which this bug occurs in and re-closing the bug in xorg-server...

Changed in xorg-server:
status: New → Fix Released
Tim Hull (thully) wrote :

Please look at this as it related to Compiz... I have huge title bar fonts after starting X with Compiz enabled (with Compiz disabled, it's fine...).

Matt Zimmerman (mdz) wrote :

This issue seems to be fixed for everyone else; I suspect that Tim Hull's problem is not related.

Tim Hull (thully) on 2007-10-09
Changed in compiz:
status: New → Invalid
Florian Effenberger (floeff) wrote :

I tried out an in-place upgrade from feisty to gutsy, and it seems to work now! :-)

Khorne (szczygiel-piotr) wrote :

Well, today I've made a clean install of 7.10. Even on Live CD install ,window title bar fonts were extremely huge. After install I could see the same huge font on login screen and, like on Live CD, on tittle bars. Font on tittle bars has changed after switching to non-default metacity theme but remained the same (huge) on login screen.

I didn't have this problem when I was working on Feisty and even when I updated from Feisty to Gutsy by updating repositories.

Alexander Jones (alex-weej) wrote :

Is Compiz using the GNOME API for screen DPI? I'd imagine not, hence why this bug is a problem.

Fixed in git as of d502521c3669f3f22b94c39a64ab63bfd92c6a97.

Changed in xorg-server:
status: Confirmed → Fix Released

I've got the same problem as Khorne describes, and many other people. This should be a critical bug and a fix put out pdq because NUBE's are throwing Ubuntu away when they experience their first hassle before even getting to their desktop.....

Bryce Harrington (bryce) wrote :

The remaining cases I've seen of this have been down to the user having an old xorg.conf from either Feisty or an old tribe release. In at least one case, removing the HorizSync and VertRefresh lines in Monitor and rebooting completely resolved it.

Or just run "sudo dpkg-reconfigure xserver-xorg" and it'll regenerate your xorg.conf. For most people you can just accept the defaults for any prompts it gives.

I think you meant commit 48ca5961caee62f2980017a6bdc96a1b4c747727

Changed in xorg-server:
importance: Unknown → Medium
Changed in xorg-server:
importance: Medium → Unknown
Changed in xorg-server:
importance: Unknown → Medium
Displaying first 40 and last 40 comments. View all 112 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.