[BUG] NuttX defines special key codes that are indistinguishable from keys returning ASCII, i.e., alphanumeric keys

[ppisa]

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 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 apache/nuttx-apps#3624 (comment). 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 in STM32 matrix keyboard but some other drivers call keyboard_event() even with X11 encoded KeySim (arch/sim/src/sim/posix/sim_x11eventloop.c) 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 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 host OS does this issue occur?

The problem is host system agnostic.

NuttX Version

Mainline git version

Issue Architecture

[Arch: all]

Issue Area

[Area: Drivers]

Verification

• I have verified before submitting the report.

[ppisa]

Microwindows define type to hold key code as MWKEY and definitions for special keys are provided in src/include/mwtypes.h. But I think that there is no advantage have keys 1:1 in NutttX. There should be and is defined remapping from NuttX codes to Microwindows ones in current integration drivers imlemented by @Acfboy, see https://github.com/ghaerr/microwindows/blob/master/src/drivers/kbd_nuttx_event.c and https://github.com/ghaerr/microwindows/blob/master/src/drivers/kbd_nuttx_common.h with actual remapping.