<chadmed>
can anyone with a weird and wonderful boot sequence (LUKS, weird RAID stuff, LVM, whatever) stress test this Plymouth theme I've been working on today? https://github.com/chadmed/asahi-plymouth
the_lanetly_052 has joined #asahi-dev
<chadmed>
the splash screen works but i havent tested, nor can i test, stuff like inputting passwords or message delivery
<Glanzmann>
chadmed: I tried it and it did nothing for me.
<Glanzmann>
This was on Debian testing.
<Glanzmann>
grub looks the same, no splashscreen during boot and after that its lightdm with autologin for me.
<chadmed>
do you have `splash` in your kernel command line? for some reason plymouth wont even bother trying to load the splash screen unless its there
<chadmed>
i should add that to the readme
<Glanzmann>
I don't, let me add it.
<chadmed>
if youre testing from boot you also need to do all the normal stuff to get plymouth working, rebuilt the initramfs with plymouth as one of the hooks etc
<chadmed>
oh right, if youre using debian, you can rebuilt the initramfs by adding -R to the plymouth-set-default-theme command, so its "plymouth-set-default-theme -R asahi"
<chadmed>
im on armtix and have just been testing with plymouthd --debug --no-daemon
<Glanzmann>
I tried that, did not change anything for me. No splash screen same grub picture.
<chadmed>
might be that 5.17-rc5 framebuffer thing
<chadmed>
works fine on my amd64 machine on 5.16.10
<Glanzmann>
I see.
<Glanzmann>
chadmed: This was with my usual configuration (linux-asahi my usual kernel config and Debian testing. Plymouth was installed).
<chadmed>
the up to date linux-asahi or an older version?
<chadmed>
bc the up to date one has the rc5 framebuffer problem
<chadmed>
yeah right so it may not work properly since rc5 partially broke simpledrm and simplefb. neither driver properly initialises the console, which plymouth relies on
<chadmed>
im going to test a delayed boot on my amd64 machine now just to confirm thats the problem
the_lanetly_052 has quit [Remote host closed the connection]
the_lanetly_052 has joined #asahi-dev
bisko has joined #asahi-dev
the_lanetly_052 has quit [Remote host closed the connection]
the_lanetly_052 has joined #asahi-dev
<chadmed>
plymouth sucks so hard. every theme ive looked at has a different way of asking the user for a password and drawing the text box + password dots, and all of them seem to be the most stupid possible way you could do that task
<chadmed>
the theme now shows the user messages on top of the beach ball reliably and neatly though, so thats nice :P
<marcan>
jannau: what do you think about moving AsahiLinux-PKGBUILD under AsahiLinux?
<_jannau_>
marcan: fine by me. it would make sense to prune linux-apple from its history
<marcan>
we can rewrite the history if you think that makes sense, sure
<jannau>
that results in 'Cannot find new owner ' AsahiLinux''
<marcan>
space?
<jannau>
You don’t have the permission to create public repositories on AsahiLinux
<jannau>
To transfer a repository that you own to an organization, you must have permission to create a repository in the target organization.
<marcan>
ah
<jannau>
from the help page
<marcan>
just transfer it to me then, then I can move it into asahi
<jannau>
done
<kettenis>
I've been playing with a m1n1 diff that makes stdout-path point at /chosen/framebuffer instead of serial0 if a monitor is attached to the machine
<marcan>
jannau: moved to PKGBUILDs, also invited you to a team to manage access that way
<kettenis>
This would greatly improve the experience for OpenBSD users since our kernel uses stdout-path to pick the console device
<kettenis>
Unfortunately there is a u-boot bug that kept me from ding a pull request for this so far
<kettenis>
I have a fix for u-boot but it isn't clear if that is going to be applied yet
<marcan>
hm, for linux serial always makes sense since that's largely for earlycon
akemin_dayo has quit [Ping timeout: 480 seconds]
<kettenis>
but Linux uses command line arguments to specify the console isn't it?
<marcan>
not earlycon
<marcan>
you just pass "earlycon" and then it uses stdout-path to decide what to use
<kettenis>
is it possible to use the framebuffer as earlycon?
<marcan>
no, earlycon is much earlier than a framebuffer
<marcan>
I think there's an earlycon for FBs though? but no sure if it's a thing as simplefb
<marcan>
there's an EFI earlycon, which I guess might work?
<marcan>
but then that wouldn't be looking up the DT
<kettenis>
yes, and that would probably output to both serial and framebuffer with u-boot
<kettenis>
(even if we point stdout-path to /chosen/framebuffer, u-boot will still provide output on serial)
<marcan>
then maybe it depends for u-boot to do this instead of m1n1? on m1n1, especially under the HV, you pretty much always want regular serial earlycon
<marcan>
*it makes sense
<kettenis>
hmm, maybe that is an idea
<marcan>
I need to test whether this actually works on linux though
<marcan>
but then again if you're using earlycon you probably aren't using u-boot (unless you're debugging that)
<kettenis>
I always liked how Sun machines used to switch from serial console to glass console when you plugged in a keyboard
<marcan>
heh
<kettenis>
so maybe I can implement that in u-boot
<marcan>
I still want serial on the laptops ;)
<marcan>
but sure
<marcan>
actually checking for EL1 and skipping that might not be a good idea
<marcan>
*a bad idea
<marcan>
I'm clearly distracted today :p
<kettenis>
heh
<kettenis>
if I add this code to u-boot there will be a way to override this
<sven>
glass console :D
<kettenis>
sven: not sure where that originates, but it is what we tend to call it in openbsd ;)
<sven>
never heard that before but i like it :-)
<chadmed>
fitting that these machines actually have glass displays too
<kettenis>
chadmed: :D
<chadmed>
jannau: is there a particular reason the PKGBUILD for the kernel only revs up one core when building?
<psykose>
do you have JOBS set or something in some /etc/ thing that is supposed to set it
<j`ey>
chadmed: have you set MAKEFLAGS?
<psykose>
and those
<chadmed>
im not using it rn, just perusing. thought it might make more sense to add -j $(nproc) or something
<psykose>
generally people don't set -j on every build script manually
<mps>
I already have alpine APKBUILD modeled after PKGBUILD for asahi kernel
<mps>
psykose: do you have M1 machine
<psykose>
what am i, rich? :p
<psykose>
(no)
<mps>
well, I had a hope ;)
<chadmed>
i was thinking more for people who are installing fresh kernels for the first time, but its probably nicer to just tell them to set MAKEFLAGS yeah
<alyssa>
they do be ludicrously expensive compared to my usual machines..
<chadmed>
i bought a fully specced M1 Pro 14"... and then my car rego bill came in the mail
* sven
hides is fancy but now obsolete m1 that he bought as a uart adapter
<mps>
alyssa: iirc you use chromebooks
<alyssa>
inter alia
<psykose>
inter alios
<chadmed>
my god UI developers deserve an infinite wage increase how do they do this every day
<psykose>
they probably think the same in return towards you :p
<chadmed>
no one in the universe thinks my industry needs more money :p hell, im currently fighting to get _less_ money
<sven>
looks like the atc phy also needs some of these fuses similar to the apcie one. they're even taken from a similar memory region (0x2_3d2bc000). I'm not sure yet if I can apply them from m1n1 because XNU also seems to reset the entire atc phy every time a cable is unplugged
<alyssa>
womp
<sven>
either I just add that fuses source as an additional reg or alternatively just stuff it into apple,fuses next to all the other random tunables this thing requires
<sven>
maybe actually apple,fuses because I bet they change between t8103 and t6000
<sven>
but then again.. I guess with the fancy multi-monitor support the DP crossbar stuff changed anyway
<chadmed>
surely the dt binding would be easier to maintain?
<sven>
doesn't make much of a difference tbh. this things already needs like 10 different tunables stuffed in there anyway
<sven>
*thing
chadmed has quit [Remote host closed the connection]
m42uko_ has joined #asahi-dev
m42uko has quit [Ping timeout: 480 seconds]
<marcan>
sven: fuses is what the nvmem stuff was made for!
<mps>
nvmem is some kind of eeprom? or RAM on battery