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

[Antoine Martin]

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.

[Antoine Martin]

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

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

[Antoine Martin]

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

[Antoine Martin]

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

• emacs
• konsole

[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

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

[Antoine Martin]

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.

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

[Antoine Martin]

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?

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

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

[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:

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

[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?

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

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

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

[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:

• ​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

[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:

• with -dpi 96:

  $ xdpyinfo | grep -i dots
  resolution:    48x48 dots per inch
  

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

• without it:

  $ xdpyinfo | grep -i dots
  resolution:    128x128 dots per inch
  

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.

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

[Antoine Martin]

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

Better options:

• add randr 1.2 support to dummy, as per ​this patch for Xvfb
• make the dummy driver call RRScreenSizeNotify with the newly calculated mm values from DUMMYSwitchMode?

[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

[Antoine Martin]

improved patch: minimize diff

[Antoine Martin]

same change with an xorg.conf option instead

[Antoine Martin]

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

[Antoine Martin]

same but constified (cleaner)

[Antoine Martin]

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

[Antoine Martin]

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

[Antoine Martin]

patch as used by the spec files

[Antoine Martin]

updated patch with cleaner file context

[Antoine Martin]

centos 6.5 patch

[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 

[Antoine Martin]

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

[Antoine Martin]

updated version of the patch for use with rpm specfiles

[Antoine Martin]

updated specfile patch for Fedora 19

[Antoine Martin]

updated specfile patch for Fedora 20

[Antoine Martin]

updated specfile patch for Fedora 21

[Antoine Martin]

updated specfile patch for CentOS 6.x

[Antoine Martin]

updated specfile patch for RedHat? 7

[Antoine Martin]

whitespace cleaned up version of the driver

[Antoine Martin]

Also, on win32 it looks like we may want/need to do more work. See ​AnandTech: Scaling Windows - The DPI Arms Race: Developers can call ​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.

[Antoine Martin]

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

[Antoine Martin]

spec file patch for centos7

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

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

[Antoine Martin]

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:

• you must have the updated dummy drivers installed server side for our DPI code to work (should already be the case)
• XP is probably not very relevant here, and every version of windows does things slightly differently - please read ​Writing DPI-Aware Desktop and Win32 Applications
• you probably need a DPI above 120 to trigger automatic scaling on win32 - either set it manually, or using a hidpi display
• opengl windows may or may not be affected by this scaling (and for that matter, maybe even non-opengl windows - in which case the change above does nothing at all)
• we only have a single DPI value... so with multiple monitors, we end up with an average value
• fontmatrix is a good little app that honours the Xft.dpi, many other apps (ie: Java apps) will read the "hardware" dpi instead (as per xdpyinfo)

Understanding the points above and their caveats:

• verify that the DPI we detect is "correct" (the one that is set - more or less) - that's the value that gets printed as per comment:28 ':0.0' (1187x965 mm) workarea: 4720x2295 - DPI: 101x101
• verify that we then set the correct DPI in the xpra session, using:
  • xrdb -query | grep dpi (note this value may actually be different from the "real" DPI with Linux clients because we sync the xrdb database for those, and so we mirror this setting.. unless the --dpi flag is used - confusing!)
  • xdpyinfo | grep -i dots
• verify that if older xpra versions do get scaled by the OS (maybe only when turning off opengl?), newer ones don't
• do we have problems with rotated displays? (detecting size and orientation, dpi, etc)

Last minute thoughts:

• we could also add a runtime tray option to change the DPI.
• do we want the dpi switch to also affect the dpi reported by xdpyinfo ("hardware" dpi) - I don't see why not.

[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:

• ​xserver forces 96 DPI on randr-1.2-capable drivers, overriding correct autodetection
• ​Please add option to avoid forcing of 96dpi

[Antoine Martin]

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

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

[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:

• ​High Resolution Guidelines for OS X
• ​Retina display support for Mac OS, iOS and X11
• ​Mac OS X HighDPI mode is not visible to NPAPI plugins via OS APIs
• ​How to simulate a retina display (HiDPI mode) in Mac OS X 10.8 Mountain Lion on a non-retina display?
• ​NSView OpenGL Additions Reference: Apps that want to take advantage of the higher pixel density on high-resolution displays need to opt-in to get a high-resolution backing surface.

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

• 0.14.0 r7276 client (windows 7) - 0.14.0 r7255 server (fedora 20)

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)

---

• 0.15.0 r7813 client (windows 7) - 0.15.0 r7794 server (fedora 20)

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)

---

• 0.15.0 r7840 client (windows 7) - 0.15.0 r7840 server (fedora 20)

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)

---

• 0.15.0 r7847 client (windows 7) - 0.15.0 r7847 server (fedora 20)

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

[alas]

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

[Antoine Martin]

@afarr: this image is as expected I think.

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

• the command line
• /etc/X11/Xresources config file, and maybe also /etc/X11/Xresources/xterm
• the per user version ~/.Xresources

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:

• with DPI set to 101: 659 x 388
• with DPI set to 144: 979 x 580

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

[alas]

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

• 0.15.0 r7847 client vs. 0.15.0 r7847 fedora 20 server:

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)

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

• Older clients were definitely reading higher DPI incorrectly (Xpra menu placement was asurprise even after a warning) ...

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

• Note, I did manage to break a google-chrome browser with the newer revision:

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

[alas]

firefox fullscreen on 4K monitor displays mostly "offscreen"

[alas]

• One additional note, testing again with 2560x1440 monitor (default 96 DPI), the fullscreen firefox video played as expected (same server session).

[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)

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

• Note, on the windows 8.1 slider there are only 4 settings, and apparently no support for custom settings (or at least not that I've found so far).

• Testing more carefully with a 4K monitor, adjusting statically before connection, I get the following:

• The "largest" setting gives this output:

  2014-10-02 11:39:06,503 sending updated screen size to server: 2880x1620 with 1
  screens
  2014-10-02 11:39:06,503   '1\WinSta-Default' (508x285 mm - DPI: 144x144) workarea: 2880x1578
  2014-10-02 11:39:06,505     DISPLAY1 (621x341 mm - DPI: 117x120)
  

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

• 2nd largest:

  2014-10-02 11:56:45,641 desktop size is 3840x2160 with 1 screen(s):
  2014-10-02 11:56:45,641   '1\WinSta-Default' (677x381 mm - DPI: 144x144) workarea: 3840x2104
  2014-10-02 11:56:45,641     DISPLAY1 (621x341 mm - DPI: 157x160)
  

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

• 3rd largest:

  2014-10-02 11:44:16,207 sending updated screen size to server: 4608x2592 with 1
  screens
  2014-10-02 11:44:16,209   '1\WinSta-Default' (812x457 mm - DPI: 144x144) workarea: 4608x2525
  2014-10-02 11:44:16,209     DISPLAY1 (621x341 mm - DPI: 188x193)
  

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

• 4th largest (aka smallest):

  2014-10-02 11:48:52,930 sending updated screen size to server: 5760x3240 with 1
  screens
  2014-10-02 11:48:52,931   '1\WinSta-Default' (1016x571 mm - DPI: 144x144) workarea: 5760x3183
  2014-10-02 11:48:52,931     DISPLAY1 (621x341 mm - DPI: 235x241)
  

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

• Oddly, adjusting dynamically gives the same output for changes, except when changing back to the original "size slider" setting, upon which adjustment the client doesn't output any new information (though the displayed size adjusts as expected).

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

• As for the firefox issue, since it doesn't happen on a 2560x1440 monitor at fullscreen with the same client (but windows 7 vs. 8.1) and not only the same server but when connecting to the same server session, I assume it is a regression. (Just to be thorough, I switched the 8.1 machine to the 2560x1440 display, and the fullscreen video played as expected... so it is either a regression with the new changes as they affect play on 4K monitors, or the lack of significant testing on firefox with 4K monitors previously just resulted in us never finding it before...)

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

[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?

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

[Antoine Martin]

I think we can close this for now.

[alas]

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

[Antoine Martin]

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

[Antoine Martin]

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

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

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