Another thing I would mention is that the current logic supports numerous input and output devices. For input this includes all of the keyboard support, mouse support, and touchscreen support. A separate user-space "listener" thread receives the input from hardware drivers and directs the input to the appropriate window logic and directs the input to the window at that X/Y position that has focus. ________________________________ From: Gregory Nutt <[email protected]> Sent: Sunday, May 31, 2026 2:41 PM To: [email protected] <[email protected]> Subject: Re: NuttX keyboard codec confusions
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
