pass client DPI preference to server (and use sane defaults of 96dpi) #163

totaam · 2012-07-12T06:13:32Z

Issue migrated from trac ticket # 163

component: core | priority: blocker | resolution: fixed

2012-07-12 06:13:32: antoine created the issue

As discussed here on the mailing list

We need to calculate the client's screen dimensions and pass it to the server so that the Xvfb uses the same dimensions.

The --dpi option of xrandr actually computes dimensions from the resolution and dpi.

The text was updated successfully, but these errors were encountered:

totaam · 2012-07-24T07:15:00Z

2012-07-24 07:15:00: antoine commented

Actually, looking at both Xdummy and Xvfb, I get reasonable values for the dpi:

Xdummy:
$ xrdb -query | grep dpi
Xft.dpi:        96
$ xdpyinfo | grep -i dot
  resolution:    37x47 dots per inch
Xvfb:
$ xrdb -query | grep dpi
Xft.dpi:        96
$ xdpyinfo | grep -i dot
  resolution:    100x100 dots per inch
Now, the X11 server DPI reported is not great in the case of Xdummy, but since all the toolkits use the value from xrdb, I'm not sure we should worry too much about this. Even if we did, this 6 year old bug is not getting any response from Xorg...

totaam · 2012-07-24T08:22:35Z

2012-07-24 08:22:35: antoine commented

r1175 improves things by always setting the DPI to 96 by default (obviously this can be changed with --xvfb).

The only problem is that despite reporting the correct value with Xdummy in the Xorg server log file:
$ grep -i dpi Xorg.10.log
[  7265.289] (++) DUMMY(0): DPI set to (96, 96)
xdpyinfo still disagrees:
$ xdpyinfo | grep -i dot
  resolution:    30x37 dots per inch
And this is as far as I am willing to go battling xorg API.

totaam · 2012-07-30T18:19:05Z

2012-07-30 18:19:05: antoine commented

Note: the Xft.dpi is already sent to the server as part of _XSETTINGS_SETTINGS.

totaam · 2012-08-01T18:56:15Z

2012-08-01 18:56:15: antoine commented

Applications known to have problems (which I happen not to use...):

emacs

konsole

totaam · 2012-08-01T19:13:28Z

2012-08-01 19:13:28: antoine commented

Just tested both with trunk at r1255 and the following command lines:

xpra --no-daemon --bind-tcp=0.0.0.0:10000 start :10 \
  '--xvfb=/usr/local/bin/Xorg -nolisten tcp +extension GLX \
  +extension RANDR +extension RENDER \
  -logfile /home/antoine/Xorg.10.log \
  -config /home/antoine/xorg.conf'

DISPLAY=:10 konsole &
DISPLAY=:10 emacs&
xpra attach :10

Both konsole and emacs look fine.

Version info:

$ rpm -qa | egrep -i "konsole|emacs"
xemacs-filesystem-21.5.31-4.fc17.noarch
emacs-24.1-3.fc17.x86_64
konsole-part-4.8.4-1.fc17.x86_64
emacs-common-24.1-3.fc17.x86_64
konsole-4.8.4-1.fc17.x86_64
emacs-filesystem-24.1-3.fc17.x86_64

Here's what I have in my client PC:

$ xdpyinfo | egrep -i "dot|dim"
  dimensions:    2560x1600 pixels (677x423 millimeters)
  resolution:    96x96 dots per inch

And in the xpra server I find:

$ xdpyinfo | egrep -i "dot|dim"
  dimensions:    2560x1600 pixels (2338x584 millimeters)
  resolution:    28x70 dots per inch

The Xft.dpi is identical though:

$ xrdb -query | grep dpi
Xft.dpi:	96

totaam · 2012-08-01T19:13:28Z

2012-08-01 19:13:28: antoine

totaam · 2012-08-01T19:13:28Z

2012-08-01 19:13:28: antoine

