Xpra: Ticket #697: gtk screen dimension detection is broken with high dpi displays on windows7 and later

This is causing no end of problems with:

etc.. probably more we haven't noticed yet.

A 4k monitor at 3840x2160 gives me this data:

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=(903, 508)
client.screen[0].size=(2560, 1440)
client.screen[0].size_mm=(451, 254)
client.screen[0].workarea=(0, 0, 2560, 1440)
client.screens=1

The DPI is set at 144x144. Even more strange is how the screen size is half the monitor size! The monitor DISPLAY1 claims to have a DPI of 72x72. We get the same problem with the GTK3 build.

This looks like what gdk-window-get-scale-factor is for, but we don't have working GTK 3.10 builds for win32... and until GTK3 reaches feature parity (#640), we need a workaround for GTK2 too. Also, as explained here: http://lwn.net/Articles/562287/#Comments:

If we can somehow figure out the scaling factor, the maybe we can tell gnome server side using Gdk/WindowScalingFactor}, see hidpi support in gnome. Some info on doing this for Linux gnome clients: https://bugzilla.gnome.org/show_bug.cgi?id=726238



Mon, 29 Sep 2014 03:33:38 GMT - Antoine Martin: owner, priority, status changed

The solution is not pretty: r7823 calls SetProcessDpiAware before loading GTK. That's because: SetProcessDPIAware must be called as soon as possible. That may be a problem for MFC applications, which execute their own code before InitInstance? is called., which I found here: Making your application DPI aware. This needs to be backported, and it's big...


Mon, 29 Sep 2014 08:27:28 GMT - Antoine Martin: owner, priority, status changed

Backport in r7829.

Please check on displays that have high dpi and verify that the reported screen dimensions were wrong before, but are now correct. (you can also see the tray menu popping up in the wrong place on those displays)

Raising to blocker as 0.14.8 is now overdue.


Mon, 29 Sep 2014 22:46:00 GMT - alas:

Testing with a 2560x1440 display... (have a line on a 4K, will post results once I have it set up).

I don't see any difference between the monitor[0].size_mm and the .size_mm numbers between a 0.15.0 r7840 client vs. a 0.15.0 r7813 client vs. a 0.14.0 r7276 client (except that the 0.14.0 doesn't explicitly indicate DPI settings).

Also, it looks like all DPI settings are being converted to 72x72.

2560x1440

96x96 DPI -> 72x72 DPI

2014-09-29 14:08:22,674 desktop size is 2560x1440 with 1 screen(s):
2014-09-29 14:08:22,677   '1\WinSta-Default' (677x381 mm - DPI: 96x96) workarea:
 2560x1400
2014-09-29 14:08:22,677     DISPLAY1 (903x508 mm - DPI: 72x72)
2014-09-29 14:08:22,901 server: Linux Fedora 20 Heisenbug, Xpra version 0.15.0 (r7840)
$ xpra info :23 | grep client.screen
2014-09-29 14:10:29,429 rencode at '/usr/lib64/python2.7/site-packages/rencode/__init__.pyc' lacks versioning information
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=(903, 508)
client.screen[0].size=(2560, 1440)
client.screen[0].size_mm=(677, 381)
client.screen[0].workarea=(0, 0, 2560, 1400)
client.screens=1

151x151 -> 72x72

2014-09-29 14:00:53,362 desktop size is 2560x1440 with 1 screen(s):
2014-09-29 14:00:53,364   '2\WinSta-Default' (430x242 mm - DPI: 151x151) workarea: 2560x1382
2014-09-29 14:00:53,365     DISPLAY1 (903x508 mm - DPI: 72x72)
$ xpra info :23 | grep client.screen
2014-09-29 14:04:40,351 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=(430, 242)
client.screen[0].workarea=(0, 0, 2560, 1382)
client.screens=1

96x96 -> 72x72

2014-09-29 14:39:10,480 desktop size is 2560x1440 with 1 screen(s):
2014-09-29 14:39:10,480   '1\WinSta-Default' (677x381 mm - DPI: 96x96)
2014-09-29 14:39:10,483     DISPLAY1 (903x508 mm - DPI: 72x72)
2014-09-29 14:39:10,710 server: Linux Fedora 20 Heisenbug, Xpra version 0.15.0 (r7794)
2014-09-29 14:42:05,033 rencode at '/usr/lib64/python2.7/site-packages/rencode/__init__.pyc' lacks versioning information
Warning: invalid option: 'scaling'
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=(903, 508)
client.screen[0].size=(2560, 1440)
client.screen[0].size_mm=(677, 381)
client.screen[0].workarea=(0, 0, 2560, 1440)
client.screens=1

151x151 -> 72x72

