Thanks Tomek! I'll take a closer look at these! On Mon, Jun 29, 2026 at 3:27 PM Tomek CEDRO <[email protected]> wrote:
> 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 > > > >
