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
