WebUI "Paste text" has problems with uppercase #60

New issue

Open

opened 2026-02-20 08:19:48 -05:00 by deekerman · 10 comments

deekerman commented 2026-02-20 08:19:48 -05:00

Owner

Copy link

Originally created by @jimcheetham on GitHub (Jan 17, 2025).

Possibly related to #30 ...

I noticed that a password that I was trying to paste into the remote machine wasn't working, and resorted to looking at it instead of just entering it at an unechoed input :-) When I pasted it somewhere visible, I could see that some capitalised letters were arriving as lowercase.

I've sent a few test strings, and because #30 said that you're sending a shift and then a character, I wonder if the timing if these is messed up somehow.

I tried a couple of test strings, sending each one 5 times

• Initial Caps For Words
• CamelCase WordTests

What I got pasted into the remote machine was reasonably non-deterministic ...

Initial Caps for words
InitiaL caps for words
InitiaL caps for words
Initial caps for words
Initial caps for words

CamelcasE wordtests
CamelCase wordtests
Camelcase wordtests
Camelcase wordtests
Camelcase WordTests

My machine is
App: 0.3.5-dev202501022149
System: 0.2.0
(It would be very nice if I could copy/paste that rather than having to retype it)

Originally created by @jimcheetham on GitHub (Jan 17, 2025). Possibly related to #30 ... I noticed that a password that I was trying to paste into the remote machine wasn't working, and resorted to looking at it instead of just entering it at an unechoed input :-) When I pasted it somewhere visible, I could see that some capitalised letters were arriving as lowercase. I've sent a few test strings, and because #30 said that you're sending a `shift` and then a `character`, I wonder if the timing if these is messed up somehow. I tried a couple of test strings, sending each one 5 times * `Initial Caps For Words` * `CamelCase WordTests` What I got pasted into the remote machine was reasonably non-deterministic ... ``` Initial Caps for words InitiaL caps for words InitiaL caps for words Initial caps for words Initial caps for words CamelcasE wordtests CamelCase wordtests Camelcase wordtests Camelcase wordtests Camelcase WordTests ``` My machine is App: 0.3.5-dev202501022149 System: 0.2.0 (It would be very nice if I could copy/paste that rather than having to retype it)

deekerman added the

component: ui

label 2026-02-20 08:19:48 -05:00

deekerman commented 2026-02-20 08:19:48 -05:00

Author

Owner

Copy link

@dlorch commented on GitHub (May 3, 2025):

Text from the "Paste text" text box will be sent character-by-character to the target system by simulating keystrokes. The above should translate to:

• key: "KeyI", modifiers: "ShiftLeft"
• key: "KeyN", modifiers: none
• key: "KeyI", modifiers: none
• key: "KeyT", modifiers: none
• key: "KeyI", modifiers: none
• ...

See the code here:

github.com/jetkvm/kvm@d79f359c43/ui/src/components/popovers/PasteModal.tsx (L48-L60)

There shouldn't be a timing issue between shift and the character, as they are sent at the same time. Could you provide the keyboardReport log entries for review? They look something like this:

2025-05-03T20:19:10Z TRC jetkvm jsonrpc Received RPC request id=21 method=keyboardReport params={"keys":[],"modifier":0}
2025-05-03T20:19:10Z TRC jetkvm jsonrpc Calling RPC handler id=21 method=keyboardReport params={"keys":[],"modifier":0}

@dlorch commented on GitHub (May 3, 2025): Text from the "Paste text" text box will be sent character-by-character to the target system by simulating keystrokes. The above should translate to: - key: "KeyI", modifiers: "ShiftLeft" - key: "KeyN", modifiers: none - key: "KeyI", modifiers: none - key: "KeyT", modifiers: none - key: "KeyI", modifiers: none - ... See the code here: https://github.com/jetkvm/kvm/blob/d79f359c4394b236e142d7e60a030569971931df/ui/src/components/popovers/PasteModal.tsx#L48-L60 There shouldn't be a timing issue between `shift` and the `character`, as they are sent at the same time. Could you provide the `keyboardReport` log entries for review? They look something like this: ``` 2025-05-03T20:19:10Z TRC jetkvm jsonrpc Received RPC request id=21 method=keyboardReport params={"keys":[],"modifier":0} 2025-05-03T20:19:10Z TRC jetkvm jsonrpc Calling RPC handler id=21 method=keyboardReport params={"keys":[],"modifier":0} ```

