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.