10:12 <eiln> so als from the aop side looks like:

10:13 <eiln> hello/ack, load als calibration, (nothing), then aop suddenly starts reporting a stream of als data (e.g. lux, chromaticity, and etc)

10:13 <eiln> there's an als register being written to (stacktraces say the kext is AppleALSColorSensor) that turns on als. aop is hooked up to als s.t. aop automatically starts reporting als data when als is on. restated, als is not controlled by aop, rather its own register range (independent from aop) by some external kext

10:13 <eiln> everything else on the aop side we can do, see https://github.com/AsahiLinux/m1n1/pull/381. you can also trace it, set ALSEndpoint VERBOSE=True

10:13 <eiln> problem is, we don't know the register range of als. there's no als node in adt. I realize this is stupid but I seriously cant find the als base register

10:14 <eiln> any ideas..?

11:09 <chaos_princess> eiln: unfortunately the answer is "you don't", you need to figure out which specific als model is present via a separate aop subdevice, and then hardcode it.

11:16 <eiln> chaos_princess: so it's model FireFish2/CT720, that we can probe via aop. do you might know where macos hardcodes *that* range? I tried tracing the entire mmio range but it times out

15:24 <eiln> hehehe I got something good

15:27 <j`ey> eiln: found an address?

15:29 <eiln> no that was a red herring

20:59 <eiln> janneg: I am going to try to generalize afk.c to take a struct device

21:01 <nicolas17> away from keyboard .c?

21:03 <leio> Apple Firmware Kit, if you were wondering

21:05 <nicolas17> to talk to rtkit coprocessors?

21:06 <j`ey> it's a layer above that

21:06 <leio> I merely read the afk.h top comment as you got me curious on the actual meaning too, but looks like something on top of rtkit (using it)

21:13 <janneg> eiln: good luck. do you have a device on which you can test dcp's afk use?

21:15 <sven> wait, there’s something else that uses the mess that is afk?

21:16 <j`ey> sven: seems like AOP does

21:20 <sven> ouch. I very much did not enjoy writing that thing originally

21:53 <eiln> janneg: it seems the meaningful afk endpoint is dptx which ive not got

21:53 <eiln> but the only real difference is the ringbuf calls which should be fine with some fn ptrs

21:54 <janneg> for now, there are more coming. for dp/hdmi audio and additional information

21:55 <janneg> I could see if I can get my hacky dp altmode branches to work

21:55 <janneg> on m1 devices

22:02 <eiln> I'll probably get a 16" m2/m3 by april ish

22:48 <eiln> ok hold on I had not considered the price would nearly double with usuable ram and ssd

22:48 <eiln> was originally thinking 15" m2 air. if im going m2 pro, I'd rather take a baseline m3 for avd work, but m3 pro is completely out of the question rn

22:49 <eiln> maybe m2 air + m3 mini but I'm not sure when I'll have the mini

23:34 <nicolas17> what is AOP used for in Mac apart from ALS?

23:46 <j`ey> nicolas17: mics

23:46 <j`ey> gyro, accel

23:47 <j`ey> https://github.com/AsahiLinux/m1n1/pull/381/files#diff-3ed315179c8720d72f0227cdf55099ef849b93764b8eb90e9a6756b00fead227R171

23:47 <j`ey> ok, not gyro

23:48 <nicolas17> gyro and accel are mentioned in the AOP firmware for macOS, but do Macs actually have the sensors?

23:49 <j`ey> eiln: so does aop_als.py work standalone? since you talked about needng some hardcoded ranges, but i dont see any of that in there