feat(capture): allow restricting input to host - #493
Draft
TibiIius wants to merge 1 commit into
Draft
Conversation
* when pressing the jail bind, all input is jailed to host and not relayed to clients
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I came from Barrier to this project since Barrier is no longer maintained and does not work on the Wayland compositor I use. So far I'm very happy with my switch! :)
One feature I'm currently missing however is having a key bind to allow restricting all input to the server/host system on-demand. I gave it my best effort trying to implement this feature here. One drawback currently is that modifier keys do not sync to their state but rather just toggle the restriction on/off, as I've not been able to find a way to easily read the state of a modifier. This means that if you'd start Lan Mouse with scroll lock engaged (assuming scroll lock is the bind used), the toggle logic is reversed, i.e. scroll lock on -> restriction off, scroll lock off -> restriction on.
I'm marking this as a draft for now as I have yet to actually test it. I mainly created the PR in such an early state to avoid wasted/redundant effort in case someone else wants to implement this feature as well.
Disclaimer: I used a coding agent mainly to get an overview about what I can work with more quickly (structs, pub functions, etc) and to refactor. I have manually verified all changes made. The edge-trigger logic was suggested by AI, so I am unsure as to whether this is actually needed (i.e. if holding down the key bind would otherwise toggle the state repeatedly).