5 ms·

I suffer from the limitations of both X11 and Wayland. Some things work in one and not the other, it's a trade off. In Wayland I can use different scaling for e

I suffer from the limitations of both X11 and Wayland. Some things work in one and not the other, it's a trade off. In Wayland I can use different scaling for each monitor (in exchange for a LOT of RAM). But in X11 I can use Barrier to share my mouse / keyboard with my other computer. So I use one when I have a second monitor and have to restart my session when I use a second computer :'( Please fix this!

superkuh 3y ago
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 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 ago
      Sounds justified. How is the implementation?
jsrjenkins 3y ago
Can't you just set the dpi in each display with X11?
Rondom 3y ago
Take a look at input-leap. It has experimental support for Wayland.

superkuh 3y ago

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 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 ago
    Sounds justified. How is the implementation?

jsrjenkins 3y ago

Can't you just set the dpi in each display with X11?

Rondom 3y ago

Take a look at input-leap. It has experimental support for Wayland.