Porting Nano-X to NuttX

[shijogeorge24]

I was planning to port nano-x to Nuttx

1. what are the major part that need to be ported ?
2. Recommendations and suggestions for the porting process are highly encouraged and appreciated.

[georgp24]

I would recommend to get Nano-X to work on a standard Linux system first and shorten the makefile to avoid that all the examples are build. Then give it a try on NuttX. Look at the config file and turn off everything you can first, to see if it compiles at all. Then turn on the options step by step.

[ghaerr]

After getting Nano-X running on a Linux desktop (preferably using the src/Config/config.linux-fb configuration file copied to src/config, or using X11 using src/Config/config.linux-X11), the next steps would be to look at the screen, keyboard and mouse drivers and determine how to best write new ones for NuttX. These drivers are in the src/drivers directory. At first, skipping mouse and keyboard input and only getting a screen driver working would be simplest. The Linux framebuffer driver is src/drivers/scr_fb.c.

Some quite old but useful architecture information is available on the microwindows.org website: http://www.microwindows.org/microwindows_architecture.html.

There is also documentation in the https://github.com/ghaerr/microwindows/tree/master/doc directory.

[ppisa]

I was thinking about Nano-X and our SuiTk based on it to be ported to NuttX. I have years of experience with Nano-X or better lower GD Microwindows layer porting to H8S sysless, iMX1 sysless and iMX1 on RTEMS. We have even added VESA bios based drivers to RTEMS mainline and then used it for Microwindows demos.

Me, my students and company for which I provide consultations use and contribute to NuttX mainline intensively. They use NuttX include graphic (LVGL).

That is, I have interest in Nano-X on NuttX, we have lot of experience on all sides. Problem is the time. But I hope that we can provide at least some help, code review etc.

By the way, I am at Embedded World in Nuremberg now, so if somebody has interest in these and other topic than we can be reached there OSADL has kindly provided us space (hall 4, booth 4-168) to present some of our univesity projects.

[georgp24]

It took me a long time to get a screen driver to work. To test the Makefile, you can use my scr_null.c driver together with the kbd_null.c and mou_null.c drivers. This way you can see if it compiles at all.
https://github.com/ghaerr/microwindows/blob/dd0277666ac0ff9551e3c8e04544494223368953/src/drivers/scr_null.c

[shijogeorge24]

I tested it on a Linux machine. It compiles when we disable a few options, but the apps don't work at all. When I tried the same with an X11 config file, it doesn't even compile.

ubuntu :23.04
kernel :Linux 6.2.0-39-generic

disbled options

HAVE_BMP_SUPPORT = N
HAVE_GIF_SUPPORT = N
HAVE_PNM_SUPPORT = N
HAVE_XPM_SUPPORT = N

HAVE_PNG_SUPPORT = N

HAVE_PCF_SUPPORT = N
HAVE_PCFGZ_SUPPORT = N

HAVE_FREETYPE_2_SUPPORT = N

config file :config.linux-fb

~/nano-x/microwindows/src$ ./runapp demo-nuklear-overview
Cannot bind to named socket
nxclient: retry connect attempt 2
nxclient: retry connect attempt 3
nxclient: retry connect attempt 4
nxclient: retry connect attempt 5
nxclient: retry connect attempt 6
nxclient: retry connect attempt 7
nxclient: retry connect attempt 8
nxclient: retry connect attempt 9
nxclient: retry connect attempt 10
Unable to open graphics

~/nano-x/microwindows/src$ ./runapp demo-aafont
Cannot bind to named socket
nxclient: retry connect attempt 2
nxclient: retry connect attempt 3
nxclient: retry connect attempt 4
nxclient: retry connect attempt 5
nxclient: retry connect attempt 6
nxclient: retry connect attempt 7
nxclient: retry connect attempt 8
nxclient: retry connect attempt 9
nxclient: retry connect attempt 10
cannot open graphics