deekerman commented 2026-02-20 08:19:48 -05:00

Author

Owner

Copy link

@jimcheetham commented on GitHub (May 3, 2025):

Where do I find keyboardReport logs? I cannot find a mention of these on the Discord, and there's nothing interesting in /var/log on the KVM itself ...

@jimcheetham commented on GitHub (May 3, 2025): Where do I find `keyboardReport` logs? I cannot find a mention of these on the Discord, and there's nothing interesting in `/var/log` on the KVM itself ...

deekerman commented 2026-02-20 08:19:48 -05:00

Author

Owner

Copy link

@dlorch commented on GitHub (May 4, 2025):

You can get trace (TRC) log output by re-building the entire solution and running the application in debug mode. The logs are then sent to the terminal:

./dev_deploy.sh -r <ip-address-of-jetkvm>

@dlorch commented on GitHub (May 4, 2025): You can get trace (`TRC`) log output by re-building the entire solution and running the application in debug mode. The logs are then sent to the terminal: ``` ./dev_deploy.sh -r <ip-address-of-jetkvm> ```

deekerman commented 2026-02-20 08:19:48 -05:00

Author

Owner

Copy link

@dlorch commented on GitHub (May 4, 2025):

The logging code in the dev branch has changed quite a bit since the latest app release (0.3.9). The JetKVM app developers have rewritten quite a big portion of that code. What you are seeing above is tracing output generated by the latest code.

In the future, you will be able to manually set the parameter default_log_level to TRACE in /userdata/kvm_config.json and then view the logs in /userdata/jetkvm/last.log.

The only tricky part will be to run kill jetkvm_app before manually making changes to the config file, to prevent the app from overwriting the file with the settings that are in memory (CC: @ym).

@dlorch commented on GitHub (May 4, 2025): The logging code in the dev branch has changed quite a bit since the latest app release (0.3.9). The JetKVM app developers have rewritten quite a big portion of that code. What you are seeing above is tracing output generated by the latest code. In the future, you will be able to manually set the parameter `default_log_level` to `TRACE` in `/userdata/kvm_config.json` and then view the logs in `/userdata/jetkvm/last.log`. The only tricky part will be to run `kill jetkvm_app` before manually making changes to the config file, to prevent the app from overwriting the file with the settings that are in memory (CC: @ym).

deekerman commented 2026-02-20 08:19:48 -05:00

Author

Owner

Copy link

@adamshiervani commented on GitHub (Jul 15, 2025):

A lot has changed since this issue was created. @jimcheetham, without running the software with different log levels, could you do a quick check to see whether this is still an issue on the latest version?

@adamshiervani commented on GitHub (Jul 15, 2025): A lot has changed since this issue was created. @jimcheetham, without running the software with different log levels, could you do a quick check to see whether this is still an issue on the latest version?

deekerman commented 2026-02-20 08:19:48 -05:00

Author

Owner

Copy link

@jimcheetham commented on GitHub (Jul 16, 2025):

Yep, I'm still having this issue. FW version in use is now autoupdated to 0.4.7-dev202507031912 ...

It looks like this version supports TRACE logging as per the comment above, so I enabled it. Annoyingly there doesn't seem to be any scp support on the machine, so getting it out was a challenge. I grepped for 'TRC jetkvm jsonrpc' and had to copy/paste from the terminal buffer :-)

Looking at the logs (attached) I can see that everything looks consistent, even when the results vary. For example, I sent the text "Initial Caps For Words" 5 times, and the middle 3 times I saw a lower-case 'f' arrive; but the TRC logs indicate that {"keys":[9],"modifier":2} was recorded every time.

I'm assuming that no-one else has duplicated this issue, so it's increasingly likely to be something about the machine at the other end, rather than the JetKVM itself?

