On Fri, Mar 28, 2025 at 10:13 AM Alan C. Assis <acas...@gmail.com> wrote:
> Hi Nathan, > > It could be just: > > default y if LCD_FRAMEBUFFER > > This way it will be "ON" for boards with LCD and Framebuffer enabled and > "OFF" for all other boards. That is a good combination. If there's a framebuffer there's a splash screen by default, and developers can turn that off if they don't want it. > > Maybe we need to think about how to get NXlogo working for LCD_DEV too. > > BR, > > Alan > > On Fri, Mar 28, 2025 at 10:07 AM Nathan Hartman <hartman.nat...@gmail.com> > wrote: > > > Replying inline below: > > > > On Thu, Mar 27, 2025 at 5:15 PM Tim Hardisty <timhardist...@gmail.com> > > wrote: > > > > > Hi Nathan, > > > > > > Thanks for your thoughts. It has made me think more logically (I hope) > > > about why and when you might want a splashscreen. > > > > > > > > > > I'm currently thinking that it is only a pretty "hello world" that > > > allows branding. With that in mind: > > > > > > * Embedded devices, using NuttX, may not have an LCD of course > > > * Whether to display a splashscreen is a decision only the product > > > design team (team of 1 in my case lol) can make > > > o Likewise: how long it's displayed for > > > * NXboot should only be there for a brief time -as you say - so not > > > really a place for a "wow, look at what you've just powered up" > > > pretty-pretty graphic > > > o If things go wrong during the bootloader process, a > splashscreen > > > is irrelevant: that's where my error recovery suggestion comes > > in. > > > * NXboot - as I understand it and currently use it - boots an image > > > which is a complete standalone NuttX kernel and startup app: nsh to > > > get you going; a custom app, most likely, in the RW. > > > > > > So: > > > > > > * I think a splashscreen in the kernel *does* make sense. > > > * It should be enabled/disabled via Kconfig. But what default? > > > o Default "on" - would be good for new users > > > o Default "off" - doesn't change anything for current users > > > > > > > > I think Default "off" makes the most sense. As you pointed out elsewhere, > > systems running NuttX don't necessarily have displays. In fact, until now > > everything I use NuttX for is deeply embedded, nothing visual you can > see. > > Even for systems that do come with displays, the developer might not > want a > > splash screen because the graphic consumes limited flash memory, or > perhaps > > because NuttX boots instantaneously so the graphic wouldn't be visible > for > > long enough to justify it being there. New users should have a relatively > > easy time getting a splash screen if they want it, since it's only a > > Kconfig away. > > > > > > * If enabled, it will be displayed when the framebuffer driver is > > > registered > > > o default graphic would be NuttX logo > > > > > > > > Agreed, there should be a default NuttX logo in case another one isn't > > provided. > > > > > > o custom logo can be supported via Kconfig choice > > > + I favour a "c" or header file created using an online tool, > > > rather than messing around with converting jpegs on the > fly. > > > > > > > > Agreed a C header (of hex values) is preferred. > > > > I wonder what would save flash memory--converting the image to a bitmap > in > > advance, and then the splash program just copies the bitmap to > framebuffer > > (more flash usage for the image, less flash usage for code to display it) > > or saving the JPEG to flash (as a C header of hex values) at the cost of > a > > more complicated display code (less flash usage for the image, more flash > > usage > > for code to display it). > > > > I suppose one benefit of converting images to a framebuffer bitmap at > build > > time: any format can be supported (jpeg, png, svg, whatever). > > > > > > * Timeout. Hmmm... > > > o "none" could mean display it and forget about it until > something > > > comes along to reinit/overwrite. Onus on the developer. > > > o "auto" could mean display until NuttX is done loading. Is there > > > a signal or anything we could use to check this? > > > o a non-zero value "n" could mean keep it there for "n" seconds > > > regardless - and delay finishing NuttX load until that timeout > > > expires or NuttX is ready (whichever is longer). Also needs a > > > signal or something so we know when NuttX is ready. > > > * With the above implemented: > > > o the NXboot app could build it's minimal kernel with no > > > splashscreen enabled > > > o the "main" app could build it with a splashscreen enabled (if > > > wanted) > > > > > > WDYT ;-) > > > > > > > > Makes sense to me! > > > > Cheers, > > Nathan > > >
