Ignores keyboard mapping and doesn't have a correct mapping in the keyboard settings

deekerman commented

2026-02-20 08:22:08 -05:00

Owner

Originally created by @plastikos on GitHub (Jun 27, 2025).

JetKVM somehow grabs the raw keystrokes before they are mapped. It does not have a U.S. Dvorak mapping in the Keyboard settings and there is no way to map keys in addition to any selected base mapping. I have tried this in two different browsers and neither of them honor the desktop keyboard mapping. I've never had a keyboard mapping problem with other HTML5 KVMs nor with Java KVMs.

Debian GNU/Linux 13 (trixie)
Kernel 6.11.10-amd64
Firefox 139.0 and Chromium 136.0.7103.113
JetKVM App 0.4.4 / System 0.2.4

Originally created by @plastikos on GitHub (Jun 27, 2025). JetKVM somehow grabs the raw keystrokes before they are mapped. It does not have a U.S. Dvorak mapping in the Keyboard settings and there is no way to map keys in addition to any selected base mapping. I have tried this in two different browsers and neither of them honor the desktop keyboard mapping. I've never had a keyboard mapping problem with other HTML5 KVMs nor with Java KVMs. Debian GNU/Linux 13 (trixie) Kernel 6.11.10-amd64 Firefox 139.0 and Chromium 136.0.7103.113 JetKVM App 0.4.4 / System 0.2.4

deekerman added the

component: hid/keyboard

label

2026-02-20 08:22:08 -05:00

deekerman commented

2026-02-20 08:22:09 -05:00

Author

Owner

@macdja38 commented on GitHub (Jun 27, 2025):

I'm having the same issue.

@macdja38 commented on GitHub (Jun 27, 2025): I'm having the same issue.

deekerman commented

2026-02-20 08:22:09 -05:00

Author

Owner

@IDisposable commented on GitHub (Jul 1, 2025):

They need to completely revamp the keyboard support to include the concepts introduced (partially) in the Paste-Keyboard option. I'm soliciting opinions on if I should just build in keyboard.info imports so we can support everything :)

@IDisposable commented on GitHub (Jul 1, 2025): They need to completely revamp the keyboard support to include the concepts introduced (partially) in the Paste-Keyboard option. I'm soliciting opinions on if I should just build in keyboard.info imports so we can support everything :)

deekerman commented

2026-02-20 08:22:09 -05:00

Author

Owner

@didierb99 commented on GitHub (Aug 2, 2025):

Same here. Very annoying bug

@didierb99 commented on GitHub (Aug 2, 2025): Same here. Very annoying bug

deekerman commented

2026-02-20 08:22:09 -05:00

Author

Owner

@plastikos commented on GitHub (Aug 6, 2025):

The business I work for wants to purchase a pile of JetKVMs but I'm telling them it's a non-starter since it uses the raw keycodes rather than the cooked keycodes. It completely ignores all keymappings and makes it impossible to type for anyone that uses any keymapping that is not part of the configuration list. Having to specifically set the keymap on the JetKVM configuration rather than just use the cooked keycodes from the desktop is a completely broken approach. While there should be a special input method for sending keycodes that the desktop does not usually pass (e.g. <ESC>, <F1>, etc) that should be an exception to sending all cooked keycodes.

@plastikos commented on GitHub (Aug 6, 2025): The business I work for wants to purchase a pile of JetKVMs but I'm telling them it's a non-starter since it uses the raw keycodes rather than the cooked keycodes. It completely ignores all keymappings and makes it impossible to type for anyone that uses any keymapping that is not part of the configuration list. Having to specifically set the keymap on the JetKVM configuration rather than just use the cooked keycodes from the desktop is a completely broken approach. While there should be a special input method for sending keycodes that the desktop does not usually pass (_e.g._ `<ESC>`, `<F1>`, _etc_) that should be an exception to sending all cooked keycodes.

deekerman commented

2026-02-20 08:22:09 -05:00

Author

Owner

@IDisposable commented on GitHub (Aug 7, 2025):

I'm working on redoing the entire keyboard processing... but I want to be sure I understand what you mean about Cooked vs. Raw? What exactly are you asking it to do? We're in a browser, so we get the native-machine's key down/key up/key press messages and pass them directly through (with modifier tracking).

