Table of Contents |
---|
External - system-side update/fix required, can't be fixed/resolved on the JDK side without it.
Unresolved:
JDK-8280983 [External][Pure Wayland][X11 compatibility]: java.awt.Robot emulating keyboard/mouse events
Problem: | Cannot emulating keyboard/mouse events on Pure Wayland at all, in X11 compatibility mode only inside X11 server |
Affected: | Pure Wayland(External), X11 can be used with limitations. |
Related links: | [X11 compatibility]: Robot.mouseMove does not visually move mouse cursor [X11 compatibility]: XTest emulated mouse click does not bring window to front.. [X11 compatibility]: Click on title to request focus test failures |
Discussion: | The java.awt.Robot class provides methods to emulate input; keyPress(), keyRelease(), mousePress(), mouseRelease() |
Current robot implementation doesn't work for Pure Wayland port at all, but it mostly works for X11 compatibility mode |
. However, there are some cases when it fails for X11 - when trying to reach outside XWayland server with using XTest API |
: JDK-8280995 X11 compatibility: Robot.mouseMove does not visually move mouse cursor JDK-8280990 X11 compatibility: XTest emulated mouse click does not bring window to front. JDK-8280988 X11 compatibility: Click on title to request focus test failures Implementing this via libEI will also fix the above issues | |
Solution: | X11: Can be used in X11 compatibility mode with the above-mentioned limitations, otherwise we'll have to use the same options as for Pure Wayland. |
Pure Wayland: Solution #1. Not yet usable This will probably be implemented by libEI. However, its shipping time(even estimated) is not yet known. |
Solution #2. Not yet usable You can do most of this using the RemoteDesktop portal. Once permission is given, you can use it to completely control the keyboard and mouse. However, you can't keep the permission as you can with | |
Workaround: |
JDK-8280984 [External][Pure Wayland]: Showing a splash screen
Problem: | Unable to control the position of the splash screen (e.g., display it in the center of the screen) |
Affected: | Pure Wayland(external) |
Related links: | wayland/wayland-protocols/-/issues/67 |
Discussion: | The native Wayland splash screen window usually appears somewhere in the upper left corner of the screen. This is due to Wayland not allowing windows to position themselves. This will need a Wayland protocol extension to add a role for an output-only, centered surface. it'd just need a fallback implementation for compositors that doesn't support it, e.g. a dialog Add input to this existing issue : wayland/wayland-protocols/-/issues/67 Implementation will probably be similar to this MR for Picture-In-Picture video: wayland/wayland-protocols/-/merge_requests/132 |
Solution: | None yet (see discussion in the GitLab issue). |
Workaround: | use X11 if available |
JDK-8280997 [External][X11 compatibility]: HiDPI.
Problem: | Applications running on XWayland looks blurry on HiDPI screens |
Affected: | X11(external) |
Related links: | xserver/-/issues/1318, GNOME/mutter/-/issues/402 |
Discussion: | Quote from Maxim Kartashev's e-mail:
|
Solution: | None |
Workaround: |
JDK-8280995 [X11 compatibility]: Robot.mouseMove does not visually move mouse cursor
Problem: | Robot.mouseMove does not visually move mouse cursor |
Affected: | X11 |
Related links: | [External][Pure Wayland][X11 compatibility]: java.awt.Robot emulating keyboard/mouse events |
Discussion: | Javadoc for
Despite the fact that this mouse movement is successfully emulated within the XWayland server(following mouse press emulation will be in a right place), the mouse cursor does not visually move. With current specification of |
Solution: | Use the same solution as for the Pure Wayland toolkit Preferred: see earlier point on working with RemoteDesktop portal(can't keep the user permission between sessions) |
Workaround: | Change the documentation to reflect the current behavior |
JDK-8280990 [X11 compatibility]: XTest emulated mouse click does not bring window to front.
Problem: | window does not come to front on emulated mouse click. Window focus transfer happens without issues. | |||||||||||
Affected: | X11 | |||||||||||
Related links: | [External][Pure Wayland][X11 compatibility]: java.awt.Robot emulating keyboard/mouse events | |||||||||||
Discussion: |
| |||||||||||
Solution: |
Use the same solution as for the Pure Wayland toolkit Preferred: emulate mouse click with libei | |
Workaround: | modify tests to use another API to bring window to front (e.g XMapRaised) |
JDK-
8283278 [External]8280988 [X11 compatibility]:
XOR rendering issueClick on title to request focus test failures
Problem:window is not rendered correctly(wrong colors) using setXORMode in Virtual Box with 3D acceleration | enabled.Some tests are trying to get focus of a window by clicking on its title bar. |
Affected: | X11(external) |
Related links: | xorg/xserver/-/issues/1333 → mesa/mesa/-/issues/6596 |
Discussion: | |
Solution: | None, wait for external fix | Workaround: |
Fix in progress/Workaround known:
JDK-8280982 [X11 compatibility][Pure Wayland]: java.awt.Robot taking screenshots
It is doable as of now, but not in a standard and convenient way. It can be done using some shell specific APIs, e.g. org.gnome.Shell.Screenshot DBUS API (which will not work for KDE, it has another API)
It has several drawbacks:
- There is no direct access to the screenshot data. Screenshot is saved to
png
file, after that you have to read it, decode it. - Filesystem footprint. You need to save it to some file(its filesystem can be slow). It can be workarounded by using shared memory object though.
- Using DBUS API in this case is really slow. For instance, just a sync DBUS call to take a 1000x1000 screenshot and save it to the shared memory object file is ~14 time slower(it is just saving, without decoding and extracting data) comparing to full X11 implementation.
So, it would be great to get some standard API to get screenshot data in memory. I see that there is an open bug against this issue.
Solution #1.
Specifically, it provides org.freedesktop.portal.Screenshot#Screenshot which can be used to create a screenshot.
However, it has some drawbacks(at least on Gnome):
- It does not allow to take a specified screen area, only whole screen.
It asks a confirmation on each screenshot request, so it is unusable for automated testing.(note, this was fixed for GNOME 43, not yet delivered to most distros)- It saves a screenshot to disk, which must be read and deleted(may be slow depending on drive).
- A user can deny the request. In this case as a possible solution we can throw a SecurityException for Robot#createScreenCapture (javadoc update required). Currently it is thrown only if readDisplayPixels permission is not granted(which is not suitable here).
- There is no way to disable the "screen flash" after screenshot
There is also org.freedesktop.portal.Screenshot#PickColor API which can't be used for Robot#getPixelColor needs. It does not allow to take a pixel color at specified location, but interactively asks a user to pick a color with mouse cursor.
Solution #2.
Finally, another possibility is to use the Screencast portal.
This might be a bit of overkill, but it avoids several of the problems mentioned in the screenshot and color picker portals.
- implementation is more complicated comparing to Screenshot API
- A user can deny the screenshot request too.
- Permission to make screenshots can be stored with restore_token (string, introduced in xdg-desktop-portal 1.12), that needs to be stored safely somewhere.
- new permission required if display set is changed or rearranged, might be an issue in case of remote automated testing.
- Permission to make screenshots can be stored with restore_token (string, introduced in xdg-desktop-portal 1.12), that needs to be stored safely somewhere.
- no intermediate file, screenshot data can be obtained from memory
- each display has its own stream, in case if requested screenshot area covers several displays resulting screenshot need to be combined from pieces.
Each solution is viable, but #2 seems to be more preferable.
However we may want to implement both of approaches:
If some new display got or disconnected, new permission request from user is required. In case of automated testing it may be a stopper. But we can fallback to a solution #1.
Prototype is available here.
-DuseScreencast=false
to switch off screenshot via Screencast. Enabled by default-DscreencastDebug
=true to print debug info, disabled by default
Testing on latest supported Linux distros for JDK19:
Packages required for permission restoration:
- xdg-desktop-portal 1.12+
- xdg-desktop-portal-gnome 42+ (it is a backend for xdg-desktop-portal)
However xdg-desktop-portal-gnome package is installed only for Ubuntu and SLES, OEL9 and RHEL9 does not have it yet.
Where partially means that you can make a screenshot, however it requires user permission on each request.
JDK-8280993 [X11 compatibility]: Popup menu dismiss in X11 compatibility mode.
XGrabPointer
to get mouse input and dismiss popup menus on mouse click. Obviously, it does not work outside of XWayland server.E.g. if we have shown some popup menu, it will be closed upon clicking on any of XWayland's windows.
But it will not be closed if we click on some other window from Wayland.
Expand | ||
---|---|---|
| ||
|
For a first look this workaround seems to work reliably except only one case:
clicking on window's title containing origin component does not lead to focus change, thus we don't hiding a popup.
issues: | [External][Pure Wayland][X11 compatibility]: java.awt.Robot emulating keyboard/mouse events |
Discussion: | |
Solution: | Use the same solution as for the Pure Wayland toolkit |
Workaround: | Click on window's body instead of decorations, request focus in other way |
JDK-8283278 [External][X11 compatibility]: XOR rendering issue
Problem: | window is not rendered correctly(wrong colors) using setXORMode in Virtual Box with 3D acceleration enabled. |
Affected: | X11(external) |
Related links: | xorg/xserver/-/issues/1333 → mesa/mesa/-/issues/6596 |
Discussion: | |
Solution: | None, waiting for external fix |
Workaround: |
JDK-8280987 [X11 compatibility]: crash when mapping a lot of windows
Problem: | GUI are crashing if you are trying to map a lot( > ~260) of windows at once. |
Affected: | X11(external) |
Related links: | xorg/xserver/-/issues/1222. |
Discussion: |
It may be faced when running some tests which are trying to map a lot of windows, e.g. one for every GraphicsConfiguration. If you have 210 GraphicsConfigurations per display on Xwayland, then running such test in 2 display configuration will lead to crash. |
Solution: | None (yet) |
Workaround: | Fix the failing test, e.g. by adding some delay after each ~100 windows displayed |
Fix in progress:
JDK-8280982 [X11 compatibility][Pure Wayland]: java.awt.Robot taking screenshots
Problem: | The java.awt.Robot class provides createScreenCapture() method which currently uses X11-specific APIs |
Affected: | X11, Pure Wayland |
Related links: | |
Discussion: | It is doable as of now, but not in a standard and convenient way. It can be done using some shell specific APIs, e.g. org.gnome.Shell.Screenshot DBUS API (which will not work for KDE, it has another API) It has several drawbacks:
So, it would be great to get some standard API to get screenshot data in memory. I see that there is an open bug against this issue. |
Solution: | Solution #1. Specifically, it provides org.freedesktop.portal.Screenshot#Screenshot which can be used to create a screenshot. However, it has some drawbacks(at least on Gnome):
There is also org.freedesktop.portal.Screenshot#PickColor API which can't be used for Robot#getPixelColor needs. It does not allow to take a pixel color at specified location, but interactively asks a user to pick a color with mouse cursor. Solution #2. Preferred Finally, another possibility is to use the Screencast portal. This might be a bit of overkill, but it avoids several of the problems mentioned in the screenshot and color picker portals.
Each solution is viable, but #2 seems to be more preferable. However we may want to implement both of approaches: If some new display got or disconnected, new permission request from user is required. In case of automated testing it may be a stopper. But we can fallback to a solution #1. Prototype is available here.
|
Workaround: |
Testing on latest supported Linux distros for JDK19:
Packages required for permission restoration:
- xdg-desktop-portal 1.12+
- xdg-desktop-portal-gnome 42+ (it is a backend for xdg-desktop-portal)
However xdg-desktop-portal-gnome package is installed only for Ubuntu and SLES, OEL9 and RHEL9 does not have it yet.
works? | xdg-desktop-portal | xdg-desktop-portal-gnome | Gnome | ||
---|---|---|---|---|---|
Ubuntu 22.04 | Yes | 1.14.4-1 | 42.1 | 42.2 | |
OEL9 | Partially | 1.12.1-1 | missing | 40.4.0 | persist_mode and restore_token has no effect |
RHEL9 | Partially | 1.12.1-1 | missing | 40.4.0 | persist_mode and restore_token has no effect |
SLES15 | Partially | 1.10.1 | 41.1 | 41.2 | protocol version 3 (1.10 < 1.12), restore_token is not supported |
Where partially means that you can make a screenshot, however it requires user permission on each request.
JDK-8280993 [X11 compatibility]: Popup menu dismiss in X11 compatibility mode.
Problem: | We are using XGrabPointer to get mouse input and dismiss popup menus on mouse click. Obviously, it does not work outside of XWayland server. | |||||
Affected: | X11 | |||||
Related links: | ||||||
Discussion: | E.g. if we have shown some popup menu, it will be closed upon clicking on any of XWayland's windows. But it will not be closed if we click on some other window from Wayland.
For a first look this workaround seems to work reliably except only one case: clicking on window's title containing origin component does not lead to focus change, thus we don't hiding a popup.
| |||||
Solution: | ||||||
Workaround: | Dismiss menu on focus lost event |
JDK-8280988 [X11 compatibility]: Click on title to request focus test failures
JDK-8280987 [X11 compatibility]: crash when mapping a lot of windows
// gcc windowSpawnDoS.c -o windowSpawnDoS -lX11 && ./windowSpawnDoS
#include <X11/Xlib.h>
#include <unistd.h>
int main(void) {
XInitThreads();
Display* dpy = XOpenDisplay(NULL);
Window root = DefaultRootWindow(dpy);
for (int i = 0; i < 500; ++i) {
Window ww = XCreateSimpleWindow(dpy, root, 50, 50, 50, 50, 0, 0, 0);
XMapWindow(dpy, ww);
}
for(;;) {
XEvent e;
XNextEvent(dpy, &e);
}
}
It may be faced when running some tests which are trying to map a lot of windows, e.g. one for every GraphicsConfiguration.
If you have 210 GraphicsConfigurations per display on Xwayland, then running such test in 2 display configuration will lead to crash.
Fixed:
JDK-8280985 [External][X11 compatibility]: Wayland crash on huge window
Problem: | System session crashes when trying to display a huge window |
Affected: | X11(external) |
Related links: | xorg/xserver/-/merge_requests/754, wayland/wayland/-/merge_requests/179 |
Discussion: | // gcc hugeFrame.c -o hugeFrame -lX11 && ./hugeFrame #include <X11/Xlib.h> #include <unistd.h> static Display* display; int main(void) { int width = 22000; int height = 25000; display = XOpenDisplay(NULL); Window win = XCreateSimpleWindow(display, DefaultRootWindow(display), 0, 0, width, height, 0, 0L, 0L); XMapWindow(display, win); XFlush(display); sleep(1); }
where -2094967296 looks like an integer overflow of 4 * 22000 * 25000 So it fails to create a pool, but doesn't handle it gracefully. |
Solution: | external fix released |
Workaround: |
JDK-8280994 [External][X11 compatibility]: Drag and Drop java → Wayland does not work
Problem: | Drag and drop from java to Wayland apps does not work with current JDK implementation. |
Affected: | X11(external) |
Related links: | GNOME/mutter/-/issues/2042, GNOME/mutter/-/merge_requests/2124 |
Discussion: | |
Solution: | external fix released |
Workaround: |
JDK-8281612 [External][X11 compatibility]: Drag and Drop, drop performs to a wrong window from X11 client
Problem: | Can't perform a Drag and Drop operation from X11 client to a Wayland client if there is an intermediate window during the drag. |
Affected: | X11(external) |
Related links: | GNOME/mutter/-/issues/2136 |
Discussion: | |
Solution: | external fix released |
Workaround: |
JDK-8280992 [External][X11 compatibility]: Custom cursor might be displayed in wrong color
Problem: | Custom cursor(e.g. loaded from GIF) set by Component#setCursor might be displayed in wrong color. |
Affected: | X11(external) |
Related links: | /xorg/xserver/-/issues/1303, MR |
Discussion: | For example on following screenshot X shaped cursor should be displayed in yellow: Reported as /xorg/xserver/-/issues/1303 |
Solution: | external fix released |
Workaround: |
JDK-8280991 [External][X11 compatibility]: fake configure event for XRandR emulation
Problem: | We are not getting updates from the system after "changing" screen resolution via XRRSetScreenConfigAndRate . |
Affected: | X11 (external) |
Related links: | xorg/xserver/-/merge_requests/731, xorg/xserver/-/issues/1305 |
Discussion: | Excerpt from Olivier's mail:
This notification would be helpful. This MR adds notification, however it has several issues:
|
Solution: | external fix released |
Workaround: |