totaam · 2012-08-01T19:13:28Z

2012-08-01 19:13:28: antoine

totaam · 2012-08-01T19:35:38Z

2012-08-01 19:35:38: antoine commented

As per the mailing list, the clients which exhibit this problem do not have Xft.dpi set to anything.

One can workaround the issue by setting it by hand before connecting with xpra:
echo "Xft.dpi: 96" | xrdb -

totaam · 2012-08-03T10:00:14Z

2012-08-03 10:00:14: antoine changed status from new to closed

totaam · 2012-08-03T10:00:14Z

2012-08-03 10:00:14: antoine changed resolution from ** to fixed

totaam · 2012-08-03T10:00:14Z

2012-08-03 10:00:14: antoine commented

done in r1262

Adds --dpi=NNN option to xpra, and default value of 96 set in the global config file. See changeset commit log for details.

totaam · 2012-10-16T12:10:13Z

2012-10-16 12:10:13: Sergio Callegari commented

This is still open for me as of xpra 0.7.0

when using xdummy with the default config, I have xdpyinfo returning 20x25 pixels per inch. In spite of the Xft.dpi, this breaks all java apps.

If I modify the xpra setup in etc, to have the xorg.conf including a more reasonable displaysize (e.g. DisplaySize 508 317) then everything is fine.

totaam · 2012-10-16T12:11:03Z

2012-10-16 12:11:03: Sergio Callegari changed status from closed to reopened

totaam · 2012-10-16T12:11:03Z

2012-10-16 12:11:03: Sergio Callegari changed resolution from fixed to **

totaam · 2012-10-16T12:11:03Z

2012-10-16 12:11:03: Sergio Callegari changed type from enhancement to defect

totaam · 2012-10-16T12:59:28Z

2012-10-16 12:59:28: antoine changed status from reopened to closed

totaam · 2012-10-16T12:59:28Z

2012-10-16 12:59:28: antoine changed resolution from ** to fixed

totaam · 2012-10-16T12:59:28Z

2012-10-16 12:59:28: antoine commented

Thanks, applied in r1983 (will be in 0.7.1)

Note though that this is only a workaround, Java should be honouring the Xft.dpi value. This new display size may be better for your use case, but it may not match everyone's... Would you mind sharing how you got to these values?

totaam · 2012-10-16T17:22:58Z

2012-10-16 17:22:58: Sergio Callegari commented

Basically, I searched for something giving me a value between 80 and 90 (I get 84 with this). This assures that I get readable fonts and at the same time xpra remote windows get a slightly smaller font that my standard ones, which is nice to quickly distinguish them.

totaam · 2012-11-16T09:14:31Z

2012-11-16 09:14:31: http://eureka7.ru/ commented

I have this issue, too. The problem is that DPI changes after attaching if Virtual option in servers xorg.conf is set too high. The default is 5120 3200. Here's what I have:

-Client:*
> xdpyinfo | grep -C 2 "screen #"
number of screens:    1

screen #0:
dimensions:    1920x1080 pixels (508x285 millimeters)
resolution:    96x96 dots per inch
-Server before the client attaches:*
> DISPLAY=:100 xdpyinfo | grep -C 2 "screen #"
number of screens:    1

screen #0:
dimensions:    5120x3200 pixels (1355x847 millimeters)
resolution:    96x96 dots per inch
-Server after the attaching:*
> DISPLAY=:100 xdpyinfo | grep -C 2 "screen #"
number of screens:    1

