Multiple displays not working on M1 mac

[caparomula]

Tried using pre-built 3.0.2 binary. It required installing Rosetta, which surprised me, since I downloaded the arm64 version. Regardless, when I enter full screen, the application fills only my primary display. I selected "All Monitors" for span mode, and also tried "Automatic" with same results. I've used the linux and windows binaries to connect to the same (linux) server and successfully used all screens, so it seems to be a bug in the macOS version.

My Mac Studio is running macOS Ventura 13.0.1

[dcommander]

The arm64 package shouldn't require Rosetta, so that's a bug. Full-screen multi-screen spanning requires that you uncheck "Displays have separate Spaces" in System Preferences-->Mission Control and log out/back in.

[dcommander]

I can't find anything obvious in the application bundles that would suggest the need for Rosetta. All of the executables and .dylib files in TurboVNC Viewer.app are arm64, and all of the compiled AppleScripts in TurboVNC Viewer (Listen Mode).app and Uninstall TurboVNC.app are universal x86-64/arm64. Can you narrow down exactly when TurboVNC fails without Rosetta, i.e. when Rosetta is first required? Is it during installation or when attempting to use a particular app in the TurboVNC distribution?

[caparomula]

Thanks for the feedback. I tried disabling "Displays have separate spaces", and the result was that my primary display showed one VNC screen and the other two monitors were just dark. Regarding Rosetta, the prompt to install it popped up pretty much immediately after launching the TurboVNC installer.

[dcommander]

RE: full-screen

Ugh. Full-screen multi-screen spanning in the TurboVNC Viewer is problematic on macOS in general, because we are using a Java interface that is supposedly deprecated but for which the OpenJDK developers haven't seen fit to provide an alternative. (https://bugs.openjdk.org/browse/JDK-8228638) With Intel Macs, I observed an issue whereby I had to build JavaAppLauncher using Xcode 4.6 and the OS X 10.7 SDK in order for full-screen multi-screen spanning to work. I never figured out why that was the case, so I just included a static x86-64 build of JavaAppLauncher into the source tree. For Apple silicon Macs, the build system builds JavaAppLauncher from source code instead. Based on your observations, it seems that the same issue that I observed on Intel Macs exists on Apple silicon Macs as well, but of course, there is no way to use Xcode 4.6 or the OS X 10.7 SDK to work around it. I guess I need to figure out what's really going on.

RE: Rosetta

Can you confirm whether the TurboVNC Viewer works without Rosetta after you install the TurboVNC package? If so, then that would point to an issue with the package generation rather than the TurboVNC apps themselves.

[dcommander]

And thank you for testing this. I don't have access to an M1 Mac, so I have no ability to test it myself.

[dcommander]

This is a shot in the dark, but I think the Rosetta issue may be due to our Distribution.xml file lacking a hostArchitectures key. Please try https://turbovnc.org/downloads/TurboVNC-3.0.3-arm64.dmg and let me know whether that installs properly without Rosetta.

[caparomula]

I can imagine that dealing with the weirdness of full screen support for multiple monitors cross-platform has got to be a bear. Do you have a suggestion how I can determine whether the binary is using Rosetta? It appears there's no supported way to remove Rosetta once it's installed without resorting to hackery (which I would prefer to avoid).

[caparomula]

I found that "Activity Monitor" will show whether you are running intel or apple machine code. And I confirmed that the 3.0.2 viewer is indeed native apple, while the installer is intel. After checking that, I verified that the 3.0.3 installer is native apple.

[dcommander]

Cool. I will push that commit, then, and assume that that problem is fixed.

[caparomula]

Nice. I don't know much about macOS development, but I'm tempted to dig in to see if I can offer any help (I mostly do java system programming on linux, haven't done any GUI programming in about two decades!). Lack of a decent vnc viewer is the only thing holding me back from switching to macOS full-time.

[dcommander]

I am no closer to figuring out the cause of the full-screen multi-screen issue, but assuming it's the same issue that I observe on x86-64, I have ascertained that the issue doesn't occur if JavaAppLauncher is built with Xcode 9.4.x and prior. (I tested 4.6.x, 5.0.x, 7.2.x, 8.3.x, and 9.4.x.) It does exist if JavaAppLauncher is built with a later version of Xcode. (I tested 10.3, 12.1, 12.2, and 13.2.) More to the point, the issue exists if JavaAppLauncher is built with the macOS 10.14 or later SDK. Of course, building with Xcode 12.0 or later is necessary when targeting macOS 11+ and Apple Silicon.

[dcommander]

To clarify one point regarding the symptoms of the issue:

When I observe the issue on x86-64, multi-screen spanning usually works the first time that the TurboVNC Viewer enters full-screen mode, but switching away from the full-screen TurboVNC Viewer window and back to it again (using Command-Tab) causes multi-screen spanning to stop working. At the low level, the TurboVNC Viewer correctly sets the window geometry so that it should span multiple screens, but Java doesn't honor that request.

I suspect that the issue has something to do with the app bundle itself. When I first started observing it (several years and several macOS releases ago), the issue would only occur when the TurboVNC Viewer was launched through the app and only if JavaAppLauncher was built with a recent Xcode release. Now the issue always occurs unless the TurboVNC Viewer is launched through the app and JavaAppLauncher is built with an old Xcode release. Also, according to the commit log, when I first encountered the issue, it would occur when JavaAppLauncher was built with the 10.11 or later SDK. Now it seems to occur when JavaAppLauncher is built with the 10.14 or later SDK.

I keep hoping that maybe the issue is due to some Info.plist key that I'm missing. :|

[dcommander]

I'm still investigating this. I'll keep you posted with my findings.

[dcommander]

No luck so far. I have ascertained that it appears to be a macOS issue rather than a Java issue. Symptomatically, when the issue occurs, macOS sends a second resize event to the full-screen window that constrains it to a single screen. It is still unclear why that doesn't occur when the TurboVNC Viewer is packaged as an app bundle using JavaAppLauncher built against older macOS SDKs.

[dcommander]

Example application that reproduces the issue:
https://gist.github.com/dcommander/6cd87e4f2980b741b506c9f5e7c9f29c