vncviewer produces a blank X window on the ratpoison window manager

[Apteryks]

Hello, and thank you for this software.

I've packaged it for my system (GNU Guix), with similar adjustments as done by the NixOS packaging of turbovnc. When I run vncviewer, it spawns a blank X window. I suppose there should be a menu bar, or something? It is totally blank.

I've tried a few different opendjk versions, such as 12 and 17, but the result is the same. I've also tried the one but last release, 3.0, but I still reproduce the problem there.

I'm not sure if that's helpful, but here's the output with the java -verbose flag:

java -verbose -Djava.library.path=/gnu/store/kcbi3m1nqd2685gvyg80ghckss42b2lm-turbovnc-3.0.1/share/turbovnc/classes -jar /gnu/store/kcbi3m1nqd2685gvyg80ghckss42b2lm-turbovnc-3.0.1/share/turbovnc/classes/VncViewer.jar

vncviewer.output.txt

The direct dependencies used are:

freetype@2.10.4 libfontenc@1.1.4 libjpeg-turbo@2.0.5 libx11@1.7.3.1 libxdamage@1.1.5
+ libxext@1.3.4 libxfont@2.0.4 libxi@1.7.10 libxkbfile@1.1.0 linux-pam@1.5.1 mesa@21.3.8 openjdk@17.0.3
+ openssl@1.1.1l perl@5.34.0 pixman@0.40.0 python@3.9.9 xkbcomp@1.4.5 xkeyboard-config@2.34 xtrans@1.4.0
+ zlib@1.2.11

CMake is at 3.21.4.

Any idea?

Thank you!

[dcommander]

You mean the window is blank after successfully connecting to the VNC server? That probably indicates a window manager failure of some sort. Check the server log under ~/.vnc for errors. However, there should indeed be a toolbar at the top of the TurboVNC Viewer window. If you aren't seeing that, then something else may be amiss.

[Apteryks]

Hi! Thanks for the lightning-fast reply!

The client doesn't even try to connect to the server, it seems. The window is totally blank, and pressing mouse or keyboard keys such as F8 doesn't cause any menu to be drawn, so it seems the problem is with the GUI. Using vncviewer from TigerVNC, I can connect to the server and view applications started on this particular display (:5), so I know the server component is working.

vncviewer --help works. vncwiever or vncviewer localhost:5905 leaves me with a blank window: and no connection logs appear on the server's end.

The server is Xvnc from TigerVNC, configured with -SecurityTypes None and running on display :5 (SSH-tunneled locally).

Thanks!

[Apteryks]

Interesting: if I start TurboVNC's vncviewer from my VNC server, on that :5 display, then I can see the GUI fine via TigerVNC's vncviewer on my local machine!

So it seems there's something on my local environment that's causing it to not display correctly?

[Apteryks]

It also works from another Guix System machine that is using GNOME instead of the ratpoison window manager that I use on my main machine. I'll update the title accordingly.

As an aside, TigerVNC's viewer works correctly on ratpoison in window mode, but fails to display in full screen mode. TigerVNC/TurboVNC are the first applications I've encountered in the last 7 years of using ratpoison that doesn't work at all with this tiling window manager.

[dcommander]

There seems to already be a Java bug regarding this: https://bugs.openjdk.org/browse/JDK-6574362 Unfortunately, it has been open since Java 6 with no resolution. :( There is unfortunately nothing that our project can do about it.

[Apteryks]

OK, thanks for the reference!

[Apteryks]

Wow, the issue is very silly. Apparently Java has a hard-coded list of window managers it knows that are 'non-reparenting', and 'ratpoison' is not on it. The workaround suggested at https://bugs.openjdk.org/browse/JDK-6574362?focusedCommentId=12119795&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12119795 works; e.g. wmname LG3D. Setting the _JAVA_AWT_WM_NONREPARENTING (e.g. to 1) also achieves the same. I'll see if I can submit a patch to OpenJDK to resolve it for good. Thanks again for the help!

[dcommander]

Glad there is a workaround. The TurboVNC Viewer is written in Java solely for historical reasons. Basically, back when there were three TurboVNC viewers (Xt, Java, and Win32), I got a lot of funding to improve the Java viewer (because companies were interested in using it with Java Web Start.) Thus, our Java viewer (with an embedded JRE) was in the best position to become the sole TurboVNC Viewer in TurboVNC 3.0. At this point, the viewer is a hybrid of Java code and C (JNI) code that I use to work around the quirks in Java. I’ve seen the struggles TigerVNC has had with FLTK, so I don’t really want to go down that road either, but if I had the resources, I would rewrite the whole viewer in C++ and use a modern GUI framework like Qt. For now, however, I’m going to have to live with Java.

[Apteryks]

OK, thanks for the historical perspective! I really was curious about what got Java into this project. I thought the maintainers at the time must have been familiar with how to make GUIs with Java or something :-).

[dcommander]

I actually had very little familiarity with Java at the time but have become a bit of a Swing GUI ninja in the intervening years. The ease at which GUIs can be created and modified is one of the strengths of Java, as well as the built-in cross-platform networking and cryptography APIs. Input device handling is a huge weakness, however, and has proven to be a royal PITA to work around. I would have a lot fewer problems with Java as a concept if the OpenJDK developers responded to bug reports in a timely manner, but the reality is that the last five JDK issues I've encountered received no action from their end, thus requiring me to spend many hours digging through the JDK source to figure out a workaround (which often required dropping to JNI.)

[dcommander]

For reference, another user reported what appeared to be an unrelated issue when using the TurboVNC Viewer with the i3 window manager. If the connection drops and the viewer is in full-screen mode with keyboard grabbing enabled, the error dialog pops up behind the full-screen window, and since keyboard grabbing is enabled, this prevents the user from dismissing the error dialog and thus closing the viewer. This effectively locks the user out of their window manager session, requiring them to SSH in from another machine to kill the TurboVNC Viewer process.

The user confirmed that setting _JAVA_AWT_WM_NONREPARENTING=1 in the environment also works around that issue.

[Apteryks]

Hi! I'm glad to know the previously discovered workaround is proving useful for other window managers as well! Cheers!