Re: FB console/terminal
Hi Tim, I think there is not a framebuffer text in place for NuttX, but you can use the code to handle text fonts from nx graphics to render the text directly in the framebuffer. For Linux some years ago I used fbtext https://sourceforge.net/projects/fbtext/ to print a message from initrd to let user know a secret key the decript the disk. Alternatively if you want to print images in the screen you can use something like fbprint ( https://github.com/Weinsen/fbprint ). BR, Alan On Saturday, February 15, 2025, Tim Hardisty wrote: > What is efficient solution to just do text though? > > > On 15 Feb 2025, at 13:42, Alan C. Assis wrote: > > > > Hi Tim, > > > > You can create a NuttX application with LVGL and display your message or > > image. > > > > Actually you don't need to use a graphic library if you just want to > write > > in the framebuffer, you can convert image to display directly in the > > /dev/fb0 > > > > BR, > > > > Alan > > > >> On Sat, Feb 15, 2025 at 7:45 AM Tim Hardisty > >> wrote: > >> > >> Hello NuttX Colleagues! > >> > >> During MCUboot I want to display text messages on the framebuffer LCD > >> driver (/dev/fb). This could either be via a FB console (useful for > >> other reasons) or a FB terminal, or something else. > >> > >> I also quite like the idea of my main graphics app - LVGL based - having > >> a console option (for syslog messages, perhaps), so perhaps LVGL is an > >> option, but I'm wanting to keep the size down of course. > >> > >> Which of the NuttX armoury of features might be a good choice for this? > >> > >> Thanks! > >> > >> TimJTi > >> > >> >
Re: [VOTE] NuttX Contributing Guidelines update 202502.
On Sat, Feb 15, 2025 at 4:53 PM Tomek CEDRO wrote: > > Okay so here goes the vote results :-) Thanks, Tomek, for doing all of this! I would like to add some more of my thoughts: Regarding these rules: 9. Zero trust approach to user testing 10. Breaking changes not welcome. 11. Respect for long term maintenance and self-compatibility 12. Breaking changes handling process 14. Minimum code reviews 2 -> 4 Raiden said something very relevant (in #11) that I would like to expand upon: > Not every interface in NuttX is equally mature. Until we > establish which API is stable and which is not, this change is bad. > Breaking a stable API should be avoided, breaking an unstable and > under development API should be allowed. We *should* try to keep NuttX as stable and backwards compatible as feasible so that people can adopt NuttX and count on it to keep working for them in the long run. At the same time, we need to be very careful not to make rules that are too strict and inflexible, because then we would risk turning away contributors and we would end up with old cruft that is really broken and generating a lot of complaints but can't be fixed because it would break the rules. So we need to strike a good balance. How to strike a good balance? When deciding how easy or hard it should be to change some code, we should consider: * How new or mature the area of code is * How well the area of code works (known buggy .. known good) * How much will changes in this code affect other parts of the system * How well the area conforms to established standards Then: Code in mainline that is relatively new, known buggy, and won't affect too much the rest of the system should be allowed to change easily. Not too much discussions, votes, and other ceremony needed here. Just make the change with one reviewer (not from same org) and move on... Code in mainline that has existed for a long time, is mature, known to be working well, and will break many parts of the system if changed, should require careful consideration before changing. We shouldn't outright forbid such a change; maybe it's a "breaking" change but still needs to happen for important reasons. This is an area that needs lots of input, so, there should be a good discussion in the mailing lists, possibly including a [VOTE] to decide should we make this change or not. We could come up with some kind of formal "status" for each area of the code: * Under Development * Experimental * Production Stable * Periphery I'll describe each: # Under Development: This status is for things that are substantially working but are still considered incomplete. Examples might be a new CPU arch, a new board, a new driver, etc. Why include it in NuttX mainline? Because this way, other people can join the effort. Consider how Lup made NuttX boot on the PinePhone. (Thanks, Lup!) Most features were not implemented, but putting it in NuttX mainline means that people could play with it, experiment with it, hack on it, and help develop it further. It helps to inspire new contributors and that's a good thing. We shouldn't include totally broken things, but under development and *working* to some extent is welcome. If it's a new CPU arch and board, NuttX should at least boot to NSH prompt. It's okay if most other drivers (display, sound, GPS, who knows what) don't work yet. Areas like this should be allowed to change easily without too much worrying about stability or backwards compatibility because they are not stable yet and people probably shouldn't try to build products with them. If you do build a product with "Under Development" code, you should understand the risks and be prepared to solve problems and hack on it when things break. One reviewer (not from the same org) should be enough. # Experimental: This status is for things that are considered "finished" (not "Under Development") but it hasn't received widespread testing yet. There might be rough edges or occasional crash or who knows what. So it's finished, but needs more testing in the wild before it can be considered good enough for production use. People can consider to build products with this kind of code but should be informed of the risks and be prepared to test heavily and help solve problems. It should be relatively easy to submit bugfixes for this kind of code. 1 reviewer (not from the same org) should be enough. Breaking changes in this kind of code should have a discussion and maybe 2 reviewers, because the code might already be used in production somewhere. If someone is using it in production with good results, perhaps it should be elevated to the next level: # Production Stable: This status is for things that are complete and working in production. This kind of code needs to remain as stable as possible. Bugfixes are always welcome, of course. I suggest 3 reviewers (not from the same org) and a good description of what was the bug and how is it fixed. Breaking changes are possible but need to
Re: FB console/terminal
Thanks Alan - I'll see if I can find nx graphics code to repurpose and, if not immediately obviously, I'm sure there's code out there, such the fbtext tool you linked to. On 16/02/2025 10:45, Alan C. Assis wrote: Hi Tim, I think there is not a framebuffer text in place for NuttX, but you can use the code to handle text fonts from nx graphics to render the text directly in the framebuffer. For Linux some years ago I used fbtext https://sourceforge.net/projects/fbtext/ to print a message from initrd to let user know a secret key the decript the disk. Alternatively if you want to print images in the screen you can use something like fbprint ( https://github.com/Weinsen/fbprint ). BR, Alan On Saturday, February 15, 2025, Tim Hardisty wrote: What is efficient solution to just do text though? On 15 Feb 2025, at 13:42, Alan C. Assis wrote: Hi Tim, You can create a NuttX application with LVGL and display your message or image. Actually you don't need to use a graphic library if you just want to write in the framebuffer, you can convert image to display directly in the /dev/fb0 BR, Alan On Sat, Feb 15, 2025 at 7:45 AM Tim Hardisty wrote: Hello NuttX Colleagues! During MCUboot I want to display text messages on the framebuffer LCD driver (/dev/fb). This could either be via a FB console (useful for other reasons) or a FB terminal, or something else. I also quite like the idea of my main graphics app - LVGL based - having a console option (for syslog messages, perhaps), so perhaps LVGL is an option, but I'm wanting to keep the size down of course. Which of the NuttX armoury of features might be a good choice for this? Thanks! TimJTi
Re: [VOTE] NuttX Contributing Guidelines update 202502.
Thank you Nathan :-) I just noticed that we missed self review can be added to 17 :-P I am allergic to bureaucracy myself. All this is to improve project quality not to make life harder. But also avoid obvious situations like self merging, sending untested changes, making breaking changes standard, and in general distinguishing lack of self-compatibility from fake innovation. NuttX is really unique in modern ICT world of enforced changes and we should nurture that quality over quantity approach. This is why there are no changes in requirements yet until everyone is happy and we sort things out :-) I checked that NuttX supports over 15 different architectures, 342 unique boards, and over 1600 different configurations!! 2024Q4 we had 1233 commits in nuttx repo and 228 commits in nuttx-apps repo :-) Some good things already noticed is the increase in reviewers activity and this was my main goal behind point 14 whatever final form it gets, PR and git messages improved already, and we are working on distributed test tools, so the situation seems quite motivational and constructive, big thank you everyone for that :-) Have a good day folks :-) Tomek On Sun, Feb 16, 2025 at 6:31 PM Nathan Hartman wrote: > > On Sat, Feb 15, 2025 at 4:53 PM Tomek CEDRO wrote: > > > > Okay so here goes the vote results :-) > > Thanks, Tomek, for doing all of this! > > I would like to add some more of my thoughts: > > Regarding these rules: > > 9. Zero trust approach to user testing > 10. Breaking changes not welcome. > 11. Respect for long term maintenance and self-compatibility > 12. Breaking changes handling process > 14. Minimum code reviews 2 -> 4 > > Raiden said something very relevant (in #11) that I would like to expand upon: > > > Not every interface in NuttX is equally mature. Until we > > establish which API is stable and which is not, this change is bad. > > Breaking a stable API should be avoided, breaking an unstable and > > under development API should be allowed. > > We *should* try to keep NuttX as stable and backwards compatible as > feasible so that people can adopt NuttX and count on it to keep > working for them in the long run. > > At the same time, we need to be very careful not to make rules that > are too strict and inflexible, because then we would risk turning away > contributors and we would end up with old cruft that is really broken > and generating a lot of complaints but can't be fixed because it would > break the rules. > > So we need to strike a good balance. > > How to strike a good balance? > > When deciding how easy or hard it should be to change some code, we > should consider: > * How new or mature the area of code is > * How well the area of code works (known buggy .. known good) > * How much will changes in this code affect other parts of the system > * How well the area conforms to established standards > > Then: > > Code in mainline that is relatively new, known buggy, and won't affect > too much the rest of the system should be allowed to change easily. > Not too much discussions, votes, and other ceremony needed here. Just > make the change with one reviewer (not from same org) and move on... > > Code in mainline that has existed for a long time, is mature, known to > be working well, and will break many parts of the system if changed, > should require careful consideration before changing. We shouldn't > outright forbid such a change; maybe it's a "breaking" change but > still needs to happen for important reasons. This is an area that > needs lots of input, so, there should be a good discussion in the > mailing lists, possibly including a [VOTE] to decide should we make > this change or not. > > We could come up with some kind of formal "status" for each area of the code: > * Under Development > * Experimental > * Production Stable > * Periphery > > I'll describe each: > > # Under Development: > > This status is for things that are substantially working but are still > considered incomplete. Examples might be a new CPU arch, a new board, > a new driver, etc. > > Why include it in NuttX mainline? Because this way, other people can > join the effort. Consider how Lup made NuttX boot on the PinePhone. > (Thanks, Lup!) Most features were not implemented, but putting it in > NuttX mainline means that people could play with it, experiment with > it, hack on it, and help develop it further. It helps to inspire new > contributors and that's a good thing. > > We shouldn't include totally broken things, but under development and > *working* to some extent is welcome. If it's a new CPU arch and board, > NuttX should at least boot to NSH prompt. It's okay if most other > drivers (display, sound, GPS, who knows what) don't work yet. > > Areas like this should be allowed to change easily without too much > worrying about stability or backwards compatibility because they are > not stable yet and people probably shouldn't try to build products > with them. If you do build a product with "Under
