mirror of
https://github.com/jetkvm/kvm.git
synced 2026-03-02 22:58:00 -05:00
AltGr + key not working #406
Labels
No labels
component/keyboard-layout
component: cloud
component: device screen
component: extensions
component: hid/keyboard
component: hid/mouse
component: network
component: timesync
component: ui
component: updater
component: usb
component: usb/hid
component: usb/storage
component: video
component: webrtc
component: webserver
need-more-details
status: working-in-progress
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/kvm#406
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @enzo-digex on GitHub (Sep 19, 2025).
Disclaimer
Application version
0.4.6
System version
0.2.5
Device model
JetKVM
Extension model
None
Remote device Hardware
No response
Remote device OS
Windows 11
Bug description
Keyboard Layout: Swiss German
Steps to reproduce
Press "Right Alt + ^"
Expected Result
On the remote system, I get a "tilde" (~)
Observed Result
Nothing happens and the keyboard inputs stuck or are repeated till I press any key.
@walter824 commented on GitHub (Oct 13, 2025):
Problem is present also in App 0.4.9 dev and System 0.2.6, but now alt+gr+@ write ^@
(Italian Keyboard layout)
@Riyooo commented on GitHub (Nov 16, 2025):
I have a similar issue with a French keyboard, pressing AltGr + 0 should give @ but it outputs nothing (attached screenshot).
When I press AltGr the pressed keys show: "ControlLeft + AltRight + AltGr", but when I press AltGr on the virtual keyboard (which works) the pressed keys show: "AltRight + AltGr" only so no ControlLeft. As a result none of these special characters can be made using my physical keyboard ~#{[|`^@]}
I tried changing device identifiers just in case, without success.
Also I noted that the virtual keyboard is not in french although the button at its top right shows "français" (French). It seems to be in English layout (Qwerty).
@adamshiervani commented on GitHub (Nov 17, 2025):
@IDisposable can you take a look at this issue?
@walter824 commented on GitHub (Nov 17, 2025):
This issue makes JetKVM partially useless..
Il giorno lun 17 nov 2025 alle ore 10:10 Adam Shiervani <
@.***> ha scritto:
--
Walter Dallari
@.***
+39 348 450 2928
@Riyooo commented on GitHub (Nov 17, 2025):
@adamshiervani I tried looking into this issue and it seems to be caused by a particularity of windows, which always emits an extra synthetic ControlLeft event before every AltGr. Most targets don't interpret this as AltGr, so special characters fail to type.
As an example, pressing ControlLeft + AltGr + Digit0 on the virtual keyboard produces nothing, while doing so physically in Windows results in a special character as it also always interprets AltGr + Key as a special combination, wether there's a Control event with it or not.
I have deployed a small fix to my JetKVM device, which tries to detect and suppress that synthetic ControlLeft, and seems to work. Would you be interested in a pull request once I finish testing it ?
@adamshiervani commented on GitHub (Nov 17, 2025):
@Riyooo - A PR fixing this would be marvelous. If you keep it small and easily testable - we can merge it quickly. Appreciate it!
@IDisposable commented on GitHub (Nov 19, 2025):
As far as I can see, the special-casing code for AltGr was deleted a long time ago. There's nothing in 0.4.10 or later that does a forced LeftCtrl.
@eeyoresan commented on GitHub (Nov 20, 2025):
This is a common issue, when using non US-keyboards mainly on Laptops. There are a number of reports regarding this issue for lots of Software's.
Would it be possible to add add some configuration to map the combination of "CtrlLeft, AltRight, AltGr" to just "AltGr" or possible "AltRight+ AltGr" which is sent from the virtual keyboard?
If so this solution can be tested by users having this issue.
@IDisposable commented on GitHub (Nov 20, 2025):
What version are you running? There's no special case handling for AltGr, it's just sent through as the modifiers given by the browser.
@eeyoresan commented on GitHub (Nov 21, 2025):
Sorry, forgot to add versions
App: 0.4.8
System: 0.2.5
Since the key codes are printed as debug info at the bottom of the page I assumed they are read by the application before being sent to the device.
As show below when pressing AltGr on my keyboard CtrlLeft is also detected and sent to the device:
This is the behavior when virtual keyboard is used (no CtrlLeft is visible)
If the buffer is printed before sending it to the device, would it be possible to remove CtrlLeft if you get it combined with AltGr,AltLeft?
@IDisposable commented on GitHub (Nov 21, 2025):
The
Keys:shown reflects the is not characters, but HID codes by name which is mildly confusing. It is the keyswitch being pressed/held (e.g. the HID code being pressed). Since the AltGr and the AltRight are the exact same HID code, we "match" both of them and thus display both when translating the HID code back to a printable string... but in reality only the modifier state (the bitmask of which modifiers are active) and the keys-down HID codes are being sent... only the AltGr/AltRight keys-down HID code. See the code in InfoBar.tsxIn the bottom screen, you pressed the AltGr key (as defined by your Keyboard selecting in settings), and that key emits the AltGr HID code, which is the exact same numerical value as the AltRight key (gee, thanks IBM / HID committee!) so we don't really know a difference so it shows both.
The top screen is because Windows+Broswer is decomposing the actual physical AltGr key event into a ControlLeft key press event, then an AltRight key press event, so both keys are down, which we display (and again show both AltRight and AltGr).
I should tweak the code in InfoBar to figure out which key is "possible" from the layout and not print both. One way to do that is treat AltGr as if it was distinct key until the very last moment where we're emitting the HID codes in the USB write.
My next big change will be revamping this keyboard to allow any layout and properly display based on the Keyboard Layout/Locale and I'll fix this then.
There's far more detail than anyone should care about in this comment