[RFC] [TRACKING] Integrate boot logo configuration

[acuteaangle]

Description

I believe it would be generally useful if PineFlash offered a GUI to assist with flashing a boot logo to a Pinecil.

Currently, adding a custom boot logo requires using a Python script to prepare an image with the boot logo, and then selecting it as a custom firmware in PineFlash.

I propose that PineFlash should be able to flash a boot logo from within the GUI. This would still require the use of an external program to prepare the image(s) (resize, ensure the threshold looks nice, etc); however, I think this would be a far better user experience.

First UX Concept

Main Screen - No boot logo configured

Boot Logo Configurator - No frames

Boot Logo Configurator - Still

Boot Logo Configurator - Animated

Main Screen - Boot logo configured

What needs to be done

img2logo.py

I propose that the best path forward, should we choose to implement this, is to port the boot logo functionality from IronOS-Meta to Rust, with the reduced scope of only supporting Pine64 devices. Adding a Python dependency would greatly complicate packaging, portability, and reliability of the project.

The Python script from IronOS-Meta currently has licensing issues [3] [4]. As PineFlash is licensed GPL-2.0-only, we cannot use the script if they choose GPL-3.0-* or Apache-2.0. Of their proposed licenses, PineFlash can use GPL-2.0-or-later and MIT.

If this cannot be resolved, we would need to reimplement the functionality from the format description, which is not preferred.

Depending on how they license their existing boot logo images, we may or may not be able to offer them as presets in the UI.

If the script and boot-logos are licensed favourably, we would be able to use them as a test oracle to ensure the Rust version gives the same output.

UI

Rough out the UI and make any necessary changes. I think it would be nice to have some basic frame-editing functionality: duplicate, reorder, etc; however, we may need to drop it for MVP if UX or implementation issues arise.

UI (and image manipulation) logic

The UI should, ideally, actually do something.

Flasher integration

Depending on how the flashing functions, we either need to modify the firmware image before flashing, or flash the boot image separately.
I've assumed the former for now.
Assuming the licensing issues on the Python script are resolved, we'll be able to study it and see what the options are here.
If the boot logo can be flashed independently, that'll likely lead to a new UX draft, as then it can be completely independent from flashing the firmware.

Prior discussion

This has been previously discussed 2025-03-08/11 on the bridged Matrix/Discord, and is being posted here for discoverability and centralization of discussion and status tracking.

[acuteaangle]

Apologies if my writing seems verbose or redundant, I want to get my current thoughts down for both visibility and my own status-tracking.

Note on PineFlash licensing:
It seems PineFlash was intentionally relicensed a couple years ago from GPL-3.0-only to GPL-2.0-only in
c6431ed3172f ("need to reset license")
and
f0c7fc0f236b ("back to gpl2 and no or later clause")

Given this, I am documenting my assumption that PineFlash was intentional relicensed to GPL-2.0-only for either ideological or dependency compatibility reasons, and is therefore unwilling or unable to relicense to GPL-3.0-*.

The primary IronOS-Meta contributors seems to have a strong copy-left preference, and based on discussions at Ralim/IronOS-Meta#48, I believe they would be likely to choose GPL-3.0-or-later in the absence of PineFlash.

Depending on the outcome of Ralim/IronOS-Meta#48:

• GPL-3.0-or-later
  We will not be able to directly port img2logo.py to Rust for PineFlash; the only option will be re-implementing the functionality from the data storage format documentation.
  We may still be able to utilize img2logo.py directly as a test dependency.

• GPL-2.0-or-later
  We can work directly from img2logo.py to port the logic to Rust, with a reduced scope of only Pinecil devices. This is expected to be far faster and less error-prone.