~/nano-x/microwindows/src$ ./runapp demo-composite
Cannot bind to named socket
nxclient: retry connect attempt 2
nxclient: retry connect attempt 3
nxclient: retry connect attempt 4
nxclient: retry connect attempt 5
nxclient: retry connect attempt 6
nxclient: retry connect attempt 7
nxclient: retry connect attempt 8
nxclient: retry connect attempt 9
nxclient: retry connect attempt 10
Couldn't connect to Nano-X server

~/nano-x/microwindows/src$ ./runapp mwmine
KDGKMODE: Inappropriate ioctl for device
Cannot initialise keyboard

~/nano-x/microwindows/src$ ./runapp mwdvetest
KDGKMODE: Inappropriate ioctl for device
Cannot initialise keyboard

X11

config file :config.linux-X11

Linking nano-X ...
/usr/bin/ld: /home/shijo/nano-x/microwindows/src/obj/nanox/srvmain.o:(.bss+0x2c): multiple definition of `nxres'; /home/shijo/nano-x/microwindows/src/obj/drivers/scr_x11.o:(.bss+0x3c): first defined here
/usr/bin/ld: /home/shijo/nano-x/microwindows/src/obj/nanox/srvmain.o:(.bss+0x28): multiple definition of `nyres'; /home/shijo/nano-x/microwindows/src/obj/drivers/scr_x11.o:(.bss+0x38): first defined here
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:101: /home/shijo/nano-x/microwindows/src/bin/nano-X] Error 1
make[1]: Leaving directory '/home/shijo/nano-x/microwindows/src/nanox'
make: *** [/home/shijo/nano-x/microwindows/src/Makefile.rules:481: subdir-/home/shijo/nano-x/microwindows/src/nanox] Error 2

[ghaerr]

~/nano-x/microwindows/src$ ./runapp mwmine
KDGKMODE: Inappropriate ioctl for device
Cannot initialise keyboard

Try changing to the non-scancode keyboard driver in your config file. Change KEYBOARD=SCANKBD to

KEYBOARD=TTYKBD

~/nano-x/microwindows/src$ ./runapp demo-nuklear-overview
Cannot bind to named socket

This means the client can't connect to the named pipe /tmp/.nano-X. This could be for permissions (non-root?) or other reasons. You can create a non-client/server version of nano-X, which will likely be what is desired for NuttX anyways by setting the following in config:

LINK_APP_INTO_SERVER     = Y

You then won't have to use ./runapp to start both the client and server, just run the application itself (e.g. bin/demo-composite

