gtk screen dimension detection is broken with high dpi displays on windows7 and later

[totaam]

This is causing no end of problems with:

• the tray menu popping up in the wrong place
• server vfb size is wrong
• DPI is wrong pass client DPI preference to server (and use sane defaults of 96dpi) #163
  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: In GTK/Linux, what's the correct way to get the DPI scale factor?, having the scale factor as an integer is bizarre and unhelpful. (though looking at the code, maybe the docs are wrong). See also: [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]

[totaam]

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

[totaam]

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.

[totaam]

2014-09-29 23:46:00: afarr commented

---

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

• With 0.15.0 r7840 win7 client and fedora 20 server

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](../commit/9e6bc9f14899c2d8c952b77fb57a449ec4dd21f4))

$ 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

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

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](../commit/e389cb8c9e2c568302277b058fa15db35e52ef08))

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](../commit/e389cb8c9e2c568302277b058fa15db35e52ef08))

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

• 0.14.0 7276 client (windows 7) 0.14.0 r7255 server (fedora 20)

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](../commit/3f194261beec4cdccb7c23369b69faf20fca2db1))

$ 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](../commit/3f194261beec4cdccb7c23369b69faf20fca2db1))

$ 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

[totaam]

@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

[totaam]

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

[totaam]

2014-09-30 18:23:39: afarr commented

---

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.

[totaam]

2014-10-02 00:47:12: afarr commented

---

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

• Testing with 0.15.0 r7813 client (windows 8.1) vs. 0.15.0 r7794 server (fedora 20) I get the same results you did:

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](../commit/e389cb8c9e2c568302277b058fa15db35e52ef08))

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

• Testing again with 0.15.0 r7847 windows client vs. 0.15.0 r 7847 fedora 20 server I get what I think we're expecting:

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](../commit/cecb66c09f2e48c9b52b1d07e4288c39ddab99f9))

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.

[totaam]

2014-10-02 05:05:49: totaam commented

---

As per #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?

[totaam]

2014-10-02 22:56:39: afarr commented

---

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

[totaam]

2014-10-03 03:40:11: totaam commented

---

I suppose the workarea reduction has to do with the bottom menu/tray
[[BR]]
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).

[[BR]]

I'm left confused how DPI is being used.
[[BR]]
You and me both.

[[BR]]

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

[totaam]

2014-12-04 17:44:08: totaam commented

---

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

[totaam]

2015-02-06 23:57:15: afarr commented

---

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

[totaam]

2015-11-05 23:16:53: afarr commented

---

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

[totaam]

2015-11-05 23:18:57: afarr uploaded file win8-1_control-panel-display-page.PNG (41.3 KiB)

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

[totaam]

2015-11-08 15:38:41: antoine commented

---

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

[totaam]

2015-11-10 03:19:47: afarr commented

---

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

[totaam]

2015-11-10 15:47:17: antoine commented

---

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

[totaam]

2015-11-12 02:30:27: afarr commented

---

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

• NativeGUI_info.exe is still listing my dpi.x and dpi.y as 96 irregardless of what I do with my local display resolutions or "text size slider". The workarea does change to reflect the pixel changes induced by said changes. (I was able to to adjust workarea from [(0,0,3840,2120), (0,0,1200,680]) to [(0,0,2048,1496), (0,0,1280,680)], to [(0,0,2560,1413), (0,0,1280,680)] ... all with the dpi still set to 77x77.)

• The server and client desktop output seems to be behaving a little bit differently, however. It looks like the adjustments to the resolution / text-size is changing the dpi rating of the main (4K) monitor, but not that of the second monitor. Does that indicate "per-monitor" awareness? ... double checking with XPRA_DPI_AWARENESS=1, however... I discover that the behavior is not different after all.

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?

[totaam]

2015-11-12 03:14:35: antoine uploaded file win8.1-dpi144.png (410.4 KiB)

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

[totaam]

2015-11-12 04:48:28: antoine commented

---

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: widt_width_mm*25.4 / height_height_mm*25.4)

