Client not working on Wayland (Swaywm)

[BrendanBall]

Hey, thanks for sharing this project, it's exactly what I've wanted for a while.
Unfortunately it (both keyboard and mouse) doesn't currently work for me when using Wayland (Sway).
I've tested that it works for me using X (i3).

Have you tested rkvm on Wayland at all?

My setup:
Server: X (i3)
Client: Wayland (Sway)

Additionally, on Wayland I've tested that libinput is indeed receiving the events using libinput debug-events.
I'm not really sure where the problem lies, but when I was trying to reimplement barrier in rust (it's just a prototype) a while ago, I remember having lots of trouble with this. It's a little different because it uses absolute events for the mouse due to how barrier works, but seen as the keyboard also doesn't work with rkvm that difference probably doesn't matter too much. I just tested my barrier-rust prototype on a Wayland client and the mouse does work.

I think it might be with how you setup the virtual input devices because I remember it being really finicky, e.g. even though libinput receives the events, some other system (maybe Wayland or the specific compositor or something?) doesn't read the events if the device doesn't conform to some heuristic based on its capabilities, e.g. If you try create a mouse without a left button it will ignore mouse events from that device. Unfortunately I didn't document exactly what I found so I can't be sure.
In this case it might be that you created a single virtual device for both the keyboard and mouse, instead of separate virtual devices for each.

Do you have any thoughts on this?

[Jaakkonen]

This worked with Sway when I tested it like 2 months back. However it's no longer working and is just freezing the server side Sway even when no clients are connected.

[BrendanBall]

I've got a branch where I've separated the mouse and keyboard into separate devices and modified the supported event types for each and this makes it work on sway. I'm not sure whether it's sway specifically or wayland or wlroots etc and I'm not sure whether this is a bug or expected behaviour, but I'm probably going to use this branch and clean this up some time so that I at least have a usable kvm system with wayland. The keyboard supported events still needs to be expanded on my branch though to work 100%.

[BrendanBall]

After doing some binary searching on enabling ranges of key types for the keyboard, I have found that the issue seems to be trying to enable key types that don't exist with the range [0..KEY_MAX]. E.g.
Given the snippet:

#define KEY_ROTATE_LOCK_TOGGLE	0x231	/* Display rotation lock */

#define KEY_BUTTONCONFIG		0x240	/* AL Button Configuration */

when enabling the range [0..=KEY_ROTATE_LOCK_TOGGLE] then the keyboard works, but the range [0..=KEY_BUTTONCONFIG] no longer works.
The range [0x232..=0x239] of key events don't seem to exist.

So I would say this is a bug with rkvm. It's more work, but we should probably enable events in a type safe way rather than just using ranges, unless you can do both.

[seiichiro0185]

I can report the same for Gnome 40 on Wayland (Archlinux) as Client (Archlinux with XFCE as Server) - Using the version from this repository does not work, the switch seemingly happens, but mouse and keyboard don't work on the Client Side. Using the Branch from @BrendanBall with separated Mouse and Keyboard Devices does work.

Edit: Well, works mostly. With this branch some keys stop working, like e.g. the Arrow keys. I suspect this has something to do with the mentioned supported keyboard events that need to be expanded. Is there any Solution for this yet?

[Nelson-Morais]

@BrendanBall did you ever managed to take a look at the key ranges ? This is the only kvm solution working on my wayland client ( thanks to your branch ) and now im just missing some of my keys to be completely happy for now :D

[BrendanBall]

My setup has changed so I no longer need rkvm/barrier. I haven't looked at this in a long time, but from rereading this, I believe my branch was just to test whether using proper key ranges fixes the issue with wayland. I don't think I ever finished the work.
So you'll have to build on my branch to include all the valid key ranges for a keyboard.

[Nelson-Morais]

@BrendanBall alright, I might fork the project and take a look at it sometime soon, this is still the only kvm working on wayland so far which is kinda absurd.
Appreciate your efforts !

[jimdigriz]

I am using this with no problems between two Debian "bookworm" 12 systems running the distro packaging for sway (version 1.7). Using rkvm commit ec11f26 which is a little later than the tagged release of 0.3.2.

To get it to compile, I did have to include some pinning (/etc/apt/preferences.d/99pin) to deal with your "hey it's Tuesday" Rust build breakages (clap_lex requires Rust 1.64 or later)... :-/

Package: rustc libstd-rust-dev
Pin: release o=Debian,a=unstable
Pin-Priority: 900

[AkechiShiro]

Could there be a fix put upstream on rkvm @jimdigriz ?
Like, it feels like there is only more fragmentation in this open source effort, everyone is forking/branching but no real effort is made to put the fixes upstream ?

[jimdigriz]

@AkechiShiro I do not understand what you mean by "fix put upstream", no fixes are needed to the project to make it work.

As for "everyone", it looks like two (2) people have forked the project and actively done anything with it, one of those forks is a pending PR so again confused what you are referring to here?

[jimdigriz]

@AkechiShiro I see there are some earlier forks with useful work, but you have to remember, htrefil/rkvm is not our project its @htrefil so they get to decide what helps them. We are all just secondary concerns...people who nag and whine and are best ignored for ones own sanity :)

Forks are good thing. Everyone wants someone from a given project and that venn diagram rarely overlaps 100%, so they should be encouraged!

i would suggest building your own fork and merge in all the other work you are interested in.

[AkechiShiro]

Sorry @jimdigriz if I came of as rude here but I thought there was no pending PR about the fixes mentioned here.

You also mentioned an issue with compiling, if I can get to fix this and there is no PR, I'll put one.

I'm not against forking but if this project is still actively maintained then, there people forking and fixing bugs should PR, they're not forced to PR but I believe they should do that effort.

Now if the maintainer does or doesn't pick up the PR that is another matter.