Wayland Roadmap

[kwhat]

It looks like Wayland is now the default option on several distributions and supporting it is becoming more of a priority. There are still a number of features missing from the Wayland ecosystem and fragmentation is going to be a real problem for any software trying to support multiple compositors. Getting this library to work with Wayland is going to require a combination of runtime dependency loading, XDG Portals and cutting features that aren't available. I have created this bug to track the progress of the outstanding issues. Please add any information or ideas you may have to this ticket.

• hook_create_screen_info(unsigned char *count);

Support Added

Support was added using wl_output_interface provided by Wayland. This provides enough information to satisfy this requirement.

Gnome/GTK Support

gdbus call -e -d org.gnome.Mutter.DisplayConfig -o /org/gnome/Mutter/DisplayConfig -m org.gnome.Mutter.DisplayConfig.GetCurrentState

We need to use something like glib g_variant_get() https://github.com/fzwoch/obs-gnome-screencast/blob/master/gnome-mutter-screencast.c#L90 to pare this information.

Plasma/QT Support

Unknown

X11

Continue to use XRandr / Xinerama but change the code to use dlsym and convert from a compile time dependency to a runtime dependency.

Other Compositor

Unknown, we may need to cut this feature unless we can use XDG Portal to acquire monitor info.

---

• hook_get_auto_repeat_rate();

Gnome/GTK Support

Unknown

Plasma/QT Support

Unknown

X11

Continue to use XkbGetAutoRepeatRate / XF86MiscGetKbdSettings but change the code to use dlsym and convert from a compile time dependency to a runtime dependency.

Other Compositor

Unknown. As it currently stands, this feature will likely be removed from all platforms.

---

• hook_get_auto_repeat_delay();

Gnome/GTK Support

Unknown

Plasma/QT Support

Unknown

X11

Continue to use XkbGetAutoRepeatRate / XF86MiscGetKbdSettings but change the code to use dlsym and convert from a compile time dependency to a runtime dependency.

Other Compositor

Unknown. As it currently stands, this feature will likely be removed from all platforms.

---

• hook_get_pointer_acceleration_multiplier();

Gnome/GTK Support

Unknown

Plasma/QT Support

Unknown

X11

Continue to use XGetPointerControl but change the code to use dlsym and convert from a compile time dependency to a runtime dependency.

Other Compositor

Unknown. As it currently stands, this feature will likely be removed from all platforms.

---

• hook_get_pointer_acceleration_threshold();

Gnome/GTK Support

Unknown

Plasma/QT Support

Unknown

X11

Continue to use XGetPointerControl but change the code to use dlsym and convert from a compile time dependency to a runtime dependency.

Other Compositor

Unknown. As it currently stands, this feature will likely be removed from all platforms.

---

• hook_get_pointer_sensitivity();

Gnome/GTK Support

Unknown

Plasma/QT Support

Unknown

X11

Continue to use XGetPointerControl but change the code to use dlsym and convert from a compile time dependency to a runtime dependency.

Other Compositor

Unknown. As it currently stands, this feature will likely be removed from all platforms.

---

• hook_get_multi_click_time();

Gnome/GTK Support

Bus Name: org.freedesktop.portal.Desktop
Object Path: /org/freedesktop/portal/desktop
Interface: org.freedesktop.portal.Settings

Read("org.gnome.settings-daemon.peripherals.mouse", "double-click")

Plasma/QT Support

Unknown

X11

Continue to use XtGetMultiClickTime / XGetDefault but change the code to use dlsym and convert from a compile time dependency to a runtime dependency.

Other Compositor

Unknown. This is kind of a critical feature for tracking click count for mouse events. If we cant find a solution to this problem, we will have to drop the click count tracking from events.

[kwhat]