2014-09-29 14:51:48,585 desktop size is 2560x1440 with 1 screen(s):
2014-09-29 14:51:48,586   '2\WinSta-Default' (430x242 mm - DPI: 151x151)
2014-09-29 14:51:48,588     DISPLAY1 (903x508 mm - DPI: 72x72)
2014-09-29 14:51:48,812 server: Linux Fedora 20 Heisenbug, Xpra version 0.15.0 (r7794)
2014-09-29 14:53:59,885 rencode at '/usr/lib64/python2.7/site-packages/rencode/__init__.pyc' lacks versioning information
Warning: invalid option: 'scaling'
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=(430, 242)
client.screen[0].workarea=(0, 0, 2560, 1440)
client.screens=1

2560x1440

96x96

2014-09-29 15:08:31,973 desktop size is 2560x1440 with 1 screen(s):
2014-09-29 15:08:31,974   '1\WinSta-Default' (677x381 mm)
2014-09-29 15:08:31,976     DISPLAY1 (903x508 mm)
2014-09-29 15:08:32,147 server: Linux Fedora 20 Heisenbug, Xpra version 0.14.0 (r7255)
$ xpra info :23 | grep client.screen
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=(903, 508)
client.screen[0].size=(2560, 1440)
client.screen[0].size_mm=(677, 381)
client.screen[0].workarea=(0, 0, 2560, 1440)
client.screens=1

151x151

2014-09-29 15:02:55,022 desktop size is 2560x1440 with 1 screen(s):
2014-09-29 15:02:55,023   '2\WinSta-Default' (430x242 mm)
2014-09-29 15:02:55,023     DISPLAY1 (903x508 mm)
2014-09-29 15:02:55,197 server: Linux Fedora 20 Heisenbug, Xpra version 0.14.0 (r7255)
$ xpra info :23 | grep client.screen
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=(430, 242)
client.screen[0].workarea=(0, 0, 2560, 1440)
client.screens=1

Tue, 30 Sep 2014 02:28:03 GMT - Antoine Martin:

@afarr: to trigger this, you may need to set high DPI settings manually if your monitor configuration is not using high dpi: http://msdn.microsoft.com/en-us/library/dn469266(v=vs.85).aspx#appendix_a_setting_high_dpi_in_windows

An easier way of seeing the values we detect for the screen dimensions is to run GTK_info.exe on win32.

See also: #163, #559


Tue, 30 Sep 2014 02:52:45 GMT - Antoine Martin: summary changed

Edit title: I believe that the "wrong" dimensions reported only happens with windows 7 and later, and this is dpi related.


Tue, 30 Sep 2014 17:23:39 GMT - alas:

Sorry, the labeling I used was clear to me, but obviously only to me.

The sections above headed with 151x151 are output I got after manually resetting the DPI from the monitor's default of 96 up to 151 (a custom setting, arbitrarily chosen).

The sections headed by a 151x151 -> 72x72 were the sections where the output indicated that the Default Window (which read correct settings from the system) had a DPI of 151 but the Display then converted the DPI to 72.

I also found it interesting that your setting of DPI to 144 converted to 72, while my setting of 151 also converted to 72... so the half-value you noted above was actually a coincidence with your initial value, it looks like the Display isn't setting to half value but rather always setting to 72.

In the meantime, I've gotten my hands on a 4K monitor, but now I'm having to get tricky with a bootcamp in order to set up a system with both windows and a display port that will support a 4K monitor. Will have some output as soon as I can.


Wed, 01 Oct 2014 23:47:11 GMT - alas:

Looks like this is fixed in r7847 windows client (with 4K monitor).

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
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)
client.screen[0].display=1\WinSta0\Default
client.screen[0].monitor[0].geometry=(0, 0, 3840, 2160)
client.screen[0].monitor[0].name=\\.\DISPLAY1
client.screen[0].monitor[0].size_mm=(621, 341)
client.screen[0].size=(3840, 2160)
client.screen[0].size_mm=(677, 381)
client.screen[0].workarea=(0, 0, 3840, 2104)
client.screens=1
xrdb -query | grep dpi -> Xft.dpi: 144
xdpyinfo | grep -i dots => resolution: 45x60 dots per inch

Posted further results in #163.


Thu, 02 Oct 2014 04:05:48 GMT - Antoine Martin:

As per ticket:163#comment:39, your xpdyinfo looks wrong, it should report the "correct" DPI, the same value as Xft.dpi. Your server log should contain a line like this one:

DPI set to 144 x 144

Verify your patched dummy driver is installed correctly.

Also, I'm a bit lost between the "screen" dimension and DPI ("1\WinSta-Default") and the "monitor" values ("DISPLAY1"). Do you have any clue how they change and which one is the "right" one? Or rather how they relate to the physical attributes of the monitor and the various settings that influence the results we get from the OS? Bearing in mind that windows7 and windows8 and windows8.1 may all give slightly different results from each other.. Did you test any other windows version?