• the workarea is "correct" and uses unscaled coordinates (screen size minus task bar)

• the screen dimension as reported by GTK_info.exe was not, it was showing: width=1067 and height=800 when my screen was actually 1600x1200 but running the client showed the correct value - r11192 fixes that: we must run gui_init (which sets dpi aware / awareness) before querying the screen

[totaam]

2015-11-12 23:24:01: afarr changed owner from afarr to antoine

[totaam]

2015-11-12 23:24:01: afarr commented

---

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?

[totaam]

2015-11-13 04:15:56: antoine changed owner from antoine to afarr

[totaam]

2015-11-13 04:15:56: antoine commented

---

It still makes no sense that the dpi is larger
[[BR]]
Why not?

[[BR]]

Which is a very good thing, because my width_mm and height_mm were not changing as I adjusted scaling
[[BR]]
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 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.

[totaam]

2015-11-18 02:31:01: afarr commented

---

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?

[totaam]

2015-11-18 07:50:55: antoine commented

---

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.

[totaam]

2015-11-19 20:48:49: afarr changed owner from afarr to antoine

[totaam]

2015-11-19 20:48:49: afarr commented

---

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

[totaam]

2015-11-22 09:48:18: antoine changed owner from antoine to afarr

[totaam]

2015-11-22 09:48:18: antoine commented

---

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: [DPI Data]. Once all the data is well presented there, we can remove the data section from [DPI](../wiki/DPI-Data]. Once all the data is well presented there, we can remove the data section from [../wiki/DPI). Once all the data is well presented there, we can remove the data section from [DPI Data]. Once all the data is well presented there, we can remove the data section from [DPI](../wiki/DPI-Data]. Once all the data is well presented there, we can remove the data section from [../wiki/DPI).

• xsettings.Xft/DPI is always set to Xft.dpi multiplied by 1024, and can be omitted entirely

• can we find better terms for "XXX smallest"?
• we need the screen resolution we detect as well as the DPI - to see if the OS is ever lying to us about that
• workarea: taskbar is at bottom of the screen I assume, the values for the second monitor look like they've been cooked by the OS (bigger than the resolution set) and will cause us problems - does this match the screen dimension detected?
• workspace shown for "third smallest" dual monitor, looked wrong - I computed a different value
• the tables found in the second half of the wiki include changes to "scaling", aren't the "window-frame" attributes also affected?
• from the second half onwards, I am struggling to figure out where the values are coming from: It seems to be mixing client side data with server side data. 4 different DPI values are shown, all identical too - simply stating that they are identical (correctly synced) would be much easier to understand.
• You state ".. does have different results however, as indicated below..", it wouldn't hurt to tell us what to look for since the table is quite big.

• the cursor size is always at 32, except for one case - you sure about this one? looks really out of place (value is 48 only for "Third Smallest" and the DPI is also out of line with the rest)
• it looks to me like without "DPI Aware", changing the font size affects the DPI - changing "scaling" always affects the DPI. I can only assume that the screen resolution we detect is also affected?

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

[totaam]

2015-12-02 02:26:56: afarr commented

---

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

• The xsettings.Xft/DPI looked like it might be important, so I included it... I won't miss it.

• Windows doesn't seem to have any explicit terminology to refer to the text size settings &/or DPI scale/number-line stuff other than a line from smaller to larger... which led me to use that "XXX smallext" terminology (though, I did at least refrain from a listing for "least smallest" in the charts). Some researching on the topic and I noticed that there is a lot of references to 100%, 125%, etc. ... which, once I decided to embrace the notion that 96 DPI is "100%", made it easy to put some more coherent seeming terms into the tables.

• Checking detected screen resolutions... I found that they all matched that provided by NativeGUI_info.exe, so I modified the chart headers to reflect that.

• Taskbar is indeed at the bottom of the screen. Looking at those values for the second monitor, and trying out some math to see if any fit, I found that the second monitor's workareas seem to be getting multiplied by the scaling ratio (rather than divided by it, as is apparently the case when using XPRA_DPI_AWARE=0)... after the scaled Taskbar dimensions are first stripped from the workarea. Considering the matter, I tried the "Let me choose one scaling level for all my displays" box... and found that the values output with both the NativeGUI_info.exe and those detected upon connecting a client seemed considerably less wacky - I put the values into the wiki/DPI/Data table.