• This is what was sent - only local machine I copied this text and pasted it into the "Paste text" input box on the KVM browser window - pastetest.txt
• This is what was received on the remote machine, where I was in a Debian/Gnome Terminal window running cat > pasteresult.txt - pasteresult.txt
• This is an extract from last.log, selecting just the TRC jsonrpc lines and excluding Mouse data - TRCkeyboard.log

@jimcheetham commented on GitHub (Jul 16, 2025): Yep, I'm still having this issue. FW version in use is now autoupdated to 0.4.7-dev202507031912 ... It looks like this version supports TRACE logging as per the comment above, so I enabled it. Annoyingly there doesn't seem to be any scp support on the machine, so getting it out was a challenge. I grepped for 'TRC jetkvm jsonrpc' and had to copy/paste from the terminal buffer :-) Looking at the logs (attached) I can see that everything looks consistent, even when the results vary. For example, I sent the text "Initial Caps For Words" 5 times, and the middle 3 times I saw a lower-case 'f' arrive; but the TRC logs indicate that `{"keys":[9],"modifier":2}` was recorded every time. I'm assuming that no-one else has duplicated this issue, so it's increasingly likely to be something about the machine at the other end, rather than the JetKVM itself? * This is what was sent - only local machine I copied this text and pasted it into the "Paste text" input box on the KVM browser window - [pastetest.txt](https://github.com/user-attachments/files/21251619/pastetest.txt) * This is what was received on the remote machine, where I was in a Debian/Gnome Terminal window running `cat > pasteresult.txt` - [pasteresult.txt](https://github.com/user-attachments/files/21251617/pasteresult.txt) * This is an extract from `last.log`, selecting just the TRC jsonrpc lines and excluding Mouse data - [TRCkeyboard.log](https://github.com/user-attachments/files/21251618/TRCkeyboard.log)

deekerman commented 2026-02-20 08:19:48 -05:00

Author

Owner

Copy link

@Jonher937 commented on GitHub (Jul 16, 2025):

I've been following this issue and would like to add that this is not only limited to pasting text.

Most of the time I'm using JetKVM on the same LAN ethernet -> ethernet and it's fine, or at least happens very seldom.

As soon as you add latency, you start having issues with out of order characters, Shift not engaging the correct characters, sometimes shift sticks for a few chars and sometimes it's missed.
Having typed Shift+A and releasing the Shift key too quickly after pressing a you'll sometimes get: aaaaaaaaaa printed after the A.

TL;DR: This is probably reproducible if you add latency between yourself and the JetKVM

@Jonher937 commented on GitHub (Jul 16, 2025): I've been following this issue and would like to add that this is not only limited to pasting text. Most of the time I'm using JetKVM on the same LAN ethernet -> ethernet and it's fine, or at least happens very seldom. As soon as you add latency, you start having issues with out of order characters, Shift not engaging the correct characters, sometimes shift sticks for a few chars and sometimes it's missed. Having typed Shift+A and releasing the Shift key too quickly after pressing a you'll sometimes get: `aaaaaaaaaa` printed after the `A`. TL;DR: This is probably reproducible if you add latency between yourself and the JetKVM

deekerman commented 2026-02-20 08:19:49 -05:00

Author

Owner

Copy link

@jimcheetham commented on GitHub (Jul 16, 2025):

As you mention latency @Jonher937, I'm also now noticing that normal typing via the JetKVM is also acting in a similar manner, I'm getting extra characters and typos that I'm confident weren't caused by my fingers. So it isn't something related to just the paste function, it may be more generally about how keystrokes are sent (to clarify, I don't usually use the JetKVM to type much into this computer, it's primarily for mouse input to a browser, so I may not have noticed this before).

I checked paste into a different application, the gnome 'text editor', and it also showed the same non-caps behaviour (although no extra/repeats).

I ran xev, which produces detailed keystroke data from an input X window. Unfortunately it produces only a log output, and I can't see my typing echoed to see if the non-caps thing was happening; the logged key events all seem to be perfectly correct.

xev.log

On the other hand, it does show that X is seeing the SHIFT_L and letter keys being pressed simultaneously (according to timestamp) and later, released simultaneously ... perhaps we have a timing issue on the remote machine that could benefit from slowing down the rate at which we send keys?

KeyPress event, serial 34, synthetic NO, window 0x800001,
    root 0x49a, subw 0x0, time 2739220703, (153,-15), root:(153,54),
    state 0x0, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 34, synthetic NO, window 0x800001,
    root 0x49a, subw 0x0, time 2739220703, (153,-15), root:(153,54),
    state 0x1, keycode 31 (keysym 0x49, I), same_screen YES,
    XLookupString gives 1 bytes: (49) "I"
    XmbLookupString gives 1 bytes: (49) "I"
    XFilterEvent returns: False

KeyRelease event, serial 37, synthetic NO, window 0x800001,
    root 0x49a, subw 0x0, time 2739220725, (153,-15), root:(153,54),
    state 0x1, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 37, synthetic NO, window 0x800001,
    root 0x49a, subw 0x0, time 2739220725, (153,-15), root:(153,54),
    state 0x0, keycode 31 (keysym 0x69, i), same_screen YES,
    XLookupString gives 1 bytes: (69) "i"
    XFilterEvent returns: False

@jimcheetham commented on GitHub (Jul 16, 2025): As you mention latency @Jonher937, I'm also now noticing that normal typing via the JetKVM is also acting in a similar manner, I'm getting extra characters and typos that I'm confident weren't caused by my fingers. So it isn't something related to just the paste function, it may be more generally about how keystrokes are sent (to clarify, I don't usually use the JetKVM to type much into this computer, it's primarily for mouse input to a browser, so I may not have noticed this before). I checked paste into a different application, the gnome 'text editor', and it also showed the same non-caps behaviour (although no extra/repeats). I ran `xev`, which produces detailed keystroke data from an input X window. Unfortunately it produces only a log output, and I can't see my typing echoed to see if the non-caps thing was happening; the logged key events all seem to be perfectly correct. [xev.log](https://github.com/user-attachments/files/21266600/xev.log) On the other hand, it does show that X is seeing the SHIFT_L and letter keys being pressed simultaneously (according to timestamp) and later, released simultaneously ... perhaps we have a timing issue on the remote machine that could benefit from slowing down the rate at which we send keys? ``` KeyPress event, serial 34, synthetic NO, window 0x800001, root 0x49a, subw 0x0, time 2739220703, (153,-15), root:(153,54), state 0x0, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 34, synthetic NO, window 0x800001, root 0x49a, subw 0x0, time 2739220703, (153,-15), root:(153,54), state 0x1, keycode 31 (keysym 0x49, I), same_screen YES, XLookupString gives 1 bytes: (49) "I" XmbLookupString gives 1 bytes: (49) "I" XFilterEvent returns: False KeyRelease event, serial 37, synthetic NO, window 0x800001, root 0x49a, subw 0x0, time 2739220725, (153,-15), root:(153,54), state 0x1, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 37, synthetic NO, window 0x800001, root 0x49a, subw 0x0, time 2739220725, (153,-15), root:(153,54), state 0x0, keycode 31 (keysym 0x69, i), same_screen YES, XLookupString gives 1 bytes: (69) "i" XFilterEvent returns: False ```

deekerman commented 2026-02-20 08:19:49 -05:00

Author

Owner

Copy link

@jimcheetham commented on GitHub (Dec 18, 2025):

App 0.5.1-dev202512181609, System 0.2.7 is now on my kvm, and it looks like the (new to me) paste system with the default 20ms delay is working well - my original test of 10 lines of text is working correctly.
Pushing the delay down to 1ms does introduce some errors similar to the original problem - but more suggesting that the SHIFT is applied to an immediately preceding key-press, rather than the original difficult-to-characterise behaviour)

So the current state on this dev release seems to address the reported problem, and in a general way.

@jimcheetham commented on GitHub (Dec 18, 2025): App 0.5.1-dev202512181609, System 0.2.7 is now on my kvm, and it looks like the (new to me) paste system with the default 20ms delay is working well - my original test of 10 lines of text is working correctly. Pushing the delay down to 1ms does introduce some errors similar to the original problem - but more suggesting that the SHIFT is applied to an immediately preceding key-press, rather than the original difficult-to-characterise behaviour) So the current state on this dev release seems to address the reported problem, and in a general way.

