Client not working on Wayland (Swaywm) about rkvm HOT 12 OPEN

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.

from rkvm.

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%.

from rkvm.

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.

from rkvm.

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?

from rkvm.

@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

from rkvm.

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.

from rkvm.

@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 !

from rkvm.

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

from rkvm.

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 ?

from rkvm.

@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?

from rkvm.

@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.

from rkvm.

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.

from rkvm.