ChanServ changed the topic of #asahi-dev to: Asahi Linux: porting Linux to Apple Silicon macs | Non-development talk: #asahi | General development | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Logs: https://alx.sh/l/asahi-dev
hightower2 has quit [Remote host closed the connection]
hightower2 has joined #asahi-dev
zef has joined #asahi-dev
zef_ has quit [Ping timeout: 480 seconds]
pthariensflame has joined #asahi-dev
pthariensflame has quit []
c10l9 has quit []
c10l9 has joined #asahi-dev
skmp__ has quit []
md_ has joined #asahi-dev
<md_>
hey! Any ETA on speaker? I would like to contribute too, if you guys helps me to start out
md_ has quit [Quit: Konversation terminated!]
md_ has joined #asahi-dev
md_ has quit []
bisko has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
gladiac has joined #asahi-dev
darkapex has quit [Remote host closed the connection]
<marcan>
I think I'm going to work on speakers again a bit today
<marcan>
jannau_: re the M2 series, feel free to respin it and I can try to get it in this week. For anything that's going through our tree that I authored (like the pmgr thing) I think I just need an r-b.
<marcan>
maz_: assuming krzysztof doesn't insist on splitting the whole series into 15 subsystems (sigh... robher?) are you okay with me pulling in that aic2 change via soc? I think that patch is the only one that has any binding changes beyond strictly the compatible.
<jannau_>
marcan: I'll respin it today. I reviewed the pwr-states bindings patch. we need to find someone to review the devicetree patch
<marcan>
sven? :>
bisko has joined #asahi-dev
gladiac has quit [Quit: k thx bye]
robinp has quit [Remote host closed the connection]
robinp has joined #asahi-dev
uartman_ has joined #asahi-dev
seeeath has joined #asahi-dev
seeeath has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #asahi-dev
bisko has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<maz_>
marcan: absolutely. binding changes that are backward compatible and that do not change driver code or existing behaviours are fine by me. just merge the damn sucker.
<marcan>
<3
stickytoffee has quit [Quit: brb]
<chadmed>
marcan: do you have the speaker work you did on stream published anywhere?
<chadmed>
(specifically the model and derivation of the voltage/current)
<marcan>
I was going to ask whether you can unify it a bit with asahi_firmware/img4.py but... probably not worth it here.
<marcan>
I'll give it a spin next time I do installer tests
<ChaosPrincess>
also, i wouldnt mind someone looking at the rest of the z2 series :P
<marcan>
ChaosPrincess: can you add a sanity check at the end? read the whole file through the transparent decompression, crc32 it and check against the zip metadata.
<marcan>
(I think it has uncompressed crc32 in there)
<ChaosPrincess>
i installed an os via it already and did a sha comparison for compressed vs uncompressed.
<ChaosPrincess>
but can do that too
<marcan>
and yes, I know... too many things in my head atm, I really need a TODO list
<marcan>
ChaosPrincess: yeah, it's more like in case we run into corner cases on block boundaries and weirdness like that. always nice to have sanity checks when "interesting" processing is involved.
<jannau_>
ChaosPrincess: any preference on warning/clippy fixes and rustfmt for asahi-nvram? I'd like to package it and add it to asahi-meta to sync the bt pairing keys on first boot
<marcan>
more than first boot even, should probably sync on every boot + shutdown in the other direction? otherwise if you add a device you end up with split brain again.
<ChaosPrincess>
jannau_: sure, sounds like a good idea.
<jannau_>
I wanted to start with the simple case of first-boot as syncing is obviously correct there
<marcan>
PSA: I'm going to try out $stuff with the DRM folks on the freedesktop.org gitlab. if it goes well we might move asahi-soc there.
<marcan>
arnd: I'll let you know if we do move and CC you on the MAINTAINERS update & notify linux-next (I think that's about it for things to do?)
<arnd>
marcan: yes, that should be fine. I tend to fast-track MAINTAINERS file updates through the fixes branch, so if you do the move now and I end up sending another fixes PR, it would be reflected in 6.2
<marcan>
ack. I suspect it might take a bit longer, since we'll be playing games with CI and clang-format and such, but we'll see :)
<arnd>
I don't have any other fixes queued at the moment though, and it's probably not urgent enough to send it to linus if it's the only other thing
<marcan>
I do have the M2 DTs pending for the regular process, can you get those in if I send you the pull on Thursday?
<marcan>
(cutoff is this weekend right?)
<marcan>
if it's too late it's not a big deal anyway
<povik>
uh, what's the command for checking a specific binding schema once again?
<marcan>
`make dt_binding_check dtbs_check DT_SCHEMA_FILES=Documentation/..../foo.yaml` is what I use
<povik>
thanks!
<chadmed>
pushed some fixes
<chadmed>
we will need a way to know what sample rate the main pcm has been opened by $audio_server at since the visense pcm will refuse to be opened at any other rate
<chadmed>
which is more than a little bit annoying
<jannau_>
'Documentation/..../' is not necessary, 'DT_SCHEMA_FILES=apple,sart.yaml' for example works as well
<povik>
jannau_: ha!
<povik>
that's pretty much what my script did
<povik>
...and it didn't need to :)
<marcan>
chadmed: we need to rethink the whole samplerate thing anyway
<marcan>
ideally visense should be openable even without the main PCM open (and just stay idle), and ignore the samplerate
<marcan>
and then either we report the sample rate some other way (control?), or just don't and the daemon can guess from the timing of samples arriving
<povik>
also i think there should be a way to figure out the rate the pcm will let you be opened in without brute force
<povik>
marcan: you can open the visense pcm without main pcm running but i think alsa timeouts will shut you down
<povik>
otherwise there's nothing enforced from the side of mca/macaudio
<marcan>
yeah, I plan to look into all this next time I do a stream about it (was going to be today but...)
<chadmed>
alsa-lib will let you query the pcm for supported rates (and by extension the rust bindings)
<marcan>
we also need the safety interlocks etc
<chadmed>
but being that theyre still bindings for alsa-lib its all very fragile :(
<marcan>
chadmed: I don't think trying to interlock the sample rates is a viable solution long term, it's inherently racy
<marcan>
we want the safety daemon to just always be there, idling (and not keeping hardware awake) when nothing is using the playback pcm, and just be woken up with samples when there are some
<marcan>
trying to play PCM open/close games to match sample rates is a losing game for this use case
<marcan>
we're just going to run into rare races that break audio for people
<chadmed>
is there a way to get samples out of a pcm without having it "properly" open?
<povik>
probably
<povik>
(that was a response to marcan)
<marcan>
I mean we'll still need "a" sample rate for opening it, but it can just be fake or allow any of the valid ones or whatever
<marcan>
and the samples actually arrive at the rate determined by the playback sample rate
<marcan>
it'll probably need some ASoC changes or core ALSA changes to make this possible but eh
<marcan>
it'll be tricky getting all the flows right and making sure it acts as a subordinate and doesn't spuriously keep power domains on and things like that
<arnd>
marcan: it's really late for new content for 6.3, I would much prefer to have an intitial to merge by -rc4 rather than -rc8, with follow-up patches and fixes on top up to the merge window. I have a few other things going on this week, so it's possible that this will have to wait for 6.4, but I'll have a look when you send it
<marcan>
arnd: it can wait then (it's a pile of DT compatible additions + t8112 device trees)
<povik>
13:13 <@marcan> it'll be tricky getting all the flows right and making sure it acts as a subordinate and doesn't spuriously keep power domains on and things like that
<povik>
doesn't look that way to me
<marcan>
even better then :)
<povik>
it's effectively another slave device on the bus
<marcan>
(I honestly don't know how ASoC works)
<povik>
so it should work out modulo the idleness/rate symmetry issues
<povik>
i didn't want to know how ASoC works but now i do
<marcan>
:)
<chadmed>
yeah the only issue i see is the rate. re idleness we can just stop talking to visense when the speakers up indicator goes dark, and we can also block program flow on an empty sample buffer
<povik>
the only issue are the alsa timeouts AFAIK, opening/closing the PCM but not having the sample rate race might be OK
<marcan>
main thing is not closing the PCM because then you end up with corner cases around reopening it / add safety corner cases if something goes wrong when reopening it / etc
<marcan>
much better to leave it open and just deal with disabling whatever timeouts might get in the way
<povik>
well, it can be in safety state unless the sense PCM is open?
<povik>
meaning it's significantly attenuated
<marcan>
it can, but then you introduce a weird timing dependency there
<povik>
that's true
<marcan>
consider a loaded system, the safety daemon gets the notification a bit late / runs late, then you get a weird "speakers are quiet for a split second" effect
<povik>
yeah
<chadmed>
oh its working at different rates now
<chadmed>
it mustve just not liked 44.1
<marcan>
incidentally, we probably want to make the safety daemon RT, and we need to make sure that doesn't trigger any overeager scheduling when the PCM is dark or demote it during that time
<chadmed>
it can definitely cut audio levels which is good but its erm.... very crude so needs refining
<povik>
13:17 <@marcan> consider a loaded system, the safety daemon gets the notification a bit late / runs late, then you get a weird "speakers are quiet for a split second" effect
<povik>
on second thought it's better if you get a weird effect rather than compromise safety on unresponsive daemon
<marcan>
for the interlock, I was thinking of a raw control we write with the current CLOCK_MONOTONIC_RAW timestamp or something, periodically. if the kernel sees an out of whack update or no updates for 1 second, it goes into safety mode.
<marcan>
povik: ^
<povik>
or in other words: if the deamon's not responsive it's hard to assure safety anyway
<marcan>
and then the kernel would keep track of PCM downtime and only require those updates within 1 second of the re-start
<povik>
marcan: right, a solution
<marcan>
main thing here is there's a window between the "unmute ramp-up/sound start" time and the "safety timeout" time
<marcan>
for unmute you really don't want to spend ages on it, it kind of sucks when new sounds get cut off at the beginning (very persistent problem on some platforms)
<marcan>
so << 1 second
<marcan>
but 1 second is reasonable for safety
<povik>
hah, haven't seen (heard?) the startup cutoff yet
<marcan>
quite a few platforms suffer from that (slow power-up amps and such)
<marcan>
and then like every system sound has the first fraction of a second cut off
<chadmed>
apple actually have a slight buffer and quick signal decay in userspace because these amps pop when you cut off their singnal too quick lmfao
<chadmed>
same on startup
<marcan>
lol, don't they do softmute properly?
<chadmed>
they might poke the register but theres a volume ramp down in coreaudio too
<marcan>
heh
<jn>
hmm, if there's a 1 sec grace period after sound output starts, it should probably be designed in such a way that a cycle of on for 995ms, off for 5ms (for example) doesn't bypass the safety requirement (you probably thought of that problem already)
<marcan>
jn: yes, my idea was that there's a 1 sec cumulative interval grace, and the daemon should itself have a timeout where after it stops getting samples it does one final update at the very least
* jn
nods
<marcan>
should be easier to bikeshed this once I have the code in front of me
<marcan>
sven, jannau_, povik: can you tell me which branches from github are still relevant? I could transfer them all, but I think we have a lot of junk in there anyway so we might as well do some spring cleaning
<chadmed>
\o/
<sven>
euh.. good question. probably not a lot for me
<sven>
so i guess I’ll have to create a fdo account now :)
<marcan>
yeah :) (sorry)
<sven>
huh, looks like I already have one
<marcan>
... not surprised, given how many projects we care about are on there
<sven>
ohhh. I remember now. I tried to create one and it didn’t get approved (or maybe I just didn’t get the email?)
<sven>
guess that just got fixed in the past weeks or months
<jannau_>
marcan: isn't it just lina sven and you with write access? dcp/sleep and dcp/wtf can be deleted as bits/200-dcp has the same functionality
<marcan>
yeah, it should be, just checked
<marcan>
so probably just sven needs to check
cylm has joined #asahi-dev
<sven>
I have local copies of everything important anyway
<sven>
and I stopped pushing WIP branches because people started annoying me too much over /msg
<sven>
so feel free to drop everything I guess
<sven>
“Not all browsers support WebAuthn. Therefore, we require that you set up a two-factor authentication app first. That way you'll always be able to sign in - even from an unsupported browser.” *sigh*
<marcan>
ha, must've come from the (no longer default) msm branch I forked from.
<marcan>
let me kill all that
<marcan>
ohh no, it was using an out-of-tree CI config, TIL gitlab can do that
<marcan>
(I have a plan for CI but it's not whatever that was)
<marcan>
should be gone now
<povik>
audiowise nothing but the bits branch is relevant
<marcan>
yeah bits are all cloned of course
<povik>
:)
<j`ey>
marcan: so the github one is going to be deprecated?
<marcan>
probably
<marcan>
will probably wait a bit and play around with CI and come up with a finished plan before pulling the trigger
<marcan>
I can make the gitlab repo auto-push to github to keep it alive
<jannau_>
out-of-tree CI config is probably required for supporting a large number of linux subtree with CI
<marcan>
we can have the CI in a bits branch or something like that, like everything else
<marcan>
it can even be upstreamed
<marcan>
the actual gitlab repo config is what sets the CI config path
<marcan>
so it can live under our own directory
<jannau_>
the asahi tree cares about different things than the rest of trees and it would be hard to provide the CI infrastructure for that
<marcan>
I'm debating whether I want to split off asahi-soc into its own CI thing, since we probably want significantly different configs for that vs. the full downstream tree
<marcan>
jannau_: yes, but we can have something like drivers/soc/apple/.gitlab-ci.yml and throw our stuff then, and only our repo (which is configured to point there) would use it
<marcan>
so that could be upstreamable
<marcan>
DRM plans to do something similar
beeblebrox has joined #asahi-dev
<marcan>
for now, let's start by trying out clang-format. I added an override file with some minor things.
chadmed has quit [Remote host closed the connection]
chadmed has joined #asahi-dev
Cyrinux9 has quit []
Cyrinux9 has joined #asahi-dev
<jannau_>
looks ok to me
<jannau_>
the tree has still some msn-next-* branches
<sven>
no opinion on any code formatting as long as it’s automatic here
jannau_ has quit []
jannau has joined #asahi-dev
seeeath has joined #asahi-dev
leitao has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
leitao has joined #asahi-dev
leitao has quit [Ping timeout: 480 seconds]
leitao has joined #asahi-dev
seeeath has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
seeeath has joined #asahi-dev
chadmed has quit [Remote host closed the connection]
chadmed has joined #asahi-dev
<marcan>
robher: is your DT checker bot script public somewhere? I'm thinking of setting up something similar as a GitLab CI
<marcan>
in particular whatever logic it uses to diff results to find new warnings/errors and such
<robher>
marcan: all in gitlab.com/robherring/
<robher>
That script should be in the dt-review-ci. On my phone ATM...
leitao has quit [Ping timeout: 480 seconds]
<marcan>
ack, thanks :)
<marcan>
awesome, all done as GitLab CI already!
<marcan>
ChaosPrincess: congrats you broke my Thunderbird
<marcan>
(you probably did nothing wrong, this whole process is just beyond cursed)
<ChaosPrincess>
i kinda partially locked myself out of that gmail account by losing my old sim card, and tried to use this newfangled b4 thingy :P
<j`ey>
I really wasn't expecting pwm to get to v7 (or v8/9 if you count the resends D:)
<ChaosPrincess>
neither did i
stickytoffee has quit [Ping timeout: 480 seconds]
winter has joined #asahi-dev
stickytoffee has joined #asahi-dev
stickytoffee has quit []
MajorBiscuit has quit [Ping timeout: 480 seconds]
rkjnsn_ has joined #asahi-dev
seeeath has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
seeeath has joined #asahi-dev
neutrino2211 has joined #asahi-dev
linuxgemini1 has quit []
leitao has joined #asahi-dev
leitao has quit []
kesslerd has joined #asahi-dev
mkurz_ has joined #asahi-dev
kesslerd has quit [Ping timeout: 480 seconds]
mkurz__ has joined #asahi-dev
mkurz has quit [Ping timeout: 480 seconds]
mkurz_ has quit [Ping timeout: 480 seconds]
mkurz__ has quit [Read error: No route to host]
mkurz__ has joined #asahi-dev
mkurz__ has quit []
<povik>
give your comments on the sio binding or live with it for eternity!
zalyx has quit [Ping timeout: 480 seconds]
<chadmed>
povik: the buffer which the samples are read into is an array of i16s. I convert them to 32-bit floats after the samples are in.
<chadmed>
more accurately, i take the slice of samples relating to each speaker and convert the elements of that slice
axboe has quit [Ping timeout: 480 seconds]
___nick___ has quit [Ping timeout: 480 seconds]
axboe has joined #asahi-dev
<povik>
sure, but there are no 16-bit floats nor 32-bit TDM slots in the picture, so that comment was just misleading
<povik>
(playback uses 32-bit slots though)
mkurz has joined #asahi-dev
mkurz has quit []
kesslerd has joined #asahi-dev
seeeath has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
seeeath has joined #asahi-dev
zalyx has joined #asahi-dev
neutrino2211 has quit [Read error: Connection reset by peer]
kesslerd has quit [Ping timeout: 480 seconds]
seeeath has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
seeeath has joined #asahi-dev
hightower3 has joined #asahi-dev
hightower4 has joined #asahi-dev
hightower2 has quit [Ping timeout: 480 seconds]
hightower3 has quit [Ping timeout: 480 seconds]
darkapex_ has joined #asahi-dev
darkapex has quit [Ping timeout: 480 seconds]
seeeath has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
seeeath has joined #asahi-dev
seeeath has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
seeeath has joined #asahi-dev
<axboe>
marcan: cc me on these things, I'm quite serious when I say I think this is a big deal and if my voice can add a bit of push back to the BS, then I'm more than happy to do so. I absolutely hate for this to be an unnecessary burden, seems like such a waste of time when that energy could be spent so much better on solving actual issues