You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@nuttx.apache.org by GitBox <gi...@apache.org> on 2020/10/29 22:15:12 UTC
[GitHub] [incubator-nuttx-apps] w8jcik opened a new pull request #450: LVGL using display driver directly
w8jcik opened a new pull request #450:
URL: https://github.com/apache/incubator-nuttx-apps/pull/450
## Summary
LVGL example is using frambuffer device `/dev/fb0`.
Such framebuffer takes width x height x bpp of memory which is a lot.
But it is possible to use LVGL with just a procedure that draws.
This PR changes LVGL example to work without `/dev/fb0`, with low memory footprint and it works for SSD1289, but it is not ready for merge. Not handling other color depths for example, I can add it.
I am opening this draft PR, because I have a question. I consider this change an obvious thing to do, so I would expect somebody to do it before. Am I missing something? Is it possible to configure `/dev/fb0` interface to not use that much memory. I know that `/dev/fb0` can be configured to talk to basic displays which accept simple drawing procedures, but it always allocates width x height x bpp.
Should I finish adding this here, or should such functionality be added to `/dev/fb0`. Not sure if it would make sense. On one hand it would be a framebuffer without framebuffer. On the other hand, most display chips have framebuffer of it's own. Sending rows of pixels is just filling their internal framebuffer. So `/dev/fb0` could represent that framebuffer and offer uniform interface.
## Impact
Low memory requirement to use LVGL.
## Testing
This is draft pull request.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx-apps] v01d commented on pull request #450: LVGL without framebuffer
Posted by GitBox <gi...@apache.org>.
v01d commented on pull request #450:
URL: https://github.com/apache/incubator-nuttx-apps/pull/450#issuecomment-719108586
I have opened the relevant PR on main nuttx repo: https://github.com/apache/incubator-nuttx/pull/2166
I'm closing this as it is not the proper way to deal with this. You can try extending the lvgldemo app with
this driver (once it is merged), which would be more appropriate for LCD devices.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx-apps] v01d closed pull request #450: LVGL without framebuffer
Posted by GitBox <gi...@apache.org>.
v01d closed pull request #450:
URL: https://github.com/apache/incubator-nuttx-apps/pull/450
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx-apps] v01d commented on pull request #450: LVGL without framebuffer
Posted by GitBox <gi...@apache.org>.
v01d commented on pull request #450:
URL: https://github.com/apache/incubator-nuttx-apps/pull/450#issuecomment-719071440
Wow, incredible coincidence that I was just adding a PR for lvgl.
Regarding this change: this is not the way to do it since you are calling OS interfaces directly. In fact, I was also about to make a PR for a LCD character driver I wrote sometime ago and never upstreamed. It is exactly for this reason: it offers userspace interface to deal with LCDs. It also avoids the need for the framebuffer -> LCD driver which is quite inefficient in memory and communication.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org