search

htrefil / rkvm

Virtual KVM switch for Linux machines
MIT License
414 stars 51 forks source link

Windows #2

Closed awsomearvinder closed 3 years ago

awsomearvinder commented 3 years ago

Hi! I like the project and would absolutely be willing to contribute, but I was wondering if windows support is planned? I have a windows machine next to my linux machine on two seperate systems, and I would love to be able to use rkvm as barrier and synergy don't work well with wayland.

htrefil commented 3 years ago

Hello! Yes, Windows support is planned and welcome. Client support could be implemented first as it's the easiest part -- it would only involve translating the events into Windows' native structures (key codes are documented here) and then send them using the SendInput API.

Overall it should be quite straightforward to do, except for translating the Key and Button enums into Windows' native key codes. rkvm uses keycodes generated from the Linux headers and it's sometimes not clear which Linux keycode would be the equivalent on Windows. Also the set of keys that Linux defines is much larger than the one of Windows, so some events would be ultimately lost and it should be decided what to do with such keys (propagate them server or silently swallow it and do nothing).

Regarding Windows servers, the situation is less clear as I'm not aware of any API that would allow us to grab and filter input events and I'd like to avoid solutions such as injecting a DLL into every windowed application and hook input events from there which, IIRC, is what Synergy or Barrier does.

awsomearvinder commented 3 years ago

Perfect, I'll take a stab at the Client support tomorrow then. I appreciate the in-depth response!

awsomearvinder commented 3 years ago

Looking through the input library, everything seems super Linux specific. Would you be willing / would it be possible to just move the current code into a separate Linux-input library and have a library for each platform, and then making a single lib on top that just ties them all together? The other easy option is trying to make a separate input library that is fully API compliant but just uses windows under the hood, and then using a #[cfg] to switch at comp time.

If not that's fine too, currently I'm trying to make input library itself be able to switch to windows, but it's not going super well.

Edit: On second thought I might just call it here, I do like the code quality though, and a part of me doesn't want to mess it up by redesigning the architecture willy-nilly after it's been implemented.

htrefil commented 3 years ago

Why do you think there is a reason to turn it into separate libraries?

Overall you only need to only conditionally compile the impls of EventWriter, Event, KeyKind, Key and Button. Sounds like a huge list, but it isn't, really.

Just make Event::to_raw() return a INPUT instance instead of input_event on Windows and do the same for the impl of EventWriter and write it with SendEvent.

awsomearvinder commented 3 years ago

The reason why I was thinking that was due to the only thing the two implementations seemingly would share was event manager, and maybe the event enum itself. Everything else seemed to be more or less platform specific to me. Just throwing #[cfg()] everywhere seemed to more or less make the entire codebase but the event_writer file filled with them. (The only other files that didn't have them was due to it not being required since the goal is only to make a client impl right now). I might take another stab at it later, but I have a few exams coming up I have to study for.

I appreciate all the input you're giving me though!

htrefil commented 3 years ago

I implemented Windows client support in the 0.2.0 release, so closing this.