Xpra trac archive

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

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.


Tue, 24 Jul 2012 06:15:00 GMT - Antoine Martin:

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

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...

Tue, 24 Jul 2012 07:22:35 GMT - Antoine Martin:

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.

Mon, 30 Jul 2012 17:19:04 GMT - Antoine Martin:

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

Wed, 01 Aug 2012 17:56:15 GMT - Antoine Martin:

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

Wed, 01 Aug 2012 18:13:27 GMT - Antoine Martin:

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

Wed, 01 Aug 2012 18:35:38 GMT - Antoine Martin:

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 -

Fri, 03 Aug 2012 09:00:13 GMT - Antoine Martin: status changed; resolution set

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.

Tue, 16 Oct 2012 11:10:13 GMT - Sergio Callegari:

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.

Tue, 16 Oct 2012 11:11:02 GMT - Sergio Callegari: status, type changed; resolution deleted

Tue, 16 Oct 2012 11:59:27 GMT - Antoine Martin: status changed; resolution set

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?

Tue, 16 Oct 2012 16:22:57 GMT - Sergio Callegari:

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.

Fri, 16 Nov 2012 09:14:30 GMT - rkfg:

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.

Fri, 16 Nov 2012 17:14:24 GMT - Antoine Martin:

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:

Tue, 20 Nov 2012 05:54:31 GMT - rkfg:

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?

Tue, 20 Nov 2012 13:07:15 GMT - Antoine Martin:

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.

Tue, 11 Dec 2012 17:41:44 GMT - Antoine Martin:

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.

Thu, 14 Mar 2013 08:47:34 GMT - leuko:

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.

Thu, 21 Mar 2013 17:05:10 GMT - Antoine Martin:

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)

Some related info:

Tue, 04 Jun 2013 09:03:17 GMT - Antoine Martin:

More applications seem to be affected: they are reading the dpi directly using xlib instead of Xft.dpi, see #347: evince for example.


I'm not convinced that the "-dpi 96" flag we pass to Xorg is particularly useful, with my 2560x1600 monitor I get:

