<phire>
marcan: yes I've tried to talk to the ALARM folks too. Got slightly more than radio silence, but they don't really seem to be interested in being anything more than a distro for low-cost single-board computers.
<phire>
Which is understandable. It might be more accurate to say it's a project that feels like it has acheived it's goals and doesn't want to expand it's scope futher
<chadmed>
marcan: could you define "up to standard" for the gentoo port? its in pretty good shape imo, we have an overlay and an installer that takes care of all the apple-isms. what else could i take care of to make it better (apart from binpkgs)?
<chadmed>
noting that once lina gets the kernel driver up to scratch ill copy over the mesa ebuild from the gentoo tree and add a VIDEO_CARDS for asahi but thats a while away
chadmed_ has quit [Quit: Konversation terminated!]
uniq has joined #asahi-dev
uniq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
duban has quit [Quit: I'm out]
duban has joined #asahi-dev
<marcan>
Foxboron: he replied to my initial email within a day or two, but hasn't replied to my response for a week
<marcan>
phire: yeah, that sounds about right...
<marcan>
chadmed: sell it to me? :)
<marcan>
main things that need to be right are m1n1/u-boot/kernel updates with some kind of sensible automation (though it's gentoo so obviously there will still be some manual stuff) and an init.d script to update firmware on every boot if it has changed
<marcan>
the latter, ideally before udev even starts (I need to change the arch script to do that too, right now it's racy)
<marcan>
maybe some kind of "eselect dt" thing to choose which of the installed kernels' DTBs are installed into m1n1?
<marcan>
or maybe it can just track "eselect kernel"?
<marcan>
and then of course just keeping the overlay reasonably up to date
<kode54>
best part about gentoo on Apple Silicon is that you don't have to spend an hour configuring your kernel to fulfill the "desired" fully custom kernel that only has exactly what you'll ever need forever more
<kode54>
(there is no real way to do that anyway, there are countless peripherals you could conceivably attach
<marcan>
?
<kode54>
oh
<kode54>
well, the last time someone tried to sell me on setting up Gentoo, they insisted I hand configure my kernel rather than use a jack-of-all-trades config
<marcan>
lol
<marcan>
I mean I do that but there's genkernel?
<kode54>
when I asked for help, he spent 20 minutes hand configuring a kernel for my machine
<kode54>
not using genkernel, but make menuconfig
<marcan>
yeah some people like to force their ideas upon others...
<kode54>
I really don't like that ALARM is stuck on being a budget SoC distribution
<marcan>
personally, these days I actually have a silly script on my Threadripper chroot that builds 3 kernels for all my servers (two variants intended for bare metal and one for VMs, though I will probably unify the two bare metal ones some day)
<marcan>
then I just rsync /boot across
<marcan>
(no modules
<kode54>
I just spent 5 hours last night migrating my machine from a Proxmox VM to bare metal
<kode54>
almost all of that was just watching rsync scroll by endlessly
<marcan>
sounds about right
<kode54>
yes, the Arch wiki for rsync says to use -v for backup
<kode54>
but then says to use -q for restore
<kode54>
why yes, I will just let a command finish 3 hours of backup with no visual feedback
<marcan>
anyway, I have some kernel stuff to take care of this coming week (maz: haven't forgotten about your USB ports) but I'll also start working on helping out with the Fedora port
<kode54>
cool
e1eph4nt has quit [Ping timeout: 480 seconds]
<kode54>
I'll take this to offtopic, but I've kind of fallen into a rut, and started maining my Ryzen machine on Arch instead for the time being
<marcan>
as for gentoo, maybe I should install it on my Mac Studio? though considering I want to run Ceph and the Gentoo maintainer for that has been kind of bad at keeping it building across compiler/boost updates, I'm a little worried. Fedora might be a better bet for that reason alone... but we'll see
<kode54>
good luck, it is annoying when updates just break things, then you have to pick up the pieces
e1eph4nt has joined #asahi-dev
<phire>
kode54: I came the the conclusion that idealy ALARM would merge upstream into proper Arch Linux, or Arch Linux would otherwise transition into being a multi-arch distro. But you would kind of need someone willing to become a full-time maintainer on that effort to push that fowards
<phire>
if Arch Linux was even open to that direction
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
<mps>
hm, Asahi kernel -> boot Alpine distro :) (just noticed both logos have 'A')
<DmitrySharshakov[m]>
I have a bit of concern about Fedora aarch64. It appears that it's hard/impossible to setup multiarch (x86_64 libraries on aarch64 system), so that might cause issues with emulation (box86/box64), which is an integral part of Apple Silicon experience and is generally needed for full compatibility
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
hir0pro has joined #asahi-dev
<Glanzmann>
marcan: From my point of view, what is missing for all distributions, is the ability to have multiple dts installed. In my head the way to that would be having keyboard support in m1n1, and be able to select the right m1n1, which has the right dt in it. And whilt it is already there no need for u-boot and grub. But of course this could also be the case but it no longer necessary. But maube you have a
<Glanzmann>
better idea. Than for Debian the kernel packages could package the corresponding /boot/efi/m1n1/m1n1-kernelversion.bin and we have multiple kernerls.
<kettenis>
the whole idea of matching dts and kernels is wrong
<kettenis>
a single dt should work for all OSes (and u-boot)
<Glanzmann>
kettenis: I aggree. But in practice we have that since beginning until now. We have an upstream kernel that does not boot with the asahi dt and vice versa.
<kettenis>
that's a bug that needs to be fixed
<kettenis>
and the best way to fix it is to upstream more stuff
<Glanzmann>
kettenis: Sure, but to my understanding that bug can not be fixed at the moment because the understanding of the hardware is not completle. And while it completes the dt will change, break more stuff in the future.
<kettenis>
well, yes, you're using alpha software
<Glanzmann>
Anyhow, while it is alpha software, I welcome the ability to have multiple dts without having the need of a second computer or copy over boot.bins in macos. But that is just me. I'm happy with removing this workaround until the hardware is better understood and manifested in the dt.
uniq has joined #asahi-dev
<sven>
I’m with kettenis. Just upstream more and the dts bug disappears
<Glanzmann>
sven: I appreciate that your nvme dt changes made it upstream.
<Glanzmann>
To be honest if it annoys me to much, I will just implement it myself. But probably it doesn't. And since I only have m1 devices at the moment it would be useless for the Debian users, which need it the most.
e1eph4nt has quit [Ping timeout: 480 seconds]
<marcan>
what kettenis said
<marcan>
the m1n1 boot picker thing might happen, well into the future, when it makes sense for secure boot
<marcan>
it won't happen as a workaround for the dts issue
<marcan>
that's on the same level as 16K pages, we aren't working around a problem
<marcan>
Glanzmann: and I really would appreciate it if you don't try to subvert our development incentives, though I can't stop you
e1eph4nt has joined #asahi-dev
uniq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<shorne>
Hello, I am a kernel maintainer of the OpenRISC port, I have some experience with toolchains and kernel. I would like to help on asahi, particularly getting suspend to work
<shorne>
I have been lurking and reading doc's on the github wiki
<shorne>
I guess just saying hi now until I can figure our enough to get started
e1eph4nt has quit [Ping timeout: 480 seconds]
<DmitrySharshakov[m]>
Oh nice, welcoome! marcan is planning to work on s2idle the next stream or so (?).
<DmitrySharshakov[m]>
marcan: btw when is the next kernel stream planned?
<DmitrySharshakov[m]>
Presumably the main task is to figure out PSCI without the ARM Trusted Firmware. Correct me if my info is terribly outdated
Glanzmann has quit [Quit: leaving]
<shorne>
DmitrySharshakov[m]: cool, in that case maybe I can help review patches, if I heard right drivers like pci need to be updated to handle the idle states
<DmitrySharshakov[m]>
Typically for PM ops we (the kernel living in EL2 while being capable of virtualization) must ask someone higher (EL3) to manage power interfaces. This is the PSCI calling ABI. But Apple SoC has no TrustZone extension, so PSCI need to be handled by the kernel itself. I guess marcan has already invented the idea of this fix
<DmitrySharshakov[m]>
I'm not sure (not a maintainer, I'm here mostly for news + I do some work for userspace audio in PipeWire), but 99% you can do this
<DmitrySharshakov[m]>
Quite a bit of testing should be needed to ensure the best efficiency and stability
<shorne>
DmitrySharshakov[m]: cool, I will read up on PSCI, maybe I misheard /read it as pci
e1eph4nt has joined #asahi-dev
<DmitrySharshakov[m]>
Well, PCIe controller driver should definitely be updated for suspend/resume xD
<DmitrySharshakov[m]>
PSCI is power system coordination interface iirc
<j`ey>
s/system/state/
<DmitrySharshakov[m]>
Probably better to wait for marcan, as he certainly has more fresh info about PM than I do
<DmitrySharshakov[m]>
j`ey: yes it is, thanks
hir0pro has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<sven>
pcie and WiFi don’t handle suspend correctly yet iirc
uniq has joined #asahi-dev
<sven>
but the bigger task is defining and implementing that new psci-in-el2 thing
<DmitrySharshakov[m]>
sven: WiFi on its own or because APCIe breaks in some way?
<DmitrySharshakov[m]>
What's wrong exactly? Might it be a generic brcmfmac issue or platform one?
<DmitrySharshakov[m]>
sven: Hasn't it yet been proposed?
<j`ey>
DmitrySharshakov[m]: only briefly talked about on irc
<DmitrySharshakov[m]>
Well, not all ARM SoCs use PSCI for PM. Should M1 do so? Does it use PSCI in macOS? Can it be avoided by simply doing all by register writes (SMP bringup reversed)?
<j`ey>
the arm64 linux maintainers wont accept the latter in upstream
<sven>
WiFi on its own because apple invented sone suspend protocol that’s different from what brcmfmac supports
<DmitrySharshakov[m]>
x86 does its s2idle (S0ix) like this: 1. bring down non-boot cpus, 2. suspend pcie peripherals, 3. drive the CPU 0 into low-power idle
<sven>
I think there was at least one report that pcie itself also breaks but when I tested bt resume it just worked
<DmitrySharshakov[m]>
But yes, I guess that'd duplicate what is done by default PSCI
<sven>
possibly because the pcie power domains were marked as always-on though
<DmitrySharshakov[m]>
sven: So you just suspended to idle, without bringing CPUs down?
<sven>
yes
<sven>
but that was just to debug Bluetooth suspend/resume
hir0pro has joined #asahi-dev
<DmitrySharshakov[m]>
I guess suspend protocol can be reversed by m1n1 introspection, or doesn't macOS suspend work while booted under HV?
<sven>
but even suspend to idle fails for WiFi already
<sven>
I think we already have a good idea how deep sleep work. Flip some sysreg to enable it, store cpu context, wfi, restore context, disable deep wfi again
<sven>
the bigger task really is that psci stuff
<DmitrySharshakov[m]>
sven: Yea. Why would it break kernel concepts?
<DmitrySharshakov[m]>
sven: I meant cannot you watch macOS suspending and resuming wireless with m1n1 hypervizor?
<sven>
sure
<j`ey>
could be worth measuring deep sleep vs non-deep sleep power usage, see how worth it, it is
<sven>
someone just needs to do it :D
<DmitrySharshakov[m]>
does arm even have deep sleep? Is it like x86 where EC wakes the system up? Probably ARM has a different concept
<j`ey>
I know someone that is 'against' the psci/efi/el2 idea, and was suggesting to maybe try improve the spin-table stuff, but that wouldn't help with the actual power usage
<DmitrySharshakov[m]>
sven: btw how are your ATCPHY/TB-NHI/USB3 works? Are you testing locally without a branch or there's a branch to watch the news?
<sven>
only local tests from m1n1
<sven>
i don’t push wip branches anymore because people have been annoying me too much about them
<DmitrySharshakov[m]>
Ah, no kernel driver yet?
<DmitrySharshakov[m]>
And what's left/which questions are to be answered?
<DmitrySharshakov[m]>
Something like PD-out and DP tunneling?
<sven>
almost everything is left :D
hir0pro has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<sven>
i have a wip nhi driver but it’s not working yet
<DmitrySharshakov[m]>
Have you figured out the DP thing you asked recently?
<DmitrySharshakov[m]>
Like plain DP not tunneled in TB4
<DmitrySharshakov[m]>
Or there's DCP dependency for it to work with external display?
<sven>
As I said, almost everything is left
<DmitrySharshakov[m]>
understood, good luck REing it for a perfect driver
hir0pro has joined #asahi-dev
<povik>
nah, no need to be perfect, just good enough
<DmitrySharshakov[m]>
well, yes actually!
hir0pro has quit []
hir0pro has joined #asahi-dev
riker77 has quit [Quit: Quitting IRC - gone for good...]
e1eph4nt has quit [Ping timeout: 480 seconds]
riker77 has joined #asahi-dev
<kettenis>
fwiw, I plan to do some work on suspend/resume for OpenBSD this week
<DmitrySharshakov[m]>
Are you going to do it by a new register-based driver or adapt PSCI for running in EL2? Btw does OpenBSD kernel on M1/M2 run in EL2?
<kettenis>
PSCI
<kettenis>
OpenBSD drops down to EL1; no vmm(4) for arm64 (yet)
<DmitrySharshakov[m]>
Ah, so are you planning to run a bit of code in EL2 for the kernel to call into for PSCI actions?
<DmitrySharshakov[m]>
Probably needs a long-term solution that won't be a roadblocker to running the kernel in EL2
<kettenis>
no, we're planning to implement the PSCI-in-EFI idea that has been floating around
<j`ey>
DmitrySharshakov[m]: the PoC I wrote (for linux) puts the PSCI handler in m1n1, which is then put into the EFI memory map
<DmitrySharshakov[m]>
Ah, cool. So it'll call into U-Boot or so? I've not really seen PSCI-in-EFI
<DmitrySharshakov[m]>
Ah, m1n1 will also implement a part of EFI stuff
<DmitrySharshakov[m]>
j`ey: can I have a link to the branch?
hir0pro has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<j`ey>
DmitrySharshakov[m]: not online yet
<j`ey>
I will try clean it up and post the patches as a PoC/WIP
<j`ey>
especially if kettenis is going to start this week
<kettenis>
and IIUC m1n1 needs to be involved somehow anyway
<kettenis>
since after deep sleep the CPUs come back at the reset vector, which is locked
<j`ey>
yeah that ^
<DmitrySharshakov[m]>
That changes all the things. If m1n1 has to do that, then let it be sorta firmware to deal with PSCI in a generic manner. Will also reduce code duplication then. Thanks for explaining!
e1eph4nt has quit [Ping timeout: 480 seconds]
<DmitrySharshakov[m]>
So macOS didn't ever have this problem as XNU is the reset vector (or called shortly after it)
<j`ey>
and they're OK with having m1 specific code everywhere :P
<DmitrySharshakov[m]>
lol having no need to detect things saves quite a lot of thinking and LoC
<sven>
they also have a different kernel for each SoC which also helps things
<sven>
Linux is a single binary that has to work everywhere
e1eph4nt has joined #asahi-dev
<DmitrySharshakov[m]>
This exactly :) Also any Linux driver has to match other drivers' and userspace behavior, so it needs some more complex approach
<sven>
Apple also has some horrible hacks in their kernel. I still enjoy the fake-gpu-iommu kext and adt node that’s just a wrapper that calls back into the main gpu kext
<DmitrySharshakov[m]>
just why?
<sven>
so if the main kext allocates io memory it’ll call into their iommu api which calls the fake iommu kext which calls back into the main kext :D
<sven>
my best guess is that the gpu kext team didn’t want to or wasn’t allowed to talk to the iommu team to get some api to just register custom iommu ops
<sven>
so they went with the fake adt node
<DmitrySharshakov[m]>
Well, not adding UAT as a type of IOMMU page, but introducing a fake driver translating UAT into common IOMMU call
<DmitrySharshakov[m]>
sven: maybe
<sven>
also different incentives. Linux will probably support m1 drivers for 10+ years. Apple can just drop support or introduce breaking changes whenever they want to.
<DmitrySharshakov[m]>
Well, generally Apple also does ~10 years cycle (with end of it being maintenance bugfixes and security only), but with Linux the same HW should remain useful for a lot more considering its power. And, of course, those drivers need to be flexible enough (proven by M2) to be adaptable for newer generations
<sven>
can anyone with a m1 pro/max run trace_device("/arm-io/atxN-xbar") for all atcs and then plug two external screens into some usb-c ports using dp altmode?
<sven>
/arm-io/atcN-dpxbar actually
e1eph4nt has quit [Ping timeout: 480 seconds]
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bisko has joined #asahi-dev
<jannau>
hah, tricked myself. cn't trace atc0-dpxbar when stealing that port for the HV. I checked the adt first for a typo
<sven>
nice, thanks. do you know which dcpext it ended up using?
<sven>
offset 0x60 is what controls the mux
<sven>
it’s using dcpext0 and whatever dcpext is mapped to 2
<Foxboron>
marcan: hrm, still not sure what it's about. Holla at me if you need anything into actual Arch though
<jannau>
sven: looks like decpext0 and dcpext1
<sven>
hrm, interesting. looks like I’ll have to go and figure out how the dcpext maps to bits in that register then
<sven>
xnu talks about dcpextN,M so maybe they want to support two streams inside each dcpext at some point? dunno
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ricekot has quit [Quit: ttyl]
e1eph4nt has joined #asahi-dev
hir0pro has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<sven>
yup, looks like it's just two streams per dispext
bisko has joined #asahi-dev
hir0pro has joined #asahi-dev
<chadmed>
marcan: the overlay already has our u-boot, m1n1 and linux-asahi with the tags shipping with the installer keyworded as arm64 and the latest tag as ~arm64. update-m1n1 and update-vendor-fw are installed in /bin by the installer as well as a local.d script which runs update-vendor-fw on every boot. the only thing i need to get around to for feature parity is that python firmware thing if thats still relevant
hir0pro has quit []
<chadmed>
i edited update-m1n1 to grab from /usr/src/linux/arch/arm64/boot/dts/apple/*.dtb, u-boot and m1n1 binaries after being build are doins-ed to /usr/lib/asahi-boot or wherever the alarm pkgbuild puts them, i reused the path
hir0pro has joined #asahi-dev
<mps>
chadmed: why run update-vendor-fw on every boot
hir0pro has quit []
<chadmed>
iirc the original intention for new hw enablement was to update the vendor-fw tarball from macos and have linux check it for changes on every boot
<chadmed>
which is how i got the bt firmware sorted, so i just went with it for now until we figure out something better
<chadmed>
the script just immediately exits if theres nothing new so its not like its copying all the brcmfmac firmware on every boot or anything
<mps>
aha, thanks for explanation. maybe I should do same for alpine
<sven>
it’s a good idea to do it every boot because then you can also be sure it works because it’s tested all the time
<DmitrySharshakov[m]>
Btw does the script also forward the ICC profile to Linux? It could be useful, since all Macs have factory screen calibration. When DCP is ready (btw what stops it from being merged into Asahi branch?) we'll 100% be able to make use of it
<DmitrySharshakov[m]>
Unsure, but maybe simple simpledrm also can apply gamma ramps needed for calibration
<chadmed>
does colour management work like... at all under linux yet
<sven>
the entire point of that script is to add new firmware once we discover it’s required
<sven>
why bother with things that may not even be firmware already?
<chadmed>
also the simpledrm crtc does not have a gamma lut so colour correction wont work in kwin or mutter just yet, its why i cant daily linux just yet
<sven>
that calibration sounds like something that could end up in the device tree as well
<DmitrySharshakov[m]>
chadmed: I guess ICC profiles worked on Wayland for long now (with default colorspace)
<chadmed>
yeah but do applications obey it?
<chadmed>
iirc the whole reason its been an issue is because applications simply do not obey colour management information in the protocol, and the thrust now is for compositors/wms to take control of it
<DmitrySharshakov[m]>
sven: Well, I know it's somewhere in /usr/share for macOS, but to persist between reinstalls and wiping it should be somewhere in DT or EDID-like thing
<chadmed>
there was some discussion in #asahi-gpu about this aaages ago
<sven>
we’ll figure it out once we get to that point
<DmitrySharshakov[m]>
chadmed: Yes, when KWin applies the gamma (e.g. night colour setting), it does this over the whole screen
<DmitrySharshakov[m]>
Color management is a problem for HDR, where you need to process a lot of colorspaces and extra metadata
<chadmed>
yeah but the goal for kwin and mutter right now is to no longer apply gamma correction, which relies on LUTs from the kernel display driver
<chadmed>
there were links to where theyre discussing this upstream for both compositors in #asahi-gpu if you can find them
<chadmed>
this is an issue on eg nvidia cards, since their kms driver does not supply gamma luts which is why night mode doesnt work under wayland on some of those chipsets
<chadmed>
and to answer the question you asked before, this was, inter alia, blocking merging dcp
<chadmed>
do it once do it right and so forth
<DmitrySharshakov[m]>
Hmm, okay, just need to find the right place to obtain a copy of calibration data (to the firmware question)
<DmitrySharshakov[m]>
So what are the showstoppers on the DCP code now?
<jannau>
chadmed: I think we should make ebuilds for the manually installed scripts and an asahi-meta ebuild
<chadmed>
jannau: agreed, it was on my list but ive had a bunch of stuff due these past few weeks and time slipped away from me. happy to take contributions as usual ;)
<jannau>
I hope the screen calibration data is in the adt, the dcp driver will need to provide it for DCP
<jannau>
chadmed: same here, still sitting on the half finished asahi-fwexxtract ebuild
<chadmed>
product/primary-calibration-matrix and product/artwork-display-gamut seem to be what we want wrt screen cal btw
<DmitrySharshakov[m]>
Are those in the ADT dump?
<chadmed>
yarp
<jannau>
"display-temp-compensation" too but that's iirc not enough data
<DmitrySharshakov[m]>
Temperature compensation independent from gamma? Weird thing
<DmitrySharshakov[m]>
Maybe that's not color temperature but some thermal coefficients xD
<DmitrySharshakov[m]>
But that shouldn't matter for LCDs even in pro workloads
<DmitrySharshakov[m]>
What formats are those nodes and their data? Is there a dump to look at?
<jannau>
wtf apple "nits-to-pwm-percentage-part1" and "nits-to-pwm-percentage-part2" properties for the keyboard backlight
<DmitrySharshakov[m]>
could you please paste?
<DmitrySharshakov[m]>
Is there nits-to-pwm-percentage record for the screen and touchbar?
<jannau>
I think display-temp-compensation is thermal. I guess it's required for the the mini leds for max brightness in HDR mode
e1eph4nt has quit [Ping timeout: 480 seconds]
<jannau>
no touchbar and the backlight has no such properties but it has "milliAmps2DACTablePart1" and "milliAmps2DACTablePart2"
<sven>
lol, nits to pwm :D
<sven>
cause it’s so important that the keyboard backlight is properly calibrated!
<DmitrySharshakov[m]>
jannau: Does SMC report something related to screen temp?
<DmitrySharshakov[m]>
jannau: So you know current drive but don't know nits :/
<DmitrySharshakov[m]>
Did you take the dump on Liquid Retina XDR-enabled laptop (14" or 16")?
<jannau>
there are 3 display-temp-sens reachable over spi
<DmitrySharshakov[m]>
I guess AS machines are going to have the most hwmon sensors ever
<DmitrySharshakov[m]>
Sound amps also have temp sensor available via i2c regs, so add 6 more on Pro's :)
e1eph4nt has joined #asahi-dev
<DmitrySharshakov[m]>
What remains untested or nonfunctional within DCP driver which prevents it from being in Asahi kernel? If gamma LUT change is proposed than it could be changed
e1eph4nt has quit [Ping timeout: 480 seconds]
<DmitrySharshakov[m]>
Also, what is the temperature range backlight can heat up? Maybe that's not only a technique to compensate light intensity correlation with temperature, but also a protection mechanism? I really hope it has proper cooling from the top cover and cannot be really hotter than ~50 °C
e1eph4nt has joined #asahi-dev
<matthewayers[m]>
It probably is in there as a protection mechanism that is seldom used but is still necessary. I wouldn’t be surprised if some computers caught on fire or had issues due to the heat from the screen
e1eph4nt has quit [Ping timeout: 480 seconds]
<matthewayers[m]>
(At Apple during testing more than likely)
<tpw_rules>
i can't imagine how an led would get hot enough to catch fire
<tpw_rules>
burn out and die, yes
<matthewayers[m]>
Maybe not a single one by itself but a tightly packed array of them could be more of a threat
<tpw_rules>
then the chinese would have burned down half the western world with crappy led light bulbs by now
<DmitrySharshakov[m]>
Laptop LED backlight almost never has issues. Only TVs burn like that
<tpw_rules>
yes, i have seen some TVs burn but that's voltage rather than heat
<tpw_rules>
an led overheats, goes open circuit, then something that really shouldn't suddenly has 250V across it
<tpw_rules>
then starts arcing. but a battery powered device like a laptop wouldn't have an led circuit like that
<DmitrySharshakov[m]>
I guess MacBook has the whole back cover as a heatsink to those LEDs, so they should be safe. To heat up over 50 degrees they need a couple tens of watts
e1eph4nt has joined #asahi-dev
hir0pro has joined #asahi-dev
<matthewayers[m]>
That’s a good point. I’m not the most experienced when it comes to LEDs, clearly 😅
hir0pro has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
hir0pro has joined #asahi-dev
rappet has joined #asahi-dev
Race has quit [Ping timeout: 480 seconds]
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
Gaspare has joined #asahi-dev
e1eph4nt has joined #asahi-dev
Gaspare has quit []
hir0pro has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
e1eph4nt has quit [Ping timeout: 480 seconds]
the_lanetly_052__ has quit [Ping timeout: 480 seconds]
hir0pro has joined #asahi-dev
e1eph4nt has joined #asahi-dev
the_lanetly_052__ has joined #asahi-dev
nicolas17 has joined #asahi-dev
the_lanetly_052__ has quit [Ping timeout: 480 seconds]
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
e1eph4nt has quit [Remote host closed the connection]
e1eph4nt has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
hir0pro has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
hir0pro has joined #asahi-dev
e1eph4nt has joined #asahi-dev
yuyichao_ has quit [Quit: Konversation terminated!]
hir0pro has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
mini0n has joined #asahi-dev
hir0pro has joined #asahi-dev
mini0n has quit []
<andersonwatts[m]1>
"I'll help 10individuals how to earn $30,000 in 72 hours from the crypto market. But you pay me 10% commission when you receive your profit. if interested send me a direct message on WhatsApp by asking me (HOW) for more details on how to get started
andersonwatts[m]1 was kicked from #asahi-dev by ChanServ [SPAM]
<marcan>
sven: pcie broke with the power domains going down, it probably will work with them marked always on as long as the pcie link also doesn't go down (since no hotplug)
<sven>
yeah, that explains why it worked for bt
<sven>
i had no smc driver so the power gpio stayed on
<sven>
and also a hack that only kept it in suspend for 2 seconds or so