This project is probably dead and Wayland killed it. There is no feasible why to support non-retaliative mouse movement in a compositor agnostic way. I naively though that if I could obtain the current pointer position I could calculate the subsequent position based on the relative movement. Unfortunately, that isn't possible due to acceleration and scaling applied at the compositor level. The only way to continue development would be to target each compositor individually which would require porting this library to C++ causing even more issues for everyone using it. You might be asking yourself: "But what about XQueryPointer?" After all, Wayland supports most of the X11 API right? Well, it doesn't work properly in my tests. Take the following basic C program and build it with gcc -lX11 test.c

#include <X11/Xlib.h>
#include <stdio.h>

int main(void) {
    Display *disp = XOpenDisplay(NULL);
    Window screen = DefaultRootWindow(disp);  // to To access the home screen 
    int x, y, winX, winY;
    unsigned int mask;
    Window child;
    XQueryPointer(win, screen, &screen, &child, &x, &y, &winX, &winY, &mask);
    printf("\nx: %d, y: %d\n", x, y);
    XCloseDisplay(win);
    return 0;
}

It doesn't matter where I move the mouse, I always get x: 2560, y: 547 as my output. Why 2560 and 547? I have no idea but the same program works correctly under X11. If we ignore that problem and just go with relative mouse movement, there really isn't much difference between where this library ends up and the existing and better supported HID libraries that are already out there. Unless a project like xdg-desktop-portal can come up with a solution, I see no way forward with this project or its child projects. Wayland was a nice idea created by a bunch of academics who have spent more than a decade solving a problem no one had.

[raphaelmenges]

I have no idea about the details, but the mouce crate seems to have a Wayland compatible mouse hook: https://github.com/emrebicer/mouce/blob/master/src/nix/uinput.rs

[kwhat]

@raphaelmenges This comment basically sums up the problem.

// For some reason, absolute mouse move events are not working on uinput
// (as I understand those events are intended for touch events)
//
// As a work around solution; first set the mouse to top left, then
// call relative move function to simulate an absolute move event

The reason this doesn't work is because uinput has no idea what the resolution or scaling of the monitor is. The "work around solution" only works if the scaling of the monitor is at 100% and the mouse sensitivity / acceleration is 1:1. This is the same problem that I've been battling with. I can determine the current mouse position and monitor sizes and ordination, however, if I just move the pointer +/- x or y pixels based on uinput we eventually get out of sync. How many screen pixels +217 x, +445 y ends up being from 0, 0 is not necessarily 217, 445. I could very easily be 434, 890 if the acceleration is 2x.

Wayland seems like it was very much designed to kill access to information programs like this library depend on, all in the name of security! They set out to prevent key logging and still failed to do so. They feel that raw input (HID) should be more than enough information for any program requiring this sort of info and that programs should only be aware of the windows they own. It is very much of a Java style sandbox for the entire graphical environment. You can track mouse movements across a window you draw with the correct scaling and acceleration, but as soon as you leave the bounds of that window, the input is no longer available. I tried to use this concept to draw a window that covers the entire screen for a frame to acquire the absolute position and then use the uinput relative movement to track the mouse in a similar way as they code you posted, and it works to get the position but fails as the mouse moves if I play with scaling or acceleration. Because both of these are controlled by the compositor. It is up to Plasma, Gnome or one of the myriad of other compositors to provide that information and none of them do at this time. Even if they did it would be up to the compositor to provide the API, which all but guarantees there will be N+1 ways of pulling it in with no overlap which likely makes the fragmentation problem for this library insurmountable.

Let me ask all of you a question: What functionality does this library provide that cannot be accomplished with raw HID? On the surface, it seems like the only thing it provides over HID are absolute mouse coordinates and language support for key typed events. Why not just use HID? If I was to sit down and create this library again, I would probably just use HID instead as it fulfills all of the original requirements and several portable libraries already exist.

[raphaelmenges]

Thank you very much for the explanation @kwhat! I often read comments that Wayland can makes things more complicated or even impossible and it is interesting yet sad to read a well laid out example like this.