deekerman commented 2026-02-20 08:19:49 -05:00

Author

Owner

Copy link

@Jonher937 commented on GitHub (Dec 18, 2025):

Can confirm the paste feature (and regular input) is solid for me too since 0.4.9

@Jonher937 commented on GitHub (Dec 18, 2025): Can confirm the paste feature (and regular input) is solid for me too since 0.4.9

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

dev

dependabot/npm_and_yarn/ui/vitejs/plugin-react-swc-4.2.3

dependabot/npm_and_yarn/ui/vite-tsconfig-paths-6.1.1

dependabot/npm_and_yarn/ui/framer-motion-12.34.3

dependabot/npm_and_yarn/ui/tailwind-merge-3.5.0

dependabot/npm_and_yarn/ui/multi-d88693a43a

dependabot/go_modules/github.com/pion/webrtc/v4-4.2.9

dependabot/npm_and_yarn/ui/inlang/cli-3.1.6

dependabot/npm_and_yarn/ui/eslint-plugin-react-refresh-0.5.2

dependabot/go_modules/golang.org/x/sys-0.41.0

dependabot/go_modules/golang.org/x/crypto-0.48.0

dependabot/npm_and_yarn/ui/zustand-5.0.11

dependabot/go_modules/github.com/prometheus/procfs-0.20.1

