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
Poplar has quit [Quit: leaving]
sarucchi has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
dax has joined #asahi-dev
<marcan>
povik: oh yeah, docs are a different issue and it's not perfect
<marcan>
what I meant is that ASoC at least seems to have a reasonable model to cover the combinations, while so many other niche SoC subsystems in the kernel kind of utterly fail at abstracting things out usefully
zjstraus has quit [Ping timeout: 480 seconds]
zjstraus has joined #asahi-dev
zjstraus2 has joined #asahi-dev
zjstraus has quit [Ping timeout: 480 seconds]
zjstraus2 is now known as zjstraus
psykose has joined #asahi-dev
dax has quit [Quit: dax]
dax has joined #asahi-dev
psykose has quit [Remote host closed the connection]
cylm has quit [Quit: WeeChat 3.6]
cylm has joined #asahi-dev
brolin has joined #asahi-dev
brolin has quit [Ping timeout: 480 seconds]
eiln has quit [Quit: WeeChat 3.8]
cylm_ has joined #asahi-dev
cylm has quit [Ping timeout: 480 seconds]
cylm_ has quit [Ping timeout: 480 seconds]
cylm_ has joined #asahi-dev
sarucchi has joined #asahi-dev
mlp has joined #asahi-dev
mlp has quit [Ping timeout: 480 seconds]
<marcan>
kettenis: is there some way we can skip u-boot USB init on laptops by default on internal installs? that will both speed up boot time and insulate us from USB stack brokenness a bit (which people keep running into...)
<marcan>
(or maybe once we get that Rust USB stack into m1n1 we should replace u-boot's stack with that too :p)
mlp has joined #asahi-dev
mlp has quit [Ping timeout: 480 seconds]
<jannau>
marcan: make the 'usb start' in CONFIG_PREBOOT conditional
mlp has joined #asahi-dev
mlp has quit [Ping timeout: 480 seconds]
psykose has joined #asahi-dev
gabuscus has quit []
cylm has joined #asahi-dev
cylm_ has quit [Ping timeout: 480 seconds]
gabuscus has joined #asahi-dev
systwi has quit [Read error: Connection reset by peer]
systwi has joined #asahi-dev
cylm has quit [Read error: Connection reset by peer]
bisko has joined #asahi-dev
cylm has joined #asahi-dev
wonjongbot has joined #asahi-dev
wonjongbot has quit [Ping timeout: 480 seconds]
Ziemas has joined #asahi-dev
MajorBiscuit has joined #asahi-dev
MajorBiscuit has quit []
bps2 has joined #asahi-dev
MajorBiscuit has joined #asahi-dev
<povik>
err, s/the day of light/the light of day/, not sure why i keep writing this idiom the wrong way...
<povik>
anyway what i was getting at is that the lack of docs (in places) might be related to the usefulness of the abstraction
<povik>
since then the abstraction can be bend to the needs of different users
<povik>
so some of the details are made up on spot, and only in combinations of components that see actual use the details are worked out to compatibility
<povik>
that's not to say ASoC isn't lacking in high-level docs, the lack of which isn't contributing to anything
MajorBiscuit has quit []
MajorBiscuit has joined #asahi-dev
<kettenis>
marcan: if you don't start the usb controllers, you lose the usb keyboard
<_jannau_>
usually not huge loss on notebooks if the lid is open
Ziemas has quit [Read error: Connection reset by peer]
chadmed has quit [Remote host closed the connection]
nsklaus has joined #asahi-dev
c10l has quit [Quit: Bye o/]
c10l has joined #asahi-dev
<j`ey>
povik: the day of light sounds a lot more religious :P
chadmed has joined #asahi-dev
<chadmed>
jannau: cherry picking that commit did nothing, im gonna say that it's a kwin issue
<chadmed>
just by vibe analysis the way theyre calculating the CTM looks wrong
<chadmed>
but i havent looked into it deeper than glancing over the commit that added the feature last night
<chadmed>
colour management on kde is just horrifically broken in general
<_jannau_>
are you using kwin 5.27.4(.1)?
<chadmed>
yeah
<_jannau_>
I don't see how kwin should make a difference then unless you have additional color management
<chadmed>
itd be nice to eliminate the screen/a colour space mismatch and check on a known-good monitor but obv cant without dcpext
<kettenis>
_jannau_: but problematic for the desktop machines
<kettenis>
unfortunately your last attempt to get marex to look into the usb induced crashes doesn't seem to have worked
<_jannau_>
chadmed: I'd expect more problems with external (non-Apple) displays
<kettenis>
maybe time for me to finally come up with a diff to address at least the obvious problems with aborted usb transfers in the xhci host code
<_jannau_>
kettenis: marcan asked for it to be skipped on laptops
hightower2 has quit [Ping timeout: 480 seconds]
sarucchi has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<kettenis>
I suppose we could call usb_init() from the board code based on whether we already have a keyboard or not
<chadmed>
jannau: true, and its not like i dont know what its meant to look like on this screen either. macos behaves properly
<chadmed>
but we seem to apply the CTM correctly unless that unknown field does something
psykose has quit [Remote host closed the connection]
pjakobsson has joined #asahi-dev
chadmed has quit [Remote host closed the connection]
chadmed has joined #asahi-dev
bisko has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<marcan>
I rebased your old series on the current kernel, fixed some stuff
<marcan>
and fixed the sample rate mismatch / read timeout issue (managed to do it entirely in macaudio, though perhaps in a hacky way)
<marcan>
next the watchdog/lockout stuff. I think for that I'm going to use the existing kctl lock mechanism, I just need a new callback for lock/unlock so the controls can use that to take actions
<marcan>
the pd stuff I got some nasty fault at some point, I suspect some path is trying to remove the device link twice so I just hardened all of those, but you may want to go over it
eiln has joined #asahi-dev
<povik>
from the looks of it there's at least the double free of apple_mca_release/mca_fe_disable_clocks
<povik>
if you open a stream once and then unload the driver
<povik>
ah, that tree has the clock shutdown fixup you made
<povik>
i wanted to suggest we flip on ignore_pmdown time flag on all the PCM links from macaudio instead
<povik>
that should be another way of fixing the shutdown ordering, but i have yet to try it and confirm that
<povik>
wasn't it rebasing hell, redoing the ivsense patches on top of that clock shutdown patch?
<marcan>
the dance with the sample rate is a bit awkward, but it does work in practice
<marcan>
required safetyd behavior is that it looks up the available rates then picks one (it will either get a range if the playback PCM is closed, or the playback PCM rate as a single supported rate if it's open)
<marcan>
as long as it does that it works
<marcan>
once the PCM is running it doesn't matter any more
<povik>
what else would it do but pick one of the available rates?
<chadmed>
is it not possible to have it only try opening the secondary pcm when the primary one is running with the speaker active kctl?
<marcan>
I mean it could hardcode one and then that would fail
<marcan>
unfortunately there's no reasonable way to do driver-initiated hw_params feedback as far as I know, hence the mixer control feedback instead
<marcan>
but eh
<chadmed>
povik: previously it was hardcoded to 48000 and it would explode
<marcan>
chadmed: that is possible but it introduces a race
<marcan>
there shouldn't be any downside to keeping the PCM open in theory
<marcan>
I did check that we drop the clocks and stuff even if the sense PCM is open
<chadmed>
oh so we can switch the sample rate with the pcm open, neato
<chadmed>
that works way better then
<marcan>
yeah we just don't care basically
<marcan>
the only reason it has to get the rate right if the other side is open is because there's a check in that path
<marcan>
on the core code (which I ended up not touching)
<marcan>
but the macaudio driver nukes the rate set on the capture path, and if the DAI rate is 0 then the rate equality checks don't apply
<marcan>
so it all works out
<marcan>
it's all kind of hacky but at least it fits into the existing framework without major changes, like new UAPI for rate change signaling
<marcan>
which is kind of overkill here
<povik>
marcan: i think the props->is_sense path in dpcm_hw_params can't get hit
<marcan>
it can
<povik>
since is_sense is a frontend prop and this is hw_params for a backend
<povik>
oh it can?
<marcan>
via macaudio_fe_hw_params
sarucchi has quit [Ping timeout: 480 seconds]
<marcan>
but that confused me, I don't get why that calls it
<povik>
ah fe_hw_params calls into the general one
<povik>
that explains the name
<marcan>
seems redundant but I dind't try removing it
<povik>
its not, the bclk_ratio needs to be applied on both frontend and backend
<povik>
i should add a comment
<marcan>
ah ok
<povik>
it just confused me and i was the one who wrote it :D
<marcan>
:)
<marcan>
anyway, going to get some dinner
<marcan>
feel free to hack on the code as much as you like
chadmed_ has joined #asahi-dev
chadmed has quit [Ping timeout: 480 seconds]
alyssa has joined #asahi-dev
stipa is now known as Guest931
stipa has joined #asahi-dev
<alyssa>
kettenis: With the build of U-Boot that Fedora Asahi is shipping, booting an M1 MacBook Air with certain type-C USB devices plugged in reliably causes a boot loop (requiring me to unplug the devices while booting and then plug back in once booted)
<alyssa>
Specifically, if I have plugged in the "Apple USB-C Digital AV Multiport Adapter" ( https://m.media-amazon.com/images/I/31DDmAfrcvL._AC_SL1024_.jpg ), with power plugged connected, a USB Razer mouse plugged in to the type-A port, and no HDMI connection
<mps>
alyssa: this also happens to me with one usb-c ssd
<alyssa>
mps: OK
<alyssa>
(There's nothing funny about the USB devices, it's a U-Boot bug, so it's unsurprising other devices are affected.)
<kettenis>
keep complaining about this on the u-boot mailing lists ;)
<mps>
I'm not using fedora built u-boot but alpine
<_jannau_>
no, probably a different u-boot usb problem
cylm has quit [Ping timeout: 480 seconds]
Guest931 has quit [Ping timeout: 480 seconds]
<alyssa>
It's a shame because the kernels were shipping are rocksolid
<alyssa>
Wondering if u-boot's approach of "be our own kernel and support everyone's hardware" is not great, actually >_>
<alyssa>
maybe iBoot got this right here.
<alyssa>
if not for UEFI.. side.
<alyssa>
*sigh
<alyssa>
(my desktop is tethered boot... m1n1 is excellent and I had no idea how many issues that shielded me from until I got a macbook and installed what we ship and hit boot loops on my first day.)
<povik>
FYI the cpu_dai of BEs and FEs is different
<povik>
so we are probably not clearing the cpu_dai->rate of frontend
<chadmed_>
alyssa: if you dont need any of what u-boot provides you can cat your kernel and initramfs directly to m1n1 stage 2
chadmed_ is now known as chadmed
<_jannau_>
doesn't solve the problem of shipping the same problem to users and breaks on the next update
<alyssa>
^
<chadmed>
agreed, just an option for alyssa's specific case. obviously it needs to be fixed
<alyssa>
I had no idea we were shipping "known to boot loop, end users hitting it in the wild, can't be fixed, good luck"
<kettenis>
ultimately those that have the hardware that triggers the issue need to invest time, either by continuing nagging about this on the u-boot lists or fix the issue
<chadmed>
in the same way i have speakers enabled daily and the max volume bumped up in macaudio.c but wouldnt ship this to users in a billion years
<alyssa>
chadmed: ehehe so about that
* alyssa
whispers conspiratorially
<alyssa>
i hear you can make my macbook's speakers work
<alyssa>
what's your price
* alyssa
gets out her soul chequebook
<Shiz>
alyssa: i've noticed a *bunch* of issues when configuring and compiling our own u-boot for $dayjob
<Shiz>
it's pretty... surprising
<chadmed>
alyssa: vulkan 1.3 :P
<Shiz>
basic Kconfig missing dependencies leading to compile errors
<povik>
hahaha
<Shiz>
implicitly-assumed defaults that aren't checked
<povik>
chadmed: steep!
<Shiz>
not to mention the SPL mess...
<chadmed>
if you promise not to yell at me if (when) they melt then i will do my best
<chadmed>
afaict the m1 air shares hardware with my 13" x86 macbook, but with a different chassis shape
<Shiz>
14:03:40 @alyssa : Wondering if u-boot's approach of "be our own kernel and support everyone's hardware" is not great, actually >_>
<Shiz>
at least they mostly import drivers from linux these days :p
<chadmed>
alyssa: a deal even the ferengi would consider unfair
<chadmed>
assuming you have an m1 air leave it with me and ill see what i can do. i tried to get a start on those machines a while ago but the linux sound driver for the x86 macbook pro is out of tree and mega jank
<alyssa>
why do i expect this is going to be a rickroll or something
<povik>
chadmed: bet you are getting vulkan 1.3 soon!
<chadmed>
eta: whenever hl3 is released
<alyssa>
chadmed: I am not allowed to comment on this matter.
<alyssa>
:-p
<chadmed>
ooooh i knew it
<povik>
alyssa is working on hl3?
<chadmed>
not that it wasnt obvious or anything, but congrats nonetheless
<chadmed>
whos to say?
<chadmed>
flat structure and all that :P
<chadmed>
anyway with the mini unfortunately theres probably not a lot else i can do beyond whats there... the speaker is exceedingly crap
<alyssa>
:-D
<chadmed>
pretty damning that apple didnt even bother with dsp on it at all
<povik>
is that right?
<chadmed>
yeah macos does nothing with the minis
<chadmed>
these new ones sound materially worse than a 2011 sandy bridge one i have in a cupboard somewhere
<chadmed>
i think the trick will be to have the psychoacoustic bass plugin so i can relax the cone a bit
<chadmed>
the 13" laptops will be way more interesting
<chadmed>
no dual opposed woofers to cancel out chassis vibrations
<chadmed>
i suspect psychoacoustic bass will be a hard necessity on those machines for shipping to users just going by how much this 14" jiggled around before i brought up the opposed woofers
<chadmed>
then again if they are indeed similar/identical hardware to the 13" i have then the woofers are pathetic enough that it doesnt matter
<alyssa>
"psychoacoustic bass" Not sure that's legal where I live
<sven>
And then you realize that 2016 is already 6-7 years ago now…
<alyssa>
that's like a week in kernel time scale
<povik>
there are dog years and then there are kernel years
<alyssa>
not to be confused with kennel years
bcrumb has joined #asahi-dev
<marcan>
alyssa, kettenis, jannau: I'm going to have to fix that u-boot splat myself aren't I
<alyssa>
:lina_splat:
<marcan>
why do I always have to fix USB problems everywhere? it's not like I wrote the virtual xHCI support in qemu, I absolutely did not...
<marcan>
< povik> so we are probably not clearing the cpu_dai->rate of frontend <- that's fine because there are two frontends
<povik>
right you are
<marcan>
(today I spent most of the 5 hour stream trying to understand how all those pieces tie together...)
<marcan>
(I still only somewhat get it, but hey, I made it work :p)
<povik>
you did!
<povik>
(i assume, i haven't checked)
* j`ey
didnt know there was a stream
<marcan>
I did toot it!
<marcan>
I left the speakers thing unstarted yesterday and felt bad about it :p
fredmb has joined #asahi-dev
* j`ey
isnt on mastodon on the work computer
<marcan>
aw
<j`ey>
it's ok, speaker stuff goes over my head anyway!
<marcan>
hey next one will be more boring
<povik>
:D
<marcan>
just implementing an interlock mechanism for the mixer controls
<marcan>
:p
<marcan>
after that it should be shippable in principle, except we still need to make and validate profiles for all the other machines and do a bunch of integration work before it really ships
<j`ey>
and the kernel side of speakersafetyd isnt done yet?
<kettenis>
marcan: I think all the issues we care about are in xhci_wait_for_event()
<marcan>
today I did the "make it work" part of the kernel side
<marcan>
next time I will do the "make it fail safe" part
<marcan>
that's the interlock thing
<kettenis>
one issue is that some of the callers expect that it always returns a valid pointer, whereas there is a "return NULL" in that function
<marcan>
in principle in the state it's in now, it can be tested end-to-end with pipewire and such, it's just that there is nothing keeping the speakers safe if the safety daemon dies
<marcan>
(also the daemon is missing idle catch-up but that just means it's too conservative)
<marcan>
kettenis: ack
<kettenis>
the issue has been on my radar since forever but 1) it never makes it to the top of the list of things for me to work on and 2) I don't seem to have USB devices that hit the issue
<marcan>
chadmed: practical issue: do you think we should have the kernel safe fallback volume cap global, or per-speaker?
<marcan>
global pros: the speakers remain in balance. global cons: quieter
<povik>
isn't there some quick workaround we can do, returning some scratch structure from that function?
<povik>
just so we stop users hitting boot loops today
<marcan>
I'll fix this before the next update
<marcan>
I guess this is why people pay me ;)
<povik>
marcan: i don't get in what sense keeping the speakers in balance is of advantage with the fallback cap
<marcan>
means it just gets quieter, not weird
<marcan>
but I'd defer to chadmed's opinion on that since he knows how that'd sound
<marcan>
also it would be mildly simpler to have a single global cap instead of per-speaker caps
<povik>
ah, i wanted to write it's weird to start with, without dsp
<povik>
but the fallback can be w/ dsp still
<povik>
yeah, then the balance makes sense
<marcan>
yeah, they're orthogonal
mlp has joined #asahi-dev
<sven>
marcan: at least someone else gets to share my usb pain :p
<marcan>
sven: this is worse, this is USB core stuff. you're lucky you just have to sequence PHYs :p
<sven>
that dwc3 mode switch race was pretty bad as well ;)
<marcan>
yeah but xHCI takes the standard level of USB insanity and wraps it in a mixed register/ring buffer/DMA interface ;)
<marcan>
I dread the day I get back to figuring out why dwc3 has broken port sleep...
<sven>
nhi/thunderbolt does that dma ring buffer thing as well but it doesn’t seem to be as bad xhci
<marcan>
fair
bps2 has quit [Ping timeout: 480 seconds]
<sven>
at least it’s mostly ring buffers there and not much mixing between registers and ring buffers
<sven>
though you ofc access registers of all the crap on the path to the device via those ringer buffer commands
<marcan>
right...
<marcan>
xHCI has lovely things like "the buffer is full message goes in the buffer"
<sven>
if you really want some pain you can always pick up fixing the pcie hotplug mess as well :>
<sven>
lol
mlp has quit [Read error: Connection reset by peer]
<j`ey>
xhci in m1n1 means that the only thing we'll need on the nvme is the m1n1 stage1/stub? (compared to usb booting now which needs stage2 and uboot on the nvme)
<marcan>
j`ey: yes, which is done automatically by bputil/kmutil
<marcan>
when your stub partition is on USB
<marcan>
so no repartitioning of nvme at all
<marcan>
i.e. it works like macOS on USB
<j`ey>
oh right, that's the thing where it copies it for you
<marcan>
yes
<marcan>
it basically does the actual bootability provisioning in iSCPreboot instead of the Preboot partition itself
<marcan>
so you end up with source files in Preboot (on USB) and the actual boot/ folder on iSCPreboot
<marcan>
this is already PoCed in expert mode, you can do a USB install of just m1n1
<marcan>
the funny thing is once it's all set up and the default boot partition, you can unplug the disk and it still boots into m1n1
<marcan>
because of course it's on NVMe :p
roxfan2 has joined #asahi-dev
roxfan has quit [Ping timeout: 480 seconds]
amarioguy has quit [Remote host closed the connection]
amarioguy has joined #asahi-dev
brolin has quit [Ping timeout: 480 seconds]
mlp has joined #asahi-dev
<maz>
marcan: not sure you're already aware, but the apple cpuidle driver screams like mad when used with lockdep.
<povik>
if only git blame had stream timestamps, that would then truly be suited to on-demand watching
brolin has quit [Ping timeout: 480 seconds]
brolin has joined #asahi-dev
mlp has quit [Ping timeout: 480 seconds]
yrlf has joined #asahi-dev
brolin has quit []
orowith2os has quit [Quit: Connection closed for inactivity]
<chadmed>
macan: i think the global limit as we do it now is fine. bumping up the amp limit to 18.5 dBmV gives enough volume to be ~the same as macos with dsp all applied
<chadmed>
in terms of safety when the daemon goes down then id suggest using the codec's hardware volume cut. setting the fallback volume limit at the kctl level will screw with peoples alsamixer settings
<chadmed>
but that will require macaudio to know about the codecs, which i dont think it can
<chadmed>
that can be fixed by having the daemon pull everything up to 100 when it starts but that makes it very desktop-centric and break UX for folks without sound servers which kinda defeats the purpse
<povik>
sure it can
<povik>
there's no pretense of macaudio working with any codec
<chadmed>
oh well if it can poke codec registers then yeah the hardware safe mode would be grand
<chadmed>
halves the output without changing values in the DVC register which means its totally transparent to userspace
<chadmed>
does the codec in the imac have a similar feature?
<povik>
it shouldn't poke the registers directly, but what's required can be exposed as a control from the codec which is toggled by the machine driver and can't be written from userspace
<povik>
the imac codec doesn't have ivsense, so it's removed from this discussion entirely
<chadmed>
oh ok that makes things easy
<chadmed>
but yeah having a control thats readonly from userspace works too
<povik>
maybe it can even be hidden, but that's another point to potentially have to argue out on the mailing list so why bother :-p
<povik>
let's go with the ASoC default of restricting things as little as possible
darkapex has quit [Remote host closed the connection]
chadmed_ has joined #asahi-dev
<chadmed_>
povik: having the control visible to userspace will be useful for diagnostic purposes imo
orowith2os has joined #asahi-dev
<eiln>
did surgery on stable diffusion & got the text encoder/decoder part working yesterday
<eiln>
turns out they didn't really add much in the ventura fw update
<eiln>
kept running out of ram in converting the image (unet) part from pytorch though
<eiln>
and ragequit lol
<eiln>
take 2 today, gonna try to split the model
nsklaus has quit [Ping timeout: 480 seconds]
lewurm- has joined #asahi-dev
lewurm`` has quit [Read error: Connection reset by peer]