[HN Gopher] LAN Mouse: Mouse and keyboard sharing software
___________________________________________________________________
LAN Mouse: Mouse and keyboard sharing software
Author : galdan
Score : 45 points
Date : 2024-01-02 13:26 UTC (9 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| galdan wrote:
| Lan Mouse is a mouse and keyboard sharing software similar to
| universal-control on Apple devices. It allows for using multiple
| pcs with a single set of mouse and keyboard. This is also known
| as a Software KVM switch.
|
| The primary target is Wayland on Linux but Windows and MacOS and
| Linux on Xorg have partial support as well (see below for more
| details).
|
| Goal of this project is to be an open-source replacement for
| proprietary tools like Synergy, Share Mouse.
|
| Focus lies on performance and a clean, manageable implementation
| that can easily be expanded to support additional backends like
| e.g. Android, iOS, ... .
|
| blazingly fast(tm) because it's written in rust.
| superkuh wrote:
| > proprietary tools like Synergy
|
| Synergy 1.x still exists and is completely open source. It
| compiles and works on desktop OSes from 1998 to 2024. Synergy 2
| is the commercialized one.
| tzzek wrote:
| You can also use its forked version here:
| https://github.com/debauchee/barrier
|
| I use this between my Windows, Mac and Wayland(Sway)
| computers.
| packetlost wrote:
| It... doesn't work with wayland? At least not as far as
| I've been able to get working
| tzzek wrote:
| Hmm I could be mistaken, perhaps it was when I still was
| on X..
| resonanttoe wrote:
| Barrier is succeeded by input-leap
|
| https://github.com/input-leap/input-leap
| feschber wrote:
| Yes, you are right. I probably should have stated that more
| clearly. (I did mention input-leap though, which is a fork of
| synergy 1.x as far as I'm aware)
| jvanderbot wrote:
| Honest question:
|
| Is the "blazingly fast" tagline satirical? Like, how would I
| compare the "fastness" of this implementation? I assume
| latency? Is Rust as a language choice the predominant minimizer
| of latency or is the dividing line between systems-level stuff
| (C, Rust, Cpp) or optimized networking (Go, etc) versus higher
| level stuff (python, etc).
| jvanderbot wrote:
| I am a part-time rust programmer at best, and it was my
| understanding of the Rust design that it goes something like
| "Systems programming and memory safety without sacrificing
| performance" not "automatically faster", unless you compare
| only to "memory safety without performance guarantees" e.g.,
| Python, JS/CLI, Java, etc. It seems to me that Go lives in
| this same domain where it intersects networked systems
| programming.
| feschber wrote:
| Yes, it's meant satirical (mostly). Simply because its rust
| and people say rust is "blazingly fast".
|
| It still is quite fast though I would say (I have not
| compared it to anything else though).
|
| While moving a 1000Hz polling rate mouse, the cpu usage is
| about 2% of a single core on my machine (according to htop).
| It also uses udp to get the lowest possible latency (which
| e.g. barrier / input-leap does not afaik).
| jvanderbot wrote:
| OK. Thanks for clarifying. That makes sense, sorry for
| being humorless!
|
| If you're looking to prove seriousness of the speed, I
| don't think CPU %, polling rate, or UDP-guesstimates are
| what you want. You probably want RTT measurements, which
| for I/O with mice via LAN is probably a little wonky to get
| and I guess will be dominated by network.
|
| You could instrument your code and get latency b/w UI
| callback / USB poll and the time the packet hits the OS
| buffer / is written out (and reverse on receiver side).
| That's kind of the only meaningful metric that matters for
| I/O code and would ignore network effects, and here CPU
| time is a hard proxy to use.
| feschber wrote:
| Yeah I was planning to do some RTT measurements at some
| point but have not gotten round to implementing it. Would
| be great to have that directly in the ui as well!
|
| As you said, I was thinking to get capture->send latency
| and receive->emulate latency and subtracting that from
| the RTT to get an estimate of both network and system
| latency (without the compositing / presentation latency
| of course which is likely the largest part without some
| 500hz monitor).
| 20after4 wrote:
| You might take some inspiration (or some code) from
| https://github.com/htrefil/rkvm
|
| I've used it and it works pretty well, is written in rust,
| and it has one big advantage - by emulating the keyboard
| and mouse at the linux evdev layer it avoids touching any
| of the desktop-specific apis. (It also has encryption,
| though over TCP so has issues with managing connections. I
| think your choice of UDP was a good one)
| superkuh wrote:
| It says the target is wayland. But which wayland? The set of
| waylands that support "complex" input device behaviors with
| libei? Or the set of waylands that hate libei (sway, etc) and
| will never use it and still plan to roll their own "someday"? And
| on top of that, will it require libportal with the InputCapture
| PR? Or xdg-desktop-portal on the other side? I guess what I'm
| saying is that there's no such thing as "wayland support" for
| complex input device since "wayland" the standard doesn't support
| it. There is only support for some subset of the waylands
| bodge/workarounds.
|
| It's a shame to see each Wayland DE become it's own incompatible
| thing. Even the lan-mouse readme's OS support table separates
| them as if they were their own OSes. Good luck in your very
| complex multi-faceted endeavour.
| Karliss wrote:
| If you scroll slightly down the readme explains which desktop
| environments are supported and using which wayland protocol
| extensions.
| feschber wrote:
| Developer of lan-mouse here: I initially started working on
| this project with only wlroots compositors in mind or more
| precisely - any compositor that supports the layer-shell
| protocol could be used for capturing input - any compositor
| that supports wlr-virtual-pointer and virtual-keyboard could be
| used for input emulation
|
| The main motivation was really to learn more about wayland at
| that point.
|
| Then later I started to expand the project to support
| additional backends for e.g. Windows and MacOS (which currently
| only support input emulation) and of course Libei to get Gnome
| working as well (and likely KDE in the future).
|
| For input emulation there is also support for the xdg-remote-
| desktop-portal which seems to be the only option for emulating
| input on KDE wayland until libei is supported there.
|
| Input Capture using Libei is WIP since the whole project and
| particularly also the Rust bindings are in a pretty early state
| right now (thank you so much ids1024 for providing the reis
| libei bindings, if you are reading this!)
|
| I agree, it's a shame that Wayland is so fragmented among the
| different DEs. Especially wlr-layer-shell support would be very
| nice to see on the Gnome Side (it was much easier to work with
| than libei!...) but I'm pretty sure that's not going to happen.
|
| On the other hand I must also say that supporting wayland
| through the mentioned interfaces was a more pleasant experience
| than supporting Xorg with hacks like Xtst (Except for the
| broken implementation of the remote desktop interface in xdg-
| desktop-portal-kde maybe, which left me with permanently stuck
| keys several times...) and I'm still figuring out input capture
| which is likely also going to rely on more hacks than the
| wayland side of things.
|
| I have also played with the idea of writing some sort of
| wlroots -> libei bridge that implements an eis server using the
| mentioned wlroots specific protocols. This would reduce the
| amount of backends required in lan-mouse but add an additional
| layer of indirection between the application and the
| compositor, so I'm not sure its such a great idea. For the
| foreseeable future, I will definitely keep support for
| everything within lan-mouse itself.
| nashashmi wrote:
| Setup requires installing the software on each terminal, plus the
| keyboard/mouse host computer. After all terminals are connected
| to host, the keyboard mouse inputs will be transferred to the
| selected terminal.
|
| All connections are via LAN. The display of the terminals on the
| host is not included.
| rjmunro wrote:
| What happened to x2vnc or Win2VNC which used to let you control
| any client system that supported VNC from X or Windows
| respectively?
| xnzakg wrote:
| Or x2x!
| iancmceachern wrote:
| Isn't there a Microsoft native thing that can do this?
| w4rh4wk5 wrote:
| For sharing a mouse/keyboard between Windows PCs, there is
| Mouse Without Borders. It's included in PowerToys nowadays.
|
| https://github.com/microsoft/PowerToys
| ghusbands wrote:
| I use it a lot and currently don't recommend it. If one of
| the computers is a laptop that goes into sleep, when you
| bring it back out of sleep it will, most of the time, be
| unable to find the other computer(s) (and will claim they
| cannot be found) until you exit Mouse without Borders and
| relaunch it (Edit: on the laptop). At least, that's my
| experience. I'm about to try switching to Barrier.
| metal_am wrote:
| Mouse Without Borders has been ubiquitous on all the SEMs
| I've used (where up to three computers can be used together).
| I've never had any problems with it. Now, the SEMs on the
| other hand...
| ballenf wrote:
| I still want a way to use multiple mice on the same machine at
| the same time. With multiple pointers. Focus follows whichever
| pointer moved last. In the end I want a separate mouse for each
| of two large monitors. And also makes pair programming easier.
| stavros wrote:
| Why multiple mouses when only one window can have focus?
| ballenf wrote:
| Mainly so that the mouse on one monitor stays put when I'm
| working on the other.
| yonatan8070 wrote:
| You can probably make an AHK script to replicate that
| behavior and change monitors with a keyboard shortcut or a
| mouse side button
___________________________________________________________________
(page generated 2024-01-02 23:02 UTC)