dependabot/npm_and_yarn/ui/inlang/sdk-2.7.0

dependabot/go_modules/github.com/gin-gonic/gin-1.12.0

dependabot/go_modules/golang.org/x/net-0.51.0

dependabot/github_actions/actions/upload-artifact-7

dependabot/npm_and_yarn/ui/npm_and_yarn-e66adb831b

feat/signed-releases

dependabot/go_modules/github.com/prometheus/common-0.67.5

fix/ipv6-readiness

fix/failsafe-tolerance

fix/failscafe-tolerance

debug/native-logs

fix/retry-sleep-mode-check

copilot/add-copilot-instructions-file

chore/es-lint-redux

fix/deploy-cloud-app

release-cloud-app/0.4.9

release-cloud-app/0.4.8

release-cloud-app/0.4.5

release-cloud-app/0.4.4

release-cloud-app/0.4.3

release-cloud-app/0.4.2

release-cloud-app/0.4.1

release-cloud-app/0.4.0

release-cloud-app/0.3.9

release-cloud-app/0.3.8

fix/prevent-video-restart-loop

fix/en-as-default

backports/ota-und-cgo

e2e-tests

release/049

feat/audio-support-metrics

fix/usb-gadget-init-rebind

feat/lldp

feat/usb-reset

feat/audio-support

fix/hdmi-mutex

main

feat/auto-reload-fe

feat/jsonrpc-typings

feat/ocr

chore/show-codec

chore/golangci-lint-additional

refactor/jsonrpc-kbd

misc/0.4.6-with-old-deps

feat/static-ip-ui

cursor/refactor-uselocation-to-prevent-re-renders-f026

cursor/remove-uselocation-from-devices-id-tsx-7751

chore/eslint-prettier-setup

feat/tls-config

feat/metrics-optin

feat/tls

release/0.5.4-dev202602080922

release/0.5.3

release/0.5.3-dev202602061404

release/0.5.3-dev202601281951

release/0.5.2-dev202601071426

release/0.5.2

release/0.5.2-dev202601070105

release/0.5.2-dev202601070032

release/0.5.2-dev202601061215

release/0.5.2-dev202601051816

release/0.5.2-dev202512291946

release/0.5.1-dev202512211114

release/0.5.1

release/0.5.1-dev202512181840

release/0.5.1-dev202512181609

release/0.5.1-dev202512181144

release/0.5.0-dev202512051510

release/0.5.0

0.5.0-dev202511271013

0.5.0-dev202511271020

release/0.5.0-dev202511211223

release/0.5.0-dev20251120

release/0.4.9

release/0.4.8

release/0.4.7

challenge-base

release/0.4.6

release/0.4.5

release/0.4.5-rc2

release/0.4.5-rc1

release/0.4.4

release/0.4.3

release/0.4.2

release/0.4.1

release/0.4.0

release/0.3.9

release/0.3.8

Labels

Clear 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 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

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/kvm#60

No description provided.