RFE: Load the splash logo at runtime

[Conan-Kudo]

In Fedora, we have a unified branding setup that depends on us being able to ship our branding assets in a single package (fedora-logos). The reason for this is so that the package can be swapped with generic branding (generic-logos) or downstreams can ship their own branding and everything can leverage it automatically.

Currently, m1n1 pulls in the logo asset at build time, translates the input PNG into an alternate binary format, and embeds it into the loader binary itself. Would it be possible to change it so it can load it externally so that this can be swapped at install-time instead?

[marcan]

I think we can do this with a special-case payload. It would have to be the first payload and in some bespoke wrapper format, since I don't really want to run a full payload scan early nor embed a PNG decoder.

That said: m1n1 stage 1 puts up the logo first. Are you okay with that being the Asahi logo, and then stage 2 would replace it with the Fedora logo? If not, that would need to be personalized at stub install time, since stage 1 is immutable except from macOS recovery mode. Our installer supports using different stage 1 artifacts for each selected distro, and we could add an extra logo thing to append to it, so that's not a problem, but just keep in mind that has to happen entirely outside package management due to the nature of the platform (unless we just make stage 1 not replace the Apple logo at all by default, but I'm not a big fan of that because there is debugging value in seeing that stage 1 is running).

[jannau]

the binaries provided by @leifliddy 's installer (https://github.com/leifliddy/asahi-fedora-builder) already come with a fedora logo in stage 1. I guess building the stage 1 m1n1 is out of scope for distro packages. If the logo was provided via a payload we could append a logo specified in installer_data.json during installation. This would eliminate one reason to ship a custom stage 1 m1n1. I can image that distributions still have a strong preference to compile all binaries on their infrastructure though.

[marcan]

That only works for distributions that actually opt to ship their own installer or integrate with ours, though. For those who want to go the UEFI installer path (which is probably popular), we'd have to provide stage1. We could still offer logo-ful versions, but it would have to be a cosmetic user choice at that point.

[Conan-Kudo]

I think we can do this with a special-case payload. It would have to be the first payload and in some bespoke wrapper format, since I don't really want to run a full payload scan early nor embed a PNG decoder.

This is fine with me. We can ship whatever you need in fedora-logos/generic-logos.

That said: m1n1 stage 1 puts up the logo first. Are you okay with that being the Asahi logo, and then stage 2 would replace it with the Fedora logo?

I'm mostly trying to make everything safe for trademark policy things and supporting the ability for remixes and other downstreams to easily have their branding apply.

If not, that would need to be personalized at stub install time, since stage 1 is immutable except from macOS recovery mode. Our installer supports using different stage 1 artifacts for each selected distro, and we could add an extra logo thing to append to it, so that's not a problem, but just keep in mind that has to happen entirely outside package management due to the nature of the platform (unless we just make stage 1 not replace the Apple logo at all by default, but I'm not a big fan of that because there is debugging value in seeing that stage 1 is running).

This is probably fine too, we can do stuff like this if we can come up with a good mechanism.

[marcan]

If it's mostly about the logos Fedora ships in packages then I guess only stage2 matters, so that's easy. I'll put the payload thing on my list then, should be easy to do (or maybe someone else can pick it up: just make up a little header format with a magic that can hold the two logo versions/sizes, make the normal payload code skip it, add something to FB init that looks for it, and a little Python script to build it using Pillow or whatever). For stage1, this will have to be a discussion to have together with installation mechanisms.

[marcan]

Oh yeah, do you need to actually remove the built-in logo? Logically speaking, the payload logo ought to replace it, though it wouldn't be hard to provide a config option to have no default logo (which would mean either black or leave the existing logo up? For stage 2 that'd leave the Asahi logo drawn, for stage 1 that would mean the Apple one).

[Conan-Kudo]

I only need to remove the stage1 Asahi logo if there's a licensing issue with it.

[marcan]

No licensing issues, it's CC BY-SA 4.0 and we don't have any particular trademark policy, certainly no issue leaving in a m1n1 build.

[Conan-Kudo]

Then we should be gravy on that front, and really only need a stage2 swap.

[Conan-Kudo]

cc: @davide125

[Conan-Kudo]

the binaries provided by @leifliddy 's installer (https://github.com/leifliddy/asahi-fedora-builder) already come with a fedora logo in stage 1. I guess building the stage 1 m1n1 is out of scope for distro packages. If the logo was provided via a payload we could append a logo specified in installer_data.json during installation. This would eliminate one reason to ship a custom stage 1 m1n1. I can image that distributions still have a strong preference to compile all binaries on their infrastructure though.

Building our own stage 1 is a requirement. We build everything from source as it is. I'm okay with an install-time logo merge too, we can structure this properly downstream. The key is that we should not need to compile in the image at build-time, because it makes switching logos impossible.

[Conan-Kudo]

FYI, @davide125's packaging for m1n1 is available here: https://src.fedoraproject.org/rpms/m1n1

[davide125]

This is probably out of scope for this ticket, but in the interest of clarity: currently our Fedora packaging of m1n1 is only building stage 2, not stage 1. We have a few options:

• treat stage 1 as "firmware" that's put in place by the installer, and ignore it; this means stage 1 boots with the Asahi logo, and chainloads our (Fedora-branded) m1n1 stage 2
• add support to the installer for combining our logo with the stage 1 (I believe that's what @marcan was suggesting above)
• build and ship our branded stage 1 in Fedora, and add support to the installer for using that instead
• build and ship our own branded installer, including our own stage 1

My personal preference is for the first or second option, but if we do decide we want our own stage 1 that'd be easy enough to build as a subpackage. Maintaining our own installer build seems unnecessary.

[Conan-Kudo]

In the interest of cohesion with other Fedora ARM stuff, we probably do want to have stage 1 build by us. Insofar as our own branded installer, I don't know yet. It'll probably come down the road, but for now we don't have to worry about it.

[marcan]

Right now, the installer uses its bundled stage 1 artifact for everything, but it would be trivial to make it pull it from distro zip archives if you really want to use your own build (I think this is fairly academic if people are using our installer hosted by Asahi, but don't have a strong opinion here - that said, do note that stage 1 builds require Rust and therefore have a slightly more convoluted build process). However, that presupposes the "distro image" install flow. If the user is using the UEFI + external USB installer flow, then stage 1 is firmware as far as the distro is concerned, since at that point the installer doesn't know what distro the user will install.