|
|
|
|
|
|
by westurner
913 days ago
|
|
|
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/ |
|
|
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."