<chadmed>
an attempt was made but im not sure how good it is. it builds and it runs and its fast but idk if its very "rust"y
<tpw_rules>
"This seems like it would suck to implement." why?
vup has quit [Server closed connection]
<chadmed>
because the driver would have to be running a time check on the last access to the IOCTL. how would that play out with suspend etc?
<tpw_rules>
isn't that exactly when you would want the check to fire though?
<chadmed>
it depends on exactly what we're trying to prevent from happening. if the daemon encounters a runtime error (all possible ones are currently handled) then it can just send a single IOCTL to the driver to enable codec safe mode
<chadmed>
the keepalive would only be useful in the case of the daemon segfaulting (should be impossible) or being forced dead by oomd or whatever
<tpw_rules>
not sure off the top of my head how to best put the device name in there
<tpw_rules>
you would also want to register a panic hook to do your emergency ioctl
<chadmed>
thats what helpers::fail() will do eventually
<chadmed>
so i hook that into panic!
<tpw_rules>
the fail() function, yes. instead of calling it
<chadmed>
ah and that would negate the need for those superfluous exit()s
<tpw_rules>
and save you if some library or the runtime itself explodes
<tpw_rules>
(though a real segfault will not go through the panic mechanism)
<chadmed>
yeah but ideally the daemon itself should never segfault
<chadmed>
and we dont use the mixer or pcm alsa lib interfaces which are the ones prone to such nonsense
<tpw_rules>
certainly a lot less likely than in C but it's not absolutely impossible. just saying you would have to register a separate signal handler for that case
<chadmed>
yeah
<tpw_rules>
looked it up and you would want let val: i32 = self.level.val.get_integer(0).unwrap_or_else(|| panic!("level of {} is readable", self.drv))
<tpw_rules>
the || introduces a lambda which is only called if get_integer returns None to avoid the (likely negligible) cost of formatting the string in the happy path
<chadmed>
ah see i was trying to avoid unwrap()s and expect()s thinking it would be better to explicitly handle each Option and Result from the alsa lib bindings but if thats acceptable then that works and is less gross
<tpw_rules>
why would you want to avoid them?
<chadmed>
i was under the impression that they just unconditionally panic on failure and i wanted to handle whatever alsa-lib returned in a controlled manner
irth has quit [Server closed connection]
<tpw_rules>
they do unconditionally panic on failure, but imo that's what you should hook into if you are just going to complain and die
irth has joined #asahi-dev
CME has quit [Server closed connection]
CME has joined #asahi-dev
<chadmed>
yeah that was the missing piece, didnt realise you could tell panic! to do things
<tpw_rules>
unwrap_or_else will call a function on None and return that functions value but obviously if it panics or std::process::exit()s then that won't happen
<tpw_rules>
there is also the RAII approach. i admit i might be misleading you on the panic hook. i think about it a decent amount in embedded rust but maybe it's not a big thing in desktop rust now that i poke a bit
lonjil has quit [Server closed connection]
lonjil has joined #asahi-dev
<chadmed>
it makes sense to me in this case since (imo) we should put the speakers in safe mode and die if we encounter any error
<chadmed>
something has gone very wrong if any of the values we get back from the CTL interface are bad, we cant guarantee safety for machines we dont have the config data for, etc
qyliss has quit [Server closed connection]
<chadmed>
my main concern apart from that anyway was the maths for the actual safety stuff, but i cant really test any of that until the driver has V/ISENSE support anyway
qyliss has joined #asahi-dev
nyx_o has joined #asahi-dev
povik has quit [Server closed connection]
povik has joined #asahi-dev
greguu has quit [Ping timeout: 480 seconds]
espo has quit [Server closed connection]
espo has joined #asahi-dev
noopwafel has quit [Server closed connection]
noopwafel has joined #asahi-dev
veloek has quit [Server closed connection]
veloek has joined #asahi-dev
dsharshakov has joined #asahi-dev
<dsharshakov>
chadmed: "how would that play out with suspend etc?" Block immediately after suspend and unlock when daemon thaws and starts working. We shouldn't let 1% chance (likely bc of user's own stupidity) to bite someone
mjolnir[m] has quit [Server closed connection]
matrix_ds has quit [Server closed connection]
mjolnir[m] has joined #asahi-dev
ahdeb[m] has quit [Server closed connection]
ahdeb[m] has joined #asahi-dev
<dsharshakov>
Suspend can be a corner case for ALSA, btw. In PW we have quite some bugs of hardware not working after resume (some are caused by drivers though). So if daemon is dead after suspend (alsa bugged out, or device resumed badly and only gives 00s or otherwise garbage) it shouldn't be considered adequate
<chadmed>
theres a PR in AsahiLinux/linux that makes power management work for the tas codecs, so we dont have to worry about the hardware doing undefined stuff
matrix_ds has joined #asahi-dev
<dsharshakov>
And yes, it might be useful to check whether hw doesn't give us obvious nonsense such as high-entropy data or constants (or other failure modes). We mustn't claim it's fine by measurements but raise an alarm
<chadmed>
its more a case of how much overengineering do we want to do to prevent an edge case of an edge case of an edge case (someone not using a DE on the laptops -> the daemon crashing -> someone blaring bass boosted amogus trap nightcore remix at full volume)
<dsharshakov>
* daemon receiving a signal from layer8 which truly believes you tossed some malware to them. How could speakersafetyd be useful for my computer hmmm
<dsharshakov>
And some issues which lead to us getting garbled buffers might exist really if some bug happens in the kernel driver
<chadmed>
yeah and what if evil ninjas sent by tim apple break into my house and killall speakersafetyd while im not looking? should speakersafetyd have an aperture science turret built in to it?
<dsharshakov>
Well, if it's not pinging kernel enters safe mode then
<chadmed>
yeah but do you see my point
<chadmed>
we could run this treadmill all day and all night and end up with a 30MB binary that has a firewall built into it to stop people breaking in via telnet to run aplay -D hw:0,1
<chadmed>
and then someone will come along and say "ok but what if they use ssh"
<dsharshakov>
The ping is not overengineering imo. This way to destroy the speakers user has to know how to call ping ioctls, that unlikely coexist with stupid actions
<chadmed>
again though, its a case of this only _ever_ being a possible failure mode in a vanishingly small set of circumstances
<dsharshakov>
Well, not insisting. The overall approach seems quite nice engineered, looking forward to seeing some info about it working
<chadmed>
hell with the IRs alone the speakers are impossible to blow up, so not only does the daemon have to fail but you have to be accessing it via the raw alsa device AND doing so at sustained full volume
<dsharshakov>
Yes
<chadmed>
if the daemon is killed by any means we already have our panic and fail handlers that would theoretically do the IOCTL to put them into safemode
<dsharshakov>
And if it ooms oom service likely will send a sigterm first
<chadmed>
so the only way that wouldnt happen is if its killed by segfaulting _itself_ or ooming
<dsharshakov>
Idk if kernel oom killer will warn before killing
<chadmed>
we can handle sigterm
<chadmed>
so theres like 0.00000000001% chance that we enter a state where a keepalive would be useful
<dsharshakov>
Yes, oomd and early earlyoom send terminate, but what about kernel
<dsharshakov>
I see the point
<dsharshakov>
Well, users need to kill it with segkill to avoid proper shutdown, Yes?
dsharshakov has quit [Remote host closed the connection]
<chadmed>
we can handle all signals
dsharshakov has joined #asahi-dev
<dsharshakov>
SIGKILL cannot be handled rly. Well, then in typical scenario systemd restarts the thing. But there're edge cases...
<dsharshakov>
Doing own daemon-in-daemon supervision can help a bit, but that seems to be hackier than a ping ioctl.
<dsharshakov>
I mean running another instance as a child process
dsharshakov has quit [Remote host closed the connection]
<chadmed>
i guess with a keepalive signal its just a matter of the implementation difficulty and whether or not such things are tolerated in the kernel
<chadmed>
a quick search hasnt revealed anything similar
<chadmed>
and to me it seems silly to implement something that unorthodox in the kernel to cover a failure mode with such a slim possibility
<chadmed>
also we should probably make sure it, yknow, actually does what it says on the tin first
<chadmed>
im more worried about getting V/ISENSE out of the driver and making sure we can catch over temp situations in a controlled state at the moment
<tpw_rules>
how does macos handle this? if it's just a function of V/ISENSE, why is a (perhaps configurable) model in the kernel not doing the math
<chadmed>
V/ISENSE are 16-bit floats sent in a 32-bit TDM slot by the codec.
<chadmed>
This is expressed by the driver as a byte array, with rightmost 16
<chadmed>
bits as padding.
<chadmed>
unpack this and do floating point maths in the kernel?
<chadmed>
macos does it inside coreaudio as part of the DSP graph
<tpw_rules>
does it get feedback from the speakers?
<tpw_rules>
and i mean 16 bit float for this purpose can surely be done as 64 bit fixed point integers to an acceptable level of accuracy
<chadmed>
V/ISENSE are lines hooked up to the amp output. ISENSE is a shunt resistor and VSENSE just measures the voltage across the voice coil
<tpw_rules>
or even 32
<tpw_rules>
sorry i meant to write driver there
<tpw_rules>
i recognize actually activating fp mode in the kernel is a path to sadness
<tpw_rules>
fp-safe*
<tpw_rules>
man i am awful at words tonight. probably a sign it's way past my bedtime. good luck and bye
<chadmed>
gnight!
<marcan>
chadmed: don't bother with panic hooks, all that will be handled in the kernel
<marcan>
I absolutely want this to have things like only allowing a trusted/special process to raise levels above the max and resetting when that fd is closed or when a keepalive fails
<marcan>
you should not need to implement any emergency measures in userspace
<marcan>
(yes this will require core ALSA changes, we'll bikeshed it I'm sure, but I will not ship a solution that does not have that level of safety in some form)
<chadmed>
oh okay, so as long as the process dies and does nothing else to the CTL interface the kernel will handle the rest?
<marcan>
yes
<chadmed>
awesome
<marcan>
there will be a keepalive of some sort, though that keepalive may be implicit in "is actively reading the PCM data". I need to see how that would work, and also how it will all work when the TX side PCM is closed or idle
<marcan>
my current idea is we want the safety capture PCM to always be available, but simply cease to deliver data when the output is idle, and the daemon should compensate for that algorithm-wise
<chadmed>
ah so V/ISENSE will be channels on a PCM?
<marcan>
I assume so
<marcan>
probably a dedicated PCM for that
<marcan>
since they come in the same way as input audio data as far as the hardware is concerned, I don't see much reason to reinvent that wheel
dsharshakov has joined #asahi-dev
<chadmed>
right. ive modeled them as read only elems on the ctl interface but that probably doesnt make a lot of sense. shouldnt be too hard to change if we have a dedicated pcm to open
<chadmed>
yeah
<marcan>
ah yeah, that makes no sense, it's audio-rate data
<marcan>
you actually multiply v*i sample-wise
<marcan>
v/i separately is not enough to calculate power because you don't know the power factor
<chadmed>
yeah
<chadmed>
it should be fine if theyre on their own pcm, i had issues earlier this week trying to open the speaker pcm while pipewire had it open at the same time
<dsharshakov>
Yes, marcan's idea is very nice, kernel has no problem finding idle streams. However, I want to better know how would you trust a process? Probably it just has to be root, know the handshake and boost volume only after opening the VISENSE pcm
<marcan>
it's about the handshake, and yes root
<marcan>
the only security required is that regular users should not be able to blow up the speakers, and that it should never happen "by accident"
<marcan>
so it doesn't have to be anything complicated, just something explicit
<marcan>
(so no other app can trigger it)
<marcan>
could just be a mixer control write
<marcan>
(of some opaque value)
<chadmed>
speaker DRM :P
dsharshakov has quit [Remote host closed the connection]
<tpw_rules>
chadmed: got nerd sniped again and i really cannot see how those v/isense values would be floats. they will just be counts relative to the full scale in the datasheet
ashi has joined #asahi-dev
<chadmed>
the datasheet literally says theyre 16-bit floats
<tpw_rules>
which page?
<tpw_rules>
(of which pdf)
<chadmed>
tas2764 page 28
<chadmed>
ah wait no theyre 16 bit pcm samples right
<ashi>
marcan: If it is discouraged to use "random" branchen, then indeed you should make things private. It is totally clear that no one here should expect anything to work, but I thought #asahi-alt is all unsupported anyway, so we can tinker like we want including pointing people to what we did to make things work.
<chadmed>
#asahi-alt is for discussing non-reference distributions
<ashi>
chadmed: which are unsupported
<marcan>
...which doesn't mean it's a free-for-all for packaging unstable software
<chadmed>
i.e. packaging and maintenance of _released_ asahi software on other distros to make them work
<chadmed>
the keyword being released
<marcan>
I expect non-reference distributions not to ship anything newer than what we ship
<marcan>
because users *will* file bugs upstream or generally clog the communications channels
<marcan>
there's a reason I ranted about Manjaro shipping a random kernel of ours
<marcan>
that's the same
<tpw_rules>
but if it comes back as an audio stream then maybe moving it closer to userspace and using that plumbing makes more sense. i think i take back my idea to put it in the kernel. but yeah i very strongly suspect those numbers will be (N/65535)*3.75A/14V full scale value listed
<ashi>
I do not ship anything, but I did make gpu work on debian, and I thought it would be nice to tell people how. Obviously it is completely bad for the project. So I will keep things for myself and enjoy "random" branches without any feedback. Thanks for clarifying.
<chadmed>
tpw_rules: yeah that seems saner and extremely obvious :P
<ashi>
Seriously, if the code is intended for the inner circle only, you should just make it private, I also do it sometimes before things are ready.
<ashi>
But if stuff is out, I do not want a rant just for using and talking about things.
<chadmed>
the idea is to be transparent and forthcoming, especially given that people are donating their money to this project
<chadmed>
it has been stated many many times that mucking about with dev branches is a bad idea
loki_val has quit [Server closed connection]
crabbedhaloablut has joined #asahi-dev
<chadmed>
like i have a kernel branch locally with the speaker s2idle fix in it and the amp gains set to the "full" macos level because i have a DSP graph for pipewire that i know is safe for _me_ to use
<chadmed>
im not gonna ship that in gentoo though because i know someones gonna go "the bass isnt fully sick and hectic enough", crank up some slider and blow things up and then complain here that we broke their $3000 laptop
<ashi>
chadmed: For me it is not a bad idea to play with dev branches and see new stuff working while knowing it could crash at any times.
<ashi>
Speakers are disabled for a reason, thats good
<chadmed>
okay sure but dont ship it and dont complain about bugs if you run into them because chances are someone already knows about them
Stary has quit [Server closed connection]
<ashi>
And even I know how I can enable them, I would not, after I read all of marcans writeups and the comments in speaker research
Stary has joined #asahi-dev
<chadmed>
yeah exactly so if you know these things happen, dont spruik dev branches to people when you dont know how theyre going to behave with them
<chadmed>
reminds me of people distributing pre-publication research manuscripts that are then rejected during peer review
greguu has joined #asahi-dev
<ashi>
chadmed: hmm, dont get that. I did not tell people to enable speakers while I do not
<ashi>
Anyway do not want to argue. Pointing people to dev branches - forbidden. Got that.
<ashi>
Oh damn, I am so sorry, I though I joined #asahi-alt - did not intend to spam your dev channel :(
<ashi>
I indended to reply to marcan on -alt because he quoted me there. SORRY. I am off
ashi has left #asahi-dev [Leaving]
m5zs7k has quit [Server closed connection]
m5zs7k has joined #asahi-dev
SSJ_GZ has joined #asahi-dev
<ChaosPrincess>
Did someone end up testing a restore from complete destruction of all data in nor flash?
chadmed_ has joined #asahi-dev
dsharshakov has joined #asahi-dev
<dsharshakov>
ChaosPrincess: iirc it's only repairable by Apple (or you if you have backed it up). However, the SPI controller node it's attached to is blocked in DT, so you cannot destroy the flash accidentally
<dsharshakov>
it shouldn't be needed for us anyway since all useful data is extracted and filled into the ADT aiui
<sven>
don’t think anyone tested it but it should be possible
<sven>
and we’ll need access to the SPI since it contains nvram eventually
<dsharshakov>
the boot selection or what precisely?
<sven>
yeah
<sven>
also if we want to support system firmware updates eventually
<sven>
and dunno what else is stored in there but wouldn’t surprise me if there’s more useful things
<dsharshakov>
I remember reading some writeup telling that NOR contains ID and calibration, so unless you have a backup you need to send it to Apple to repair (maybe Apple Store employees can restore as well, but certainly needs some tech)
<dsharshakov>
Well, that's another risk area like speakers are. Maybe it doesn't worth it unless tested and consideres carefully
<dsharshakov>
So far it's boot picker (replaceable by just holding option while booting), updates (how to download those, maybe that's better done by the second macOS install or rebooting into stub)
<dsharshakov>
What else? Maybe bt pairing data as well, but most likely SEP holds that
<sven>
lol, no
<sven>
bt pairing data is probably inside nvram
<sven>
it makes no sense for SEP to “hold that”
<dsharshakov>
Have anyone RE'd SEP enough or just thoughts?
<dsharshakov>
however that's not SO sensitive to live in SEP, that makes sense
<sven>
And the dfu restore can and does talk to apples servers. It wouldn’t surprise me if it can just download whatever is required from there
<dsharshakov>
sven: they keep a backup of sn-paired data like wireless calibration?
<sven>
I don’t know
<dsharshakov>
then someone will have to verify that before shipping with nvram enabled...
<dsharshakov>
Essentially the two things possibly permanently breakable from software thus requiring extra safety when playing around
<sven>
uh, yes?
<dsharshakov>
well, can someone imagine other part of the system you could damage with software not being able to DFU-restore afterwards?
<dsharshakov>
speakers are one of those, and nvram might be so as well (needs testing). Anything else seems to be unbreakable thanks to SMC and other hardware handlers of critical things
dsharshakov has quit [Quit: Page closed]
<ChaosPrincess>
I have already "tested" corrupting nvram, just interested in what happens if the rest of the nor is corrupted
joske has joined #asahi-dev
joske has quit []
cylm_ has joined #asahi-dev
leitao has joined #asahi-dev
cylm has quit [Ping timeout: 480 seconds]
leitao has quit [Ping timeout: 480 seconds]
gabuscus has quit [Ping timeout: 480 seconds]
gabuscus has joined #asahi-dev
chadmed_ has quit [Remote host closed the connection]
chadmed_ has joined #asahi-dev
kenzie7 has quit []
kenzie7 has joined #asahi-dev
beeblebrox has joined #asahi-dev
chadmed_ has quit [Remote host closed the connection]
goldsoultheory has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kettenis has quit [Ping timeout: 480 seconds]
r0ni has quit [Ping timeout: 480 seconds]
goldsoultheory has joined #asahi-dev
leitao has joined #asahi-dev
leitao has quit [Ping timeout: 480 seconds]
kilolima is now known as kl_
jluthra has quit [Remote host closed the connection]
jluthra has joined #asahi-dev
corion has joined #asahi-dev
<amarioguy>
sven, dsharshakov: i have it on fairly good authority BT pairing is not sep
dsharshakov has joined #asahi-dev
<amarioguy>
but yes, there is one part of NOR you really don't want to touch
<dsharshakov>
amarioguy: well, that was not a surprise. I just supposed sep could be involved in storing the pairing keys as they're sorta secure material. however, not to that extent
<amarioguy>
do you mean hardware pairing keys?
<jannau>
keys of paired bt devices are in nvram and in the nvram proxy data in the ADT
<amarioguy>
oh
<dsharshakov>
amarioguy: what it is? Is there a map or description of what is in the NOR?
<amarioguy>
dsharshakov: do you mind hopping in asahi-re
<amarioguy>
i'd rather not say it here due to well people wanting to avoid binary re talk
<dsharshakov>
"in the nvram proxy data in the ADT" seems someone needs to expose the adt node as a efuse-like node in OF DT and then as a nvram device to userspace so that bluez can get it either directly or using our initramfs scripts
<jannau>
I thought of transferring the bt keys to the devicetree but as far as I can see it would be readable by every user
<dsharshakov>
"do you mind hopping in asahi-re" - no problem, write there, I might just read from logs if I have no questions
<dsharshakov>
"it would be readable by every user" might be the case if you simply place it there. But if it's an nvram device node, user cannot access it. `cat /dev/nvram` gives me permission error on my AMD machine
<sven>
amarioguy: I know, it makes no sense at all to use sep for this
<sven>
the bt stack needs the keys in plaintext
<amarioguy>
yep
nicolas17 has joined #asahi-dev
<dsharshakov>
But how to do it (pass ADT pairing to bluetoothd) sanely? Reserved memory page created by m1n1, copy adt pairing data there and then expose the page as a virtual device from the kernel?
<sven>
*sigh*
<dsharshakov>
amarioguy: got your msg. IIRC marcan had the same findings, that ID info loss will likely break DFU as well, so will likely need employees regenerating the data
<dsharshakov>
jannau: how can non-root user read the DT info?
<j`ey>
dsharshakov: DT is in sysfs and proc
<dsharshakov>
well, then it's likely to be considered public to the apps. Well, maybe there're some examples of passing sorta secret data from bootloader to Linux in other OF systems?
<jannau>
only in sysfs, ls -ld /proc/device-tree: "/proc/device-tree -> /sys/firmware/devicetree/base"
<jannau>
there is a nvram driver under development
<dsharshakov>
So it'll be read from NOR, not using the ADT proxied data?
<jannau>
yes
<dsharshakov>
Well, since nvram has more use cases, this makes more sense than working around to receive the bt pairing data from ADT. Also this way devices paired in Linux could be made working with macOS/recoveryOS
<amarioguy>
fwiw it doesn't look like nvram has any property that can't be restored with a DFU restore
<amarioguy>
(this is from an nvram -p run on macos, entirely possible i missed something)
<dsharshakov>
There's a burned-in SN in the SoC itself so restore tool can just grab backups from the Apple online?
<amarioguy>
SoCs don't have the SN burned in
<amarioguy>
what they have is an 'ECID' burned in
<nicolas17>
dsharshakov: I'm not sure if that was actually *tested*
<dsharshakov>
ECID is what, sorry?
<amarioguy>
think like a ID unique to every soc that comes off the factory line
<amarioguy>
it's part of the update personalization process
<amarioguy>
i don't think this pertains to backups tho
<amarioguy>
SN is part of that region i told you earlier
<nicolas17>
syscfg?
<dsharshakov>
Before enabling users to nuke the NOR somebody has to be sure to know how to restore that
<amarioguy>
nicolas17: yep
<nicolas17>
did anyone *actually* screw up the NOR contents including serial number, and do a DFU restore, and the restore tool recovered the data from Apple based on the ECID (exclusive chip ID)? there were theories that it worked that way but idk if anyone took the risk and tried it
<amarioguy>
these are thousand dollar+ machines there's a reason almost no one wants to do it :P
<sven>
i mean.. maybe just dump all traffic while running idevicerestore and check if there's NOR calibration data in there
<dsharshakov>
yeah, but to restore the machine AC2 needs to grab the ECID and somehow match it to the machine data
<nicolas17>
sven: you mean while running AC2, in case this is actually a missing idevicerestore feature :P
<dsharshakov>
sven: great idea to do before nuking a test machine
<sven>
nicolas17: i'd start with idevicerestore first and if there's nothing there go to AC2 :D
<sven>
there's a restore_send_nor in idevicerestore, maybe start looking at that
<nicolas17>
ah interesting
<nicolas17>
amarioguy: well, marcan broke his speakers :D
<sven>
grepping code >> random uneducated speculation
<amarioguy>
very true
<nicolas17>
I don't remember if he managed to get it fixed for free?
<dsharshakov>
btw did he already get the m2 air back?
<amarioguy>
dsharshakov: he had a 13" MBP
<amarioguy>
not the air
<dsharshakov>
would be fun if NOR can be debricked by DFU. then speakers are the only soft-breakable thing in the system which makes it fairly solid
<jannau>
iirc the m2 air with the broken speakers was replaced on the spot with a different one
<dsharshakov>
Ah, okay, but the question remains
<nicolas17>
dsharshakov: I'm sure we can find more if we really look :D
<dsharshakov>
what're the examples? Maybe microLED XDR backlight (it has temperature sensors)
<dsharshakov>
voltages for all components are handled by SMC, so unless it bugs out we're safe
<nicolas17>
I'm not sure how much we can mess with thermals from software, but yes, that's generally one area
<dsharshakov>
oh btw what do power curves lina has been calculating mean? what are they used in for GPU?
<dsharshakov>
are they just for software to account for the power GPU uses (like perf metrics) or needed for hardware management and affect performance states somehow?
systwi has joined #asahi-dev
<dsharshakov>
nicolas17: they're likely to have a thermal protection poweroff by SMC firmware. Nobody checked probably, I don't know for sure
<dsharshakov>
So overheating the SoC is very unlikely. But microLEDs are being cut in brightness when it's too hot, as stated by Apple support
<dsharshakov>
Probably current DCP support doesn't enable the XDR mode anyway, so screens are unlikely to heat up that much. But when the microLED backlight will be used to its full potential for HDR support thermal safety might need to be taken into accout
systwi__ has quit [Ping timeout: 480 seconds]
dsharshakov has quit [Quit: Page closed]
corion has quit []
tired has quit [Quit: /]
tired has joined #asahi-dev
corion has joined #asahi-dev
as400 has quit [Remote host closed the connection]
as400 has joined #asahi-dev
djorz has joined #asahi-dev
goldsoultheory has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
chengsun has joined #asahi-dev
kettenis has joined #asahi-dev
chengsun_ has joined #asahi-dev
systwi_ has joined #asahi-dev
systwi has quit [Ping timeout: 480 seconds]
chengsun_ has quit [Quit: Quit]
chengsun has quit [Ping timeout: 480 seconds]
corion has quit [Quit: Page closed]
<ChaosPrincess>
So, the reason im asking is that i am getting a new m1 machine soon, and can test complete nor destruction. (If i can"t recover it myself, ill just take it back to the store and claim it was doa)
<amarioguy>
ChaosPrincess: you can always take a bit by bit copy of the nand and reflash using an HW programmer :P
<amarioguy>
(fun note this is the only way to downgrade assuming you haven't updated and SEP hasn't rolled it's anti-replay token in secure storage)
<amarioguy>
(er, downgrade ios devices i mean
<amarioguy>
macos is obviously free reign
<amarioguy>
correction 2: ios devices that don't have chain of trust breaks