Please be specific, so I am sure I'm addressing your use-case. Please differentiate between Physical Keyboard (on browser), Browser OS Language and Keyboard Layout setting, Host (controlled machine) OS language and Keyboard Layout. Also noted that Virtual Keyboard is a totally different issue, because we're showing a keyboard on-screen that needs to match the host's keyboard layout, Paste also needs that information, and then there's Macros, which are basically half-way between simulating physical keyboard with paste-character logic.

@IDisposable commented on GitHub (Aug 7, 2025): I'm working on redoing the entire keyboard processing... but I want to be sure I understand what you mean about Cooked vs. Raw? What exactly are you asking it to do? We're in a browser, so we get the native-machine's key down/key up/key press messages and pass them directly through (with modifier tracking). Please be specific, so I am sure I'm addressing your use-case. Please differentiate between Physical Keyboard (on browser), Browser OS Language and Keyboard Layout setting, Host (controlled machine) OS language and Keyboard Layout. Also noted that Virtual Keyboard is a totally different issue, because we're showing a keyboard on-screen that needs to match the host's keyboard layout, Paste also needs that information, and then there's Macros, which are basically half-way between simulating physical keyboard with paste-character logic.

deekerman commented

2026-02-20 08:22:09 -05:00

Author

Owner

@rgl commented on GitHub (Sep 8, 2025):

@IDisposable, I have a couple of use-cases, maybe these can be taken into consideration?

I would like to use Puppeteer to drive/test the JetKVM connected device using headless chrome/chromium. I'm trying to use the Puppeteer Keyboard class, more exactly, the Keyboard.type function, but it seems the keyboard layout is at play here, as its not working as expected, e.g., typing/pasting Aa|!"#$%&/()=?«»<>,;.:-_\zZ ends up being mangled/mistyped in the device.

