Bugzilla – Bug 53811
X11 miscalculates dpi for virtual resolutions
Last modified: 2010-08-14 10:13:41 UTC
X11 seems to calculate the screen density (dpi) by dividing the resolution by the size. Unfortunately, it does seem to use the virtual resolution rather than the physical one from the Modelines. That's just wrong.
Hmm ... is this a Multihead setup? Did you specify DisplaySize in XF86Config?
No Multihead, just a notebook LCD panel. DisplaySize 292 219 [...] Modes "1024x768" (--) RADEON(0): Virtual size is 1024x768 (pitch 1024) (**) RADEON(0): *Mode "1024x768": 65.0 MHz (scaled from 0.0 MHz), 48.4 kHz, 60.0 Hz [...] (**) RADEON(0): Display dimensions: (292, 219) mm (**) RADEON(0): DPI set to (89, 89) But with Virtual 1024 832 I get (--) RADEON(0): Virtual size is 1024x832 (pitch 1024) (**) RADEON(0): *Mode "1024x768": 65.0 MHz (scaled from 0.0 MHz), 48.4 kHz, 60.0 Hz [...] (**) RADEON(0): Display dimensions: (292, 219) mm (**) RADEON(0): DPI set to (89, 96) The xdpyinfo report is consistent with this, but just as wrong. As the dpi are even used frop something nowadays, this should be fixed IMHO. Is this bug radeon specific?
This isn't driver specific. Nearly all drivers (SiS seems to be an exception) use xf86SetDpi() (xc/programs/Xserver/hw/xfree86/common/xf86Helper.c) for this. And unless you use the Xserver command line option "-dpi" the virtual resolution is used for calculating the DPI value. Which resolution you configured should be used instead? The first, the second, ..., the last? You'll run into problems when switching the resolutions as well. DPI won't match any more. Any reasons why you configure another virtual resolution than the resolution you use?
1. I like to have a larger virtual screen than real screen. 2a. I think it's obvious that calculating the dpi from the virtual resolution is just nonsense. 2b. The real resolutions are better for sure. An obvious choice would be the first one, which is the one X11 uses when it starts. Another possible, but less obvious choice would be the largest one found. 3. The fact that the dpi change when you change the screen resolution is clear. You can't avoid this. For now, I would ignore that problem. Few people change resolutions and as TFTs become more and more popular it will be even fewer in future.
> 1. I like to have a larger virtual screen than real screen. How many people do this? I'm aware of two guys in the work, you and Bernd Kaindl. > 2a. I think it's obvious that calculating the dpi from the virtual > resolution is just nonsense. No, it's the first and in most cases the best approach. > 2b. The real resolutions are better for sure. An obvious choice would > be the first one, which is the one X11 uses when it starts. > Another possible, but less obvious choice would be the largest one > found. Sounds for me like a feature request. Therefore I set this to enhancement for now. I would also be interested what Egbert thinks about this.
> How many people do this? I'm aware of two guys in the work, you and Bernd s/work/world/
How can calculating the dpi from a virtual resolution be correct if the virtual resolution is not the one being displayed? I can't see that it could be the best approach. Anyway, do what you think is best ...
It's the best approach, if you don't look at the available modes. :-)
The problem lies still elsewhere. The DPI calculation is real crap as we don't announce it to the application as DPI, the application instead does the calculation. Furthermore the physical screen resolution may change however the application doesn't know about this (unless it is RandR aware). All this is horribly broken and needs to be fixed. I'm not sure how though. My theory is: On normal displays the DPI value only depends on the resolution of the screen, not on the size of the screen as the user adjusts his monitor such that he will view it under a comfortable viewing angle so that he can see the entire screen at once. (I know that people have huge CRTs just to read from a tiny xterm in the top left corner - but this is bad habit). At the same time you use the DPI value to view a document under the same viewing angle as if you had it on the table in front of you. Knowing this one just needs to know to physiological values: 1. The normal reading distance. 2. The main viewing angle of the human eye. With this and information about the physical screen resolution you can calculate a 'felt screensize' which you announce to the clients to caluclate the DPI. This however will not resolve the virtual screen issue: You get virtual screens usually when you resize the physical resolution. However an application cannot know about this and therefore will not query the information about the screen size again (I'm not even sure if this is transmitted in the connection info block which gets passed once during connection creation).
We may be able to correct this in the light of the RandR extension. I'll take a look one day....
9.1 is dead, bring forward to 10.1 for reeval
*** Bug 224504 has been marked as a duplicate of this bug. ***
> We may be able to correct this in the light of the RandR extension. > I'll take a look one day.... BTW, RANDR 1.2 is on the way for X.Org 7.3. Not sure if it covers the DPI issue though.
Let "DPI" override it all.
JFYI, Matthias. This is a bugreport, which is assigned to Egbert/me or with Egbert/me in CC or reported by Egbert/me.
Kurt, I don't think that RANDR 1.2 already adresses this issue, but a RANDR 1.2 radeon driver is already on openSUSE 10.3 ("radeonrandr12"). http://www.suse.de/~sndirsch/randr12.html
With RANDR 1.2 you can now set the DPI value on-the-fly xrandr --dpi <dpi>/<output>
This is still a problem. the entire DPI calculation is broken. I would like to keep this open as a reminder to look back into it.
My T400 system autosets the dpi to 121x120 instead of 96x96, so this is still valid for me, overriding on start with xrandr is no real solution as all already started applications have the wrong dpi and we now expect Xorg to autostart with an xorg.conf, so I'd be grateful for a proper fix =)
Needs to be addressed upstream.