Closed Gerdathlete closed 4 months ago
Same problem, tough I'd not call the Delete key very "special", and rather essential. Tried changing Keyboard layout, and even though both machines have the same layout this changes it to some weird morph between the national layout and ... british? But now the delete key work again, so a minor success even though it's still unusable.
I can't replicate issue on my devices and previously this issue was reported only once maybe 2 weeks ago so it does not seem to be affecting everyone which is good but also means it might be harder to get to the core of the issue, especially as I can't replicate it personally.
@Brynyard @Gerdathlete could I ask you to use https://www.toptal.com/developers/keycode and let me know what 'Javascript Key Code' they print out on both devices related to the issue occurring on either of them? And let me know what Keyboard Layout you're using originally.
I've asked this the first person that reported the issue over email but received no response yet.
@ragauskl I strongly suspect the reason it doesn't work is because I run Windows with English as the language and Norwegian as my keyboard layout. This might sound like a very controversial choice, but it is fairly common amongst devs for practical reasons (we need our tools to work and not spew out very badly translated and obscure messages, yet we still need to occasionally communicate with other Norwegians).
Synergy also fails spectacularly at this (it crash if you type certain keys), and as Win32 doesn't really have an API to properly detect keyboard layout, some assumptions needs to be made. I made a patch for synergy for this, I'll attach a diff to synergy-core #ee19a40b it so you can see what I had to do. kbd_layout.diff.txt
When using the not-source (don't remember what it was called) option for layout, some buttons got jumbled around, some had UK layout, and some (for example AltGr+8 which in no layout means [) got mapped to sequences, Incidentally, Delete seemed to be mapped to a sequence of keys, it may be a artifact of Linux.
Unfortunately (for you), this kerfuffle (and this is not my first rodeo) just convinced me that SW based KVM is not the way (tm), I'll be building one of these instead: https://hackaday.com/2023/12/26/building-a-better-keyboard-and-mouse-switch/
I am using standard English layout on both systems. Here's what pressing "Enter" does: https://imgur.com/a/1yQqB04 Here's what pressing "backspace" does: Here's what "esc" does: And "tab":
If it helps at all, I am using a physical KVM that my mouse and keyboard connect into. It outputs 1 USB A cable and takes in two USB A inputs currently, the mouse and the keyboard. I'm using a tenkeyless (80%) keyboard.
@Brynyard I don't think it's an issue with the keyboard layout, English is not my native language so I also have multiple keyboard layouts, although I do use them rarely I'm aware of the fact that plenty of users will have different keyboard layouts for various reasons and where possible I do testing with multiple keyboard layouts.
To make sure it's not just keyboard layout I've tested all Norwegian layouts I could find on Windows, macOS and Linux (Ubuntu 20) - they all work as expected over KVM while the system language is set to English on all of the devices. All layouts printed out the same numbers for all keys mentioned using the website I provided in my first response, can you confirm if these are the numbers you see?:
enter - 13, esc - 27, tab - 9, backspace - 8, delete - 46
@Brynyard btw - kerfuffle - nice word, would have not guessed it's an English one 😄 thought it's some username or something until I googled it 😅 now I'll know
@Gerdathlete Could I also ask you to confirm - the screenshots are made on Ubuntu where they are simulated by Cursr? The screenshots indeed do indicate correct 'history' for Unicode codes for every key. Cursr can use the 'u+' shortcut on linux if in 'virtual switch' settings you have 'source' set for keyboard layout which is the default. Reason being - unlike macOS and Windows - Ubuntu does not allow printing out characters that are not present on the current keyboard layout, therefore to keep 'source' option working when different keyboard layouts are selected the unicode keyboard shortcut is used. But for Cursr to use that the key event has to be marked as printable character by device sending it, so Windows in this case, and lookup for keycodes should return empty result on Ubunut for this logic to get triggered as last resort. Anyway if that's the case it'll be a bug with Cursr that I'll need to look into.
However if screenshots are made on Windows device where key presses originate/physical KVM is connected to - it will be more likely issue with physical KVM.
Have you tried using Cursr without the physical KVM? Just to see if by any chance a compatibility issue?
Yes, the screenshots were from a ubuntu system running Cursr, with the mouse and keyboard connected to the windows machine, granted it also has the same issue when the mouse and keyboard is plugged into the ubuntu pc, and then Cursr is used to simulate keyboard input on the Windows machine.
I just confirmed that bypassing the physical KVM does not have any effect (still the same symptoms).
I had the keyboard layout in 'Source' mode. Changing the layout to 'Current' mode actually fixed the issue for me. When the target computer (that simulates the mouse and keyboard using Cursr) has 'Current' as its keyboard layout, everything works as expected.
UPDATE: right click is not working when the keyboard and mouse are plugged into the windows machine and the ubuntu machine is controlled via Cursr
I checked using an online mouse tester and what's happening is that right click is actually sending middle click and middle click is sending right click.
@Gerdathlete I can replicate the right-click/middle-click issue, that will be a quick fix to add with next release 1.7 coming out soon
I've also borrowed computer from a friend and actually managed to replicate the windows -> linux key issues so it's great news as it'll make the issue so much easier to fix now. I'll include a fix for this with 1.7 as well
I'll update this issue as well as soon as 1.7 with fix is out
@Brynyard this might fix your case as well, so let me know after 1.7 if it helped
1.7 is now available in pre-release mode, to allow update to pre-release you'll need to enable 'Early Access' mode in 'General' settings and 'check for updates' in 'About' settings section.
Alternatively you can wait for 1.7 to be released in stable mode as soon as some users test it and I make sure it's stable.
Fix now available in stable release 1.7, if no further comments are made on the issue in next 2-3 week I'll close it as complete
Describe the Bug/Issue
Steps to Reproduce
Expected Behavior
Backspace and enter function correctly between Windows and Linux computers
Screenshots https://imgur.com/a/Yt9jEb9
Your Environment
Additional Info
Seems that this character indicates the ability to type in the hex code of a unicode character: https://superuser.com/questions/685070/why-does-bash-sometimes-show-an-underlined-u
UPDATE: Its broken in both directions: when the windows pc has the mouse and keyboard and when the linux pc has the mouse and keyboard.