• The workspace shown for "third smallest" was wrong... fixed that.

• The tables in the second half (I assume you mean the XPRA_DPI_AWARE=0 tables?) don't include any "window-frame" attributes because the only source I could find for those was from the NativeGUI_info.exe, which indicated no difference whatever the DPI_AWARE value.

• From the second half onwards, most of the data is coming from a mix of the client side output upon connection (as well as updates when scaling with Shift-Alt-+) and the /usr/lib64/python2.7/site-packages/xpra/platform/gui.py output within the session taking new values at each desktop-scaling value. I wasn't sure if it would be interesting or not, so I tried to err on the side of providing... in case.

• I went ahead and took some time to chew on what the differences in output with XPRA_DPI_AWARE=0 vs. =1 were, and added my take on them as preface to the chart.

• The instance with the 48 cursor size was another mistake... those were the values with XPRA_DPI_AWARE=1, not =0.

• As I added to the preface regarding the XPRA_DPI_AWARE=0 charts... it looks like turning DPI AWARE off causes the client to use the same DPI settings... but then scaling reflects solely in a scaling of the workarea, by the same factor, rather than in the DPI... almost seems like a form of cooking the books - I'll try a little testing with each and see if I notice actual effects, rather than just a change as to which numbers are being massaged to create an effect.

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.

[totaam]

2015-12-05 01:09:35: afarr commented

---

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](../commit/2b18827dd03e61340e13aa2585114b1f1f647cf9)
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.

[totaam]

2015-12-05 08:03:10: antoine commented

---

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.

[totaam]

2015-12-08 02:20:21: afarr commented

---

r11357 confirms fix for mismatch between displays and workareas.

Updated a number of charts at [DPI] & [DPI Data](../wiki/DPI] & [../wiki/DPI-Data) & [DPI] & [DPI Data](../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.

[totaam]

2015-12-09 00:09:39: afarr commented

---

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.

[totaam]

2015-12-13 07:53:17: antoine commented

---

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 [DPI]?, as I said in comment:25, the idea is to have more presentable succinct data here instead: [DPI Data](../wiki/DPI]?, as I said in comment:25, the idea is to have more presentable - succinct data here instead: [../wiki/DPI-Data)?, as I said in comment:25, the idea is to have more presentable / succinct data here instead: [DPI]?, as I said in comment:25, the idea is to have more presentable succinct data here instead: [DPI Data](../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 GetCursorPos but there is also a GetPhysicalCursorPos.

[totaam]

2015-12-14 19:59:18: afarr commented

---

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:

• The data on the various values of dpi/workarea as they are are set by the combination of local "text size" (local scaling) & "desktop-scaling" are useful to have to see if the values are what you're expecting, based on the other tables. (Though that doesn't seem like a set of charts for the wiki/DPI/Data page. Perhaps another wiki page?)

• There might be use for a set of tables showing the server workarea DPI, the display DPI, and the detected workarea as detected client-side upon connection with a variety of local scaling settings with & without XPRA_DPI_AWARE enabled. (I have put together such a set of charts with the desktop-scaling details edited out for brevity/clarity, but I'll hold off posting them anywhere - as I've misunderstood your intentions often enough here that I'll be careful not to clutter any pages and thereby increase the confusion... and because this also seems like a set of charts that might better be posted on a wiki page specific to Xpra interpretations/detections rather than the wiki/DPI/Data page, which seems like it it trying to focus more on client side DPI data. Let me know if the charts seem like they would be more useful for a dpi_aware 0 vs. 1 comparison without the complications of desktop-scaling mixed into the same charts... and if so, where you would like them put to make them most useful.)

[totaam]

2016-01-11 22:29:10: afarr commented

---

Went ahead and removed redundant window_frame charts from 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 DPI 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.

[totaam]

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