ChanServ changed the topic of #asahi-alt to: Asahi Linux: porting Linux to Apple Silicon macs | User-contributed/unofficial distribution ports | Logs: https://alx.sh/l/asahi-alt
ece314378925355451680698427415 has joined #asahi-alt
tobhe has joined #asahi-alt
tobhe_ has quit [Ping timeout: 480 seconds]
mattia013_ has joined #asahi-alt
aead has quit [Ping timeout: 480 seconds]
zerdox has joined #asahi-alt
mattia013_ has quit [Ping timeout: 480 seconds]
<flokli> chadmed: what's deciding about these names, how do I debug this?
aead has joined #asahi-alt
kraem has joined #asahi-alt
nst_ has quit [Quit: WeeChat 4.4.3]
nst has joined #asahi-alt
<chadmed> flokli: im not terribly sure tbh. the ucm files are correct and working so i dont know why they wouldnt be getting picked up.
<chadmed> someone else reported a similar failure mode and i could not for the life of me work it out
<chadmed> i need more hardware :(
<flokli> chadmed: I was thinking about trying to match on alsa.id or something similar, which seems to be more reliable
<flokli> But I'm not sure if the devices I'm seeing are actually the correct ones or not
<chadmed> theyre not. the UCM profile is not being applied
<chadmed> please do not try re-engineering the matching scheme. what exists is correct and your system is what is incorrect
<chadmed> leio, sam_: the mesa driver will be enabled upstream for 25.1 which is why we can do that. might leave it until the kernel uapi changes flow through to linux-asahi though
<flokli> chadmed: I'm trying to figure out which part is still missing / outdated from the NixOS packaging. ucm not being applied might be the right hint, I'll dig into that. Thanks!
<chadmed> asahi-audio should be version 3.2 at least (3.3 ideal) but apart from that the rest of UCM is just standard pipewire/alsa functionality and shouldnt be affected by package versions
<chadmed> sorry not asahi-audio, alsa-ucm-conf-asahi
<chadmed> and it should be version 8
<flokli> Hm, it is 3.3 and 8, so that might not be it
kraem has quit [Ping timeout: 480 seconds]
<flokli> If you think it's something with the hardware, I might be able to run some patches or dig up some more info.
<chadmed> i dont think it's hardware related. the ucm stuff is all at the alsa-lib or whatever level
<chadmed> flokli: can you paste the output of `arecord -l`
<chadmed> lol the mic device isnt even there
<chadmed> what kernel version are you on and did you update your device trees
<flokli> Linux m2air 6.14.1-asahi #1-NixOS SMP currently
<flokli> I don't know how to update device trees. They're baked into uboot?
<chadmed> update-m1n1?
n3ph has joined #asahi-alt
<flokli> we don't have this script, but our u-boot expression definitely seems to be outdated.
<flokli> m1n1 is at 1.4.21, but u-boot is still at rev asahi-v2024.10-1 / version 2024.10-1-asahi
<chadmed> thats the latest, but the dtbs should be updated with every kernel uprev
<chadmed> you really really ought to have some update-m1n1 analogue
<flokli> where do the dtbs come from?
<flokli> asahi-kernel tree?
<flokli> We have a process populating bootloader things in /boot / the ESP, it could be looped into this. It might already be - Just need to know which dtbs we're talking about.
ece314378925355451680698427415 has quit [Ping timeout: 480 seconds]
<chadmed> yeah kernel tree dtbs
<chadmed> they need to be concatenated into the m1n1 payload though. they cant just exist on the filesystem
<leio> any idea why my monitor sometimes loses signal and has to reacquire it? These are the logs from that time: https://bpa.st/UHCQ - should I blame the monitor (or cable?) on that one too or probably not?
<flokli> so I'd assume my /boot/m1n1/boot.bin does contain all dtb files from the current kernel.
n3ph has quit [Ping timeout: 480 seconds]
<flokli> I'll manually diff the generated file with what's on /boot this evening, just to double check it indeed is what it's supposed to be.
<chadmed> flokli: can you also grep dmesg for "aop" and see if there are any probing errors
<flokli> [ 9.731483] apple_aop 24ac00000.aop: Adding to iommu group 7
<flokli> [ 9.731516] apple_aop 24ac00000.aop: probe with driver apple_aop failed with error -22
<chadmed> yeah okay so the kernel is shitting the bed for some reason
<flokli> chadmed: I'll be afk for a few hours, but can check later
n3ph has joined #asahi-alt
<jannau> leio: '[AFK]Restaring interfaces with reason - Capabilities changed..' sounds like it might be the monitor. I guess you're not using macos would be interesting if it happens there as well
<jannau> is there anything the monitor could report as change? monitor setting changes, integrated kvm, plugging in usb devices headphones or aan ambient light sensor
<leio> I dunno, I didn't touch the menu then, was staring at a terminal window
<leio> macOS I saw it on older monitor firmware, but newer had a related fix claim; I haven't seen it on macOS lately, but I haven't used it for any longer durations since the monitor fw upgrade
<leio> unrelatedly, the EDID stuff doesn't look to be working either?
<leio> (not to mention getting it going in 240Hz with some overrides, but I haven't cared for it anymore)
<leio> and now I got the usual problem (also desync) when playing over HDMI audio: https://bpa.st/ZWVA
<leio> (for the earlier case the internal jack was selected and working with headphones)
n3ph_ has joined #asahi-alt
n3ph has quit [Ping timeout: 480 seconds]
chaos_princess has quit [Quit: chaos_princess]
chaos_princess has joined #asahi-alt
n3ph_ has quit [Read error: Connection reset by peer]
n3ph has joined #asahi-alt
zerdox has quit [Remote host closed the connection]
JayBeeFOSS has quit [Ping timeout: 480 seconds]
JayBeeFOSS has joined #asahi-alt
zerdox has joined #asahi-alt
zerdox has quit [Ping timeout: 480 seconds]
kraem has joined #asahi-alt
zerdox has joined #asahi-alt
kraem has quit [Ping timeout: 480 seconds]
JTL has joined #asahi-alt
Hartley25 has quit [Remote host closed the connection]
Hartley25 has joined #asahi-alt
n3ph has quit [Ping timeout: 480 seconds]
nela has quit [Quit: bye!]
nela has joined #asahi-alt
cyrinux9490 has quit []
cyrinux9490 has joined #asahi-alt
Calandracas has quit [Remote host closed the connection]
Calandracas has joined #asahi-alt
<flokli> chadmed: -22 suggests it's running into the if "!audio && of.property_present(c_str!("apple,no-beamforming")) {" branch
<chaos_princess> can you check if the relevant property is present then?
<flokli> it's not
<flokli> but tbh I don't understand the logic there
<chaos_princess> isnt that the wrong driver? apple_aop is the root device, while the one for the mics should be snd_soc_apple_aop_audio
<chaos_princess> where exactly are you getting the kernel from? (commit hash if possible, otherwise which branch)
<flokli> asahi-6.14.1-2
<flokli> 31a0d9d457fde5974ff105c9ad19171f79959987
<flokli> I guess I can bump to asahi-6.14.1-3
<chaos_princess> and which device is it?
<flokli> MacBook Air J413
<chaos_princess> can you also list /proc/device-tree/soc/aop@24ac00000/
<chaos_princess> looks correct
<chaos_princess> idk then
<flokli> no worries, thanks for taking a look
<chaos_princess> i mean, if you are ok with recompiling stuff, would be cool if you could insert a bunch of log statements to see where it fails
<flokli> I'm ok with recompiling stuff, yes. I guess I'll just edit aop_audio.rs and add some log messages in a few places, and check where it breaks
<flokli> I wonder if it's possible to only build that kernel module though, and insmod it manually, rather than recompiling a new kernel all the time.
<flokli> I'll check tomorrow, bed time :-)
<chaos_princess> you are failing in aop.rs, even earlier than aop_audio
<jannau> the error is from aop.rs and not aop_audio.rs
n3ph has joined #asahi-alt
breakgimme has quit [Remote host closed the connection]
breakgimme has joined #asahi-alt
n3ph has quit [Ping timeout: 480 seconds]
zumi has joined #asahi-alt
Hartley25 has quit [Ping timeout: 480 seconds]
zerdox has quit [Remote host closed the connection]