screen #0:
dimensions:    1920x1080 pixels (1355x847 millimeters)
resolution:    36x32 dots per inch
The display size in xorg.conf on the server side seems to be ignored (though it's set to 508 317 by default) and it's calculated as virtual size divided by resolution and multiplied by physical size or something like that. Setting Virtual to the actual client resolution solves this but can I prevent setting the wrong DPI on attach or is there any other workaround except setting the Virtual size equal to the clients one? Java apps which use Swing become unusable since fonts are unreadable.

totaam · 2012-11-16T09:14:31Z

2012-11-16 09:14:31: antoine

totaam · 2012-11-16T09:14:31Z

2012-11-16 09:14:31: antoine

totaam · 2012-11-16T17:14:25Z

2012-11-16 17:14:25: antoine commented

I believe that the dpi that we set will be correct, you can verify it with:
xrdb -query | grep dpi
Both before and after the client connects.
Java should not be using the hardware values from Xorg, that's what the X resource database is for.

If you feel very strongly about this bug, feel free to file a bug with your Java distributor.

Some potential workarounds:

You may be able to find a version of Java which does not do this (openjdk or other).

Start the Java application before the display is resized, so Java will pickup the original dpi.

use Xvfb which does not do xrandr and will therefore keep its original dpi, but then you may encounter all sorts of other display anomalies.

totaam · 2012-11-20T05:54:32Z

2012-11-20 05:54:32: http://eureka7.ru/ commented

Yes, xrdb returns the correct dpi but that one from xdpyinfo matters, too. And if you can change it on the fly maybe it's good idea to send the physical display size to the server along with the resolution? I just don't understand why the physical size 508x385 mm changes to 1355x847 mm after the client connects. It should stay the same and the only thing that should change is resolution but instead it seems to use fixed dpi and changing the resolution changes the physical display size which is weird. Of course, there are workarounds like you suggested (I prefer setting virtual size to 1920x1200 hence it's the biggest resolution of all desktops I use) but it would be better to not bother about dpi at all and have it 96 for every resolution regardless of display size. Is what I'm asking not possible at all?

totaam · 2012-11-20T13:07:15Z

2012-11-20 13:07:15: antoine commented

You cannot change the physical display size - there is no such api for the dummy driver, and it's very unlikely there will ever be one. Fixing Java on the other hand is relatively easy.

totaam · 2012-12-11T17:41:44Z

2012-12-11 17:41:44: antoine commented

Please do report any application that exhibits this problem (with distro and version, etc), I'm not having any issue on Fedora 18 with:
$ java -version
java version "1.7.0_09-icedtea"
OpenJDK Runtime Environment (fedora-2.3.3.fc18.1-x86_64)
OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode)
I've tried jedit, josm, etc. If you are having problems, it may be worth trying this JVM.

totaam · 2013-03-14T08:47:35Z

2013-03-14 08:47:35: leuko commented

I am frequently using old applications written with WindU toolkit which are used by many industrial applications which are developed since ~15 years and somehow conservative regarding GUI.

WindU toolkit appearantly doesn't use the DPI value reported by the Xft.dpi. My xpra client computer has 90 dpi monitors with 3360x1050 pixels which results in unreadable fonts after attaching (connecting) like eureka7 described. My xpra server xorg.conf uses 5120x3200 virtual size.

My workaround is to decrease the virtual option to the resolution which I am using on the client that the DPI calculated by xorg doesn't get a tiny value.

totaam · 2013-03-14T08:47:35Z

2013-03-14 08:47:35: leuko

totaam · 2013-03-21T17:05:10Z

2013-03-21 17:05:10: antoine commented

Note: some Java (and possibly others) application lookup gnome.Xft/DPI instead of Xft.dpi so we now set that value as well since r3034.

To get this used with Java, one also needs to tell Java to use the GTK look and feel, more information here: How to Set the Look and Feel

Note though that I have tested this with jedit and some other apps and did notice any difference...
java -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel -jar APPJAR
The code in Java that is used to figure out the display size is in XToolkit.java and does this:
public int getScreenResolution() {
        long display = getDisplay();
        awtLock();
        try {
            return (int) ((XlibWrapper.DisplayWidth(display, 
                XlibWrapper.DefaultScreen(display)) * 25.4) /
                    XlibWrapper.DisplayWidthMM(display, 
                XlibWrapper.DefaultScreen(display)));
        } finally {
            awtUnlock();
        }
    }
Making Xlib calls to get the display size... so we cannot do anything about it or override it, the only way to get the X11 server to report the values we want is going to require some changes in Xvfb/Xdummy (see [/ticket/189#comment:13])

Some related info:

java.net ticket 672090 claiming that the X11 server is always right (sigh)

Solving the Linux DPI Puzzle - informative

PangoFonts.java source which does the lookup and calculations

XToolkit.java source which calls Xlib

totaam · 2014-11-25T01:43:56Z

2014-11-25 01:43:56: afarr commented

Some odd window client side size related output to keep in mind:

2014-11-24 17:23:16,164   '1\WinSta-Default' (1016x571 mm)
2014-11-24 17:23:16,165     DISPLAY1 (621x341 mm)
2014-11-24 17:24:16,562 unexpected message: WM_MOVE / 0 / 1703999
2014-11-24 17:24:17,548 sending updated screen size to server: 1536x864 with 1 s
creens
2014-11-24 17:24:17,549   '1\WinSta-Default' (406x228 mm)
2014-11-24 17:24:17,549     DISPLAY1 (621x341 mm)
2014-11-24 17:26:11,614 unexpected message: WM_MOVE / 0 / 1703990
2014-11-24 17:26:11,615 unexpected message: WM_SIZE / 0 / 46203774
2014-11-24 17:26:12,578 sending updated screen size to server: 1280x720 with 1 s
creens
2014-11-24 17:26:12,579   '1\WinSta-Default' (338x190 mm)
2014-11-24 17:26:12,579     DISPLAY1 (621x341 mm)
2014-11-24 17:26:28,826 unexpected message: WM_MOVE / 0 / 1704001
2014-11-24 17:26:29,799 sending updated screen size to server: 1536x864 with 1 s
creens
2014-11-24 17:26:29,801   '1\WinSta-Default' (406x228 mm)
2014-11-24 17:26:29,802     DISPLAY1 (621x341 mm)
2014-11-24 17:27:08,217 unexpected message: WM_MOVE / 0 / 1703991
2014-11-24 17:27:09,184 sending updated screen size to server: 1280x720 with 1 s
creens
2014-11-24 17:27:09,184   '1\WinSta-Default' (338x190 mm)
2014-11-24 17:27:09,184     DISPLAY1 (621x341 mm)
2014-11-24 17:27:28,611 unexpected message: WM_MOVE / 0 / 1704017
2014-11-24 17:27:29,604 sending updated screen size to server: 1920x1080 with 1
screens
2014-11-24 17:27:29,605   '1\WinSta-Default' (508x285 mm)
2014-11-24 17:27:29,605     DISPLAY1 (621x341 mm)
2014-11-24 17:29:00,207 unexpected message: WM_MOVE / 0 / 1704043
2014-11-24 17:29:09,625 unexpected message: WM_MOVE / 0 / 1704064
2014-11-24 17:29:10,612 sending updated screen size to server: 3072x1728 with 1
screens
2014-11-24 17:29:10,614   '1\WinSta-Default' (812x457 mm)
2014-11-24 17:29:10,615     DISPLAY1 (621x341 mm)
2014-11-24 17:35:36,171 unexpected message: WM_MOVE / 0 / 1704001
2014-11-24 17:35:36,740 unexpected message: 800 / -952262963 / 1
2014-11-24 17:35:36,799 unexpected message: 800 / -952262194 / 1
2014-11-24 17:35:36,857 unexpected message: 800 / -952261683 / 1
2014-11-24 17:35:36,927 unexpected message: 800 / -952260915 / 1
2014-11-24 17:35:36,983 unexpected message: 800 / -952260147 / 1
2014-11-24 17:35:37,052 unexpected message: 800 / -952259635 / 1
2014-11-24 17:35:37,115 unexpected message: 800 / -952258867 / 1
2014-11-24 17:35:37,142 sending updated screen size to server: 1536x864 with 1 s
creens
2014-11-24 17:35:37,142   '1\WinSta-Default' (406x228 mm)
2014-11-24 17:35:37,142     DISPLAY1 (621x341 mm)
2014-11-24 17:35:37,176 unexpected message: 800 / -952258099 / 1
2014-11-24 17:35:37,243 unexpected message: 800 / -952257331 / 1
2014-11-24 17:35:37,305 unexpected message: 800 / -952256564 / 1
2014-11-24 17:35:37,365 unexpected message: 800 / -952256051 / 1
2014-11-24 17:35:37,434 unexpected message: 800 / -952255283 / 1
2014-11-24 17:35:37,490 unexpected message: 800 / -952254516 / 1
2014-11-24 17:35:37,561 unexpected message: 800 / -952254004 / 1
2014-11-24 17:35:37,622 unexpected message: 800 / -952253236 / 1
2014-11-24 17:35:37,650 unexpected message: 800 / -952252724 / 1

Obtained by manipulating the two different DPI input methods available with Windows 8.1 (Control Panel\Appearance and Personalization\Display vs. Control Panel\Appearance and Personalization\Display\Screen Resolution).

The Screen Resolution page allows direct manipulation of the actual display size, while the Display page allows the use of a slider between "Smaller" (which renders the display at the size indicated in the "Screen Resolution" settings) up through a number of options until reaching "Larger" (which increases the size of text by reducing the screen size(?) and thereby increasing the DPI(?)).

When all is said and done (and interpreted), the '1\WinSta-Default' value is usually rather fictional, while the DISPLAY1 size is accurate.

Confusion is now documented better... with any luck it will help in the future.

totaam · 2015-07-17T03:54:21Z

2015-07-17 03:54:21: totaam commented

More DPI values recorded in #885#comment:9

totaam · 2015-10-14T05:46:02Z

2015-10-14 05:46:02: antoine commented

See also: #976#comment:15 and r10832.

totaam · 2015-10-23T06:57:52Z

2015-10-23 06:57:52: antoine commented

Very relevant post: Of DPIs, desktops, and toolkits:

''
GTK+ is written to use the values from xsettings or the X resource database, if there are any. But what does it do when nothing has written the settings?''
(..)
As of Monday, it would default to hintstyle ‘full’, and for the DPI, it would calculate it from the resolution and the display size reported by X. I found that, on the test VM, with a resolution of 1024×768, xdpyinfo reported the display size as 270x203mm. The calculation uses the vertical values, so we get: 768 / (203 / 25.4) * 1024 = 98400.851231527 , which rounds up to 98401 – the gtk-xft-dpi value we found that boot.iso was using! Eureka.
and:
ou can press ctrl+shift+d (or ctrl+shift+i) in any running GTK+ 3 app to launch GtkInspector, a rather handy debugging tool. By clicking the GtkSettings ‘object’ and then going to ‘Properties’, we can see the relevant settings (down at the bottom): gtk-xft-antialias, gtk-xft-dpi, gtk-xft-hinting and gtk-xft-hintstyle.

Note: r11151 fixes windows 8.1 onwards "DPI awareness".

totaam · 2015-10-23T06:57:52Z

2015-10-23 06:57:52: antoine

totaam · 2015-10-23T06:57:52Z

2015-10-23 06:57:52: antoine

totaam · 2015-11-13T04:18:21Z

2015-11-13 04:18:21: antoine commented

Some of the data in this ticket may not be correct (done without logging out and logging back in with win32).

The correct and up to date information on DPI is now being moved to DPI, see also #1086.

totaam · 2015-11-13T04:18:21Z

2015-11-13 04:18:21: antoine

totaam · 2015-11-13T04:18:21Z

2015-11-13 04:18:21: antoine

totaam closed this as completed Oct 8, 2014

totaam mentioned this issue Apr 6, 2022

add new resolutions to Xdummy on the fly - dummy driver needs randr support added? #56

Closed

pass client DPI preference to server (and use sane defaults of 96dpi) #163

pass client DPI preference to server (and use sane defaults of 96dpi) #163

Comments

totaam commented Jul 12, 2012

2012-07-12 06:13:32: antoine created the issue

totaam commented Jul 24, 2012

2012-07-24 07:15:00: antoine commented

totaam commented Jul 24, 2012

2012-07-24 08:22:35: antoine commented

totaam commented Jul 30, 2012

2012-07-30 18:19:05: antoine commented

totaam commented Aug 1, 2012

2012-08-01 18:56:15: antoine commented

totaam commented Aug 1, 2012

2012-08-01 19:13:28: antoine commented

totaam commented Aug 1, 2012

2012-08-01 19:13:28: antoine

totaam commented Aug 1, 2012

2012-08-01 19:13:28: antoine

totaam commented Aug 1, 2012

2012-08-01 19:13:28: antoine

totaam commented Aug 1, 2012

2012-08-01 19:35:38: antoine commented

totaam commented Aug 3, 2012

2012-08-03 10:00:14: antoine changed status from new to closed

totaam commented Aug 3, 2012

2012-08-03 10:00:14: antoine changed resolution from ** to fixed

totaam commented Aug 3, 2012

2012-08-03 10:00:14: antoine commented

totaam commented Oct 16, 2012

2012-10-16 12:10:13: Sergio Callegari commented

totaam commented Oct 16, 2012

2012-10-16 12:11:03: Sergio Callegari changed status from closed to reopened

totaam commented Oct 16, 2012

2012-10-16 12:11:03: Sergio Callegari changed resolution from fixed to **

totaam commented Oct 16, 2012

2012-10-16 12:11:03: Sergio Callegari changed type from enhancement to defect

totaam commented Oct 16, 2012

2012-10-16 12:59:28: antoine changed status from reopened to closed

totaam commented Oct 16, 2012

2012-10-16 12:59:28: antoine changed resolution from ** to fixed

totaam commented Oct 16, 2012

2012-10-16 12:59:28: antoine commented

totaam commented Oct 16, 2012

2012-10-16 17:22:58: Sergio Callegari commented

totaam commented Nov 16, 2012

2012-11-16 09:14:31: http://eureka7.ru/ commented

totaam commented Nov 16, 2012

2012-11-16 09:14:31: antoine

totaam commented Nov 16, 2012

2012-11-16 09:14:31: antoine

totaam commented Nov 16, 2012

2012-11-16 17:14:25: antoine commented

totaam commented Nov 20, 2012

2012-11-20 05:54:32: http://eureka7.ru/ commented

totaam commented Nov 20, 2012

2012-11-20 13:07:15: antoine commented

totaam commented Dec 11, 2012

2012-12-11 17:41:44: antoine commented

totaam commented Mar 14, 2013

2013-03-14 08:47:35: leuko commented

totaam commented Mar 14, 2013

2013-03-14 08:47:35: leuko

totaam commented Mar 21, 2013

2013-03-21 17:05:10: antoine commented

totaam commented Nov 25, 2014

2014-11-25 01:43:56: afarr commented

totaam commented Jul 17, 2015

2015-07-17 03:54:21: totaam commented

totaam commented Oct 14, 2015

2015-10-14 05:46:02: antoine commented

totaam commented Oct 23, 2015

2015-10-23 06:57:52: antoine commented

totaam commented Oct 23, 2015

2015-10-23 06:57:52: antoine

totaam commented Oct 23, 2015

2015-10-23 06:57:52: antoine

totaam commented Nov 13, 2015

2015-11-13 04:18:21: antoine commented

totaam commented Nov 13, 2015