Window Menu glitch under x2go

[mdavidsaver]

Running phoebus remotely using x2go mostly works. However, I see an oddity wrt. window menus only (not context menus).

When I click on eg. 'File', the menu appears, but below the row of toolbar buttons. I am then unable to select items by mouse. Keyboard up/down/enter still works, so it is usable for me.

Details:

client is Debian 9. X2Go Client v. 4.0.5.2 (Qt - 4.8.7)
server is CentOS 7. server 4.1.0.3, agent 3.5.99.17, java-11-openjdk-11.0.2.7-0.el7_6.x86_64

[mdavidsaver]

I initially noticed this error printed on start:

ES2 Prism: Error - reported GLX version = 1.2
    GLX version 1.3 or higher is required

Adding -Dprism.order=sw makes this go away, but the menu glitch remains.

[shroffk]

This has been reported already here:

#436 (comment)

Reponse:

Request for context menu in display builder was an actionable item which I could handle.
Menu behaviour with a specific Linux setup is very different, more like #256 or #353 or #367 .
Still, any difference when using -Djdk.gtk.version=2 vs -Djdk.gtk.version=3?
I'm using GTK2 because otherwise Drag & drop doesn't work, i.e. hard to arrange tabs or edit displays.

[mdavidsaver]

Ok. my quick search didn't find this.

[mdavidsaver]

Ah. The menus look ok with -Djdk.gtk.version=2 (from #367)

Sigh... I was so hoping that I could stop caring about GTK2 vs. 3.

[mdavidsaver]

Never mind. It still happens sometimes with gtk2.

@shroffk Do you know if there is an issue on openjfx for this? The closest I can find is https://bugs.openjdk.java.net/browse/JDK-8176844 which claims to be fixed.

[mdavidsaver]

@hhslepicka provides some insight.

Some of the mouse issues go away if the phoebus window loses, then regains, focus. The remainder seem to exist with both GTK2 and 3.

Hugo saw similar problems with Qt on Mac, which were apparently fixed with a Qt upgrade (no GTK involved).

[mdavidsaver]

I recently updated to Debian 11, and thought I would re-test this issue. I'm connecting via ssh to a VM running on my laptop. Both host and VM have Debian 11. tldr. x2go still doesn't work for me. However, plain remote X and xpra do.

Encouragingly, straight remote X seems to work correctly, the GLX version 1.3 or higher is required message is gone, and both client and server report GLX 1.4.

$ glxinfo |grep string
server glx vendor string: SGI
server glx version string: 1.4
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
OpenGL vendor string: Mesa/X.org
OpenGL renderer string: llvmpipe (LLVM 11.0.1, 256 bits)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 20.3.5
OpenGL core profile shading language version string: 4.50
OpenGL version string: 3.1 Mesa 20.3.5
OpenGL shading language version string: 1.40
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 20.3.5
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

Unfortunately, x2go (X2Go Client v. 4.1.2.2 (Qt - 5.15.2)) still shows both the menu glitch, the GLX version message, and reports GLX 1.2. :(

$ glxinfo |grep string
server glx vendor string: SGI
server glx version string: 1.2
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
OpenGL vendor string: Mesa/X.org
OpenGL renderer string: llvmpipe (LLVM 11.0.1, 256 bits)
OpenGL version string: 3.1 Mesa 20.3.5
OpenGL shading language version string: 1.40

I also tried xpra, which I haven't looked at in ~8 years. It also works! So maybe time to move away from x2go and other NX derivatives (which xpra isn't).

$ glxinfo |grep string
server glx vendor string: SGI
server glx version string: 1.4
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
...

I happened upon javafxports/openjdk-jfx#546, which is exactly the same behavior I see, although in a different situation (local X with a weird window manager). The linked trivial example application behaves the same way as phoebus for me wrt. menus.