[Feature Request] Clipboard synchronization

[solacelost]

Feature summary

I would like to be able to synchronize clipboard contents (at least textual, if not binary also) between sessions, such that I can copy something from a client and paste it onto the server, or vice versa.

Design

I think that the synchronization should only occur on screen switch events, to prevent excessive communication. I do not know enough about rust libraries that would support the buffer for managing this data stream before interaction with the appropriate client libraries.

Anticipated problems

Wayland and xfree86 implement completely different clipboard mechanisms with different architectures and even behaviors. I believe a complete implementation would need an abstraction that sits between rkvm and the window system, which is a pattern you have managed to avoid for input between the two. I do not immediately know of a way to do it without relying on, for example, a third-party clipboard manager, that doesn't involve tackling this complexity.

Notes

You didn't have an issue template, so I just tried to keep this organized enough that I'd be happy with it :)

[htrefil]

Hi, thanks for the suggestion!

I'm afraid this would require a much closer integration (and all its' pitfalls) with the display server, which is what I've been trying to avoid. rkvm should be able to work even if you're using some obscure display server from the 80's or none at all and just a tty.

This, though, could be countered by having a separate process to manage the X/Wayland/whatever keyboard and communicate with rkvm using some IPC mechanism and make the format simple so that even a shell script could do it. That would keep the architecture modular, optional and easily replaceable without needing to dig into rkvm server or client's internals, which should remain DS agnostic.

I will dig into it by the end of the week, but of course, PRs and suggestions are welcome at any time. :)

[martininsulander]

FYI There are other tools, f.ex. kdeconnect that can do clipboard sharing. Sometimes it works really well.

For implementation, it would maybe be better to have some kind of plugin interface to share anything. Then people can add f.ex. clipboard support for gnome/kde wmroots etc. or videocam or something else, keeping the input sharing lean.

[digitalsignalperson]

Something along the lines of a simple IPC mechanism as mentioned above makes sense. For example:

Assume people can redirect their clipboard via wl-paste for wayland or xclip for xorg. Provide a fifo/pipe where any standard input written is auto-typed by rkvm. Have a config param for millisecond interval between keys? Or maybe not even because you can delay pushing each character over stdio as needed. The result is rkvm is agnostic about window managers and clipboards, and it just provides an interface to send simulated keys on demand. And it's up to the user to determine what they want to type (e.g. clipboard or otherwise) and how (custom scripts, permissions, daemons, ..., or even a password manager plugin). Maybe there's some use for this auto-type ability for unit testing as well.

This idea crossed my mind thinking about password managers. Thinking of being able to have an isolated system with your password manager (e.g. KeepassXC) and sending individual passwords to another computer which never sees the master password or password database. And if it's with rkvm which is light weight enough that you can review the code and decide if you want to trust it or not. This feels better than, e.g., a suggestion I see for android phones to use keepass2android and an InputStick (closed source hardware and software) to autotype passwords over bluetooth to a USB dongle plugged in a PC. My next question would be, can rkvm run on a Raspberry Pi :)

Well there should be a solution outside of modifying rkvm too. I haven't looked into it, but maybe there's a simple way to create a virtual keyboard, be able to generate key events with it, and rkvm already will do the job of detecting that input device and sending the events.

Edit: ydotool probably works? it creates a virtual input device with /dev/uinput