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