I would like to have some way to call into the JetKVM JavaScript code. That is, Puppeteer allows us to inject JavaScript code into the page, but, how do we call into the JetKVM JavaScript code? E.g. How to call some JavaScript global function like, JetKvm.pasteText("Aa|!"#$%&/()=?«»<>,;.:-_\\zZ")?

I would like to have support for some kind of inline markup like the packer boot_command.

@rgl commented on GitHub (Sep 8, 2025): @IDisposable, I have a couple of use-cases, maybe these can be taken into consideration? I would like to use Puppeteer to drive/test the JetKVM connected device using headless chrome/chromium. I'm trying to use the Puppeteer [Keyboard class](https://pptr.dev/api/puppeteer.keyboard), more exactly, the [Keyboard.type function](https://pptr.dev/api/puppeteer.keyboard.type), but it seems the keyboard layout is at play here, as its not working as expected, e.g., typing/pasting `Aa|!"#$%&/()=?«»<>,;.:-_\zZ` ends up being mangled/mistyped in the device. I would like to have some way to call into the JetKVM JavaScript code. That is, Puppeteer allows us to inject JavaScript code into the page, but, how do we call into the JetKVM JavaScript code? E.g. How to call some JavaScript global function like, `JetKvm.pasteText("Aa|!"#$%&/()=?«»<>,;.:-_\\zZ")`? I would like to have support for some kind of inline markup like the [packer `boot_command`](https://developer.hashicorp.com/packer/integrations/hashicorp/qemu/latest/components/builder/qemu#boot-configuration).

deekerman commented

2026-02-20 08:22:09 -05:00

Author

Owner

@IDisposable commented on GitHub (Sep 8, 2025):

@rgl I like the idea, it's not quite as simple as exposing a function since this is a React/stateful application, but perhaps we can make it happen. Please create a distinct Issue for this as this thread is getting really haphazard.

@IDisposable commented on GitHub (Sep 8, 2025): @rgl I like the idea, it's not quite as simple as exposing a function since this is a React/stateful application, but perhaps we can make it happen. Please create a distinct Issue for this as this thread is getting really haphazard.

deekerman commented

2026-02-20 08:22:09 -05:00

Author

Owner

@rgl commented on GitHub (Sep 9, 2025):

@IDisposable I've created https://github.com/jetkvm/kvm/issues/787, please have a look. Thank you!

@rgl commented on GitHub (Sep 9, 2025): @IDisposable I've created https://github.com/jetkvm/kvm/issues/787, please have a look. Thank you!

deekerman commented

2026-02-20 08:22:09 -05:00

Author

Owner

@plastikos commented on GitHub (Sep 26, 2025):

@IDisposable, here are details of my situation:
My physical keyboard is English U.S. QWERTY with the short key.
My keyboard layout is English U.S. Dvorak.
I have additional keys mapped such as <CAPS_LOCK> as an additional <L_CTRL>.

When I have input focus to any of the apps on my desktop I get the English U.S. Dvorak with the <CAPS_LOCK> as <L_CTRL> ... except when I use JetKVM which somehow ignores all key mappings and gets raw keycodes as the physical QWERTY keyboard. It might be tolerable if there was at least an English U.S. Dvorak mapping in the JetKVM settings but there is not and I don't see any way for me to load my own keyboard mapping without changing the key mapping for all other users of the JetKVM. This underscores why JetKVM should work like all other applications on my desktop: process the remapped keycodes rather than the raw keycodes - then it works for everyone all the time without needing to mess with settings or require having the correct keymap built-in to JetKVM.

@plastikos commented on GitHub (Sep 26, 2025): @IDisposable, here are details of my situation: My physical keyboard is English U.S. QWERTY with the short <ENTER> key. My keyboard layout is English U.S. Dvorak. I have additional keys mapped such as <CAPS_LOCK> as an additional <L_CTRL>. When I have input focus to any of the apps on my desktop I get the English U.S. Dvorak with the <CAPS_LOCK> as <L_CTRL> ... *except* when I use JetKVM which somehow ignores *all* key mappings and gets raw keycodes as the physical QWERTY keyboard. It might be tolerable if there was at least an English U.S. Dvorak mapping in the JetKVM settings but there is not and I don't see any way for me to load my own keyboard mapping without changing the key mapping for all other users of the JetKVM. This underscores why JetKVM should work like all other applications on my desktop: process the remapped keycodes rather than the raw keycodes - then it works for *everyone* all the time without needing to mess with settings or require having the correct keymap built-in to JetKVM.

deekerman commented

2026-02-20 08:22:09 -05:00

Author

Owner

@IDisposable commented on GitHub (Sep 26, 2025):

I see what your situation is, perhaps there is a way we can support your setup with an addition option (per host? / per browser?) but the reason this doesn't work the way you're hoping is that it is by design using the HID keycode and sending that to the remote because the host/remote is not necessarily running the keyboard OR language that you are on your client/browser. Be sending the HID keycodes (which are what all USB keyboards send to the host, by HID specification). That keycode is not language or keyboard-mapping controlled at all... it's up the receiving host and the OS (or in the case of boot BIOS, the BIOS settings) to map those HID codes to characters... which is controlled by the host (and not even known to the remote).

To put a fine point on it, the JetKVM is pretending to be a USB HID Keyboard, so the HID keycodes (e.g KeyA, LeftShift, etc.) that the host receives are interpreted by the host+host OS. There is NO WAY to change that part of the equation.

Even more fun awaits when the Host OS lets you select your active keyboard on the fly (e.g. change the keyboard in Windows or MacOS) while you are already connected. The way things are now, your "physical keyboard" is treated "as-if" it was a physical keyboard attached to the host's USB port... so of course the host OS (and nothing else!) controls what the interpretation of the HID Keycode means.

Even, even MORE fun if the JetKVM is attached to a physical KVM, and that physical KVM is attached to multiple machines, each running a different language+keyboard layout+host OS!

In fact, that's why the Virtual Keyboard and Paste need the setting for what keyboard is desired for the host device.

What happens with Paste in that case is that we know what character the user wants typed, so we know what physical key that's located on, based on the JetKVM Keyboard Layout setting, so it actually maps to key-down/key-up on that specific physical key.

For Virtual Keyboard, we know how to map the characters shown on the virtual keycap to the HID keycode and thus we key-down/key-up that HID keycode. Noted that at this time we don't update the Virtual Keyboard appearance based on keyboard language (but we should, it's in my backlog, along with tons of keyboards including DVORAK English, etc). (Sadly, we don't currently change what's displayed for the keyboard... that's in the backlog).

What the language/keyboard setting on the JetKVM reflects what is installed/expected by the host machine+OS... because that's the machine the USB cable is connected to, It has nothing to do with what's on your side. To your point, if the remote user is using a German keyboard, connects to a US machine, it is really a matter of desire whether the pressing key next to the TAB key should result in a Q or an A... as currently specified, the character would be an A (because that's what HID KeyQ maps to in a German keyboard layout)

So what I see needing to happen to get the "finish line" is:

Update the keyboard layout setting to drive the complete layout specification (e.g. layers and mappings)
Update Virtual Keyboard to show/reflect the keyboard layout selected so the on-screen keyboard matches the host's selected keyboard, as determined in the device's settings
Add the ability to select/upload/define host keyboard layouts (so you can add/select DVORAK if that's what the host is running)
Add to determine or detect (or a setting) the remote/browser's keyboard language and layout
Add a setting to specify if the remote/browsers's keyboard (physical input keyboard) sends the HID keycode (as now) or mapped characters (e.g. the KeyPress events). This setting would NOT be stored on the JetKVM device settings as that would cause problems if you tried to control one JetKVM+host combination with multiple different users that have different expectations.

Note: this mode would make it impossible to do some things that the host-keyboard layout might allow (because you cannot express that in the controller browser+OS+keyboard mapping)
Note: this mode would make entering mode/shift/action keys hard to regulate, because we don't GET those KeyDown/KeyUp events, just KeyPress events.

Update WebRTC (e,g. live keyboard) to understand the setting and "expand" back-maps the key that the user typed (according to the remote/browser OS-settings) known as key-press events, then map that back to HID keycodes like Virtual Keyboard does.

In a perfect world, we could sense the host's language/keyboard layout/OS and know what to do... but unfortunately that's not possible from the HID Keyboard (from the host's perspective, it's an input device). If you've ever connected a new keyboard to a MacOS, you know that it pops up a dialog to ask you to press a couple specific keys, and from that combined with the UI language selected on the MacOS it can "guess" what the layout of the physical keyboard you just plugged in has...

See this:

HID "KeyA" refers to the USB Human Interface Device (HID) usage ID for the keyboard key typically labeled 'a'. When you press the physical 'A' key on your keyboard, the device sends a specific, standardized HID code to the computer to report that event.
Key details about HID "KeyA":
Physical vs. logical mapping: The HID code for "KeyA" is independent of the keyboard layout. The code represents the key's physical position, not its printed label. The operating system then translates this into the correct character based on the user's keyboard layout (e.g., QWERTY, AZERTY). On an AZERTY keyboard, for instance, the physical key at that same position is the 'Q' key.
Role in HID reports: For a keyboard, the HID report describes the state of all keys at a given moment. The report includes data that indicates which modifier keys (Shift, Ctrl, etc.) and which regular keys (like "KeyA") are currently pressed.
Standardized usage tables: The specific usage ID for "KeyA" is found in the HID Usage Tables, a collection of documents maintained by the USB Implementers Forum (USB-IF). These tables standardize the meaning of data reported by HID devices, allowing different hardware to work with the same generic drivers.
Programming reference: When developing software or firmware for HID devices, programmers use these predefined codes. For example, a Rust documentation example shows how to convert a domain key code for "KeyA" into its corresponding HID usage ID.

@IDisposable commented on GitHub (Sep 26, 2025): I see what your situation is, perhaps there is a way we can support your setup with an addition option (per host? / per browser?) but the reason this doesn't work the way you're hoping is that it is _by design_ using the HID keycode and sending that to the remote _because_ the host/remote is not necessarily running the keyboard OR language that you are on your client/browser. Be sending the HID keycodes (which are what all USB keyboards send to the host, by HID specification). That keycode is not language or keyboard-mapping controlled **at all**... it's up the receiving host and the OS (or in the case of boot BIOS, the BIOS settings) to map those HID codes to characters... which is controlled by the host (and not even known to the remote). To put a fine point on it, the JetKVM is pretending to be a USB HID Keyboard, so the HID keycodes (e.g KeyA, LeftShift, etc.) that the host receives are interpreted _by the host+host OS_. There is NO WAY to change that part of the equation. Even more fun awaits when the Host OS lets you select your active keyboard _on the fly_ (e.g. change the keyboard in Windows or MacOS) while you are already connected. The way things are now, your "physical keyboard" is treated "as-if" it was a physical keyboard attached to the host's USB port... so of course the host OS (and nothing else!) controls what the interpretation of the HID Keycode means. Even, even MORE fun if the JetKVM is attached to a physical KVM, and that physical KVM is attached to multiple machines, each running a different language+keyboard layout+host OS! In fact, that's why the Virtual Keyboard and Paste _need_ the setting for what keyboard is desired _for the host device_. What happens with Paste in that case is that we know what **character** the user wants typed, so we know what physical key that's located on, based on the JetKVM Keyboard Layout setting, so it actually maps to key-down/key-up on that specific physical key. For Virtual Keyboard, we know how to map the **characters** shown on the virtual keycap to the HID keycode and thus we key-down/key-up that HID keycode. Noted that _at this time_ we don't update the Virtual Keyboard appearance based on keyboard language (but we should, it's in my backlog, along with tons of keyboards including DVORAK English, etc). (Sadly, we don't currently change what's displayed for the keyboard... that's in the backlog). What the language/keyboard setting on the JetKVM reflects what is installed/expected by the **host** machine+OS... because that's the machine the USB cable is connected to, It has nothing to do with what's on your side. To your point, if the remote user is using a German keyboard, connects to a US machine, it is really a matter of _desire_ whether the pressing key next to the TAB key should result in a Q or an A... as currently specified, the character would be an A (because that's what HID KeyQ maps to in a German keyboard layout) So what I see needing to happen to get the "finish line" is: 1. Update the keyboard layout setting to drive the complete layout specification (e.g. layers and mappings) 2. Update Virtual Keyboard to _show_/reflect the _keyboard layout_ selected so the on-screen keyboard matches the host's selected keyboard, as determined in the _device's_ settings 3. Add the ability to select/upload/define _host_ keyboard layouts (so you can add/select DVORAK if that's what the host is running) 4. Add to determine or detect (or a setting) the _remote/browser_'s keyboard language and layout 5. Add a setting to specify if the remote/browsers's keyboard (physical input keyboard) sends the HID keycode (as now) or mapped characters (e.g. the KeyPress events). This setting would NOT be stored on the JetKVM device settings as that would cause problems if you tried to control one JetKVM+host combination with multiple different users that have different expectations. * Note: this mode would make it impossible to do some things that the host-keyboard layout might allow (because you cannot express that in the controller browser+OS+keyboard mapping) * Note: this mode would make entering mode/shift/action keys hard to regulate, because we don't GET those KeyDown/KeyUp events, just KeyPress events. 6. Update WebRTC (e,g. live keyboard) to understand the setting and "expand" back-maps the key that the user typed (according to the remote/browser OS-settings) **known as key-press events**, then map that back to HID keycodes like Virtual Keyboard does. In a perfect world, we could sense the host's language/keyboard layout/OS and know what to do... but unfortunately that's not possible from the HID Keyboard (from the host's perspective, it's an _input_ device). If you've ever connected a new keyboard to a MacOS, you know that it pops up a dialog to ask you to press a couple specific keys, and from that combined with the UI language selected _on the MacOS_ it can "guess" what the layout of the physical keyboard you just plugged in has... See this: > HID "KeyA" refers to the USB Human Interface Device (HID) usage ID for the keyboard key typically labeled 'a'. When you press the physical 'A' key on your keyboard, the device sends a specific, standardized HID code to the computer to report that event. Key details about HID "KeyA": Physical vs. logical mapping: The HID code for "KeyA" is independent of the keyboard layout. The code represents the key's physical position, not its printed label. The operating system then translates this into the correct character based on the user's keyboard layout (e.g., QWERTY, AZERTY). On an AZERTY keyboard, for instance, the physical key at that same position is the 'Q' key. Role in HID reports: For a keyboard, the HID report describes the state of all keys at a given moment. The report includes data that indicates which modifier keys (Shift, Ctrl, etc.) and which regular keys (like "KeyA") are currently pressed. Standardized usage tables: The specific usage ID for "KeyA" is found in the HID Usage Tables, a collection of documents maintained by the USB Implementers Forum (USB-IF). These tables standardize the meaning of data reported by HID devices, allowing different hardware to work with the same generic drivers. Programming reference: When developing software or firmware for HID devices, programmers use these predefined codes. For example, a Rust documentation example shows how to convert a domain key code for "KeyA" into its corresponding HID usage ID.

deekerman commented

2026-02-20 08:22:09 -05:00

Author

Owner

@plastikos commented on GitHub (Sep 30, 2025):

I see what it means to process HID keyboard events - there's utility in that. Regardless of how keyboards and events get processed it's a serious problem for using JetKVM. Until there's a way to have a unique configuration for each JetKVM connection it's effectively broken-by-design. Right now I have no way to select the keymap I need because it's not available in the JetKVM list. Even if the keymap gets added no one should rely on waiting for JetKVM to add their specific keymap - that should be something that each user can select or upload. Additional, individual key mapping overrides should also be available - such as <CAPS_LOCK> as <L_CTRL>.

Right now keymapping is so bad it's unusable.

@plastikos commented on GitHub (Sep 30, 2025): I see what it means to process HID keyboard events - there's utility in that. Regardless of how keyboards and events get processed it's a serious problem for using JetKVM. Until there's a way to have a unique configuration for each JetKVM connection it's effectively broken-by-design. Right now I have no way to select the keymap I need because it's not available in the JetKVM list. Even if the keymap gets added no one should rely on waiting for JetKVM to add their specific keymap - that should be something that each user can select or *upload*. Additional, individual key mapping overrides should also be available - such as <CAPS_LOCK> as <L_CTRL>. Right now keymapping is so bad it's unusable.

deekerman commented

2026-02-20 08:22:09 -05:00

Author

Owner

@plastikos commented on GitHub (Sep 30, 2025):

FWIW I'm using Linux with Firefox - not Windows nor Mac OS.

@plastikos commented on GitHub (Sep 30, 2025): FWIW I'm using Linux with Firefox - not Windows nor Mac OS.

deekerman commented

2026-02-20 08:22:09 -05:00

Author

Owner

@IDisposable commented on GitHub (Sep 30, 2025):

I see what it means to process HID keyboard events - there's utility in that.
Regardless of how keyboards and events get processed it's a serious problem for using JetKVM.

For some use-cases, we agree. For many folks who are running it as a KVM to a server, they're almost insured to be running the same keyboard on the client/browser machine as they are on the host, especially if multiple people are using the same JetKVM from different clients

Until there's a way to have a unique configuration for each JetKVM connection it's effectively broken-by-design.

Agreed that adding the ability to remember client-side preferences would be helpful, but calling it broken-by-design is a bit harsh. It works fantastically for me (as a user) when controlling a MacOS machine from a Windows machine.

Right now I have no way to select the keymap I need because it's not available in the JetKVM list.

Yes, I am trying to address the mappings, but understand that the only way to really do what you're hoping for is to have the client/browser be cognizant of the controller's keyboard layout, and be able to forward logical character (not keystrokes) to the device using the device's setting of the keyboard layout (as the Paste and Virtual Keyboard currently do). This is FAR less supportable/maintainable from the JetKVM side.

Even if the keymap gets added no one should rely on waiting for JetKVM to add their specific keymap - that should be something that each user can select or upload.

Totally agree. My hope is now that we have a more reliable keyboard stack that we will just allow uploading of KLC files or such so you can declare the host's keyboard layout in-use as desired.

Note that while you might have the ability to set it... there is a lot of potential for confusion if multiple people use the same JetKVM device... and then log into an OS that allows per-user keyboard layouts. Imagine trying to get that right!

Additional, individual key mapping overrides should also be available - such as <CAPS_LOCK> as <L_CTRL>.

That's a central part of the concept of keyboard layouts, I agree.

Right now keymapping is so bad it's unusable.

That's certainly your opinion, I'm sorry. I know a lot of folks are using the de-DE and they've just merged a da-DK so some folks are finding it useful.

@IDisposable commented on GitHub (Sep 30, 2025): > I see what it means to process HID keyboard events - there's utility in that. > Regardless of how keyboards and events get processed it's a serious problem for using JetKVM. For some use-cases, we agree. For many folks who are running it as a KVM to a server, they're almost insured to be running the same keyboard on the client/browser machine as they are on the host, especially if multiple people are using the same JetKVM from different clients > Until there's a way to have a unique configuration for each JetKVM connection it's effectively broken-by-design. Agreed that adding the ability to remember client-side preferences would be helpful, but calling it broken-by-design is a bit harsh. It works fantastically for me (as a user) when controlling a MacOS machine from a Windows machine. > Right now I have no way to select the keymap I need because it's not available in the JetKVM list. Yes, I am trying to address the mappings, but understand that the only way to really do what you're hoping for is to have the client/browser be cognizant of the _controller's_ keyboard layout, and be able to forward logical character (not keystrokes) to the device using the _device's_ setting of the keyboard layout (as the Paste and Virtual Keyboard currently do). This is FAR less supportable/maintainable from the JetKVM side. >Even if the keymap gets added no one should rely on waiting for JetKVM to add their specific keymap - that should be something that each user can select or _upload_. Totally agree. My hope is now that we have a _more reliable_ keyboard stack that we will just allow uploading of KLC files or such so you can declare the host's keyboard layout in-use as desired. Note that while you might have the ability to set it... there is a lot of potential for confusion if multiple people use the same JetKVM device... and then log into an OS that allows per-user keyboard layouts. Imagine trying to get that right! > Additional, individual key mapping overrides should also be available - such as <CAPS_LOCK> as <L_CTRL>. That's a central part of the concept of keyboard layouts, I agree. > Right now keymapping is so bad it's unusable. That's certainly your opinion, I'm sorry. I know a lot of folks are using the de-DE and they've just merged a da-DK so some folks are finding it useful.

deekerman commented

2026-02-20 08:22:09 -05:00

Author

Owner

@IDisposable commented on GitHub (Sep 30, 2025):

FWIW I'm using Linux with Firefox - not Windows nor Mac OS.

... and Colemac, you're not a typical user, can we agree on that point and try less "my way or the highway"?

@IDisposable commented on GitHub (Sep 30, 2025): > FWIW I'm using Linux with Firefox - not Windows nor Mac OS. ... and Colemac, you're not a typical user, can we agree on that point and try less "my way or the highway"?

deekerman commented

2026-02-20 08:22:09 -05:00

Author

Owner

@plastikos commented on GitHub (Sep 30, 2025):

The lantronix Spider KVM (https://www.lantronix.com/products/lantronix-spider/) passes mapped key events rather than raw HID events. There should be a connection-specific setting to choose how key events should be passed to the controlled device.

@plastikos commented on GitHub (Sep 30, 2025): The lantronix Spider KVM (https://www.lantronix.com/products/lantronix-spider/) passes mapped key events rather than raw HID events. There should be a connection-specific setting to choose how key events should be passed to the controlled device.

deekerman commented

2026-02-20 08:22:09 -05:00

Author

Owner

@IDisposable commented on GitHub (Nov 21, 2025):

that should be something that each user can select or upload

This is coming, in my backlog

@IDisposable commented on GitHub (Nov 21, 2025): > that should be something that each user can select or _upload_ This is coming, in my backlog

deekerman commented

2026-02-20 08:22:09 -05:00

Author

Owner

@Anachron commented on GitHub (Feb 17, 2026):

I bought a JetKVM and I'm also only now figuring all of this out.
Have a german keyboard/locale both on my host OS and the KVM client I want to remotely control.

Is there any ETA on when we can expect a first release of a remapping? Right now I can only do certain stuff, as many keys are not working ...

@Anachron commented on GitHub (Feb 17, 2026): I bought a JetKVM and I'm also only now figuring all of this out. Have a german keyboard/locale both on my host OS and the KVM client I want to remotely control. Is there any ETA on when we can expect a first release of a remapping? Right now I can only do certain stuff, as many keys are not working ...

Rows
Columns

Ignores keyboard mapping and doesn't have a correct mapping in the keyboard settings #350