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.
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...
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.
Note: the Xft.dpi
is already sent to the server as part of _XSETTINGS_SETTINGS
.
Applications known to have problems (which I happen not to use...):
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
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 -
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.
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.
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?
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.
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.
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:
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?
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.
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.
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.
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:
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:
-dpi 96
:
$ xdpyinfo | grep -i dots resolution: 48x48 dots per inch
(that's because the virtual size we define is Virtual 5120 3200
)
$ 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.
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.
Far too few benefits for the costs, so removed in r6091.
Better options:
RRScreenSizeNotify
with the newly calculated mm values from DUMMYSwitchMode
?
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
improved patch: minimize diff
same change with an xorg.conf option instead
same but with ifdef around randr code so dummy can be built without randr
same but constified (cleaner)
updated patch: use the system dpi (comes from DisplaySize? in dummy driver section of xorg.conf and falls back to Xorg -dpi value)
Sent latest patch to xorg-devel ML: "ConstantDPI" option
patch as used by the spec files
updated patch with cleaner file context
centos 6.5 patch
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
patch which allows the xDPI and yDPI to be overriden via a root window property
updated version of the patch for use with rpm specfiles
updated specfile patch for Fedora 19
updated specfile patch for Fedora 20
updated specfile patch for Fedora 21
updated specfile patch for CentOS 6.x
updated specfile patch for RedHat? 7
whitespace cleaned up version of the driver
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.
Note: the spec files are now living in svn here: browser/xpra/trunk/rpmbuild, see #605.
spec file patch for centos7
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..)
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.
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:
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:
':0.0' (1187x965 mm) workarea: 4720x2295 - DPI: 101x101
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
Last minute thoughts:
dpi
switch to also affect the dpi reported by xdpyinfo
("hardware" dpi) - I don't see why not.
Well, now that I've beaten you to the testing, I've already found some issues, see #697. Found some new DPI links:
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).
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.
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:
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
Manually set high DPI on local displays rendered in xpra session xterm frames, but not xterm content
@afarr: this image is as expected I think.
At least on Fedora. The exact font and dpi settings for xterm can be customized using:
/etc/X11/Xresources
config file, and maybe also /etc/X11/Xresources/xterm
~/.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:
Note: r7852 makes it easier to disable SetProcessDPIAware
using the environment variable XPRA_DPI_AWARE
(use any value other than 1 to disable)
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).
firefox fullscreen on 4K monitor displays mostly "offscreen"
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)
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.
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
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
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
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
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.)
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..
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?
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...
I think we can close this for now.
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.
More DPI values recorded in ticket:885#comment:9
See also: ticket:976#comment:15 and r10832.
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".
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.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/163