<marcan>
new kernel doesn't fix AirPod glitches on the M2 and I can't get my Sony ones to pair at all; let me make a proper package and compare with m1pro
<sven>
I think i replaced them all with _timeout_interruptible but it’s possible i missed one
<sven>
still weird that something timed out though
<sven>
don’t think I ever saw that
<sven>
uh wait, that looks like something in the Bluetooth core
<sven>
are the AirPods unstable in SCO or ACL mode?
<marcan>
ACL
<marcan>
but this was under the hypervisor, though I wasn't hooking anything
<marcan>
but could still have timing issues
<marcan>
let me get a proper build installed
<marcan>
this m1pro sude does get toasty doing kernel builds :)
<sven>
hrm, my Bose headphones work fine even under the HV
<marcan>
might still be M2 trouble?
<sven>
maybe I should try pairing my AirPods and see if they are different
<sven>
it should get the correct calibration data now though
<marcan>
ok, it's also terribad with the Sony earbuds
<marcan>
let me test the m1pro to make sure this is a device issue
<marcan>
this is with a proper package now
<sven>
weird
<marcan>
okaay it's also terribad on the m1pro and I know why
<marcan>
it's btcoex
<marcan>
it works fine if I turn off wifi, and mostly fine if I hop on a 5G network
<marcan>
use 2.4G wifi, bluetooth is terribad
<marcan>
I've been using 5G at home, so I didn't notice earlier
<marcan>
yeah, works about the same on M2
<marcan>
so it's a btcoex issue
<marcan>
jannau: trackpad woes should be fixed (was more than one issue)
<marcan>
off to bbq lunch :)
<sven>
huh, that’s why I never noticed it then. I’m not connected to any WiFi on the m1 mini
<marcan>
this could well be a wifi driver fail, maybe it needs some magic "enable coex" command
c10l has quit [Quit: Bye o/]
c10l has joined #asahi-dev
nehsou^ has quit [Ping timeout: 480 seconds]
<marcan>
there are some btcoex iovars for the wifi, and this seems to be another apple-exclusive thing. sigh. going to poke around that.
c10l has quit [Quit: Bye o/]
c10l has joined #asahi-dev
<jannau>
marcan: mtp seems to be better now. occasionally it was even with the firmware in the initramfs not working
<marcan>
jannau: that was a different problem
<marcan>
sometimes messages came in out of seq
<marcan>
I got rid of the seqno check
<marcan>
as for the firmware, now it only loads multitouch firmware when the HID device is actually opened (changed the whole thing to be lazy)
<marcan>
so that should never happen until the root is mounted and firmware has been updated, unless someone has some kind of mouse support in their initramfs
<marcan>
keyboard should always work either way
<jannau>
did you miss the fn key mappings in hid-apple? I see it's there now but I swear the initial kernel did not support it
<marcan>
yes, that was missing in the previous kernel
<jannau>
oh, I missed that's possible to just init the trackpad later. that avoids having to deal with the firmware in u-boot if we can't reset it
<marcan>
yes, I never expected u-boot to have to deal with firmware
<marcan>
it only has to init the keyboard
<marcan>
and I think there is some form of deinit command
<marcan>
the problem is the HID descriptors
<marcan>
those only get sent on copro startup
<sven>
ofc btcoex is apple-specific. at least it’s probably no issue with the bt driver
<marcan>
so either u-boot needs to shove them into the dockchannel again for linux to find, or pass them via DT
<sven>
I’ll probably give up on t2 support there as well. pretty sure there’s some subtle difference that crashed the fw after a while and I can’t figure that out easily without a HV + access to a t2 Mac
<jannau>
I don't think I've ever tested if it's possible to request the hid descriptors multiple times with spi-hid
<marcan>
spi-hid is different anyway
<marcan>
you don't request the hid descriptors here
<marcan>
they just come
<marcan>
when you boot the copro
<marcan>
(also the gpio requests)
c10l has quit [Quit: Bye o/]
c10l has joined #asahi-dev
c10l has quit [Quit: Bye o/]
c10l has joined #asahi-dev
c10l has quit []
c10l has joined #asahi-dev
<marcan>
this is annoying me... lately, on the M2, booting the hypervisor hangs at a random point (often during CPU startup or after some PMGR stuff, sometimes midway through linux)
<marcan>
I don't remember any of this when I was doing bring-up
rqou_ has quit [Ping timeout: 480 seconds]
nicolas17 has joined #asahi-dev
nicolas17 has quit [Ping timeout: 480 seconds]
<jannau>
marcan: I think it happened on stream too. I saw it too and I think I haven't run the hv on the m2 in the last 2 weeks
nicolas17 has joined #asahi-dev
MajorBiscuit has joined #asahi-dev
MajorBiscuit has quit []
bisko has joined #asahi-dev
rqou_ has joined #asahi-dev
<marcan>
jannau: wasn't that just the usual hv dying thing, when running macos? that's a different one (guest gets in a bad state, hv is still alive)
<marcan>
but I might be wrong
nehsou^ has joined #asahi-dev
<marcan>
ok, I tried some btcoex related iovars blindly but didn't get anywhere; I think I need to finally write a wlan tracer (which will also help with the sleep stuff)
<marcan>
that can wait. release on monday, with the btcoex caveat.
<sven>
sounds good!
<marcan>
alright, making new images
<jannau>
I think it was guest execution stopping after CPU init but hv still up and able to reboot from its shell
<jannau>
sounds good. plasma-wayland is currently very crashy. plasma x11 seems fine so not important and most likely not our problem
<marcan>
yeah, the stuck after cpu init thing is an old unknown issue, this one is different
<marcan>
I think the former may have something to do with kaslr hitting a corner case
<marcan>
the new one is much more random and weird
<marcan>
uploading images
nehsou^ has quit [Ping timeout: 480 seconds]
Catyre has joined #asahi-dev
nehsou^ has joined #asahi-dev
<marcan>
dev installer live, looks like it works well on M2 (no more first boot touchpad bork)
Catyre has quit [Ping timeout: 480 seconds]
<marcan>
also I just realized that the boot-args filtering doesn't actually stop -v from working to change display mode... which does kind of break the security of my little trick there
<marcan>
not that it matters much right now, without proper secure boot
<marcan>
but I need to double check that... if it at least filters -v from the boot-args string, I can switch to that
<marcan>
otherwise, I'll have to think of something else
<marcan>
(or maybe this changed?)
<marcan>
wonder if we can get some boot policy info in the ADT...