(that's because the virtual size we define is Virtual 5120 3200)

Which is a bit closer to what we want, though this will vary: if I switch resolution to 1280x800 I then get: 

$ xdpyinfo | grep -i dots
resolution:    64x64 dots per inch

So... without adding randr support to the dummy driver, we cannot satisfy everyone, but I guess that removing "-dpi 96" at least makes it more likely that the dpi will be closer to what we really want? Feedback welcome.

Tue, 04 Jun 2013 09:07:32 GMT - Antoine Martin: status changed; resolution deleted

Thu, 10 Apr 2014 11:43:28 GMT - Antoine Martin:

For applications that query the X11 server directly, r6086 adds support for wiki/FakeXscreenmm. There are beta RPM builds of the library too.

This works with applications that use XDisplayWidthMM and XDisplayHeightMM but not (yet?) for those that use the macros DisplayWidthMM and DisplayHeightMM as those access the screen object directly... (so the output of xdpyinfo is still wrong for the "resolution" but now correct for the screen dimensions..) Java applications will still use the wrong value..

I may still remove this feature if I can find a better way to get the right dimensions in the X server, somehow.

Tue, 15 Apr 2014 02:39:01 GMT - Antoine Martin:

Far too few benefits for the costs, so removed in r6091.

Better options:

Tue, 15 Apr 2014 10:33:00 GMT - Antoine Martin:

It took a lot of effort (randr12 support is.. like going down the rabbit hole), but in the end the patch to dummy is rather small and simple!

I will try to add an option for this new dpi mode, then try to get it merged upstream. It would also be nice to be able to override the dpi value at runtime, which implies looking up the new dpi value somewhere, probably as an X11 property.


Note: these changes should also be very useful with HiDPI displays. (ie: "4K" displays are becoming popular)


Found an old (2003!) X11 discussion, still very relevant: DPI with multiple heads and virtual desktops

Tue, 15 Apr 2014 10:33:48 GMT - Antoine Martin: attachment set

improved patch: minimize diff

Tue, 15 Apr 2014 11:04:43 GMT - Antoine Martin: attachment set

same change with an xorg.conf option instead

Tue, 15 Apr 2014 11:21:55 GMT - Antoine Martin: attachment set

same but with ifdef around randr code so dummy can be built without randr

Tue, 15 Apr 2014 11:38:03 GMT - Antoine Martin: attachment set

same but constified (cleaner)

Tue, 15 Apr 2014 13:32:47 GMT - Antoine Martin: attachment set

updated patch: use the system dpi (comes from DisplaySize? in dummy driver section of xorg.conf and falls back to Xorg -dpi value)

Tue, 15 Apr 2014 14:46:12 GMT - Antoine Martin:

Sent latest patch to xorg-devel ML: "ConstantDPI" option

Wed, 16 Apr 2014 03:57:43 GMT - Antoine Martin: attachment set

patch as used by the spec files

Wed, 16 Apr 2014 03:58:12 GMT - Antoine Martin: attachment set

updated patch with cleaner file context

Wed, 16 Apr 2014 03:58:39 GMT - Antoine Martin: attachment set

centos 6.5 patch

Wed, 16 Apr 2014 04:16:57 GMT - Antoine Martin:

updated dummy packages have been built for all the distros above (centos 6.5, redhat7, fedora 20 and fedora rawhide): http://xpra.org/beta/

Trivial with the patches above, ie: for Fedora 20: 

yum install -y yum-utils
yumdownloader --source xorg-x11-drv-dummy
rpm -ivh xorg-x11-drv-dummy*rpm
cd;cd rpmbuild
yum-builddep SPECS/xorg-x11-drv-dummy.spec
patch -p1 < /usr/src/fedora20-dummy-constant-dpi-specfile.patch
cp /usr/src/0002-Constant-DPI.patch ./SOURCES/
rpmbuild -ba SPECS/xorg-x11-drv-dummy.spec

Fri, 18 Apr 2014 11:13:25 GMT - Antoine Martin: attachment set

patch which allows the xDPI and yDPI to be overriden via a root window property

Fri, 18 Apr 2014 15:22:44 GMT - Antoine Martin: attachment set

updated version of the patch for use with rpm specfiles

Fri, 18 Apr 2014 15:22:59 GMT - Antoine Martin: attachment set

updated specfile patch for Fedora 19

Fri, 18 Apr 2014 15:23:14 GMT - Antoine Martin: attachment set

updated specfile patch for Fedora 20

Fri, 18 Apr 2014 15:23:30 GMT - Antoine Martin: attachment set

updated specfile patch for Fedora 21

Fri, 18 Apr 2014 15:24:01 GMT - Antoine Martin: attachment set

updated specfile patch for CentOS 6.x

Fri, 18 Apr 2014 15:24:24 GMT - Antoine Martin: attachment set

updated specfile patch for RedHat? 7

Fri, 18 Apr 2014 15:56:17 GMT - Antoine Martin: attachment set

whitespace cleaned up version of the driver

Mon, 21 Apr 2014 08:41:01 GMT - Antoine Martin:

Also, on win32 it looks like we may want/need to do more work. See SetProcessDpiAwareness to declare that their application is DPI aware, and if so, Windows will not perform any scaling of the application. It’s then up to the application developers to decide how best to handle “non-standard” DPI settings. We probably want to do that no matter what, since the server is meant to have the same DPI settings the client should not attempt to scale anything.

Also: With the cropped image, you can instantly see that the font that Chrome is using is not scaling very well. Text in Chrome on a High DPI system is very poor, and defeats the purpose of using a high resolution screen since you actually lose fidelity rather than gain it.

And finally: To get around these issues, Microsoft has expanded the DPI API to allow for per-monitor DPI-aware applications. - the operating system will send a WM_DPICHANGED message to the application when most of the application’s area has moved to a display with a different DPI level (in Windows 8.1). We don't have per-display DPI with Xinerama, but we could just set the global DPI instead. I'm just not sure what "most" means in this context.. more than 50% of the pixels? This will need testing on Windows 7 or later with a display DPI > 120.

Sun, 20 Jul 2014 16:54:03 GMT - Antoine Martin:

Note: the spec files are now living in svn here: browser/xpra/trunk/rpmbuild, see #605.

Sun, 20 Jul 2014 16:57:14 GMT - Antoine Martin: attachment set

spec file patch for centos7

Mon, 15 Sep 2014 02:32:54 GMT - Antoine Martin:

Extra difficulty: it seems that GTK gets confused by rotated displays, as shown here: 

desktop size is 4720x3840 with 1 screen(s):
  ':0.0' (1187x965 mm) workarea: 4720x2295  - DPI: 101x101
    DVI-I-1 2560x1600 at 0x735 (646x406 mm - DPI: 100x100)
    DP-1 2160x3840 at 2560x0 (621x341 mm - DPI: 88x286)

The 'DP-1' display is rotated but the dimensions shown are not... and so our DPI calculations are off! (sadly, also true with GTK3..)

Mon, 22 Sep 2014 12:15:10 GMT - Antoine Martin:

As per Writing DPI-Aware Desktop and Win32 Applications (worth a read), I think we should use SetProcessDpiAwareness(Process_System_DPI_Aware).

Windows 8.1 has the ability to give us per-monitor DPI, and other nice things like Viewing distance incorporated in default DPI calculation (though this one may just obfuscate things), Window notification so we know to adjust DPI for a given window, etc..

Sadly, until X11 also supports per-monitor DPI, this won't be of much use to us.

Mon, 22 Sep 2014 14:48:00 GMT - Antoine Martin: owner, status changed

OK, I believe that the default "dpi-awareness" is "system-dpi-aware" (and only windows 8.1 onwards make use of the new "dpi-awareness" API, and we only have a single monitor anyway on the X11 server side), so we use the vista-onwards SetProcessDpiAware() API instead in r7747.

afarr: please bear in mind that:

Understanding the points above and their caveats:

Last minute thoughts:

Sun, 28 Sep 2014 16:05:15 GMT - Antoine Martin:

Well, now that I've beaten you to the testing, I've already found some issues, see #697. Found some new DPI links:

Sun, 28 Sep 2014 16:19:22 GMT - Antoine Martin: priority changed

Raising priority because of the issues in #697, we need to identify the problems and also see if we have similar problems with OSX (and this one I still cannot test).

Mon, 29 Sep 2014 04:17:56 GMT - Antoine Martin:

FWIW: as long as I set SetProcessDPIAware early enough (see r7823 and #697 for details), I get 144 (which is correct?) on my 4k monitor by calling: 

import ctypes, win32gui
gdi32=ctypes.windll.gdi32
dc = win32gui.GetDC(None)
print(gdi32.GetDeviceCaps(dc, LOGPIXELSX))
print(gdi32.GetDeviceCaps(dc, LOGPIXELSY))
win32gui.ReleaseDC(None, dc)

Which is the same value we get from GTK for the screen (not for the monitor!).

And here is something else which may be useful for testing / comparing: make older programs run in this version of windows: Disable display scaling on high DPI settings.

Tue, 30 Sep 2014 05:27:12 GMT - Antoine Martin:

I couldn't wait for this to get tested, so I hope my assumptions were correct. r7843 makes us honour the client DPI values detecting using the platform specific code, both as Xft.dpi (for applications that honour this) and as "hardware" DPI.

If that works OK, we can then deal with OSX:

Tue, 30 Sep 2014 23:55:26 GMT - alas:

Testing with r7840 clients the results looked a lot like those I posted in #697 (though the Xft.dpi indicated a 96 dpi after I had manually set it to, arbitrarily, 181). Testing again with r7847 clients everything looks like it's being read as expected (though I still feel like the Display1 read shouldn't be using the DPI of 72 no matter what it's set to for hardware... probably just an OCD tic).

I'll post outputs with the 2560x1440 monitor, in case anything looks wrong (went back as far as the 0.14.0 client/server for comparison... in case).

2560x1440 display DPI 181: 

2014-09-30 12:55:48,793 desktop size is 2560x1440 with 1 screen(s):
2014-09-30 12:55:48,795   '2\WinSta-Default' (359x202 mm)
2014-09-30 12:55:48,796     DISPLAY1 (903x508 mm)
2014-09-30 12:55:48,970 server: Linux Fedora 20 Heisenbug, Xpra version 0.14.0 (r7255)

xrdp -query | grep dpi -> returns nothing (not even error message that led me to figure out correct syntax with later build)

xdpyinfo | grep -i dots -> resolution: 30x34 dots per inch

Not scaled by OS (xterm frame is scaled up, but content within the frame isn't, making it look tiny).

rotated (looks good): 

2014-09-30 13:05:18,378 desktop size is 1440x2560 with 1 screen(s):
2014-09-30 13:05:18,381   '2\WinSta-Default' (202x359 mm)
2014-09-30 13:05:18,384     DISPLAY1 (508x903 mm)
2014-09-30 13:05:18,515 server: Linux Fedora 20 Heisenbug, Xpra version 0.14.0 (r7255)

2560x1440 display DPI 181: 

2014-09-30 13:31:33,976 desktop size is 2560x1440 with 1 screen(s):
2014-09-30 13:31:33,976   '2\WinSta-Default' (359x202 mm - DPI: 181x181)
2014-09-30 13:31:33,976     DISPLAY1 (903x508 mm - DPI: 72x72)
2014-09-30 13:31:34,197 server: Linux Fedora 20 Heisenbug, Xpra version 0.15.0 (r7794)

xrdp -query | grep dpi -> returns nothing (again)

xdpyinfo | grep -i dots -> resolution: 30x34 dots per inch

Not scaled by OS (xterm frame is scaled up, but content within the frame isn't, making it look tiny).

rotated (also looks good): 

2014-09-30 13:37:35,865 desktop size is 1440x2560 with 1 screen(s):
2014-09-30 13:37:35,865   '2\WinSta-Default' (202x359 mm - DPI: 181x181)
2014-09-30 13:37:35,867     DISPLAY1 (508x903 mm - DPI: 72x72)
2014-09-30 13:37:36,009 server: Linux Fedora 20 Heisenbug, Xpra version 0.15.0 (r7794)

2560x1440 display DPI 181: 

2014-09-30 13:49:26,119 desktop size is 2560x1440 with 1 screen(s):
2014-09-30 13:49:26,121   '2\WinSta-Default' (359x202 mm - DPI: 181x181) workarea: 2560x1372
2014-09-30 13:49:26,124     DISPLAY1 (903x508 mm - DPI: 72x72)
2014-09-30 13:49:26,342 server: Linux Fedora 20 Heisenbug, Xpra version 0.15.0 (r7840)

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

xdpyinfo | grep -i dots -> resolution: 30x34 dots per inch

Not scaled by OS (xterm frame is scaled up, but content within the frame isn't, making it look tiny).

rotated (also looks good): 

2014-09-30 14:06:11,706 desktop size is 1440x2560 with 1 screen(s):
2014-09-30 14:06:11,707   '2\WinSta-Default' (202x359 mm - DPI: 181x181) workare
a: 1440x2492
2014-09-30 14:06:11,711     DISPLAY1 (508x903 mm - DPI: 72x72)
2014-09-30 14:06:11,923 server: Linux Fedora 20 Heisenbug, Xpra version 0.15.0 (r7840)

2560x1440

DPI 181: 

2014-09-30 15:04:19,463 desktop size is 2560x1440 with 1 screen(s):
2014-09-30 15:04:19,463   '2\WinSta-Default' (359x202 mm - DPI: 181x181) workare
a: 2560x1372
2014-09-30 15:04:19,464     DISPLAY1 (903x508 mm - DPI: 72x72)
2014-09-30 15:04:19,690 server: Linux Fedora 20 Heisenbug, Xpra version 0.15.0 (r7847)

xrdb -query | grep dpi -> Xft.dpi: 181

xdpyinfo | grep -i dots -> resolution: 30x34 dots per inch

Still not scaled by OS (xterm frame is scaled up, but content within the frame isn't, making it look tiny).

Rotated (looks good): 

2014-09-30 15:19:56,470 desktop size is 1440x2560 with 1 screen(s):
2014-09-30 15:19:56,470   '2\WinSta-Default' (202x359 mm - DPI: 181x181) workarea: 1440x2492
2014-09-30 15:19:56,473     DISPLAY1 (508x903 mm - DPI: 72x72)
2014-09-30 15:19:56,631 server: Linux Fedora 20 Heisenbug, Xpra version 0.15.0 (r7847)

xpra info | grep client.screen 

2014-09-30 16:12:12,361 rencode at '/usr/lib64/python2.7/site-packages/rencode/__init__.pyc' lacks versioning information
client.screen[0].display=2\WinSta0\Default
client.screen[0].monitor[0].geometry=(0, 0, 2560, 1440)
client.screen[0].monitor[0].name=\\.\DISPLAY1
client.screen[0].monitor[0].size_mm=(903, 508)
client.screen[0].size=(2560, 1440)
client.screen[0].size_mm=(359, 202)
client.screen[0].workarea=(0, 0, 2560, 1372)
client.screens=1

Wed, 01 Oct 2014 01:12:24 GMT - alas: attachment set

Manually set high DPI on local displays rendered in xpra session xterm frames, but not xterm content

Wed, 01 Oct 2014 02:29:13 GMT - Antoine Martin:

@afarr: this image is as expected I think. Manually set high DPI on local displays rendered in xpra session xterm frames, but not xterm content

At least on Fedora. The exact font and dpi settings for xterm can be customized using:

So.. it is possible to get an xterm that uses a dpi aware font (bearing in mind that you must connect the client before running it): 

xterm -fa "Lucida" -fs 10

To see what size a window is, you can use: 

xpra info | grep -e "window.*\.size="

For the default "xterm", I always get 499 x 316, no matter what the dpi is set to.

Here are the sizes I get with the Lucida command line instead:

Note: r7852 makes it easier to disable SetProcessDPIAware using the environment variable XPRA_DPI_AWARE (use any value other than 1 to disable)

Wed, 01 Oct 2014 23:27:23 GMT - alas:

Testing with a windows 8.1 client using a 4K monitor:

The DPI detected seems to be correct: 

2014-10-01 11:50:15,138 desktop size is 3840x2160 with 1 screen(s):
2014-10-01 11:50:15,138   '1\WinSta-Default' (677x381 mm - DPI: 144x144) workarea:
3840x2104
2014-10-01 11:50:15,138     DISPLAY1 (621x341 mm - DPI: 157x160)
2014-10-01 11:50:15,323 server: Linux Fedora 20 Heisenbug, Xpra version 0.15.0 (r7847)

The DPI set in the session looks right: xrdb -query | grep dpi -> Xft.dpi: 144

xdpyinfo | grep -i dots -> resolution: 45x60 dots per inch

While the xterms don't seem to scale, other applications (like google-chrome) do scale... and with the DPI detection of Windows 8.1 they actually scale dynamically as the settings are changed. 

2014-10-01 15:58:53,983 unexpected message: WM_MOVE / 0 / 7340110
2014-10-01 15:58:54,964 sending updated screen size to server: 2880x1620 with 1
screens
2014-10-01 15:58:54,966   '1\WinSta-Default' (508x285 mm - DPI: 144x144) workare
a: 2880x1578
2014-10-01 15:58:54,967     DISPLAY1 (621x341 mm - DPI: 117x120)
2014-10-01 15:59:08,905 unexpected message: WM_MOVE / 0 / 8978535

Rotated displays don't seem to be problematic (switching to portrait and re-connecting produced this client output): 

2014-10-01 12:49:53,051 desktop size is 2160x3840 with 1 screen(s):
2014-10-01 12:49:53,052   '1\WinSta-Default' (381x677 mm - DPI: 144x144) workarea: 2160x3784
2014-10-01 12:49:53,052     DISPLAY1 (341x621 mm - DPI: 160x157)
2014-10-01 12:49:53,273 server: Linux Fedora 20 Heisenbug, Xpra version 0.15.0 (r7847)

... and seems to work even on the fly: 

2014-10-01 16:03:42,769 unexpected message: WM_MOVE / 0 / 14090300
2014-10-01 16:03:43,746 sending updated screen size to server: 2160x3840 with 1
screens
2014-10-01 16:03:43,746   '1\WinSta-Default' (381x677 mm - DPI: 144x144) workare
a: 2160x3784
2014-10-01 16:03:43,747     DISPLAY1 (341x621 mm - DPI: 160x157)

0.15.0 r7813 client (windows 8.1) - 0.15.0 r7794 server (fedora 20)
2014-10-01 15:22:48,138 desktop size is 2560x1440 with 1 screen(s):
2014-10-01 15:22:48,138   '1\WinSta-Default' (451x254 mm - DPI: 144x144)
2014-10-01 15:22:48,138     DISPLAY1 (621x341 mm - DPI: 104x107)
2014-10-01 15:22:48,319 server: Linux Fedora 20 Heisenbug, Xpra version 0.15.0 (r7794)
client.screen[0].display=1\WinSta0\Default
client.screen[0].monitor[0].geometry=(0, 0, 2560, 1440)
client.screen[0].monitor[0].name=\\.\DISPLAY1
client.screen[0].monitor[0].size_mm=(621, 341)
client.screen[0].size=(2560, 1440)
client.screen[0].size_mm=(451, 254)
client.screen[0].workarea=(0, 0, 2560, 1440)
client.screens=1
xrdb -query | grep dpi -> Xft.dpi: 96
xdpyinfo | grep -i dots -> resolution: 30x34 dots per inch

... Go to site with video, maximize video, use Esc key to un-maximize video.

Results in the loss of the browser's "outside frame", and with it the ability to un-maximize/resize page. (Might be result of pepper-flash plugin?)

Client-side CLI output: 

Traceback (most recent call last):
  File "xpra\client\client_window_base.pyc", line 237, in set_size_constraints
TypeError: apply_geometry_hints() takes exactly 2 arguments (1 given)
2014-10-01 13:00:00,595 with hints={}
Traceback (most recent call last):
  File "xpra\client\client_window_base.pyc", line 237, in set_size_constraints
TypeError: apply_geometry_hints() takes exactly 2 arguments (1 given)
2014-10-01 13:00:03,362 re-starting speaker because of overrun
2014-10-01 13:00:04,260 using audio codec: MPEG 1 Audio, Layer 3 (MP3)
2014-10-01 13:00:08,288 with hints={'min_width': 357, 'min_height': 82}
Traceback (most recent call last):
  File "xpra\client\client_window_base.pyc", line 237, in set_size_constraints
TypeError: apply_geometry_hints() takes exactly 2 arguments (1 given)
2014-10-01 13:00:08,289 with hints={'min_width': 357, 'min_height': 82}
Traceback (most recent call last):
  File "xpra\client\client_window_base.pyc", line 237, in set_size_constraints
TypeError: apply_geometry_hints() takes exactly 2 arguments (1 given)

... Meanwhile, testing with firefox, it looks like the fullscreen video is being rendered as oddly as the session info was being rendered previously (will include a screenshot, no sign of logging in client or server output).

Wed, 01 Oct 2014 23:34:09 GMT - alas: attachment set

firefox fullscreen on 4K monitor displays mostly "offscreen"

Thu, 02 Oct 2014 00:31:59 GMT - alas:

Thu, 02 Oct 2014 03:52:51 GMT - Antoine Martin:

Testing with a windows 8.1 client using a 4K monitor: (...) xrdb -query | grep dpi -> Xft.dpi: 144


OK, good.

xdpyinfo | grep -i dots -> resolution: 45x60 dots per inch


Ouch. That looks wrong. The DPI shown by xdpyinfo should also be the correct DPI. Are you sure that your Fedora server has the patched Xdummy driver? Check with rpm -qa | grep dummy

While the xterms don't seem to scale..


xterms should scale as per comment:36, does it not?

... other applications (like google-chrome) do scale... and with the DPI detection of Windows 8.1 they actually scale dynamically as the settings are changed. 2014-10-01 15:58:54,964 sending updated screen size to server: 2880x1620 with 1 screens


I don't understand what you did here. Did you change the resolution at that point? Or change the DPI? or what? We should always be detecting the correct, current, unscaled resolution. And this is not a 4k resolution. And more importantly: which is the "correct" DPI in the data shown? (and by correct, I mean: the one we should be using for rendering - whatever that may be..)

Rotated displays don't seem to be problematic (switching to portrait and re-connecting produced this client output): (...) ... and seems to work even on the fly:


OK, very good.

Connecting with or without opengl doesn't seem to make any difference, either with the new clients or the old, as far as DPI detection is concerned.


OK, this is expected - rendering happens much later, still good to confirm.

Older clients were definitely reading higher DPI incorrectly (Xpra menu placement was asurprise even after a warning) ... (...) desktop size is 2560x1440 with 1 screen(s):


This is the same as my query above. This is a scaled resolution and is part of the bug this ticket is meant to fix. Hence why I am wondering how you got 2560x1440 with the new code.

TypeError: apply_geometry_hints() takes exactly 2 arguments (1 given)


Moved to: ticket:263#comment:14 - should be fixed. Not sure if this was the cause of the missing "outside frame". Please confirm, and file another ticket for that if this is still a problem. (and link back to this one)

... Meanwhile, testing with firefox, it looks like the fullscreen video is being rendered as oddly as the session info was being rendered previously (will include a screenshot, no sign of logging in client or server output).


Oh, is this a regression caused by these changes? If not, this should go in a different ticket. (and link back to this one)

Thu, 02 Oct 2014 19:34:33 GMT - alas:

Are you sure that your Fedora server has the patched Xdummy driver?

As a matter of fact, I had an old xdummy driver... updated and ran xdpyinfo | grep -i dots... resolution: 144x144 dots per inch. Much better I'm sure.

xterms should scale as per comment:36, does it not?

I was actually just mentioning the xterms to contrast with the scaling behavior of the browsers (which were re-scaling dynamically as I adjusted the display's "Change the size of all items" slider, which appears to be the windows 8.1 version of the DPI manual adjustment option)... but re-examining more closely, it looks like adjusting the size slider with windows 8.1 does adjust the text/content size, as well as window frame size, of the displayed xterms, but xpra info | grep -e "window.*\.size=" nevertheless consistently outputs window[].size=(499, 316). Without the option of setting absurd custom DPI settings though, I'm not sure if scaling DPI upward would adjust the content size as well, or if it is only because the only options I'm seeing are adjusting the content toward a smaller size (which would be toward a higher DPI, if I haven't completely confused myself at this point).

I don't understand what you did here. Did you change the resolution at that point? Or change the DPI? or what?

As I mentioned above, I was adjusting the display's "item size slider" (for lack of a better name), and the output was reflecting the client-side output as the server detected the changes in the "display size" As a general rule I'm finding that the 3rd of 4 sizes is most comfortable on the eyes, which means that most of the shifting has been toward smaller display sizes.

xdpyinfo | grep -i dots => resolution: 144x144 dots per inch

xdpyinfo | grep -i dots => resolution: 144x144 dots per inch

xdpyinfo | grep -i dots => resolution: 144x144 dots per inch

xdpyinfo | grep -i dots => resolution: 230x184 dots per inch

Hence why I am wondering how you got 2560x1440 with the new code.

I didn't get that with the new code, I got it with the old. (You asked that we "verify that if older xpra versions do get scaled by the OS (maybe only when turning off opengl?), newer ones don't" ... this verified that the older version did scale down to the 2560x1440, while the new now recognizes the 4 apparent options that windows 8.1 offers for a 4K display.)

Fri, 03 Oct 2014 02:11:32 GMT - Antoine Martin:

adjusting the size slider with windows 8.1 does adjust the text/content size (...) nevertheless consistently outputs window[].size=(499, 316)


This means that windows 8.1 is upscaling the window for us. Which is very odd, because when we set SetProcessDpiAware, I thought it would just stop doing that, and stop lying to us!

"Change the size of all items"


Could well be the problem. Looks like I need to also install windows 8.1 somewhere to test. Oh joy.

And maybe use ​SetProcessDpiAwareness as well as ​SetProcessDpiAware..

4608x2592 5760x3240


!! That's way bigger than 4k! My guess is that windows is lying to the applications and downscaling when putting stuff on screen.


Hence why I am wondering how you got 2560x1440 with the new code.

I didn't get that with the new code, I got it with the old.

What about the data found in this comment? (comment:40) Is this with the new or old code? (me, totally confused now)


As for the firefox issue..


Please create a separate ticket for this one, and link back to this ticket. We need the usual: xpra info, compare with windows 7, windows 8, etc..

Fri, 03 Oct 2014 18:05:05 GMT - alas:

What about the data found in this comment? (comment:40)

Now I'm confused. In comment:40 the reference I made to the 2560x1440 monitor referred to me physically attaching a 2560x1440 display to the windows 8.1 machine to repeat the fullscreen test with firefox to see if it was just behavior related to the 4K display, or if it was somehow related to the windows 8.1 OS itself.

The mention of "2880x1620 with 1 screens" in one of the sets of output was what the client output interpreted the screen size as when I set the "size slider" to its "largest" setting.

The reference to "desktop size is 2560x1440 with 1 screen(s)" in comment:37 was the client-side output with the old (0.15.0 r7813 client) client code.

Was there another reference that I'm missing?

Tue, 07 Oct 2014 19:49:01 GMT - alas:

Well, that is odd.

Trying to reproduce the firefox issue with 0.15.0 r7897 win32 client (windows 8.1 w/4K monitor) vs. 0.15.0 r7897 server (fedora 20)... it seems to be completely solved and unreproduceable.

Nice work...

Wed, 08 Oct 2014 01:56:25 GMT - Antoine Martin: status changed; resolution set

I think we can close this for now.

Tue, 25 Nov 2014 01:43:56 GMT - alas: 

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.

Fri, 17 Jul 2015 02:54:21 GMT - Antoine Martin:

More DPI values recorded in ticket:885#comment:9

Wed, 14 Oct 2015 04:46:01 GMT - Antoine Martin:

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

Fri, 23 Oct 2015 05:57:51 GMT - Antoine Martin:

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".

Fri, 13 Nov 2015 04:18:20 GMT - Antoine Martin:

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 wiki/DPI, see also #1086.

Sat, 23 Jan 2021 04:47:15 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/163