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
eiln has joined #asahi-dev
nsklaus has quit [Ping timeout: 480 seconds]
eiln has quit [Remote host closed the connection]
gabuscus has quit []
pthariensflame has joined #asahi-dev
pthariensflame has quit []
gabuscus has joined #asahi-dev
Armlin has joined #asahi-dev
sarucchi has joined #asahi-dev
greguu has quit [Ping timeout: 480 seconds]
mlp_ has joined #asahi-dev
mlp_ has quit [Quit: Page closed]
martinl has joined #asahi-dev
martinl is now known as mlp
mlp has quit []
martinl has joined #asahi-dev
martinl has quit []
mlp has joined #asahi-dev
Armlin has quit [Ping timeout: 480 seconds]
mlp has quit [Ping timeout: 480 seconds]
cylm_ has quit [Quit: WeeChat 3.6]
mlp has joined #asahi-dev
<jannau>
chadmed: updates only when display brightness is changed sounds like what I would expect under X11
<jannau>
does the preview work for you? there should be noticeable changes while you hold the slider / "Color emperature preview" is displayed
cylm has joined #asahi-dev
<chadmed_>
jannau: no the preview only updates when i change the brightness. then when it does, the cololur shifts to that lurid yellow-green that it has when it's active. this is at 2500K.
cylm has quit [Quit: WeeChat 3.6]
<jannau>
are you sure it's plasma/wayland? I'm not aware how you could disable atomic_swaps with plasma/wayland. you should see 1 dcp_flush for each screen update
<chadmed_>
unless running dbus-run-session startplasma-wayland actually launches xorg then yeah its wayland :P
<jannau>
can you check? I guess it's fine if it launches kwin_wayland. kwin 5.27.4.1 here
<chadmed_>
yeah its definitely kwin_wayland
Armlin has joined #asahi-dev
bps has joined #asahi-dev
chadmed_ has quit [Quit: Page closed]
Armlin has quit [Quit: Konversation terminated!]
bps has quit [Ping timeout: 480 seconds]
<jannau>
chadmed: strange. can you try to start the session via sddm, gdm, ...? not sure why that would make a difference though.
<jannau>
night color on my intel work notebook looks different, older KDE there tough
<sven>
damnit.. rebased the thunderbolt mess to 6.4 and broke something and now I’m back to the first plug just not working
<sven>
the second time i
<sven>
*the second time works though
<sven>
(and any further attempt as well)
sarucchi has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
bps has joined #asahi-dev
psykose has quit [Remote host closed the connection]
pbsds is now known as Guest810
pbsds has joined #asahi-dev
Guest810 has quit [Ping timeout: 480 seconds]
brolin has joined #asahi-dev
timokrgr has quit [Quit: Ping timeout (120 seconds)]
brolin has quit [Ping timeout: 480 seconds]
<marcan>
sven: unsupported kernel BS aside, someone on Reddit mentioned some 10gbps device not working (works via a 5gbps hub)
<marcan>
it's starting to smell like the audio codec issues we had, i.e. something is fundamentally broken in a way that causes races or undefined behavior, and that randomly gets better or worse with different kernels and configs
<sven>
yeah, I think the atcphy vs dwc3 setup is in the wrong order in asahi-dev right now
<marcan>
sounds like the codec shutdown vs clock shutdown was in the wrong order :D
<marcan>
(I'm actually surprised that worked as often as it did)
<sven>
which probably also explains that commented out part in atcphy that’s waiting for some bit that never clears with my code
<marcan>
ha!
<marcan>
yeah that might explain some things
<marcan>
I encourage you to use as many horrible hacks as you want to make it work, because at this point it's more valuable to 1) make everything work, then 2) figure out how to fix the Linux subsystem mess once we know exactly how it has to work
<sven>
yeah, my plan is to just skip typec-altmode
<marcan>
actually from what I saw of ASoC, it might be an interesting model to look at for how to design an abstraction that somehow works for a million disparate SoCs and codecs
<sven>
that entire thing is not a great fit for these SoCs
<marcan>
modulo us getting stuff wrong it actually looks pretty decent as kernel abstractions go
<sven>
and google does something similar hidden away in platform for some chromebook(?) thing
<marcan>
heh, lovely
<marcan>
I wonder if this is going to be another mailbox or it actually makes sense to unify it at some point
<sven>
typec itself is fine, typec-altmode isn’t a great fit
<sven>
because that subsystem assumes that the cpu does all the negotiation with these usb pd messages
<marcan>
is that the one that's mostly intended for x86 machines with firmware doing everything?
<marcan>
oh the other way around
<marcan>
yeah
<marcan>
doesn't really work here
<sven>
yeah, and chrome just skips all that and directly uses the typec mux/switch stuff
<sven>
that will also work for us
<marcan>
wfm
<sven>
and the typec maintainer even reviewed all of that so I don’t even see many issues getting it upstream
<marcan>
sgtm
<marcan>
and yeah I'm getting the feeling very few other platforms handle this and they're all too particular to unify sanely anyway
<marcan>
you know we have those retimers on i2c right?
<marcan>
some day we're going to have to poke them for something I bet
<sven>
not more than what typec mux/switch already does, yeah
<marcan>
it's just going to be more and more of a mess and hard to abstract out more
<marcan>
ALSA also has that layer (macaudio which ties everything together and makes it sane)
<sven>
we just need something like typec mux/switch for thunderbolt as well but that’s easy enough
<sven>
to essentially notify pcie, dwc3 and dcpext when a tunnel state changes
<marcan>
I love how apple just gets to not design anything and just invented DT-specified function calls for this
<sven>
that’s all automatically done for x86 but here we have to do it manually
<marcan>
need a hook from driver A to driver B? no problem, add a function!
<sven>
yeah :D
<sven>
or how that gpu mmu is a separate adt node with essentially a stub kext that just calls back into the main kext iirc
<marcan>
I don't think people appreciate just how much clunkier and underdesigned xnu is compared to linux
<marcan>
even with linux's bad subsystems sometimes
<marcan>
the amounts of hacks in there...
<sven>
it helps that they run xnu on like 20 different configuration and just compile it separately for those
<marcan>
sven: yeah and I bet that's so the rtkit driver can use it for buffers
<marcan>
well it's 4 on ARM right now but yeah
<marcan>
well 5 with vmapple
<marcan>
they haven't figured out how to stop using #ifdef everywhere :p
<sven>
ah, right, same kernel for all t8103 models, etc.
<marcan>
yeah
<marcan>
mac13g, mac13j, mac14g, mac14j
<sven>
well, there’s also the iPhone/iPad SoCs
<marcan>
yeah of course
chadmed has quit [Quit: Konversation terminated!]
<sven>
so maybe 10 or so different variants?
<marcan>
and then there's that raspberry pi target :D
<sven>
lol
<marcan>
I'm still annoyed the hypervisor is sekrit, like not even distributed as object files
<marcan>
self-compiled XNU = no hv
<marcan>
but I can sort of understand why, because they save/restore all the secret registers in there lol
<marcan>
ARM HVs are boring enough a significant part of the entire HV is touching secret stuff
<marcan>
(and then of course it calls into pmap/gl to actually switch to the guest etc)
chadmed has joined #asahi-dev
<marcan>
was nice confirming basically everything we already knew though, I didn't find anything unexpected in there other than a pile of official register names for registers we'd already roughly identified
<marcan>
all the extra SPRR stuff is curious but likely nobody cares enough to figure out what exactly it all does, since it doesn't really affect us
<chadmed>
jannau: is it at all possible that we are advertising the wrong colour space or pixel format to plasma
<chadmed>
colour management is just completely broken which sucks but i cant think of much else to cause it to look this subtly off while still "working"
<j`ey>
marcan: I'm working on the PIE/POE stuff which is SPRR but official
<marcan>
ooh nice :D
<marcan>
I do wonder, once official versions of these things get supported, how likely it is we can convince upstream to take alternate codepaths for the pre-standard ARM versions
<marcan>
*Apple versions
<marcan>
especially for stuff that we really care about
<marcan>
I was going to stream speakers today but maybe I should try to add a prctl for TSO?
<marcan>
I'm sure that will greatly annoy maz and make the FEX folks very happy :p
<marcan>
(TSO is confirmed to be a *big* deal for FEX so we are definitely implementing it, sorry maz)
<maz>
marcan: why should I care?
<marcan>
I thought you didn't want impdef arch stuff ;)
<j`ey>
marcan: stream prctl! (Im sure it wouldn't take more than an hour or something, youre fast)
<maz>
marcan: as long as this stuff never gets near my machines and that I don't have to support it...
<marcan>
maz: well obviously we'll be pushing this upstream because it's a *BIG* performance deal
<marcan>
hence annoy you
<marcan>
(you know I'm not a fan of having to do this, but the benefits are too big to ignore)
<marcan>
OTOH it's not exactly the ugliest thing ever, it's flipping a bit in a documented, IMPDEF-defined register (ACTLR_EL1)
<maz>
marcan: you don't have to sell it to me, only to the arm64 maintainers. the one thing I don't want is to expose something that isn't architectural to *guests*.
<marcan>
oh yeah I don't care about KVM, at least not yet
<marcan>
in a hypothetical future where FEX runs as a 4K guest we can revisit that idea, though for that it would be sufficient to enable TSO guest-wide for most purposes
<marcan>
but that future may never come
<marcan>
so you're safe for now ;)
<j`ey>
looks like KVM ignores writes to ACTLR_EL1 currently
<maz>
we already save/restore ACTLR_EL1, so this has zero impact on KVM.
<marcan>
as in save/restore the host's value, right?
<maz>
j`ey: sure? thad'be a bug.
<j`ey>
maz: not sure! just looking at access_actlr, and it has if (p->is_write..
<marcan>
apple actually has ACTLR_EL12 as an impdef, so the guest wouldn't even see the host's ACTLR I think (it got the VHE treatment)
<marcan>
but that shouldn't affect KVM much, since I think TIDCP makes it trap anyway
<maz>
marcan: I don't think actlr_el12 in the TIDCP range.
<marcan>
oh a guest wouldn't even see that one
<marcan>
I mean ACTLR_EL1 from a guest should trap I think
<marcan>
(which maps to apple's IMPDEF ACTLR_EL12 from EL2)
<maz>
but j`ey is correct, we seem to be missing ACTLR_EL1's save/restore, descpite what I said earlier.
<maz>
I wonder whether that's a regression.
<maz>
nah, TACR.
<maz>
that's why.
<maz>
so enabling it wouldn't be a big deal, and probably easy enough to track if the VMM enables it.
bisko has joined #asahi-dev
<maz>
(enables the feature requiring context switching in the guest, that is).
<marcan>
ah it's a separate bit for that one, yeah
bps2 has joined #asahi-dev
bps has quit [Read error: Connection reset by peer]
nsklaus has joined #asahi-dev
jn has quit [Quit: No Ping reply in 180 seconds.]
jn has joined #asahi-dev
mlp has quit [Read error: Connection reset by peer]
<jannau>
don't ask me why that would make a difference though
wonjongbot has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
wonjongbot has joined #asahi-dev
roxfan2 has quit [Ping timeout: 480 seconds]
roxfan has joined #asahi-dev
mlp has joined #asahi-dev
wonjongbot has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
brolin has joined #asahi-dev
korreckj328 has joined #asahi-dev
brolin has quit [Ping timeout: 480 seconds]
korreckj328 has quit [Remote host closed the connection]
mlp has quit [Ping timeout: 480 seconds]
mlp has joined #asahi-dev
<chadmed_>
jannau: ah yup figured it might be some pixfmt shenanigans. ill test and confirm later
chadmed_ is now known as chadmed
<povik>
re the ASoC model, i have been thinking myself about the approach taken there, that the interfaces are a bit underspecified and that the focus is on codec/DSP/platform combinations that actually see the day of light somewhere
<povik>
on the other hand, 'us getting stuff wrong' seems to me to be the result of the relaxed model
<povik>
i.e. that there are details in play that you can't get anywhere else but dvelving into the code, which there is a nontrivial amount of
<povik>
but in a way the model could be serving its purpose
<chadmed>
i still remember the DPCM discussion on the mailing list. i dont think what you ended up having to do is actually documented anywhere
<povik>
yeah, that for sure wasn't documented
<povik>
knowing the code it makes sense
<chadmed>
yeah of course but it would be handy to have even a "the correct way to implement these devices is with this framework, which is exemplified by [driver]"
<povik>
most likely
brolin has joined #asahi-dev
mlp has quit [Ping timeout: 480 seconds]
mlp has joined #asahi-dev
wonjongbot has joined #asahi-dev
mlp has quit [Ping timeout: 480 seconds]
wonjongbot has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
mlp has joined #asahi-dev
mlp has quit [Ping timeout: 480 seconds]
bps2 has joined #asahi-dev
mlp has joined #asahi-dev
wonjongbot has joined #asahi-dev
mlp has quit [Ping timeout: 480 seconds]
mlp has joined #asahi-dev
eiln has joined #asahi-dev
Hibyehello has quit [Ping timeout: 480 seconds]
mlp has quit [Ping timeout: 480 seconds]
wonjongbot has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
nsklaus has quit [Ping timeout: 480 seconds]
roxfan has quit [Ping timeout: 480 seconds]
bps2 has quit [Ping timeout: 480 seconds]
roxfan has joined #asahi-dev
psykose has joined #asahi-dev
psykose has quit [Remote host closed the connection]