4 ms·
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 Barrie
by westurner 3y 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 https://github.com/debauchee/barrier
libei:
https://libinput.pages.freedesktop.org/libei/ https://libinput.pages.freedesktop.org/libei/
- yencabulator 3y ago> 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 3y agoSounds justified. How is the implementation?