ppisa commented on issue #18566: URL: https://github.com/apache/nuttx/issues/18566#issuecomment-4384035705
Congratulation to be accepted in this year GSoC program. There is link to related Microwindows/Nano-X issue entry https://github.com/ghaerr/microwindows/issues/85 My idea about result of the project is to include `nano-x` or `nanox` in the NuttX APPS repository under [nuttx-apps/graphics](https://github.com/apache/nuttx-apps/tree/master/graphics) which would use something like ``` $(call DOWNLOAD,$(NANOX_URL),$(NANOX_ZIP)) ``` in the `Makefile`. Then there will be implemented logic to call `Microwindows` own `Makefiles` such way that the library, server, window manager, applications and examples are build. I expect that Microwindows would need to be forked to allow this external build call which would require some top level Makefile and rules updates. The NuttX specific screen driver(s), mouse, touchscreen and keyboard drivers needs to be implemented as Microwindows new configurable options. All these changes should be done and cleaned at the end such way that they are acceptable for Nano-X mainline. The subdirectory Makefiles should not be touched or some minor changes which are acceptable for @ghaerr could be done there. But final version should leave other already supported Microwindows build targets functional. I hope that with enough care the result could be acceptable for Microwindows/Nano-X mainline. As for the use of `nxglib`, I am not sure. I think that Microwindows/Nano-X port to NuttX framebuffer mmaped or simply shared device would be the most straightforward and would be optimal choice for the targets with enough RAM for framebuffer. For memory constrained devices some mapping directly to NuttX LCD driver API could help. Microwindows provides exposed region principles so it could be possible even for X11 mode to ask visible windows in some strip to update and then specific screen driver sends data to the target and schedules next strip to redraw. Another option is Microwidows screen driver utilizing direct drawing of pixels through NuttX LCD API one by one or in lines or rectangles. This would be probably least memory demanding on the MCU side and SPI and I2C panels have enough memory for at least one full image to be kept. But I would start with simple screen driver for NuttX framebuffer the first. We have used such approach on systemless H8S, LPC1768/LPC40xx targets as well as on iMX1 under RTEMS and in other application under Linux where framebuffer driver has been already included in Microwindows. -- 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]
