ppisa opened a new issue, #19527: URL: https://github.com/apache/nuttx/issues/19527
### Description / Steps to reproduce the issue Each attempt to use keyboard driver which should support both, special keys defined by `KEYCODE_xxx` macros provided through `enum kbd_keycode_e` defined in [include/nuttx/input/kbd_codec.h](https://github.com/apache/nuttx/blob/master/include/nuttx/input/kbd_codec.h#L44) and some keys which return regular ASCII (i.e. letters and numbers) leads to reported problem. For example, attempt to virtual keyborad provoded by QEMU where all keys can be passed to widgets, editors and terminals provided by Microwindows, see https://github.com/apache/nuttx-apps/pull/3624#issuecomment-5037794975. The NuttX build of Microwindows demo is started by ``` qemu-system-x86_64 -cpu host -enable-kvm -m 2G \ -cdrom boot_mw.iso \ -serial stdio -monitor none -no-reboot -device qemu-xhci -device usb-kbd -device usb-mouse ``` The read from the keyboard driver `n = read(kbd_fd, &event, sizeof(struct keyboard_event_s));` returns ``` struct keyboard_event_s { uint32_t type; uint32_t code; }; ``` where `type` is `KEYBOARD_PRESS` or `KEYBOARD_RELEASE` and the second field `type` should specify key uniquely. But into `code` sent to `keyboard_event()` is ASCII code for example in [g_km_keymap](https://github.com/apache/nuttx/blob/master/boards/arm/common/stm32/src/stm32_kmatrix_gpio.c#L100) in STM32 matrix keyboard but some other drivers call `keyboard_event()` even with X11 encoded KeySim ([arch/sim/src/sim/posix/sim_x11eventloop.c](https://github.com/apache/nuttx/blob/master/arch/sim/src/sim/posix/sim_x11eventloop.c#L126)) and some with keys translated to `KEYCODE_xxx` where is no space for ASCII. The simple fix is to push `KEYCODE_FWDDEL` in [include/nuttx/input/kbd_codec.h](https://github.com/apache/nuttx/blob/master/include/nuttx/input/kbd_codec.h#L44) to be above ASCII, for example 128 or 129. But may it be it can break some targets where it would result in some large arrays, etc. When keyboards with interpreted national symbols are used then it would worth to push special codes even further after basic unicode... If the fix should be future proof, then special keys codes should be mapped to area which is not and will not be used by any Unicode defined codepoints for any language scripts, letters, symbols etc. @ghaerr suggest start for special keys at 0xF800 because that belongs to the Unicode BMP Private Use Area, so no official letters,, glyphs, symbols would not mapped there. If there is no objection I would suggest to try this and if nobody complain that it breaks some applications or makes some keys recoding/remapping to overflow some array then it can be fixed as the standard long term location. @linguini1 seems to agree with shift as well and can comment if to move it so far to ensure no collision or to keep it in single byte range. ### On which OS does this issue occur? [OS: Other] ### What is the version of your OS? The problem is host system agnostic. ### NuttX Version Mainline git version ### Issue Architecture [Arch: all] ### Issue Area [Area: Drivers] ### Host information _No response_ ### Verification - [x] I have verified before submitting the report. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
