[superkuh]

It will be fixed on some Waylands with libei, but it will never be fixed on other waylands that find libei distasteful (like sway). And that's the waylands in a nutshell: many different things, never "wayland" always "waylands".

[westurner]

libei looks useful. But IDK why libei is necessary to run Barrier with Wayland?

For client systems, couldn't there just be a virtual /dev/input/XYZ that Barrier forwards events through

And for host systems, it looks like xev only logs input events when the window is focused.

Is xeyes still broken on Wayland, and how to fix it so that it would work with Barrier?

With Barrier, when the mouse cursor reaches a screen boundary, the keyboard and mouse input are then passed to a different X session on another box until the cursor again crosses a screen boundary rule.

Barrier is a fork of Synergy's open core: https://github.com/debauchee/barrier

libei: https://libinput.pages.freedesktop.org/libei/

[yencabulator]

> For client systems, couldn't there just be a virtual /dev/input/XYZ that Barrier forwards events through

You seem to be asking for kernel thing, not something Wayland. But let's assume you wanted a protocol on top of Wayland to do this:

Why can't arbitrary Wayland clients always see the mouse pointer, snoop on the keyboard, and inject keypresses? Because of security, by design.

Why is it taking a bunch of work to provide that capability in an access-controlled way? Because it's a bunch of work. For example, quoting libei: "However, the events are distinguishable inside the compositor to allow for fine-grained access control on which events may be emulated and when emulation is permitted."

[westurner]

Sounds justified. How is the implementation?