drivers/input: partial fix of indistinguishable ASCII and special keycodes - #19577
Open
ppisa wants to merge 1 commit into
Open
drivers/input: partial fix of indistinguishable ASCII and special keycodes#19577ppisa wants to merge 1 commit into
ppisa wants to merge 1 commit into
Conversation
ppisa
requested review from
jerpelea,
pkarashchenko and
xiaoxiang781216
as code owners
July 29, 2026 12:42
ppisa
force-pushed
the
kbd-special-keys-fix-base
branch
from
July 29, 2026 12:43
190b1d8 to
bfbc6b6
Compare
…codes As analyzed, the NuttX initial keyboard API design uses event type KBD_SPECPRESS/KBD_SPECREL to deliver special keys and KBD_PRESS/KBD_RELEASE to deliver ASCII codes. But it seems that this design choice has not been followed in virtio-input, goldfish_events and sim_keyboard designs and result is that external keyboard special keys events are mapped to KEYCODE_xxx values which start from 0 and overlaps with ASCII keys. The issue is tracked under apache#19527 number. This set of changes correct events reporting for mentioned keyboards to report right event type for special keys. The solution is only partial at this phase. Virtual and more complex keyboards usually deliver key pressures as scancodes (key position on keyboard) and mapping to ASCII for keys which corresponds to letter and other similar keys lacks mapping of national alphabets, second row symbols and switch to capital letter according to modifiers. Signed-off-by: Pavel Pisa <pisa@fel.cvut.cz>
ppisa
force-pushed
the
kbd-special-keys-fix-base
branch
from
July 29, 2026 13:24
bfbc6b6 to
b872b73
Compare
github-actions
Bot
added
Arch: simulator
acassis
requested changes
Jul 29, 2026
acassis
left a comment
acassis
left a comment
Contributor
There was a problem hiding this comment.
@ppisa thank you very much. I think this modification needs to be Documented in some place, maybe an Introduction to Input Device Drivers explaining the limitations, etc could be created here: https://nuttx.apache.org/docs/latest/components/drivers/character/input/index.html
|
1 task
| ****************************************************************************/ | ||
|
|
||
| uint32_t keyboard_translate_virtio_code(uint16_t keycode); | ||
| uint32_t keyboard_translate_virtio_code(uint16_t keycode, bool *p_special); |
Contributor
There was a problem hiding this comment.
Suggested change
| uint32_t keyboard_translate_virtio_code(uint16_t keycode, bool *p_special); | |
| uint32_t keyboard_translate_virtio_code(uint16_t keycode, bool *special); |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
As analyzed, the NuttX initial keyboard API design uses event type KBD_SPECPRESS/KBD_SPECREL to deliver special keys and KBD_PRESS/KBD_RELEASE to deliver ASCII codes.
But it seems that this design choice has not been followed in virtio-input, goldfish_events and sim_keyboard designs and result is that external keyboard special keys events are mapped to KEYCODE_xxx values which start from 0 and overlaps with ASCII keys.
The issue is tracked under #19527 number.
This set of changes correct events reporting for mentioned keyboards to report right event type for special keys.
The solution is only partial at this phase.
Virtual and more complex keyboards usually deliver key pressures as scancodes (key position on keyboard) and mapping to ASCII for keys which corresponds to letter and other similar keys lacks mapping of national alphabets, second row symbols and switch to capital letter according to modifiers.
Impact
Any attempt to use virtio-input, goldfish_events and sim_keyboard is broken, keys
which could be delivered as ASCII codes are often incorrectly remapped
to special key code but delivered as regular ASCII keys or they are delivered
as scancodes. Special keys are not marked as special so they are incorrectly
interpreted as ASCII coded.
Testing
The code has been tested with SIM BSP and updated Microwidows example
as well as with qemu-intel64:fb/qemu-intel64:mw configuration.
In this case multiple keyboard options have been used.
Invocation with VirtIO keyboard
Invocation with raw USB keyboard
It would worth to test code with some other NuttX demos which are know
to work with both special keys and keys reported in ASCII range.