Open Unsolved Problems

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 it's 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.

java.awt.Robot emulating keyboard/mouse events

It mostly works for X11 compatibility mode(except when trying to reach outside XWayland and windows are not restacked on emulated mouse click).

Looks like the solution for native Wayland client will be libEI

HiDPI in X11 compatibility mode.

Quote from Maxim Kartashev's e-mail:

There's a quality-of-service problem with running via the compatibility layer as
under certain circumstances native X windows look blurry.

Users with small(ish) HiDPI displays tend to enable fractional scaling and with
that enabled (regardless of the actual scale), XWayland pretends that the screen
size is smaller and then pixel-stretches the resulting window according
to the global scale. This works as a temporary solution, but people get quickly
tired of looking at text that is blurry.

See https://gitlab.gnome.org/GNOME/mutter/-/issues/402 and
https://github.com/swaywm/sway/issues/5917 for some more details.

Popup menu dismiss in X11 compatibility mode.

We are using 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.

Fake configure event for XRandR emulation

We are not getting updates from the system after "changing" screen resolution via XRRSetScreenConfigAndRate.

Excerpt from Olivier's mail:

Also worth noting that the XRandR emulation is per window/X11 client, whereas the root window is shared between all X11 clients, but maybe we could send a fake ConfigureNotify event to the given client, I would need to check if that's doable.

This notification would be helpful.

Wayland crash on huge window

Here is not much to discuss, it's just a bug which crashes the whole GUI. Didn't report it yet.

// 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);
}

/var/log/syslog shows:

gnome-shell[1248]: WL: error in client communication (pid 1248)
gnome-shell[1298]: (EE)
gnome-shell[1298]: Fatal server error:
gnome-shell[1298]: (EE) wl_shm@5: error 1: invalid size (-2094967296)
gnome-shell[1298]: (EE)

where -2094967296 looks like an integer overflow of 4 * 22000 * 25000

So it fails to create a pool, but doesn't handle it gracefully.