#163 closed defect (fixed)
pass client DPI preference to server (and use sane defaults of 96dpi)
Reported by: | Antoine Martin | Owned by: | alas |
---|---|---|---|
Priority: | blocker | Milestone: | 0.5 |
Component: | core | Version: | 0.3.2 |
Keywords: | Cc: |
Description
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.
Attachments (19)
Change History (68)
comment:1 Changed 9 years ago by
comment:2 Changed 9 years ago by
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.
comment:3 Changed 8 years ago by
Note: the Xft.dpi
is already sent to the server as part of _XSETTINGS_SETTINGS
.
comment:4 Changed 8 years ago by
Applications known to have problems (which I happen not to use...):
- emacs
- konsole
comment:5 Changed 8 years ago by
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
comment:6 Changed 8 years ago by
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 -
comment:7 Changed 8 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
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.
comment:8 Changed 8 years ago by
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.
comment:9 Changed 8 years ago by
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Type: | enhancement → defect |
comment:10 Changed 8 years ago by
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
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?
comment:11 Changed 8 years ago by
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.
comment:12 Changed 8 years ago by
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.
comment:13 Changed 8 years ago by
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.
comment:14 Changed 8 years ago by
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?
comment:15 Changed 8 years ago by
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.
comment:16 Changed 8 years ago by
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.
comment:17 Changed 8 years ago by
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.
comment:18 Changed 8 years ago by
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
comment:19 Changed 8 years ago by
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.
comment:20 Changed 8 years ago by
Resolution: | fixed |
---|---|
Status: | closed → reopened |
comment:21 Changed 7 years ago by
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.
comment:22 Changed 7 years ago by
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 fromDUMMYSwitchMode
?
comment:23 Changed 7 years ago by
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
Changed 7 years ago by
Attachment: | dummy-constant-dpi-option.diff added |
---|
same change with an xorg.conf option instead
Changed 7 years ago by
Attachment: | dummy-constant-dpi-option-ifdefed.diff added |
---|
same but with ifdef around randr code so dummy can be built without randr
Changed 7 years ago by
Attachment: | dummy-constant-dpi-option-ifdefed-constified.diff added |
---|
same but constified (cleaner)
Changed 7 years ago by
Attachment: | dummy-constant-dpi-v2.patch added |
---|
updated patch: use the system dpi (comes from DisplaySize? in dummy driver section of xorg.conf and falls back to Xorg -dpi value)
Changed 7 years ago by
Attachment: | fedora20-dummy-constant-dpi-specfile.patch added |
---|
updated patch with cleaner file context
Changed 7 years ago by
Attachment: | centos6.5-dummy-constant-dpi-specfile.patch added |
---|
centos 6.5 patch
comment:25 Changed 7 years ago by
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
Changed 7 years ago by
Attachment: | dummy-constant-dpi-v3.patch added |
---|
patch which allows the xDPI and yDPI to be overriden via a root window property
Changed 7 years ago by
Attachment: | 0002-Constant-DPI.2.patch added |
---|
updated version of the patch for use with rpm specfiles
Changed 7 years ago by
Attachment: | fedora19-dummy-constant-dpi-specfile.patch added |
---|
updated specfile patch for Fedora 19
Changed 7 years ago by
Attachment: | fedora20-dummy-constant-dpi-specfile.2.patch added |
---|
updated specfile patch for Fedora 20
Changed 7 years ago by
Attachment: | fedora21-dummy-constant-dpi-specfile.patch added |
---|
updated specfile patch for Fedora 21
Changed 7 years ago by
Attachment: | centos6-dummy-constant-dpi-specfile.patch added |
---|
updated specfile patch for CentOS 6.x
Changed 7 years ago by
Attachment: | redhat7-dummy-constant-dpi-specfile.patch added |
---|
updated specfile patch for RedHat? 7
Changed 7 years ago by
Attachment: | dummy_driver.c.whitespaced added |
---|
whitespace cleaned up version of the driver
comment:26 Changed 7 years ago by
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.
comment:27 Changed 7 years ago by
Note: the spec files are now living in svn here: browser/xpra/trunk/rpmbuild, see #605.
Changed 7 years ago by
Attachment: | centos7-dummy-constant-dpi-specfile.patch added |
---|
spec file patch for centos7
comment:28 Changed 6 years ago by
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..)
comment:29 Changed 6 years ago by
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.
comment:30 Changed 6 years ago by
Owner: | changed from Antoine Martin to alas |
---|---|
Status: | reopened → new |
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 theXft.dpi
, many other apps (ie: Java apps) will read the "hardware" dpi instead (as perxdpyinfo
)
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 byxdpyinfo
("hardware" dpi) - I don't see why not.
comment:31 Changed 6 years ago by
Well, now that I've beaten you to the testing, I've already found some issues, see #697.
Found some new DPI links:
comment:32 Changed 6 years ago by
Priority: | major → blocker |
---|
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).
comment:33 Changed 6 years ago by
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.
comment:34 Changed 6 years ago by
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.
comment:35 Changed 6 years ago by
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
Changed 6 years ago by
Attachment: | ticket163-DPI_181-xterm.PNG added |
---|
Manually set high DPI on local displays rendered in xpra session xterm frames, but not xterm content
comment:36 Changed 6 years ago by
@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)
comment:37 Changed 6 years ago by
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)
- 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).
Changed 6 years ago by
Attachment: | ticket163_firefox-fullscreen_windows0.15.0-r7847-client.PNG added |
---|
firefox fullscreen on 4K monitor displays mostly "offscreen"
comment:38 Changed 6 years ago by
- One additional note, testing again with 2560x1440 monitor (default 96 DPI), the fullscreen firefox video played as expected (same server session).
comment:39 Changed 6 years ago by
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)
comment:40 Changed 6 years ago by
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...)
comment:41 Changed 6 years ago by
adjusting the size slider with windows 8.1 does adjust the text/content size
(...)
nevertheless consistently outputswindow[].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..
comment:42 Changed 6 years ago by
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?
comment:43 Changed 6 years ago by
comment:44 Changed 6 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
I think we can close this for now.
comment:45 Changed 6 years ago by
- 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.
comment:48 Changed 5 years ago by
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".
Actually, looking at both Xdummy and
Xvfb
, I get reasonable values for the dpi:Xdummy
:Xvfb
: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...