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 >
