Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@fufesou
Copy link
Collaborator

@fufesou fufesou commented Oct 14, 2024

#8760

#9641

  1. The controlling side: send CapsLock and NumLock to the controlled side if it is Linux.
  2. The controlled side:
    (1) Wayland rdp input: handle the CapsLock and NumLock key events and ignore the lock states within the key events.
    (2) X11 or Wayland uinput: handle the lock states within the key events and ignore the CapsLock and NumLock key events.

Note: There's also a side effect that the led may be changed after the remote control. The same to #9641

Tests

Windows -> Linux, "Map mode" and "Translate mode"

  • X11
  • Wayland rdp input
  • Wayland uinput

TODO

  1. Remember the lock state before connecting? What if there're multiple controlling end.

@rustdesk
Copy link
Owner

rustdesk commented Oct 15, 2024

This PR is pending, because it is not really better than old. Both have big problem. Both have problem if local status not equal to remote, though this one seems a bit better (can work, but can not ensure local capslock status same to remote).

We need smarter solution

@hhypnos
Copy link
Contributor

hhypnos commented Apr 9, 2025

What about implementing a VirtualLockState system that manages lock states independently of physical keyboard LED indicators?

@hhypnos
Copy link
Contributor

hhypnos commented Apr 10, 2025

@fufesou
"1.Remember the lock state before connecting? What if there're multiple controlling end."
about this:
image

in each tab to be button of capslock and numlock and with virtual key management it will stay for each session

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants