alyssa has quit [Remote host closed the connection]
alyssa_ has joined #asahi-dev
<alyssa_>
arnd: haven't looked too much at the SPMI stuff, not sure what the MFD shim was for
alyssa_ is now known as alyssa
<alyssa>
er
maz has joined #asahi-dev
Glanzmann has joined #asahi-dev
Glanzmann has quit [Quit: leaving]
___nick___ has joined #asahi-dev
rohin has joined #asahi-dev
yuyichao has quit [Ping timeout: 480 seconds]
yuyichao has joined #asahi-dev
phire has joined #asahi-dev
phire_ has joined #asahi-dev
doggkruse has joined #asahi-dev
___nick___ has quit []
___nick___ has joined #asahi-dev
phire_ has quit [Ping timeout: 480 seconds]
___nick___ has quit []
___nick___ has joined #asahi-dev
doggkruse has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
___nick___ has quit [Ping timeout: 480 seconds]
bps has joined #asahi-dev
doggkruse has joined #asahi-dev
doggkruse has quit []
<kettenis>
arnd, alyssa: the spmi driver can be fairly simple
<kettenis>
the pmu may need a little bit more thought as it seems to do many things (besides being the rtc)
bps has quit [Ping timeout: 480 seconds]
jmr2_ has joined #asahi-dev
<jmr2_>
alyssa: Success :-D
<jmr2_>
Patches required to get DCP to start on the Air: dummy values for display width/heigth, trampolines for D211 (nop), D406 (nop) and D582 (true).
<jmr2_>
Details will follow (and I need to add a mouse - X's not fun without!)
<alyssa>
jmr2_: woo!!!
<alyssa>
I love problems that "solve" themselves ;-p
<jmr2_>
magic ;-D
<alyssa>
:p
jmr2_ has quit [Remote host closed the connection]
<alyssa>
I see this on the mini too, not sure what this is about
<alyssa>
(fundamental difference in the apple wifi hw compared to non-apple broadcom wifi? or just buggy corellium code?)
<alyssa>
jmr2: one more thing to try btw, if you delete the fake width/height_cm assignments, and just also delete the check/einval, does everything still work?
<alyssa>
Projectors report 0mm x 0mm so it should still be ok, and that avoids me committing a hack :)
<alyssa>
(i.e.: the trampolines you added + the rm.patch I sent)
<sven>
hrm, could also just be missing additional patches to the wifi driver
jacoxon has quit []
jmr2 has joined #asahi-dev
<jmr2>
alyssa: confirmed - 0x0 works too, on both 11.4 and 11.5.2.
aleasto has quit [Quit: Konversation terminated!]
jmr2 has quit []
jmr2 has joined #asahi-dev
<jmr2>
Oh, and for completeness: I just tried NOP'ing D117 - the one I see as the last line before "system halted" when shutting down. It turns off the display, but the backlight (and I assume, the rest of the computer) stays on. Probably better to leave that one untouched for now. Again, same on 11.4 and 11.5.2.
<alyssa>
jmr2: cool, going with that then :)
<alyssa>
jmr2: D117 should be FALSE
<jmr2>
Oh crap... OK, retrying...
<alyssa>
shutting off the display but not the backlight is deliberate
<alyssa>
well. it's more like shutting off the backlight requires more code that I haven't typed out because I don't have an Air
<alyssa>
marcan: have M1 Air prices dropped with the Pro announcements?
<j_ey>
dont think so
<alyssa>
Boo. I'll keep waiting then :-p
<j_ey>
at least on on the apple store, maybe 2nd hand
<alyssa>
(Looking for a used one, capitalize on hoards of fanboys dumping their 2020 machines for 2021 models)
<j_ey>
but i dont think ppl would be dump an air for a new mbp
<alyssa>
Boo.
<jmr2>
alyssa: looks like FALSE on D117 turns off both the display and the backlight, but not the computer.
<jmr2>
... because when I press power for 10s, I still get my monitor to flash "no signal", like it does for both NOP and no handler.
jmr2 has quit [Quit: Page closed]
<alyssa>
Sure
<alyssa>
Shut down support is missing in mu-one/linux (and mainline)
<alyssa>
Corellium has patches for it but not in a state I can cherry-pick.
<alyssa>
Pressing power for 10s after doing a Linux shutdown is the workaround for now
jmr2 has joined #asahi-dev
<alyssa>
jmr2: Okay, I just pushed a 20211018 branch which fixes the issues you reported
<jmr2>
Understood. But I'd rather have the screen stays on if the computer isn't truly shutting down, so I know it's not off. And once the real shutdown is implemented, it won't matter if the display gets turned off before.
<jmr2>
Thanks. It's your code, so your call, but I really think that should be like that for everyone. Otherwise, something goes wrong, put computer in bag, come back to a dead battery, customer not happy.
<alyssa>
what customer
<alyssa>
Realistically shutdown support should hit upstream before DCP anyway, it's a /lot/ less code.
<alyssa>
admittedly still a lot of code though
<jmr2>
My point is that nothing stays perfect forever. If for any reason, the shutdown code does't work, the user should be able to see that the shutdown didn't happen. Currently, there's no way to see it.
yuyichao has quit [Ping timeout: 480 seconds]
<jmr2>
( and I don't see what we gain in shutting down the screen anyway)
<jmr2>
So I see a con, and no pro.
<alyssa>
Omitting the DCP shutdown causes the DCP to crash when you shutdown the machine.
<alyssa>
On the Mini at least, this is visible as a brief green screen-of-death.
<alyssa>
Omitting the call is incorrect.
<jmr2>
So why didn't you have the handler for D117 previously? Is it this handler that fixed that geen flash for you ?
<jmr2>
*greed
<jmr2>
*green ... wow
<alyssa>
D117 isn't used on the Mini as far as I know.
<jmr2>
OK. So leave the shutdown unabled, and remove the D117 handler. Or maybe it should be true - keep everything on.
<jmr2>
*enabled
<jmr2>
I should try that.
<alyssa>
Omitting any handler that the DCP tries to use is wrong.
<alyssa>
If we don't have a handler, we don't ack the call, and then the DCP just hangs forever.
<jmr2>
So you're holding the info that I brought against me LOL
<jmr2>
Let me try TRUE
<alyssa>
I'm explaining why the DCP driver needs to handle everything and make the shutdown callback; omitting either would be incorrect
<alyssa>
so TRUE tells the DCP you want dark boot, whatever that is
<jmr2>
So if we don't know what that is, what makes FALSE more correct than TRUE ?
<alyssa>
A priori either FALSE or TRUE is fine.
<alyssa>
But failing to handle it at all would be wrong
<alyssa>
CONFIG_DARKBOOT is a thing in the open source XNU release
<alyssa>
some flag backed by NVRAM
<jmr2>
TRUE has the same behavior as NOP - backlight stays on, display is off.
<alyssa>
Alright
<alyssa>
jmr2: Just to make sure you're following -- NOP is wrong because the return value of D117 is a bool and NOP returns a void. So the results will be unreliable, since the DCP will read garbage memory and will behave like TRUE if the garbage was nonzero and like FALSE if the garbage was zero.
<alyssa>
But it sounds like you're in favour of handling D117 as true to keep the backlight on and then we can stop bickering about the shutdown code? :)
<alyssa>
(I am good with that solution.)
<jmr2>
Understood on NOP.
<jmr2>
My vote would be to keep it unhandled until power management is ready - and until we know how reliable that code will be.
amw has joined #asahi-dev
<jmr2>
I agree that it's incorrect, but I think it's an acceptable compromise.
<alyssa>
What's wrong with "backlight stays on, display is off."?
<alyssa>
If the backlight is on, you know shutdown didn't happen..?
<jmr2>
It's so dim that it's pretty much unnoticeable until you're in a very dark room.
<jmr2>
And battery drains faster :-D
<alyssa>
Mumble.
<jmr2>
I expect a few people to try your tree on Airs in the next few days/weeks. Given that reboot works, it won't be obvious that shutdown doesn't. At least for now, we need to make it obvious.
<jmr2>
And while I agree that it's the technically correct thing to do to handle it, I don't see side effect in not doing so.
<alyssa>
Dxxx callbacks can come from the firmware at any time for any reason.
<alyssa>
What happens if the firmware decides to query dark boot at some other time?
<alyssa>
If you handle it, all is well.
<alyssa>
If you don't handle it, the display stack hangs.
<jmr2>
True. But I'm the only one that saw that so far, didn't I ?
<alyssa>
For now
<jmr2>
That's all that I'm asking.
<alyssa>
marcan: ^^ Not sure if you have thoughts on the above.
<alyssa>
I suppose the real answer is to get rock solid power management ahead of people trying to daily drive asahi on MacBooks :0
<jmr2>
Ah. Possibly from the iphones - white ones boot black logo on white background, dark ones the opposite.
<jmr2>
Right. But for best or for worst, your tree is turning into the default one for early adopters, due to its completeness.
<jmr2>
Anyway - thanks for debating with me :-)
<alyssa>
Ah, I did not know that about the iPhones. Yep, that'd be it :-)
<alyssa>
Nice one 👍
<alyssa>
No idea what that has to do with backlight on shutdown though.
<jmr2>
Might be the backlight intensity, not a full on/off.
yuyichao has joined #asahi-dev
<alyssa>
I'd believe it
<alyssa>
I guess I need to go turn on and off an iPhone now for... research
<jmr2>
At least a white and a dark one!
<alyssa>
you're telling me I need to buy *2* iPhones? :-p
<alyssa>
well, 3, and also a screw driver
<alyssa>
Ok, this is interesting--
<alyssa>
Dark iPhone, with the "Invert colours" accessibility feature,
<alyssa>
The boot starts as white-on-black and towards the end flips to black-on-white
<alyssa>
The handoff between the early and late framebuffers (which is supposed to be seamless and invisible) is suddenly noticeable.
<jmr2>
Not buy, borrow :-D
* alyssa
knocks at every tenant and asks for the colour of their phone
<alyssa>
Relatedly, when shutting down the dark phone with inversion, a white screen persists for quite a while after the phone allegedly shut off.
<alyssa>
Here we poke behind the curtain at another bit of Apple stage magic... turn off the backlight first in shutdown, and then the user thinks the phone is shutdown
<alyssa>
In reality shut down is not instant, but if you turn off the backlight immediately and do the rest of shutdown "in the dark", the user *thinks* it's instant.
<alyssa>
Apple has a lot of stage magic like this...
<alyssa>
Another classic is the M1 MacBooks that switch resolution "instantly"
<alyssa>
Actually, they have only a single resolution, full stop. Different modes in "Displays" are just software scaling ("Looks like 1920x1080")
<alyssa>
"Sure, whatever," you say. "Surely they can't do that for external displays?"
<alyssa>
They can and do. Unless you force a mode set -- and they try hard on recent macOS to keep you from doing so, guarding real mode sets behind an option key or something in "Displays" -- it'll just software scale.
yuyichao has quit [Quit: Konversation terminated!]
<alyssa>
(Re iPhone shut down time -- it's about 7 seconds.)
yuyichao has joined #asahi-dev
<TellowKrinkle[m]>
<alyssa> "Here we poke behind the curtain..." <- Works great until you're trying to reboot your phone
<TellowKrinkle[m]>
Then you definitely notice when it doesn't restart right away and you have to keep trying blindly until it does
<alyssa>
Touche.
<alyssa>
do normies reboot their phones?
<alyssa>
---or shut them off for that matter
<mini>
can't remember the last time I did
<TellowKrinkle[m]>
Reboot? Probably not
<TellowKrinkle[m]>
Shut down? Involuntarily, if you run it out of battery
<TellowKrinkle[m]>
And when you start it back up you realize the second issue with the early boot process, they don't track display brightness from when you shut it down so if you do it at night you get blinded by a ridiculously bright Apple logo until it finishes booting up