RFR: 8351907: [XWayland] [OL10] Robot.mousePress() is delivered to wrong place [v2]

[Alexander Zvegintsev]

On Fri, 16 May 2025 19:09:41 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Before the patch the getGnomeShellMajorVersion was guarded by the "gnome.equals(getDesktop()))" should we do the same in XdgDesktopPortal? 

Thanks, this is a good point, updated.

>  or maybe we can at least check if gnome-shell exists so we don't waste time launching it? or is ProcessBuilder's performance good enough?

It's actually pretty fast for a non-existent binary, only 1 ms
The `getGnomeShellMajorVersion` check takes about 33 ms  on my machine when the binary is in the system.

Alternatively we can try to receive this version via DBUS API and see if it is faster.
It is definitely available through introspection:
`gdbus introspect --session --dest org.gnome.Shell --object-path /org/gnome/Shell | grep ShellVersion`

But not as part of this issue, [JDK-8357174](https://bugs.openjdk.org/browse/JDK-8357174) created.

> BTW how it is expected to work on KDE + wayland?

It is not a supported configuration.However, when I tested it a while ago, it only worked in a single-screen scenario for the Screencast.
There was an issue with the screen streams; they did not specify their `x` and `y` coordinates.
This prevented the correct arrangement of multiple screens.
I don't know if this has been fixed, but the issue is addressed in our code here:

https://github.com/openjdk/jdk/blob/3dd34517000e4ce1a21619922c62c025f98aad44/src/java.desktop/unix/native/libawt_xawt/awt/screencast_portal.c#L132-L155

In this case, the Screencast is simply disabled.

The Remote Desktop uses the same streams from Screencast portal to control the mouse position.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25265#discussion_r2093639881