...

Session Type = MATE (automatically changes to "Custom desktop" with command "MATE") Display = Fullscreen Set display DPI = 192

The session starts just fine, filling the screen with the MATE desktop, except that the display resolution is incorrect... with following information obtained inside a MATE terminal:

jpdavis: xdpyinfo | grep dots

resolution: 192x193 dots per inch

jpdavis: ps -waux | grep $DISPLAY | grep x2goagent

jpdavis 28204 0.2 0.3 217268 57696 ? S 10:05 0:08 /usr/lib64/nx/../x2go/bin/x2goagent -nolisten tcp -nolisten tcp -dpi 192 -D -auth /home/jpdavis/.Xauthority -name X2GO-jpdavis-50-1491062721_stDMATE_dp32 :50

jpdavis: xrandr --prop

xrandr: Failed to get size of gamma for output default Screen 0: minimum 320 x 240, current 1280 x 720, maximum 1920 x 1200 default connected 1280x720+0+0 0mm x 0mm

Thus the actual dpi being used by the display is 192*1280/2560 = 96, not the 192 sent to x2goagent and reported by xdpyinfo.

Your x2goagent is running using the correct (forced) 192 dpi as specified via the command line. But your x2go window is much smaller than your native desktop.

I am not really sure what to do here. Maybe we should try to calculate the window size in mm, pass that to x2goagent and let it recalculate the dpi itself.

I didn't see any options to x2goagent for passing window size. I actually get something much more reasonable when I DON'T specify a DPI (see attachments); then xdpyinfo reports dpi of 75x75 and size 1280x720, but xrandr still says maximum resolution is 1920x1200.

...

attempting to change the resolution from inside the session...

xrandr --size 1920x1200 works but keeps same actual dpi of 96 (so desktop is larger than my screen)

I don't get that. How can the desktop become larger than the screen? The window size of your x2go session is the size of the xserver the MATE desktop sees. The dpi setting should - from my understanding - influence the selected fonts and maybe scaling, but not the overall size of the desktop.

Can you please provide some screen shots to minimize miunderstandings?

By "screen" I mean the physical laptop display panel. I have attached three fullscreen (2560x1440) images (taken on the laptop using Windows Snipping Tool) to this e-mail, I don't know if they will show up in the mail list (if not, well unfortunately I don't have anywhere I can put them publicly to link to), but at least you should receive them.

Capture_x2go_default_setdpi192.PNG = case with client "set display dpi" turned on and equal to 192, in which the X session thinks the display is 1280x720 at 96 dpi.

Capture_x2go_1920x1200setdpi192.PNG = what I see after issuing the command "xrandr --size 1920x1200" in the session; this is what I meant by desktop larger than the physical screen.

Capture_x2go_default_nosetdpi.PNG = case with client "set display dpi" turned off, in which the X session still thinks the display is 1280x720 but at 75 dpi. This is better than the forced-dpi=192 cases, but still doesn't look like it's actually using the full resolution of the laptop.

So with some more research I have learned that the apparent 96 dpi I'm seeing is actually forced by gdm via gnome-settings-daemon for all X sessions, as explained in the comments at https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/xsettings/gs.... On the server, Xorg.0.log shows that Xorg correctly finds resolution (3840x2160) and dpi (139x137) of the attached monitor; but xdpyinfo shows dpi=96. Perhaps the remote X session generated by the x2go login is using the physical size of the laptop screen but with dpi=96 to arrive at 1280x720. I believe that when I force dpi=192, gdm automatically applies a scaling of 2, which would explain why everything is so huge in that case.

One thing I don't understand very well is the relationship between X running on the x2go server machine and X (in this case VcXsrv) running on the x2go client machine. I have toyed with the idea of putting an xrandr command in a display-specific script under /etc/gdm/ to set up the screen for my remote sessions (I only ever have one running, and it's always display :10), but I haven't actually tried this yet.

Also, can you please retry using the current developer version of nx-libs as described here: http://wiki.x2go.org/doku.php/doc:howto:nx-libs-betatesting

I made an attempt at this using the instructions in the README file (https://github.com/ArcticaProject/nx-libs) to create rhel/centos/fedora rpms, but I got an error from the mock --buildsrpm command; I think I was supposed to actually build the libraries first (using make all), so I'll try that and report back.

Jean-Paul