Thu, 02 Oct 2014 21:56:38 GMT - alas:

I updated the dummy driver and got: resolution: 144x144 dots per inch immediately.

As for the difference between the 1\WinSta-Default and the Display1 ... I don't have any clue either. From what I can discern (ganked the monitor from someone else, didn't do any research so I'm not sure what I was supposed to be expecting)... the default DPI should read at 144x144, and the system indicates that 3840x2160 is the recommended resolution (and top of the resolution options slider).

I suppose the workarea reduction has to do with the bottom menu/tray. I also surmise that, as I adjust the "size settings" slider the difference in relative real estate is being reflected in the output we're seeing, with the size "increasing" as I change DPI to make all the objects displayed "smaller"... and vice-versa. I have no idea if this is what you'd expect after looking at the api... but it's my best guess at making sense out of the output (based on a presupposition that the output is sensical in the first place - if there is a different expectation of "sensical", then I would guess that the output is problematic).

Comparing the behavior of the windows 7 output though (higher DPI seems to make the objects larger, thereby reducing the relative screen size), with the windows 8.1 (adjusting the size toward larger seems to be reducing the DPI, but likewise reducing the relative screen size)... I'm left confused how DPI is being used.

Win 8.1 doesn't explicitly mention the DPI, but the client output indicates that the DPI is smaller when the objects displayed are larger.

Adjusting the Win 7 "size slider" by using the Custom DPI Setting GUI, scaling objects from 96 DPI to 175 DPI is indicated as a 182% of normal size adjustment ... displaying objects at nearly double-size... but intuitively it feels like Dots Per Inch should go up if the object is smaller, rather than if it is larger. In this case, it appears that the DPI is larger when the objects displayed are larger.

I'm not sure what to tell you. Has there been a change in terminology between win 7 & 8?...


Fri, 03 Oct 2014 02:40:10 GMT - Antoine Martin: owner, status changed

I suppose the workarea reduction has to do with the bottom menu/tray


Yes, this one makes sense, I have added support for the win32 API called SPI_GETWORKAREA to get that information. At least something works..

