The fade-in/out will still use the BGRT when present.
This is something I believe is fair, and should require the user to
completely disable BGRT usage if undesirable.
Mainly, this aims to reduce the impedance mismatch between path
as-seen-in-stage-1 and paths-according-to-stage-2.
Now, two helpers, one using the other, are used to properly telegraph
the intent when using a file path.
With this, reading `nixos-version` was also fixed.
- get rid of deprecated URL literals (see RFC 45)
- remove unused derivation args
- remove one instance of unused rec, and two unused variable in let's
I try to convert strings to integers so the configuration is less
awkward. Nix doesn't do `0x______` integers. So since colours are never
written in base ten, let's allow strings.
... this way, the framebuffer content is not evicted by a needless mode
change.
AFAIK none of our targets will be affected by this change. The
framebuffer should already be setup with the correct mode. This was
holdover from early early cargo-culting about the framebuffer.
I have verified on a few devices, it does not worsen their behaviour.
A NixOS change for systemd-stage-1 added an `x-` mount option, which is
not handled well by busybox mount.
- 1b39491326
The same option was not an issue for the shell-script stage-1 as it
already stripped `x-` mount options
- 8be838254b/nixos/modules/system/boot/stage-1-init.sh (L365-L366)
Thus it's assumed safe to strip the options the same way.
This is useful for devices with USB, where input devices may take a
short while before showing up.
With this, external USB keyboard passphrase input is reliable in the
limited testing I did.
I don't recalle why `X_DISPLAY_MISSING` was needed at some point, but it
must not be anymore since it works fine without.
Also drop the needless stdenv adapter.
Better than doing the wildly weird thing of mounting/unmounting to peek,
and it doesn't leave a stray mountpoint after switch_root.
Why not depend on `/proc` or keep it mounted? Mainly because of the
mount options. I don't want to deal with it when it is being handled
through the mount tasks.
On a 1920×1080p the keyboard was basically full height (1056 out of
1080 pixels high).
With this, the UI will be cut-off a bit at the top, but it won't be
entirely unusable!
