<marcan>
< alyssa> Needed to backport changes from pci.c to apple-ans.c b84ba30b6c7a ("block: remove the gendisk argument to blk_execute_rq") <- that one's already in the asahi branch
<marcan>
< jannau> linux has 3 distinct drivers for the touchpad events. applespi (used by corellium), kettenis found bcm5974 (input device), hid-magicmouse is convenient since it is already hid <= ha
<marcan>
very nice find on hid-magicmouse
<marcan>
< jannau> unrelentingtech: hid-magicmouse works out of the box with my WIP SPI HID transport driver
<marcan>
awesome :D
<marcan>
do you have this in a branch somewhere? I definitely want to start testing it soon, if it looks good it can go into asahi
leah has quit [Quit: WeeChat 3.3]
leah has joined #asahi-dev
<Jamie[m]1>
am I right in understanding that the t600x macs have a different audio amp?
<Jamie[m]1>
the part number in ioreg has no* google hits
<Jamie[m]1>
,it actually has one, but weirdly it's about an amp with a completely different model number
<Jamie[m]1>
(SN00012776)
<Jamie[m]1>
(google result for that is TAS5731M)
<Jamie[m]1>
s/sn00012776/sn012776/
<Jamie[m]1>
ah i see povik has already IDed it
<marcan>
Jamie[m]1: a common pattern seems to be Google "magically" knowing which public part number Apple secret part numbers are related to
<marcan>
happens with TI partnos too
<marcan>
I suspect the Algorithm™ is learning from internal engineer google searches or something :-)
the_lanetly_052___ has joined #asahi-dev
thunfisch has quit [Ping timeout: 480 seconds]
<Jamie[m]1>
lol
<Jamie[m]1>
What do we know about the MCA audio peripherals? I see the speaker experiment in m1n1 never interacts with them (only the mca-switch), which suprised me
thunfisch has joined #asahi-dev
<marcan>
Jamie[m]1: I think that's a decoding mistake
<marcan>
if you look at the reg ranges, they overlap
<marcan>
mca-switch covers all the MCAs
<marcan>
so that code should more properly be using the mcaX device paths, most likely
<marcan>
Apple love to do horrible things with reg ranges...
<Jamie[m]1>
ahh gotcha
<marcan>
in particular mca_switch0_base + 0x4xxx is mca1, which is connected to the speaker on the Mac Mini
<marcan>
so that checks out
<kettenis>
ouch, the smc on the j293 has 1435 keys
<marcan>
not surprising
<marcan>
it does a lot of stuff :)
<sven>
lol, apple. for some reason they send some undocumented nvme command a few times (0xd8 on the admin queue) when they initialize their controller. except that these commands don't use the NVMMU but SART now
<jannau>
marcan: not yet, it's still more PoC than proper driver. I'll bring it in testable state tonight
<povik>
Jamie[m]1: MCA is mostly figured out, see sound/soc/apple/mca.c in asahi-sound as jannau linked
<Jamie[m]1>
yeah sweet
as400 has joined #asahi-dev
<as400>
povik: does the sound hardware differ between t8000 and t6000 SOCs ?
<povik>
the MCA clusters are one after other in MMIO address space, and there's no use pretending they aren't
<povik>
especially given that you have to interact with multiple clusters even if setting one audio path
<povik>
as400: ADMAC and MCA seems to mostly be the same, or exactly same
<povik>
codecs are different
<povik>
jack codec will probably be an iteration of the one on t8000 macs, likely the same driver can be used
slicey has quit [Quit: zzz]
<povik>
speaker amp is different, i don't know if linux has a driver for the analogue part i found
<povik>
it does, just looked
<povik>
as400: i expect some work due to the many speakers found on the new mbps
<povik>
but as a baseline we can bring it up using only two speakers for left/right
<as400>
povik: thx, I'm just considering trying your driver on t6000 - that's why I'm asking.
<Jamie[m]1>
yeah it won't work as-is
<povik>
right
<povik>
the jack is closest to working
<povik>
but still i need to write the DT for that, then it has some chance of working
<as400>
povik: if you do need someone to test - I volunteer.
<povik>
great
<jannau>
j`ey: currently ~800 lines, still with some stub only omplementations and some debugging code which can be removed
<povik>
Jamie[m]1: also i looked to make sure tas5731 isn't also a good match for sn012776, but it isn't
<povik>
there's still the codec on imacs i haven't looked into
<Jamie[m]1>
ah interesting
<j`ey>
jannau: drivers/hid/i2c-hid/i2c-hid-core.c is 1100, so that sounds reasonable!
<povik>
yersterday i noticed imacs have some other codec/speaker-amp
<Jamie[m]1>
where are you getting an understanding of the sn012776 register layout?
<povik>
i read it through i2c after reset
<Jamie[m]1>
macos kext RE?
<povik>
oh god no
<Jamie[m]1>
ah gotcha
<Jamie[m]1>
lol
<Jamie[m]1>
:P
<Jamie[m]1>
ah right, by comparing the reset values to the datasheet?
<Jamie[m]1>
sweet
<povik>
yes
<Jamie[m]1>
the M1 boot process sure is neat, but they certainly haven't optimised for the performance of picking a non-default option lol
<povik>
haha, no they haven't
<Jamie[m]1>
it's so refreshing to see a boot process that doesn't involve layers of messy cruft
yuyichao has quit [Ping timeout: 480 seconds]
as400 has quit [Quit: Page closed]
aleasto has joined #asahi-dev
<sven>
oh fun. 0xd8 is some kind of debug command tunnel because ofc the normal mailbox interface wasn't enough for that
<sven>
apparently macos uses it to uh... send the current time to ANS
<povik>
see, an ordinary debug message right there
<sven>
looks like it's also possibly to enable error injection and do all kinds of fancy (and some scary) things with that one
aleasto has quit [Quit: Konversation terminated!]
aleasto has joined #asahi-dev
<Jamie[m]1>
wait what
<Jamie[m]1>
does ioctl truncate the address in "xxx@address" to 32 bits?
<Jamie[m]1>
s/ioctl/ioreg/
<Jamie[m]1>
that's evil :/
<marcan>
povik: the multispeaker thing needs some kind of filter/crossover thing
<marcan>
my idea is to grab an impulse response of what macOS does :-)
<marcan>
that should all be done in userspace, of course; not sure if all the ALSA/PA profile thing can handle EQ/convolution filters, but if it can't, well, maybe it's time to start that conversation
<povik>
marcan: that's my idea exactly, grabbing impulse response
<povik>
stealing the samples sent to speakers in hypervisor
<povik>
by now i have almost ruled out that the filtering is done in hardware
<marcan>
povik: iBoot has pre-filtered boot chime samples with channels for each speaker, so yeah
<marcan>
very unlikely they'd be doing it in hardware
<marcan>
otherwise they'd use it for iBoot too
<j`ey>
marcan: are you going to write a jingle/chime for m1n1? :D
<povik>
that would be a second chime, don't be evil
<marcan>
definitely not :p
<_jannau_>
we could check if the boot chime was disabled and play the m1n1 chime only if it is. to be extra evil, we make it almost the same as the iboot chime
<j`ey>
_jannau_: just one semitone out
<jn>
detuned into hell
yuyichao has joined #asahi-dev
<landscape15[m]>
marcan: I like the idea of a m1n1 boot chime, but as jannau says only if the Mac boot chime isn’t played.
<Jamie[m]1>
sounds like we need an m1n1 midi keyboard driver
<Jamie[m]1>
with an apple boot chime sampler
nabaiste^ has quit [Remote host closed the connection]
<sven>
macOS tells ANS what time it is and then uses two commands to get the NAND ID and something they seem to call NAND geometry. probably all things we can ignore for linux
<sven>
now it also makes sense why that debug command uses SART instead of the NVMMU though. the buffers are written to directly by the ANS firmware
the_lanetly_052___ has quit [Ping timeout: 480 seconds]
bps has joined #asahi-dev
Gaspare has quit [Read error: Connection reset by peer]
aleasto has quit [Ping timeout: 480 seconds]
aleasto has joined #asahi-dev
aleasto has quit [Ping timeout: 480 seconds]
aleasto has joined #asahi-dev
aleasto has quit [Ping timeout: 480 seconds]
aleasto has joined #asahi-dev
Dcow_ has joined #asahi-dev
aleasto has quit [Ping timeout: 480 seconds]
aleasto has joined #asahi-dev
<jannau>
unrelentingtech: re usb magic trackpad 2: how large are the hid reports
<unrelentingtech>
tiny, 21 bytes for 1 finger
<jannau>
ok, the internal one in mt mode produces 78 bytes for one finger iirc
<unrelentingtech>
yeah, I've just logged some packets from my 2015 mbp too
<unrelentingtech>
they do have the first 8 bytes in common, at least
<unrelentingtech>
the 9th byte is always 0x31 on the magic and 0x75 on the internal, maybe that means compact vs big format for the following finger data
aleasto has quit [Ping timeout: 480 seconds]
<unrelentingtech>
bcm5974 uses the 48th byte (on current models) as the beginning of big finger data. so the fixed size whatever before that does also contain finger data in the compact format it seems. I'm gonna play with some parser things..