ppisa commented on issue #18566: URL: https://github.com/apache/nuttx/issues/18566#issuecomment-5153345095
Thanks @Acfboy for work and progress report and @patacongo and @ghaerr for insight feedback. I am not so much sure how big value is/could be X11 for NuttX, I see main value of Micowidows for small devices in portable GDI, blitting, fonts and similar APIs. As for the drawing style, full frames compositor versus old X11 and GDI concept expose events, our current typical NuttX use are MCUs with something like 300 to 500 kB RAM. If you consider 640x480 display even in only RGB565 mode, then Wayland style for two applications extended to almost full screen (where they can be switched between by user) and final combined buffer you need something like 1.7 MB of RAM. Even for 320x240 it is over 400 kB and even this display resolutions are considered too coarse grained (not enough smooth) even for small embedded devices today. So multiple storage for whole display size content is no go and return to original expose based X11 style has a value. For sure, with plenty of RAM situation is different. Surprisingly, even colleagues from Elektroline start to consider Nuttx with Microwidows and even may be SuiTk for SW upgrade to NuttX for their older hardware. They are using LVGL on newer one, but even that is no go for previous generation software only upgrade. As for the terminal, it has value without content refresh after being hidden and then exposed. For most of maintenance, testing tasks it is possible to repeat command etc. Longer term enhancement to keep screen content as the text array would be nice option. Keeping terminal content in text+attributes form is much more efficient than whole widow bitmap. But Nano-X could start to be interesting when NuttX is used on newer MCUs where page tables are no problem, i.e. ESP32S31. Cortex-M has fundamental design limit than its MPU and exception model is incompatible with separated address spaces, because even that MPU can be used as MIPS software TLB with some tricks, the user-space stack has to be fully covered/mapped because else there is no location where to save state during TLB miss leading to double fault and unrecoverable state... This is not case of Cortex-A and RISC-V with Sv32 and higher. On the other hand, for hard real-time MMU and pages maintenance are overhead. I can imagine that in the single address space case it could be uses-full test even that option of single application combined with server with direct calls. If for example https://www.fltk.org/ could be used such way on NuttX, then it could be quite powerful environment. Anyway at least as the test of Microwidows NuttX port, the Nano-X are great. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
