Thanks Matteo! Looks like EVDEV is the most portable standard right now? It works on Linux and FreeBSD! :-) https://en.wikipedia.org/wiki/Evdev https://man.freebsd.org/cgi/man.cgi?query=evdev https://www.freedesktop.org/software/libevdev/doc/latest/
There is also LIBINPUT but notice wayland in the url :-P https://wayland.freedesktop.org/libinput/doc/latest/index.html. And Linux UINPUT https://www.kernel.org/doc/html/v4.12/input/uinput.html that also redirects to LIBEVDEV: " 1.7.3. libevdev libevdev is a wrapper library for evdev devices that provides interfaces to create uinput devices and send events. libevdev is less error-prone than accessing uinput directly, and should be considered for new software. For examples and more information about libevdev: https://www.freedesktop.org/software/libevdev/doc/latest/ " This EVDEV could integrate well with LVGL, SDL, gamepads, etc? https://lvgl.io/docs/open/common-widget-features/events https://wiki.libsdl.org/SDL3/SDL_HINT_EVDEV_DEVICES https://wiki.archlinux.org/title/Gamepad -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info On Mon, Jun 29, 2026 at 5:50 PM Matteo Golin <[email protected]> wrote: > > After looking into it a little more (and stumbling across a note in the > LVGL docs that the NuttX keyboard codec is highly non-standard: > https://lvgl.io/docs/open/integration/rtos/nuttx), I think we may need to > determine a change in the codec to implement to become more standardized. > I'm not sure yet what that would look like to remain embedded-friendly and > backward compatible with whatever relied on the original codec, but I don't > think the current one will allow us to do much with proper keyboard input. > > On Mon, Jun 1, 2026 at 2:25 AM Tomek CEDRO <[email protected]> wrote: > > > Work in progress here: > > > > https://github.com/cederom/nuttx/tree/cederom-20260531-doc_graphics > > > > Most of the stuff was already there but not clearly visible. Updated to: > > components/graphics > > + framebuffer > > + nx graphics subsystem <- one page with table of contents > > > > No input details though. > > > > Comments welcome :-) > > > > -- > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > > > On Sun, May 31, 2026 at 8:56 PM Tomek CEDRO <[email protected]> wrote: > > > > > > Thank you Greg! I have moved remaining "implementation" parts from > > > cwiki to new docs recently, will update the display too :-) > > > > > > https://github.com/apache/nuttx/issues/19007 > > > > > > -- > > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > > > > > On Sun, May 31, 2026 at 8:41 PM Gregory Nutt <[email protected]> > > wrote: > > > > > > > > I discovered a long time ago that graphics are too controversial and > > there are so many differences in opinions and preferences that no one > > working on it can really make progress. > > > > > > > > There is a LOT of documentation of the graphics subsystem but this all > > got shit-canned when we created the new, simpler documents. But it is > > still available here: > > > > > > > > https://cwiki.apache.org/confluence/display/NUTTX/Graphics > > > > > > > > With some presentations here: > > > > > > > > > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139629398 > > > > > > > > And some documentation: > > > > > > > > > > https://cwiki.apache.org/confluence/display/NUTTX/NX+Graphics+Subsystem > > > > https://cwiki.apache.org/confluence/display/NUTTX/NxWidgets+Interface > > > > https://cwiki.apache.org/confluence/display/NUTTX/NxWM+Threading+Model > > > > > > > > Architecturally, NxWM has only a little in common with X11. It is > > more like Gnome in that environment. It is a window manager that runs in > > user space. There are several other window managers available in this old > > unsupported code as well, like one inspired by TWM. > > > > > > > > The architecture as I see it is: > > > > > > > > > > > > 1. > > > > User space window managers and graphics helpers (like the NxWidgets), > > > > 2. > > > > A graphics library at nuttx/libs/libnx that provides a multi-threaded > > interface to the NX graphics server. This is mostly user space too. > > > > 3. > > > > The NX graphics server is deep in the OS and connects to the graphics > > library via a message queue. It can serialize accesses and control > > graphics driver directly. > > > > > > > > The is also an important feature of per-window frame buffers that > > supports standard per-window operations: Resize, grab and move, etc. > > > > > > > > This is important stuff that we as a group were never able to focus > > on. It has been a long time since I was active, but this is the kind of > > thing that could draw me in if there were anyone out with common goals and > > similar architectural thinking. > > > > ________________________________ > > > > From: Tomek CEDRO <[email protected]> > > > > Sent: Sunday, May 31, 2026 2:11 PM > > > > To: [email protected] <[email protected]> > > > > Subject: Re: NuttX keyboard codec confusions > > > > > > > > Hey there Matteo :-) > > > > > > > > What I found in current documentation: > > > > * > > https://nuttx.apache.org/docs/latest/components/drivers/character/input/keypad-keyboard.html > > > > * > > https://nuttx.apache.org/docs/latest/applications/graphics/input/getevent.html > > > > * > > https://nuttx.apache.org/docs/latest/applications/graphics/nxwm/cnxconsole.html > > > > > > > > But there is not much explanation to your question. Probably NXWM is > > > > closest approach to X11/Xorg? > > > > > > > > Do we need some update, maybe a layer or dedicated module, to match > > > > X11/Xorg/Unix like input processing? > > > > > > > > -- > > > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > > > > > > > On Sun, May 31, 2026 at 2:31 PM Matteo Golin <[email protected]> > > wrote: > > > > > > > > > > Hello everyone, > > > > > > > > > > While working on porting DOOM to NuttX with keyboard input, I got > > confused > > > > > by the keyboard codec NuttX uses. > > > > > > > > > > The entire codec is defined using an enum for just "special keys", > > like > > > > > arrow keys and print-screen, etc. There are no definitions for > > > > > letter/number keys, which leads me to believe that the ASCII code is > > just > > > > > used for these (which tracks with my experimentation of `/dev/kbd` > > on sim). > > > > > However, the entire enum itself starts at KEYCODE_NORMAL = 0. > > > > > > > > > > This means that the keyboard codec is in conflict with ASCII > > characters. > > > > > When I went to extend it and add buttons like CTRL and ALT, I > > noticed that > > > > > pressing the spacebar no longer worked due to conflict with the > > keyboard > > > > > codec. > > > > > > > > > > As far as I can tell from the code, the keyboard codec translators > > I've > > > > > seen don't rely on the enum starting at 0. I would like to change it > > to > > > > > start at 128, so that it doesn't conflict with any ASCII characters, > > but I > > > > > don't trust my understanding of the keyboard input system enough to > > > > > guarantee I'm not breaking anything. > > > > > > > > > > Is there anyone more familiar with this part of NuttX who can tell > > me what > > > > > the rationale for the keyboard codec starting at 0 is, and how it's > > > > > supposed to work/be dealt with from userspace? > > > > > > > > > > Thanks, > > > > > Matteo > >
