acassis commented on PR #3624: URL: https://github.com/apache/nuttx-apps/pull/3624#issuecomment-5064118365
> > > The NnuttX provides its KEYCODE_xxx macros in [kbd_codec.h](https://github.com/apache/nuttx/blob/master/include/nuttx/input/kbd_codec.h#L44) for special keys. But only for these and rest is expected to be ASCII. > > > > > > Hi, @ppisa . I have a question about this statement. It seems to me that the ranges of the `KEYCODE_xxx` macros and ASCII are conflicting, which makes it impossible for my driver to distinguish whether it's a character or a special key. In my `sim:mw` setup, this results in being unable to type a space. > > Yes, you are right, I expected that for `KEYCODE_NORMAL` the ASCII value is returned in another field of the event structure, but there is only > > ``` > struct keyboard_event_s > { > uint32_t type; > uint32_t code; > }; > ``` > > where `type` is `KEYBOARD_PRESS` or `KEYBOARD_RELEASE`. 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. > > So this seems to be call for priority issue. > > @acassis @gregory-nutt Please, do you have some some insight what is right? > > 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... > > > > I think that there could be two drivers, one for event type and another for raw keyboards. This could be configured through Kconfig, same would be useful for device name. > > > > > > Two drivers makes the code cleaner. But specify the device path/name via Kconfig risks inconsistency with the real device. Alternatively, if Microwindows auto-selects the device based on NuttX config, then we have to keep both sides in sync — which adds maintenance overhead. > > Yes but NuttX is based on configuration and it is better to fail then to do lot of testing of different device names and even deciding if it is raw driver or event based. But in general it seems that there is pace for some discussion and making KBD simple on the NuttX side. > > > > You should try even if Nano-X server and clients can be run on NuttX. > > > > > > Okay, I'll try server and client of NanoX. > > Thanks. Hi @ppisa I don't know the right approach to keyboard input keys symbols. Actually @linguini1 faced similar issue when porting Doom to NuttX. Unfortunately NuttX doesn't have a standard keyboard symbols -- 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]
