search

AsahiLinux / m1n1

A bootloader and experimentation playground for Apple Silicon
MIT License
3.53k stars 204 forks source link

RFE: Load the splash logo at runtime #238

Open Conan-Kudo opened 2 years ago

Conan-Kudo commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

marcan commented 2 years ago

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 commented 2 years ago

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

Conan-Kudo commented 2 years ago

cc: @davide125

Conan-Kudo commented 2 years ago

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 commented 2 years ago

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

davide125 commented 2 years ago

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:

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 commented 2 years ago

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 commented 2 years ago

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.