/usr/bin/ld: /home/shijo/nano-x/microwindows/src/obj/nanox/srvmain.o:(.bss+0x2c): multiple definition of `nxres';

This is caused by a new default of a GCC option (-fno-common) that disallows multiple "common" definitions of variables that are declared MWCOORD nxres in two separate source files. This can be corrected by changing the following in drivers/scr_x11.c (or nanox/srvmain, if you're only running nano-X executables):

extern MWCOORD nxres, nyres;

[ghaerr]

Hello @ppisa,

Nice to hear from you, its been a long time! :)

I was thinking about Nano-X and our SuiTk based on it to be ported to NuttX. I have years of experience with Nano-X or better lower GD Microwindows layer porting to

Wow, SuiTk is pretty cool, I never knew about it. Nice using the Microwindows Gd lower layer and building your library on top of it. Now, years later after the initial design, I can see that the Gd layer could have been more useful for other projects with even better separation from the too-complicated make mechanism(s). I've been thinking about building a newer version of Microwindows one day that would run more like a modern compositor that draws high level graphics objects and text using a built-in rasterizer, but have been too consumed with other projects. It could live on top of a stripped-down Gd layer.

Me, my students and company for which I provide consultations use and contribute to NuttX mainline intensively. They use NuttX include graphic (LVGL).

I've looked at LVGL, it's a very nice library with its own compositor and large widget set, IIRC.

For this project, porting Nano-X to NuttX, it would be helpful to more fully understand the nature of how the applications would run on NuttX (client/server, bound-in direct graphics library calls, etc), whether a window system is needed, and what APIs are desired, things like that. That is, unless the idea is just a basic port of Microwindows and Nano-X to NuttX.

As you know, with a lower level framebuffer, it should be quite straightforward to port Microwindows/Nano-X to another OS, tools and whatnot outstanding. I ported to a "new" 32-bit OS called Fiwix in a few days (see 606bfb0 for details, this could help @shijogeorge24). A new screen driver based heavily on Linux framebuffer was written, with some small changes to the mouse and keyboard drivers, and the port was done. I'm much less familiar with NuttX, and unable to advise on make systems, compilers and OS APIs as I have not ever run it.

Have fun at Embedded World!

Thank you!

[acassis]

sic

As you know, with a lower level framebuffer, it should be quite straightforward to port Microwindows/Nano-X to another OS, tools and whatnot outstanding. I ported to a "new" 32-bit OS called Fiwix in a few days (see 606bfb0 for details, this could help @shijogeorge24). A new screen driver based heavily on Linux framebuffer was written, with some small changes to the mouse and keyboard drivers, and the port was done. I'm much less familiar with NuttX, and unable to advise on make systems, compilers and OS APIs as I have not ever run it.

Hi @ghaerr, just like Linux, NuttX has many options: originally Mr. Greg Nutt create a NX Server (similar to X Server idea for Unix, but using message queue instead of network/sockets), more info: https://nuttx.apache.org/docs/latest/components/nxgraphics/index.html

Later on NuttX gained framebuffer driver support, similar to Linux framebuffer: https://nuttx.apache.org/docs/latest/components/drivers/special/framebuffer.html

There is also something called lcd_dev that I don't know exactly how it work, but seems to be char device that lets to control LCD displays directly: https://nuttx.apache.org/docs/latest/components/drivers/special/lcd.html

I think for simplicity and easy to implement, it should be better add support to microwindows/Nano-X over framebuffer.

A fun fact is that some years ago Greg ported (rewrote in C++) the "first" WM for Unix, the TWM: https://www.flickr.com/photos/79703543@N00/52404700603/in/dateposted-public/ unfortunately NX Server and TWM didn't get too much usage by the community because people normally prefer eyes-candy interface! :-)

[ghaerr]

Hello @acassis,

originally Mr. Greg Nutt create a NX Server (similar to X Server idea for Unix, but using message queue instead of network/sockets)

I would suggest starting the Nano-X port without client/server, as discussed above first. But if NuttX lacks sockets, then there would be a bit more coding involved to setup the client/server data stream using a message queue. We can get into that later if needed.

more info: https://nuttx.apache.org/docs/latest/components/nxgraphics/index.html

Nice documentation. Nano-X also supports emulated frame buffers and has both an emulated framebuffer driver and and framebuffer emulator running on X11. It uses a named pipe to transfer screen chunks and mouse/keyboard data from the graphics application. We probably don't need that for the NuttX port unless its graphics subsystem uses framebuffer emulators a lot, which sometimes comes in handy for building applications on the desktop rather than directly on the target at first. However Nano-X gets around that problem by allowing alternate screen/mouse/keyboard drivers to be linked into the same application with no other changes, allowing for desktop and/or target development.

Later on NuttX gained framebuffer driver support, similar to Linux framebuffer:

Great, I would suggest having someone familiar with NuttX framebuffer API replace the equivalent calls in the Linux FB driver in drivers/scr_fb.c.

There is also something called lcd_dev

Nano-X could support direct I/O to LCD but I don't recommend that due to the speed issues encountered, since Nano-X keeps bitmaps and offscreen pixmaps in native framebuffer format for speed, which have to be converted for non-FB hardware.

I think for simplicity and easy to implement, it should be better add support to microwindows/Nano-X over framebuffer.

Agreed!

A fun fact is that some years ago Greg ported (rewrote in C++) the "first" WM for Unix, the TWM
unfortunately NX Server and TWM didn't get too much usage by the community because people normally prefer eyes-candy interface! :-)

Well, the same could be said about Microwindows/Nano-X except that sometimes its more important to have small, fast binaries that run well on embedded hardware at the expense of huge graphics libraries with their lovely graphics :)