thelounge7571340 has quit [Remote host closed the connection]
Dcow has quit [Remote host closed the connection]
Dcow has joined #asahi-dev
Dcow has quit [Ping timeout: 480 seconds]
Dcow has joined #asahi-dev
chadmed has joined #asahi-dev
Dcow has quit [Ping timeout: 480 seconds]
Etrien has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
Dcow has joined #asahi-dev
Etrien__ has joined #asahi-dev
Etrien has quit [Ping timeout: 480 seconds]
Dcow has quit [Ping timeout: 480 seconds]
chadmed has quit [Quit: Konversation terminated!]
LunaFoxgirlVT has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
chadmed has joined #asahi-dev
chadmed has quit []
kazuki has joined #asahi-dev
chadmed has joined #asahi-dev
kazuki has quit [Quit: Konversation terminated!]
kazuki has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
chadmed has quit [Quit: Konversation terminated!]
Etrien__ has quit [Read error: Connection reset by peer]
Etrien has joined #asahi-dev
Etrien has quit [Ping timeout: 480 seconds]
SSJ_GZ has joined #asahi-dev
chadmed has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
Etrien has joined #asahi-dev
chadmed has quit [Quit: Konversation terminated!]
chadmed has joined #asahi-dev
Etrien has quit [Read error: No route to host]
Etrien has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
chadmed has quit [Quit: Konversation terminated!]
LunaFoxgirlVT has quit [Read error: Connection reset by peer]
Etrien has quit [Ping timeout: 480 seconds]
Etrien has joined #asahi-dev
mps has quit [Quit: Lost terminal]
<marcan>
huh, I'm having the weirdest issue...
<marcan>
I got rid of update-vendor-firmware and just inlined an uncpio in the initramfs hook
<marcan>
and now it just... panics when it runs init
<marcan>
but as far as I can tell from break=postmount, everything is fine
<marcan>
is this some systemd nonsense?
<marcan>
oh wait. uhh...
<marcan>
it's the `set -e` isn't it
<marcan>
yeah... I think the rdlogger_stop just has failing commands...
<marcan>
it ends on a kill 2>/dev/null that may fail so... yeah.
Etrien has quit [Read error: Connection reset by peer]
Etrien has joined #asahi-dev
<marcan>
yeah, works now :)
<marcan>
alright, update-vendor-firmware is no more
will[m] has quit [Write error: connection closed]
nyanpasu64 has quit [Write error: connection closed]
<marcan>
pushed to asahi-dev, shouldn't cause any visible changes
<marcan>
also I managed to hit the NVMe startup timeout on the M1 MBA too (stage1 m1n1). I should push an update for everything soon, people are installing known-broken stage1s...
<marcan>
(this happens on some unclean shutdowns; the workaround is to just hold down power until the options menu shows up, then do a clean shutdown)
<marcan>
also my MBA ate its macOS container... I think it was a botched resize
<marcan>
seems the size of the APFS container increased, but not the size of the actual GPT partition
<marcan>
I tried to recreate it from Linux as the larger size, but it seems I just made it worse...
<marcan>
nothing *too* critical on this machine, but I'd love not to lose those installs... :/
<marcan>
oh, bad start align
thelounge7571340 has joined #asahi-dev
<marcan>
let's see, gdisk I think did it right
thelounge7571340 has quit [Read error: Connection reset by peer]
kazuki has quit [Quit: Konversation terminated!]
<marcan>
and we're back!
<marcan>
phew
<marcan>
so, um... my guess is doing an APFS resize and interrupting it ends up it not committing the GPT expansion? that's *bad*
<marcan>
maybe someone thought "commit after because shrinking" but for expansion it should be the *other* way
kazuki has joined #asahi-dev
<marcan>
looks like it really was just the partition size, fsck says it's good
r0ni has quit [Quit: Leaving]
<_jannau_>
notch hiding works now in dcp. I think I'll keep using it. I had a panel/global menu at the top so the notch wasn't interfering with screen contents
<_jannau_>
but in non-dark mode the panel was too bright and I found no way change its color within 5 minutes
<marcan>
_jannau_: do you have an updated branch I should pull?
<marcan>
I'm going to see about building that alternate kernel package
<marcan>
_jannau_: that just goes on top, right? so I can just merge via github?
<_jannau_>
yes
<marcan>
cool
<_jannau_>
the fixup commits can be squashed but that can wait until the next rebase
<marcan>
yeah, no rush
Etrien__ has joined #asahi-dev
kazuki has quit [Quit: Konversation terminated!]
Etrien has quit [Ping timeout: 480 seconds]
Etrien has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
Etrien__ has quit [Ping timeout: 480 seconds]
r0ni has joined #asahi-dev
greguu has quit [Quit: WeeChat 3.0]
chadmed has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
<chadmed>
marcan: so update-vendor-firmware should no longer be necessary as long as the /lib/firmware/vendor handling stuff is in place in the initramfs?
<_jannau_>
I might need something for installer images, not sure how the appending to cpio is going to work there
<chadmed>
i was thinking we could just write that functionality into the dracut hook itself
<chadmed>
and only have it run if /lib/firmware/vendor doesnt exist on the root we're trying to pivot to
<jannau>
yes, that case does not need update-vendor-firmware but can be simpler, no need check the manifest if the initramfs has no firmware at all
<chadmed>
well the idea behind the cpio is that the firmware is already sorted and arranged, so if we can just open that and dump its contents into the target root pre-pivot then we shouldnt need to check the manifest ever, right?
<chadmed>
and that would work for installer images that we ship since they will presumably be built with this hook
<_jannau_>
yes, the point was trying to make is that we can't rely on the firmware being always already in the initramfs through cpio concatenation
<chadmed>
oh yeah of course, but we can skirt around that without update-vendor-firmware and like you said just use a way simpler check in the hook
<chadmed>
just wanna make sure the fedora folks are happy with it before committing, it would suck if we had to duplicate efforts
<marcan>
_jannau_: the initramfs has fallback logic to load the cpio from the ESP if it was not loaded by the bootloader. I expect that part to stay.
<marcan>
that was just previously using update-vendor-firmware; I changed it to just uncpio the cpio
<marcan>
so someone loads the cpio either way, then the logic to copy it to a tmpfs on /new_root is the same in both cases
IcaroDextris has joined #asahi-dev
<marcan>
*ideally* we'd figure something out so whatever $bootloader is involved can load the firmware from the system-ESP regardless of what ESP we boot from, but that's a yak that can be shaved later
<marcan>
either way the current solution is strictly better than the old (racy) one and than the interim one we never shipped (which was not buggy but still relied on mutating the rootfs)
<chadmed>
oh i see in the hook now
<chadmed>
so theres no need to persist the firmware past the initramfs?
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
chadmed has quit [Quit: Konversation terminated!]
chadmed has joined #asahi-dev
mps has joined #asahi-dev
r0ni has quit [Quit: Leaving]
r0ni has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
Dcow has joined #asahi-dev
Dcow_ has joined #asahi-dev
<jannau>
marcan: is kwin preference for XRGB2101010 in 5.26? dcp's 30-bit format might be RGBA1010102, colors looked slightly off on the system which is already updated to 5.26
Dcow has quit [Ping timeout: 480 seconds]
<marcan>
jannau: it's in the current version yeah, I repro'd the problem with an 8888 framebuffer
<marcan>
so it could be that we have differences in processing between 10b/8b
<jannau>
I didn't really verified it. colors looked not broken, I saw macos use it during boot and assumed it's the same format as the boot framebuffer
<mps>
jannau: fyi, I have this warning when building latest asahi-wip branch on alpine linux https://tpaste.us/LelW
<jannau>
I noticed yesterday that kde updated to 5.26 looked a little weird, similar to displaying full range yuv as limited range
<jannau>
I think the 2 alpha bits being LSB instead of MSB could explain it
IcaroDextris has quit [Quit: Connection closed for inactivity]
mrkajetanp has quit [Remote host closed the connection]
mrkajetanp has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
kazuki has quit [Quit: Konversation terminated!]
<Dementor>
Hi marcan conan Kudo from the Fedora asahi matrix room asked me to ping you since he's not on irc and they were looking for you
Gaspare has joined #asahi-dev
<marcan>
sorry, I wanted to get more kernel work done today but I just spent 6 hours arguing with the two simpledrm maintainers over how to fix a regression for what should've been a 30 minute discussion, and I'm all out of spoons for today :(
<marcan>
jannau: that is the same format as the boot FB
<marcan>
it's just possible the color conversion isn't exactly what KDE and/or the kernel do
<marcan>
oh wait, the actual DCP fourcc?
<marcan>
yeah, it could be a shift I guess?
<marcan>
I'll have to see it myself
<marcan>
though a whole 2 bit shift would be pretty drastic
<marcan>
and cause some really weird clamping
<marcan>
so it should've looked pretty bad
<_jannau_>
I have a list with detailed fourcc information from macos
<marcan>
anyway, I think I'm going to sleep soon, that discussion really, really exhausted me
<marcan>
disagreeing with polite people who are wrong and won't budge is the worst, you can't just ragequit and you get stuck in an endless loop... :(
<marcan>
(though they did get someone else to ragequit)
<_jannau_>
No worries, I'll look at the dcp issue tonight. should be easy to verify now that I know what to look for and that there was an external change
<_jannau_>
shift seems like since light gray looked blown out towards white
<rmk>
marcan: what is your understanding of the changes needed to get the macsmc stuff into mainline? I got lost in that massive discussion about what the actual points that needed addressing were.
<marcan>
_jannau_: if the bits are just chopped off I would expect wraparound. is it possible that the format is right, but some constants need to be changed (e.g. gamma tables) when the format has more bits?
<rmk>
I think we need to move it from drivers/platform to drivers/mfd
<marcan>
rmk: I'm honestly not sure, don't really have the time to look at it right now, sorry. I never understood what he wanted about breaking up the mfd driver.
<_jannau_>
I found it surprising that "do not do more unoptimised pixel format conversion than necessary" was controversial
<rmk>
marcan: that makes two of us then :)
<marcan>
having the actual mfd core just be a dumb stub in drivers/mfd invoked by a driver in drivers/platform makes *no* sense to me
<marcan>
so I have no idea why he would want that, or how I would do it in a way that makes sense
<marcan>
and IIRC he never replied to my question about that
<marcan>
I also never got a reply to my comment to the cypress dude who introduced a broadcom firmware file with a cypress name... given that, I think I'm going to send a fixup patch to rename it, and he can choose to complain, or not, because I don't want precedent that broadcom chips are now cypress chips unless someone from those companies confirms they are actually a rebrand and not just a subset
<rmk>
Ok, I'll try to do what I think makes sense and post a new patch series - if stuff has been missed then IMHO that's the fault of people making such a long thread about it and not summarising it towards the end.
<marcan>
rmk: thank you :)
<marcan>
oh also, I fixed some stuff up in there in my tree, though I think I squashed it. let me summarize if you don't mind it ad hoc?
<rmk>
go ahead
<marcan>
smc_rtkit.c increase SMC_RECV_TIMEOUT to 500 (this is mostly an issue with the hypervisor, but I suspect mailbox shenanigans and I want to play it safe)
<marcan>
and I don't remember if this applied to smc or it was already there, but: in the Kconfig, if there are bare COMPILE_TESTs, use (COMPILE_TEST && 64BIT) since that driver won't build on 32bit properly
<marcan>
oh and there was a linter thing
<marcan>
ah no, not on this one I think
<marcan>
that should be it then, if I didn't forget anything
<rmk>
the && 64BIT thing should be on the APPLE_PLATFORMS menuconfig?
<kevans91>
i'm curious how you arrived there, i'm seeing an issue of sorts when we attempt to restore vfp state and write to fpsr/fpcr in freebsd
<kevans91>
cpu just kinda falls off a cliff, and I get a different failure mode when run under the hypervisor so it's a bit difficult to debug
uur has quit [Remote host closed the connection]
Etrien has quit [Ping timeout: 480 seconds]
SSJ_GZ has quit [Ping timeout: 480 seconds]
<rmk>
kevans91: are you getting an exception (which exception?) while restoring the vfp state ?
Gaspare has quit [Ping timeout: 480 seconds]
Etrien has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
millenialhacker has joined #asahi-dev
<kevans91>
rmk: nothing obvious, no
<kevans91>
it's an apparent stall, quite annoyingly when we first fire up init(8)
<millenialhacker>
I tried compiling kernel in asahi-wip today to test DCP driver, but even when I marked dcp as built-in module and cannot get it load with kernel, I also tried marked it as loadable module but modprobe complains about bad exec format. am I missing something?
millenialhacker has quit [Ping timeout: 480 seconds]
Etrien__ has joined #asahi-dev
Glanzmann has joined #asahi-dev
Etrien has quit [Ping timeout: 480 seconds]
Glanzmann has quit [Quit: EOF]
<kevans91>
I guess it's our earlier write to q0 that's hanging, not fpsr/fpcr. afaik we set up cpacr_el1 correctly to disable traps, not sure what else I'm missing
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]