The one I do not understand is how we go from 677x381 mm to 621x341 mm. I guess one of those values is going to be the real physical monitor dimensions (or close to it) as reported by the hardware directly, and the other will be an adjusted one that the OS makes up to match the DPI it wants us to use. My guess is that the first one is made up, as it is the one that gives us 144x144 (the same value I am also getting on my monitor, which is also double the 72x72 we've seen before - and having the exact same vertical and horizontal dpi is also a bit of a give away).


I'm left confused how DPI is being used.


You and me both.


From this ticket and #163, it looks to me like we cannot get windows 8.1 not to lie to us. So we will get some virtual screen resolution in some cases, and this will get upscaled or downscaled when rendered on screen by the OS. (upscaled is OK: it may look a bit blurry - but if that's how the OS is configured to look... downscaled is a waste of CPU and bandwidth for us - but this is probably quite rare)

I will take another look once I have installed windows 8.1


Thu, 04 Dec 2014 17:44:08 GMT - Antoine Martin: milestone changed

As per #163, I believe that we could use the actual physical screen dimensions using SetProcessDpiAwareness, this would reduce blurriness caused by client side window scaling.

This will become more of priority as Windows 8.1 and Windows 10 get deployed more widely, re-scheduling.

Until then, we will send the virtual screen dimensions and use that (which tends to be lower than the physical one - which is better for us, saving bandwidth).


Fri, 06 Feb 2015 23:57:15 GMT - alas:

Just as a note, with a 3840x2160 display (win 8.1 client 0.15.0 r8622 against fedora 20 0.15.0 r8601) I get the following server-side reading of display and dpi:

2015-02-06 15:36:17,453 client root window size is 3840x2160 with 1 displays:
2015-02-06 15:36:17,453   '1\WinSta-Default' (1016x571 mm - DPI: 96x96) workarea: 3840x2120
2015-02-06 15:36:17,453     DISPLAY1 (621x341 mm - DPI: 157x160) workarea: 3840x2120
2015-02-06 15:36:17,462 DPI set to 96 x 96
2015-02-06 15:36:17,508 sent updated screen size to 1 clients: 3840x2560 (max 8192x4096)

I do feel like the dpi should still be reading 144x144, but it does seem to be catching the right sized work area...


Thu, 05 Nov 2015 23:16:52 GMT - alas:

As a quick revisit, now that desktop-scaling is being used more, I ran the NativeGUI_info.exe on a windows 8.1 client with a variety of scaling settings, as well as xrdb -query | grep dpi & xdpyinfo | grep -i dots.

No matter the desktop-scaling settings, the NativeGUI_info.exe returned the same values (which is probably expected, now that I think about it):

* antialias.contrast               : 1200
* antialias.enabled                : True
* antialias.hinting                : True
* antialias.orientation            : RGB
* antialias.type                   : ClearType
* cursor_size                      : 32
* desktop_names                    : []
* desktops                         : 1
* double_click.distance            : (4, 4)
* double_click.time                : 500
* dpi.x                            : 96
* dpi.y                            : 96
* fixed_cursor_size                : (32, 32)
* icon_size                        : 16
* native_notifiers                 : ['Win32_Notifier']
* native_system_trays              : ['Win32Tray']
* native_tray_menu_helpers         : []
* native_trays                     : ['Win32Tray']
* system_bell                      : system_bell
* vertical-refresh                 : 29
* window_frame.border              : 1
* window_frame.caption             : 23
* window_frame.fixed               : (3, 3)
* window_frame.frame               : (8, 8, 31, 8)
* window_frame.menu-bar            : 20
* window_frame.minimum             : (140, 39)
* window_frame.normal              : (8, 8)
* window_frame.offset              : (8, 31)
* workarea                         : (0, 0, 5120, 2120)
* workareas                        : [(0, 0, 3840, 2120), (0, 0, 1280, 680)]

Since it is always outputting a DPI of 96 x 96, I suppose the 144 I had been expecting (and saw in several cases with the windows 7 client I used to use) isn't something I should continue to wonder about (?).

Meanwhile, the xrdb -query | grep dpi & xdpyinfo | grep -i dots output DPI which matches what the client and server are outputting with each desktop-scaling change.

Using the control panel to change the resolution of the 4K display (from 3840x2160 to 2048x1152) doesn't change the DPI read by the NativeGUI_info.exe, but it does successfully change the workarea(s):

* antialias.contrast               : 1200
* antialias.enabled                : True
* antialias.hinting                : True
* antialias.orientation            : RGB
* antialias.type                   : ClearType
* cursor_size                      : 32
* desktop_names                    : []
* desktops                         : 1
* double_click.distance            : (4, 4)
* double_click.time                : 500
* dpi.x                            : 96
* dpi.y                            : 96
* fixed_cursor_size                : (32, 32)
* icon_size                        : 16
* native_notifiers                 : ['Win32_Notifier']
* native_system_trays              : ['Win32Tray']
* native_tray_menu_helpers         : []
* native_trays                     : ['Win32Tray']
* system_bell                      : system_bell
* vertical-refresh                 : 29
* window_frame.border              : 1
* window_frame.caption             : 23
* window_frame.fixed               : (3, 3)
* window_frame.frame               : (8, 8, 31, 8)
* window_frame.menu-bar            : 20
* window_frame.minimum             : (140, 39)
* window_frame.normal              : (8, 8)
* window_frame.offset              : (8, 31)
* workarea                         : (0, 0, 3328, 1112)
* workareas                        : [(0, 0, 2048, 1112), (0, 0, 1280, 680)]

Likewise, xrdb -query | grep dpi & xdpyinfo | grep -i dots continue to output the DPI as adjusted by the scaling, same as the client/server output.

I suppose the failure of SetProcessDpiAwareness, mentioned in #976, is still biting us in the...?

Another interesting note though, I was poking into the control panel a bit more, and I discovered a slider at Control Panel\Appearance and Personalization\Display which is meant to "Make text and other items on the desktop smaller and larger." (I'll include a screenshot, in case the distinction between this page and the other display page is sounding like gibberish.) There are 5 discreet choices (so only just technically a slider, I suppose)... and while I usually have it on the left-most which makes all display contents "Smaller" - but moving to other settings, I find all the screen content becoming larger... but the NativeGUI_info.exe is still indicating 96 x 96 DPI. (Maybe windows 8.1 processes are actually DPI aware... but all DPI are pre-set to 96 x 96, so the awareness will be simpler?)


Thu, 05 Nov 2015 23:18:56 GMT - alas: attachment set

Screen shot of the display content size slider bar of windows 8.1


Sun, 08 Nov 2015 15:38:40 GMT - Antoine Martin: owner, status changed

Please re-test with r11151 (or later), which fixes windows 8.1 onwards "DPI awareness".


Tue, 10 Nov 2015 03:19:47 GMT - alas:

Ran all the same tests with 0.16.0 r11159 win32 (8.1) client against a 0.16.0 r11152 fedora 21 server (both from your repos).

Behavior looks exactly the same - NativeGUI_info.exe always lists as having a 96x96 DPI, but the workarea seems to reflect the changes in the display resolution, or in the slider to regulate "text and other items". On the other hand, xrdb -query | grep dpi & xdpyinfo | grep -i dots seem to reflect changes induced by scaling... but changes to display resolution or "making text of other items larger" doesn't seem to have any impact on the DPI listing for these queries server side either.

Maybe I'm just completely missing how the "DPI awareness" is supposed to work?... maybe 8.1 doesn't change DPI when adjusting screen resolution or sizing of "stuff" on the screen... it... adjusts the number of inches so that it doesn't have to use as many dots in order to reach the same DPI??


Tue, 10 Nov 2015 15:47:16 GMT - Antoine Martin:

That's odd, I would have expected the "awareness" to allow us to see the real DPI which is unlikely to be 96 in all cases, especially not on a 4k monitor. Maybe we need per-monitor-dpi-awareness, that would be using the env var:

XPRA_DPI_AWARENESS=2

(it defaults to 1 which is just plain "dpi awareness")


Thu, 12 Nov 2015 02:30:26 GMT - alas:

Well... maybe it's just me again... but XPRA_DPI_AWARENESS=2 doesn't seem to have any new effects.

Testing with windows client 0.16.0 r11185 against fedora 21 server 0.16.0 r11178...

I'll see about convincing maxmylyn to repeat these tests - maybe #817 isn't the only case in which my machine is being... potentially duplicitous?


Thu, 12 Nov 2015 03:14:34 GMT - Antoine Martin: attachment set

shows native gui info output with high dpi setting (144)


Thu, 12 Nov 2015 04:48:27 GMT - Antoine Martin:

As can be seen in the screenshot above (attachment/ticket/697/win8.1-dpi144.png), by setting "Change the size of all items" to "Larger", NativeGUI_info.exe "correctly" detects the DPI as being 144. I did have to logout and log back in after making this change.

If you still cannot get the DPI detected properly, we may have to add code to calculate it based on the reported screen resolution (yuk), and hope that this information is reliable enough. Does the reported width_mm and height_mm change? (when which setting is changed - only font size?, with all awareness settings? with all MS Windows versions?) Does it look like you can determine the DPI that way? (something like this: width//width_mm*25.4 / height//height_mm*25.4)


Thu, 12 Nov 2015 23:24:00 GMT - alas: owner changed

I did have to logout and log back in after making this change.

Err... right. I guess I should've paid more attention to that fine print.

After Logging out/in with the largest setting NativeGUI_info.exe gives me much more satisfactory output:

* antialias.contrast               : 1200
* antialias.enabled                : True
* antialias.hinting                : True
* antialias.orientation            : RGB
* antialias.type                   : ClearType
* cursor_size                      : 64
* desktop_names                    : []
* desktops                         : 1
* double_click.distance            : (4, 4)
* double_click.time                : 500
* dpi.x                            : 240
* dpi.y                            : 240
* fixed_cursor_size                : (64, 64)
* icon_size                        : 48
* native_notifiers                 : ['Win32_Notifier']
* native_system_trays              : ['Win32Tray']
* native_tray_menu_helpers         : []
* native_trays                     : ['Win32Tray']
* system_bell                      : system_bell
* vertical-refresh                 : 29
* window_frame.border              : 1
* window_frame.caption             : 56
* window_frame.fixed               : (3, 3)
* window_frame.frame               : (16, 16, 72, 16)
* window_frame.menu-bar            : 49
* window_frame.minimum             : (340, 88)
* window_frame.normal              : (16, 16)
* window_frame.offset              : (16, 72)
* workarea                         : (0, 0, 7040, 2072)
* workareas                        : [(0, 0, 3840, 2072), (0, 0, 3200, 1800)]

It still makes no sense that the dpi is larger - but it would appear that this is working after all. (Which is a very good thing, because my width_mm and height_mm were not changing as I adjusted scaling.)

I'm not sure if we still need to test XPRA_DPI_AWARENESS=2?


Fri, 13 Nov 2015 04:15:56 GMT - Antoine Martin: owner changed

It still makes no sense that the dpi is larger


Why not?


Which is a very good thing, because my width_mm and height_mm were not changing as I adjusted scaling


But that's correct! The mm (millimetre) size should not change unless the operating system is playing tricks to try to emulate a different "physical DPI" that some application may calculate themselves. (and we do do that on the server side with Xdummy) The width and height do change when you change resolution (by definition), which gives you a different DPI if you calculate it.


Now that you know that you have logout to apply the changes, we should ignore all previous data that was recorded without doing so. Let's collect some data and put it in a table on the new wiki/DPI page, then we can point all those tickets back to the correct data (and maybe delete or at least add a warning to the comments that include incorrect data).

The data should be recorded per operating system (and even per desktop environment for Linux..). The factors that may cause the DPI to change will vary, even from one version of Windows to another. (see wiki page) Also the type of monitor attached, and the number of monitors... XPRA_DPI_AWARENESS and XPRA_DPI_AWARE should also make a difference, and it would be good to know what - with the numbers. Also record the window_frame, cursors and antialias info, if it changes.


Fri, 13 Nov 2015 13:32:44 GMT - Antoine Martin: milestone changed


Wed, 18 Nov 2015 02:31:00 GMT - alas:

Updated the wiki/DPI with data from a pair of monitors with windows 8.1, and with both monitors together. Let me know if it looks like I missed anything (I have plenty more data that seemed superfluous and wasn't included).

I took a stab with OSX 10.9... and found that OSX is... uncooperative.

I'm looking into getting hold of a Windows 10 machine to try the same with, but it might take a little while.

Any use in testing the lot with windows 7? (I know the dpi functionality is completely different, which probably helped contribute to my missing the fine print after switching myself over to 8.1).

I'll try with both the XPRA_DPI_AWARENESS and XPRA_DPI_AWARE flags and post anything new I find... and I suppose close the ticket if I don't ind anything new?


Wed, 18 Nov 2015 07:50:54 GMT - Antoine Martin:

It will be very interesting to see what changes (if anything), when we change the value of XPRA_DPI_AWARENESS and XPRA_DPI_AWARE. The uncertainty surrounding this issue is the main reason why the DPI "fixes" have not been applied to v0.14.x and v0.15.x

Please also try to test with Windows 7 (or even 8.0), these versions do not have "awareness" only "aware" - so the results are expected to correspond to Windows 8.1 and later without "awareness" enabled... (it's not clear to me if "awareness" overrides or complements "aware")

As it is now, I think we can group the 3 monitor tables into one and just make a note that "fifth smallest" text size setting is not available on monitors smaller than ~4k. All these values are identical (for now - without "aware" / "awareness" tweaks): dpi, cursor size, frame info.

Those things vary per-monitor, rightly so, and can be kept in a separate per-monitor table: vrefresh (dictated by the monitor + card + cable combination), workarea.

Note: the vertical-refresh value shown on the server side is bogus but it shouldn't be too much of a problem as application are not meant to use this for anything.


Thu, 19 Nov 2015 20:48:49 GMT - alas: owner changed

Ok... went through all the permutations of XPRA_DPI_AWARENESS values and XPRA_DPI_AWARE values (0.16.0 r11185 client & server).

It looks like XPRA_DPI_AWARENESS is definitely not working - setting to 0/1/2 made absolutely no difference to output, whether or not it was combined with XPRA_DPI_AWARE values.

XPRA_DPI_AWARE, however, does change values when set to 0. I went ahead and posted values (as well as output messages for each indicating that the DPI values were being overriden) in the wiki.

I only included a chart with each of the displays, since the only values that changed when both displays were connected (vs. the values with just the 4K Dell display in the table) was to the DPI of the second display, and the total workarea (I can include those values as well, if you think it will be useful).

Passing this back to you at this point, to decide what you want to do about the failure of the DPI_AWARENESS. (Meanwhile, I'll add data for windows 7 and 10 as soon as I get the chance.)


Sun, 22 Nov 2015 09:48:17 GMT - Antoine Martin: owner changed

I have just spent a considerable amount of time re-working the data to normalize things and make it more presentable (as I mentioned in comment:23) - mostly a matter of de-duplicating things. Quality over quantity. Large tables with too much data just confuse things. See here: wiki/DPI/Data. Once all the data is well presented there, we can remove the data section from wiki/DPI.

I am not going to do anything about XPRA_DPI_AWARENESS until we at least get a handle on XPRA_DPI_AWARE.


Wed, 02 Dec 2015 02:26:56 GMT - alas:

Ok, finally got a chance to chew on the difference between our tables a bit.

After testing some with the checkbox to set both (all) displays to the same DPI, I think I might have suddenly seen some hint of light/inspiration... and I'll try some further settings with XPRA_DPI_AWARENESS=0, =1, & =2 and see if I can find something that it affects.


Sat, 05 Dec 2015 01:09:34 GMT - alas:

Interestingly, with the same windows 8.1 setup, no matter how I try to massage the interface, I can't seem to change the dpi on a per-monitor basis, whether or not I check the box that is supposed to give me the option to set the dpi of all monitors at once.

I'll check the results with the box checked more thoroughly and chart out whatever seems interesting about that data, as well as charting out the same with a windows 7 system with local dpi adjusted to the same settings as with the windows 8.1 listed above once I get the chance. (Looks mostly the same with windows 7, but there seem to be some issues with the dpi.randr immediately after changing the local scaling... which then disappear when I try to repro... will pin that down. Also, looks like the windows 7 monitor dpi settings are read very differently, even when connecting on same monitor as with a windows 8.1).

As part of my experimenting with per-monitor dpi settings though, I tried setting the smaller monitor in the setup I've been using thus far as the default. The dpi readings, both workarea and per display, behaved as expected... but it looks like the per display workarea is being confused when detected by xpra.

Below is the client-side output with local dpi set at 100%, but with the 1280x720 display (display 2 in the output) set as the primary monitor. I went through all the local dpi settings and, unsurprisingly, found the output to be consistently... similar.

2015-12-03 14:52:44,671  desktop size is 5120x2160 with 1 screen:
2015-12-03 14:52:44,671   21\WinSta-Default (1354x571 mm - DPI: 96x96) workarea: 5120x2120
2015-12-03 14:52:44,671     DISPLAY2 1280x720 (597x336 mm - DPI: 54x54) workarea: 3840x2120
2015-12-03 14:52:44,671     DISPLAY1 3840x2160 at 1280x0 (621x341 mm - DPI: 157x160) workarea: 1280x680
2015-12-03 14:52:44,763 Xpra X11 server version 0.16.0-r11342
2015-12-03 14:52:44,763  running on Linux Fedora 21 Twenty One
2015-12-03 14:52:44,779 Attached to tcp:10.0.32.136:2200 (press Control-C to detach)
2015-12-03 14:52:46,013 sound output using audio codec: MPEG 1 Audio, Layer 3 (MP3)
2015-12-03 15:11:44,957 setting scaling to 125%:
2015-12-03 15:11:44,957 sending updated screen size to server: 4096x1728 with 1 screens
2015-12-03 15:11:44,957   21\WinSta-Default (1354x571 mm - DPI: 76x76) workarea: 4096x1696
2015-12-03 15:11:44,957     DISPLAY2 1024x576 (597x336 mm - DPI: 43x43) workarea: 3072x1696
2015-12-03 15:11:44,957     DISPLAY1 3072x1728 at 1024x0 (621x341 mm - DPI: 125x128) workarea: 1024x544
2015-12-03 15:12:36,750 setting scaling to 150%:
2015-12-03 15:12:36,750 sending updated screen size to server: 3413x1440 with 1 screens
2015-12-03 15:12:36,750   21\WinSta-Default (1354x571 mm - DPI: 64x64) workarea: 3413x1413
2015-12-03 15:12:36,750     DISPLAY2 853x480 (597x336 mm - DPI: 36x36) workarea: 2560x1413
2015-12-03 15:12:36,750     DISPLAY1 2560x1440 at 853x0 (621x341 mm - DPI: 104x107) workarea: 853x453
2015-12-03 15:12:49,334 setting scaling to 200%:
2015-12-03 15:12:49,334 sending updated screen size to server: 2560x1080 with 1 screens
2015-12-03 15:12:49,334   21\WinSta-Default (1354x571 mm - DPI: 48x48) workarea: 2560x1060
2015-12-03 15:12:49,334     DISPLAY2 640x360 (597x336 mm - DPI: 27x27) workarea: 1920x1060
2015-12-03 15:12:49,334     DISPLAY1 1920x1080 at 640x0 (621x341 mm - DPI: 78x80) workarea: 640x340
2015-12-03 15:13:09,749 setting scaling to 300%:
2015-12-03 15:13:09,749 sending updated screen size to server: 1707x720 with 1 screens
2015-12-03 15:13:09,749   21\WinSta-Default (1354x571 mm - DPI: 32x32) workarea: 1707x707
2015-12-03 15:13:09,749     DISPLAY2 427x240 (597x336 mm - DPI: 18x18) workarea: 1280x707
2015-12-03 15:13:09,749     DISPLAY1 1280x720 at 427x0 (621x341 mm - DPI: 52x53) workarea: 427x227

It looks like the detection is becoming confused at the idea of a primary display being smaller (or maybe at the idea of display2 being a primary?) and half-transposing values.


Sat, 05 Dec 2015 08:03:10 GMT - Antoine Martin:

The mismatch between the individual displays and their detected workarea is now fixed in r11356 (will backport). It might be a good idea to completely bypass GTK for display detection, but this will do for now.


Tue, 08 Dec 2015 02:20:20 GMT - alas:

r11357 confirms fix for mismatch between displays and workareas.

Updated a number of charts at wiki/DPI & wiki/DPI/Data to clean up some of the extraneous fields, eliminate "XXX Smallest" nomenclature, and added both windows 7 charts and some more info about taskbar sizing effects when invoking desktop-scaling.

Windows 7 chart with XPRA_DPI_AWARE=0, at 125% local scaling in particular, shows some very odd data, but I saw it again when double checking.

There was another issue with the windows 7 scaling that is just subtle enough that I thought I was just losing my mind.

When shifting from the 100% local scaling to the 125%, the dpi.x, etc. shifts from 96 to 120... but the first time I connect and use python /usr/lib64/python2.7/site-packages/xpra/platform/gui.py, the dpi.randr reads as (96, 96) still. If I use shift-alt-+ to scale though, then scale back... it displays as (120,120), matching all the other dpi values.

Likewise, if I then change the local scaling back to 100%, then the first time I try the gui.py, the dpi.randr reads as (120,120), despite all the rest of the dpi settings indicating 96. Also, again, invoking desktop-scaling up then back, it will display again at (96, 96) as expected.

I can't help but wonder if whatever that is might be influencing those values in the XPRA_DPI_AWARE=0 chart... but I went through a number of scaling options with that, and it didn't seem to "fix" the values to something more consistent with the other dpi settings.

With that fix to the swapped values though, there isn't much more interesting things to chart. Hopefully those fixed charts look nice enough to be consolidated?... if there's some other fixing you'd like though, let me know.


Wed, 09 Dec 2015 00:09:38 GMT - alas: owner changed

Assigning this back to you, antoine, to decide if the charts seem complete enough for your purposes at this point.

I'm thinking that those charts of the second half of the wiki/DPI page should probably go into the wiki/DPI/Data page, both with XPRA_DPI_AWARE=1 & =0, but I wanted to check with you that the fields are all still relevant/desired. (I also added a field to the XPRA_DPI_AWARE=0 chart for the windows 7 client for the Taskbar, just because it seemed to be behaving rather erratically... which should maybe be migrated to the Taskbar chart on the wiki/DPI/Data page as a separate column?)

Let me know your thoughts and I'll handle the (hopefully brief) tedium of migrating data.


Sun, 13 Dec 2015 07:53:17 GMT - Antoine Martin: owner changed

I've moved "cursor size" to its own section since it only changes with the DPI, no need to repeat it everywhere.

The desktop-scaling values has very little to do with this: first and foremost, we want to understand what the OS gives us, and how the OS settings affect us. (desktop-scaling is an xpra feature, which we use to then cook those values). I've left it on the data page, but moved it to its own section. If we ever calculate the wrong server-DPI with desktop scaling then this needs to go in #976.

Why did you add more data to wiki/DPI?, as I said in comment:25, the idea is to have more presentable / succinct data here instead: wiki/DPI/Data. I want to summarize and completely remove those long tables, not make them bigger. This makes it very difficult to know what has already been moved to the new page and what hasn't.

PS: just found another thing that would cause problems if we didn't enable dpi aware(ness): we use GetPhysicalCursorPos.


Mon, 14 Dec 2015 19:59:18 GMT - alas:

The changes I made to wiki/DPI were just editing of the old tables to eliminate extraneous fields and to eliminate the "XXX smallest" nomenclature... and the added tables are just the windows 7 data.

It seemed like that page would make a good "staging" area to look at charts before moving the data to the wiki/DPI/Data page. So that is where I put the windows 7 charts with the mix of local and desktop scaling data... so it could be looked at before deciding exactly what to do with it (or not to do with it, as might be the case).

The extra entries to the Taskbar size chart were added to answer the question in the header about what influence scaling might have on the taskbar size. (Perhaps that additional data should be moved to wherever the other charts with the mix of local and desktop scaling land, and the Taskbar size without the additional wrinkle of desktop scaling should remain on the wiki/DPI/Data page?)

Looking at the tables as they stand now - it looks (to me) like:


Mon, 11 Jan 2016 22:29:10 GMT - alas: owner changed

Went ahead and removed redundant window_frame charts from wiki/DPI, as well as the charts with all of the workarea and cursor size effects of scaling, both local and desktop-.

Added a link to the Links section to point to wiki/DPI/Data for users to see the charts that seem to still be useful.

Seem to have lost the charts I'd massaged with a slightly more cogent set of charts to show all the effects of local & dektop- scaling interactions and expectations when mixed with XPRA_DPI_AWARE setting options... but there didn't seem to be a lot of interest in any case.

Handing this back to you to glance at and decide if I missed anything.

If you do think that a set of charts with examples of the effects of mixing the local scaling, desktop scaling, XPRA_DPI_AWARE/NESS settings, etc. would be of use, let me know — I saved the charts I deleted and can re-massage them relatively easily, at least until I lose this copy as well.


Tue, 12 Jan 2016 02:49:03 GMT - Antoine Martin: status changed; resolution set

This will do for 0.16, will follow up in #1086.


Sat, 23 Jan 2021 05:03:17 GMT - migration script:

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