Display uses 1/4 of screen while mouse uses whole screen coordinates

[lukego]

Describe the bug
VNC is showing my desktop at 1/4 size and occupying only the bottom-left quadrant of my viewer window. The mouse seems to be operate in the full coordinate space. I think the VNC desktop pixels need to be scaled up by a factor of 2 to work correctly.

I am running tigervnc server 1.9.0 on Linux (NixOS) and tigervnc client 1.9.0 (macOS homebrew) on a Macbook laptop with Retina display. The problem does not seem to occur on my desktop Mac with non-Retina display.

To Reproduce

You can install the exact VNC setup that I am using via Docker like this:

docker run --rm -ti -p 0.0.0.0:5901:5901 studioproject/master vnc

and then run vncviewer localhost:1 outside of Docker on the host.

Expected behavior

VNC desktop uses whole viewer window.

Screenshots

Client (please complete the following information):

• macOS Mojave.
• TigerVNC 1.9.0.
• Downloaded from homebrew.

Server (please complete the following information):

• OS: Alpine Linux from Docker and Nix to install VNC.
• VNC serer: TigerVNC 1.9.0.

[samhed]

If I recall correctly this didn't happen to me when I ran the vncviewer on macOS with scaling.

I'm unfamiliar with homebrew, but I believe it is possible that they are building with a different version of FLTK. Could you check what version they used?

Lastly, how come you used a client from homebrew? Doesn't one uploaded on bintray for the 1.9.0 release work for you? https://bintray.com/tigervnc/stable/tigervnc/1.9.0

[lukego]

Thanks for the tip @samhed. I have been using the homebrew version just because that is my default way to install software. I switched to the stable binary from bintray and this is now working as expected.

Here is what I can immediately see about the dependency versions of the homebrew version:

$ otool -L $(which vncviewer)
/usr/local/bin/vncviewer:
	/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 158.0.0)
	/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 23.0.0)
	/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 50.1.0)
	/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
	/usr/local/opt/fltk/lib/libfltk_images.1.3.dylib (compatibility version 1.3.0, current version 1.3.4)
	/usr/local/opt/fltk/lib/libfltk.1.3.dylib (compatibility version 1.3.0, current version 1.3.4)
	/usr/local/opt/gettext/lib/libintl.8.dylib (compatibility version 10.0.0, current version 10.5.0)
	/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
	/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.200.5)
	/usr/local/opt/jpeg-turbo/lib/libjpeg.8.dylib (compatibility version 8.0.0, current version 8.2.2)
	/usr/lib/libpam.2.dylib (compatibility version 3.0.0, current version 3.0.0)
	/usr/local/opt/gnutls/lib/libgnutls.30.dylib (compatibility version 54.0.0, current version 54.0.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.4)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1560.12.0)
	/System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics (compatibility version 64.0.0, current version 1247.4.1)
	/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 934.0.0)
	/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1560.12.0)
	/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)

[samhed]

Ok, its good to hear that you found a solution.

As I'm quite limited on time at the moment I will close this issue now. If our build works I don't have any plans to digging into why homebrew's version doesn't.

[lukego]

Thanks for your help! I will follow up with homebrew.

[amelialdrew]

Hi - sorry to reopen this but did anyone find a fix for this bug? I can't get the version from the bintray link to work for me and the homebrew one is perfect other than this screen problem.

[kflu]

Hi I'm seeing exactly the same problem on mac os using my locally built vncviewer fresh from git repo (/issues/867). I need to able to locally build and run in order to develop a PR. Can someone help take a look?

[matlupi]

Thanks for your help! I will follow up with homebrew.

Is there any news from them?
In the dedicated issue they mention that this is TigerVNC issue, not homebrew.
Here it is mentioned that it is a homebrew issue, not TigerVNC.

[CendioOssman]

Unfortunately our verdict still stands. The posted screen shot is obviously built with a different .plist file than ours (since we have HiDPI disabled).

I'd advise poking homebrew again and at least get them to give a reason why they think this is a TigerVNC issue. Our own builds work fine after all.

[penagos]

I can confirm building tip from source on Apple Silicon Monterrey the 1/4 window usage issue seems to be related to running vncviewer from a dmg file vs. the executable directly (once you patch fltk 1.3.4-2 to get past the blank window issue). When I ran the executable directly from the terminal (vncviewer), I hit this exact bug. When building the dmg target and using the vncviewer application within that package, I cannot reproduce this issue.