<mxw39>
povik: hey! thanks for helping fix my 3.5mm jack on a j316 last time. I've got another question - it seems the alsa ucm config only works for a headphone with mic.
<mxw39>
the other day I plugged in a headphone without mic but the sound output device didn't appear
<mxw39>
I do have "cs42l84 2-004b: Detected bare headphone (no mic)" in dmesg so it likely is with userspace?
<mxw39>
editing the ucm conf file to remove the headset SectionDevice works for getting the headphone without mic picked up, but that seems more of a hack...
sadams0978 has joined #asahi
marvin24 has joined #asahi
marvin24_ has quit [Ping timeout: 480 seconds]
mxw39 has quit [Remote host closed the connection]
sadams0978 has quit [Read error: Connection reset by peer]
sadams0978 has joined #asahi
thelounge7571340 has joined #asahi
thelounge7571340 has quit [Remote host closed the connection]
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
sadams0978 has quit [Quit: Konversation terminated!]
<marcan>
cpufreq v3 sent
<marcan>
OK, so as for kernels: I'm going to merge in DCP, and also start merging in all the rust-for-linux downstream stuff so we can build with stub rust support
kenzie7 has quit []
<marcan>
then there will be two packages: linux-asahi-dev will have DCP and the rust stuff enabled
<marcan>
this is a wake-up call for other packagers: if you want the GPU driver when it's ready, better take care of the rust build infra now ;)
kenzie7 has joined #asahi
<tpw_rules>
elvishjerricco: ^ ?
<marcan>
arnd: expect a PR once the DT checker finishes running
thelounge7571340 has joined #asahi
thelounge7571340 has quit [Remote host closed the connection]
thelounge7571340 has quit [Remote host closed the connection]
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #asahi
Etrien_ has joined #asahi
guillaume_g has joined #asahi
Etrien has quit [Ping timeout: 480 seconds]
Etrien_ has quit [Read error: Connection reset by peer]
Etrien has joined #asahi
SSJ_GZ has joined #asahi
nepeat has quit [Ping timeout: 480 seconds]
<jannau>
marcan: any timeframe on merging DCP? I haven't tested current tree on a t600x laptop yet (downsides of using it as main computer) and it probably makes sense to squash some of the commits
<jannau>
I should have fixed all intermediate errors reported by the kernel test robot on intermediate commits after lina pushed them with gpu-wip
thelounge7571340 has joined #asahi
thelounge7571340 has quit [Remote host closed the connection]
<rkjnsn_>
marcan, does IRC support exempting users from the IP-address ban? If so, would you be willing to exempt “rkjnsn”, my primary (NickServ-registered) nick?
dviola has joined #asahi
julio7359 has joined #asahi
dianshi has joined #asahi
pjakobsson has quit []
chipxxx has joined #asahi
pjakobsson has joined #asahi
chip_x has quit [Ping timeout: 480 seconds]
thelounge7571340 has joined #asahi
thelounge7571340 has quit [Remote host closed the connection]
pjakobsson has quit [Remote host closed the connection]
danielnechtan has joined #asahi
pjakobsson has joined #asahi
chadmed_ has joined #asahi
davido has joined #asahi
davido is now known as capta1nt0ad
nepeat has joined #asahi
capta1nt0ad has quit [Quit: Konversation terminated!]
capta1nt0ad has joined #asahi
capta1nt0ad has quit []
danielnechtan has quit [Ping timeout: 480 seconds]
capta1nt0ad has joined #asahi
vx has quit [Quit: G-line: User has been permanently banned from this network.]
vx has joined #asahi
chadmed_ has quit [Quit: Konversation terminated!]
thelounge7571340 has joined #asahi
thelounge7571340 has quit [Remote host closed the connection]
capta1nt0ad has quit [Quit: Konversation terminated!]
capta1nt0ad has quit [Quit: Konversation terminated!]
capta1nt0ad has joined #asahi
capta1nt0ad has quit [Quit: Konversation terminated!]
capta1nt0ad has joined #asahi
kov has quit [Quit: Coyote finally caught me]
thelounge7571340 has joined #asahi
thelounge7571340 has quit [Remote host closed the connection]
chadmed_ has joined #asahi
<marcan>
capta1nt0ad: not in release kernels yet
<capta1nt0ad>
marcan: Oh, thanks for clarifying :)
chadmed_ has quit [Quit: Konversation terminated!]
capta1nt0ad has quit [Quit: Konversation terminated!]
capta1nt0ad has joined #asahi
thelounge7571340 has joined #asahi
thelounge7571340 has quit [Remote host closed the connection]
capta1nt0ad has quit [Quit: Konversation terminated!]
oi_wtf has quit [Quit: WeeChat 3.6]
oi_wtf has joined #asahi
int16h has joined #asahi
danielnechtan has quit [Ping timeout: 480 seconds]
thelounge7571340 has joined #asahi
thelounge7571340 has quit [Remote host closed the connection]
vmeson has quit [Quit: Konversation terminated!]
int16h has quit [Ping timeout: 480 seconds]
vmeson has joined #asahi
<rann>
Hi all, quick question: I heard there is a status page that lays out what works and doesn’t currently, but I can’t seem to find it. Anyone have a link?
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #asahi
<rann>
Thanks!
<rann>
I think I saw on HN that very recently suspend/resume was implemented; don’t see it explicitly mentioned on that page for M2 Air
thelounge7571340 has joined #asahi
thelounge7571340 has quit [Remote host closed the connection]
<rann>
Also, I see there's mention that speakers work for the M1 with a caveat about safe volume-levels; Are speakers not yet supported for M2?
kov has joined #asahi
<rann>
Another way to ask: is anyone here using the M2 Air? What are they big things that don't work yet?
<rann>
(any personal experience stories greatly appreciated)
Dementor has quit [Remote host closed the connection]
Dementor has joined #asahi
<j`ey>
webcam is a big one, if its important to you
<j`ey>
GPU too of course
<rann>
Not too important for me + saw it's wip, which is positive; what's the story with the GPU? I saw the rather amazing news about GL ES 2.1 100% passing tests w/ the latest userspace + rust kernel driver; is that something that is just a pacman -Syu away, or does one need to do some custom kernel build dances to make that happen?
<j`ey>
yeah you need to build the kernel + mesa yourself currently
<rann>
fair enough!
<jannau>
also only m1 so far
<j`ey>
jannau: do you know about speakers on m2?
<rann>
ah good point; want to take the plunge and get an m2 as experimental linux 2nd-daily-driver (i.e., will use it extensively, but won't have to depend on it, stuff can break, not-on-my-critical-path)
<jannau>
unsafe and already broken one macbook air
<jannau>
m2 gpu/dcp support is probably just a few weeks behind
bestouff has quit [Read error: Connection reset by peer]
bestouff has joined #asahi
<rann>
jannau: what makes the speaker stuff unsafe? what needs to be in place for the driver to have a safety limit for volume and do you happen to know the status on that?
sjasin has joined #asahi
<marcan>
it's not just volume limits, we need a speaker safety model which computes voice coil temperature based on voltage/current feedback
<povik>
or rather it *is* volume limits, but dynamic
<marcan>
safe volume limits would give you crappy speaker volume (especially on the tweeters)
<rann>
marcan: is this typical/specific to mac? does other sound-hardware like intel-hd-audio or ac97 do this kind of stuff in hardware or did the peeps who did those drivers also have to handle this?
<ar>
rann: on many relatively modern x86 laptops on linux your laptops speakers will be quieter than on windows, because on windows they do that safety stuff in software
<rann>
ar: that's true actually, I never realised this stuff might be the reason
<marcan>
also almost every other laptop sounds worse than these macs
<marcan>
apple are pretty much the only laptop vendor actually trying hard with speaker/DSP quality
<rann>
true that
<marcan>
to the point where I showed up at the Apple Store with blown tweeters and the Genius couldn't tell
<marcan>
because just woofers sound better than most laptops anyway
<marcan>
I had to drag him to the showroom floor and do a side by side comparison with an identical, intact unit
<rann>
ahahah
<rann>
What is VISENSE?
<marcan>
voltage/current sense
<rann>
Is it trivial to connect bluetooth headphones? I suppose these would theoretically work (I have a couple of headphones, B&W PX-7's I use with Void Linux on my current laptop and desktop systems)
julio7359 has quit [Read error: Connection reset by peer]
julio7359 has joined #asahi
<marcan>
yes, though wifi coexistence is a bit questionable right now. don't use the LDAC codec if supported, and ideally use 5GHz WiFi simultaneously
<marcan>
YMMV depending on the specific device, I have some that work quite well and others not so well (it's a known issue that we're missing commands to prioritize audio streams properly)
<rann>
Right; actually, I had the wifi-coexistence issues with realtek wifi 2.4ghz + bluetooth also; afaict only intel and atheros do that stuff right
<rann>
s/realtek/mediatek mt7921/g
<rann>
w/regards to suspend/resume; I caught a thread on HN that mentioned that is working (preliminary) now; is that right? S3 or something equivalent on M2 also?
<j`ey>
s2idle is what is working
<marcan>
"S3" is technically supported by the hardware but not very useful on modern SoCs because they save power by default
<marcan>
s2idle just means some hardware shuts down and your machine is quiesced into being idle
Gaspare has joined #asahi
<rann>
right
<rann>
That sounds very usable
<j`ey>
and the last s2idle fix was wifi, which marcan did last week
<marcan>
yes
<j`ey>
(and just a broadcom issue, not apple related)
<marcan>
so with that, M1 Air idle time is 18h; with DCP merged in, 30h.
<marcan>
and the next big improvement will probably be when we get around to implementing the CPU deep idle thing
<rann>
Is there a an issue that tracks cpu power scheduling/scaling where I can read up on the status on that?
<marcan>
all that is supported properly already
<marcan>
it's just the second deep idle state that is not, and the only reason it isn't is bureaucratic
<marcan>
implementing it in Linux is trivial, but not upstreamable
<rann>
(I'm seriously impressed with how many things are working already, it's really something)
<marcan>
and for technical reasons we need to cook up a custom PSCI interface because these machines can't support standard PSCI
<rann>
Why is it not upstreamable?
<marcan>
because upstream will reject custom cpuidle implementations on arm64
<marcan>
since it's all supposed to use PSCI
bestouff has quit [Ping timeout: 480 seconds]
sjasin has quit [Remote host closed the connection]
<marcan>
cpufreq does work fine, I just sent v3 for upstreaming a few hours ago (that has worked fine for like a year now, just not upstream because it took a while to figure out the "right" way to do it)
<marcan>
you don't get boost states as a consequence of the deep idle thing, since they require it
<marcan>
but that will automatically work once deep idle works
<rann>
So, as I understand it, Apple M* does support PSCI, but not in a compatible way so that it works like CONFIG_ARM_PSCI can handle it?
<marcan>
(boost meaning 3.2GHz instead of 3GHz, not exactly a massive difference)
<marcan>
no, there is no PSCI
<marcan>
the problem is standard PSCI requires the existence of a supervisor or hypervisor
<marcan>
and M* chips do not support supervisors
<rann>
right
<marcan>
and doing it in a hypervisor would break KVM since it'd need nested virt which M1 does not support (M2 does) but it's also a terrible idea
<marcan>
so we need a third option, the idea is cooking up a standard for PSCI-over-UEFI-Runtime-Services
<marcan>
but cooking up such a standard is preferable to an ad-hoc cpuidle driver, since other platforms can use it (I think there's at least one other with a similar problem)
<povik>
so you can deep idle cores selectively, and that will be what kernel does based on workload?
<marcan>
yes, the kernel already knows how to do idle states
<povik>
good kernel
bestouff has joined #asahi
<marcan>
it just needs a driver for it and the only upstream-approved driver for this on arm64 is psci
<povik>
you can wake up by any ordinary interrupts?
<marcan>
yes, it's just another idle state, the only difference is it loses the GPR contents except SP/PC, so you need a save/restore around the wfi
<marcan>
and presumably it has higher latency
<marcan>
macos actually just lets the cpus do some heuristic magic and decide what idle state to enter themselves
<povik>
ok, good
<marcan>
linux probably prefers to control it itself
<marcan>
also this is part of how to enter "S3" (AIUI you set things up to go into proper sleep, then deep-WFI all cores)
<marcan>
not sure if something "magic" happens at that point or if it's just a consequence of the design that "S3" isn't much more than deep WFI as far as the CPUs are concerned
<rann>
marcan: how/why would it be possible to implement this with a hypervisor that supports nested virtualization (and it sounds crazy to me also, but why do you think its a terrible idea)
<marcan>
PSCI supports hypervisors, that much would just work
<marcan>
but it's a terrible idea because first it would have to be M2+ only, and second because nested virt is stupidly complex to implement and has nontrivial overhead
<rann>
fair enough!
<marcan>
m1n1 implements a research hypervisor but I am not adding nested virt to it so people can do crazy stuff like this :p
<j`ey>
and it wouldnt work on m1 anyway
<rann>
right, good poinst
<rann>
just to verify my own understanding: you would in such a case implement a psci device/interface in m1n1 so that when linux boots on top of that, it could use that (through CONFIG_ARM_PSCI presumably). To implement that, you would need to use nested virt which is madly complex and m2 only. Did I grasp it correctly?
brad_ has joined #asahi
<marcan>
we could use normal virtualization but then that would break virtualization in linux
<marcan>
which is obviously undesirable
<marcan>
and the only way to keep both things is NV
unicordian has quit [Ping timeout: 480 seconds]
Moprius has joined #asahi
<rann>
right, so psci over uefi runtime services is then a psci device which lives in m1n1 and somehow utilizes uefi runtime services to do what it needs to do, without a dependency on any kind of virtualization?
<marcan>
yes
<marcan>
u-boot provides the UEFI bit
<marcan>
the plan is to have an ad-hoc hook from u-boot back into m1n1 (linux doesn't have to care about this) so m1n1 can implement the actual PSCI handler
<marcan>
and then u-boot exposes it over UEFI
<marcan>
this does mean cpuidle will only work when booting via u-boot (which is the normal way, but not how I usually boot during development), but that's not a big deal
<rann>
fair enough
<marcan>
the issue is how PSCI calls are made
<marcan>
supervisor -> SMC instruction
<marcan>
hypervisor -> HVC instruction
<marcan>
UEFI runtime services -> just jump into UEFI
<marcan>
i.e. we're making a standard for PSCI that does not involve a privilege change
<marcan>
since there is no higher privilege to go to that we can use
<rann>
when within uefi, you can essentially do whatever you want (highest privilege)?
<marcan>
yes, but because the kernel is the same privilege, there is no change
<rann>
right
<rann>
that's smart as hell
thelounge7571340 has joined #asahi
<marcan>
it's hypervisor privilege (EL2)
<marcan>
(since that's how the kernel runs to support KVM)
<marcan>
normally PSCI would be implemented in an EL3 supervisor, but these chips don't do EL3
thelounge7571340 has quit [Remote host closed the connection]
<marcan>
so it's either come up with a new standard to stay in EL2, or drop the kernel to EL1 and then you lose virtualization support
Moprius has quit [Read error: Connection reset by peer]
<j`ey>
I think we need some kinda generic-ish u-boot device tree properties, to tell u-boot what extra regions it should map into the uefi memory map
<j`ey>
(at least that's how my PoC works)
Moprius has joined #asahi
<null>
TBH, I don't think we should try to have a non={HVC,SMC} PSCI here, since we *cannot* do most of the things PSCI functionally does, and we will need a very different contract for handing over CPU state
<null>
I'd much rather we had a generic SMP spin table-ish mechanism that allows us to hand the CPU back, with a well defined CPU state
sadams0978 has joined #asahi
sadams0978 has quit []
<null>
WindowPain: 17
<null>
ugh, sorry, tab completion for /win 17 went wrong
<Tramtrist>
happens to the best
<j`ey>
null: how does cpuidle work currently for spintable stuff, or does it not?
<null>
There's no idle or CPU-off for spin-table today
<null>
(which is why I said "ish")
<null>
PSCI and UEFI runtime calls have quite different behaviours that need to be considered (e.g. requisite TTBR management and concurrency/mutual-exclusion), and I'm really not keen on tying a "pretend" PSCI implementation behind UEFI calls as I suspect it's going to cause longer-term maintenance pain and cause us to overlook issues if we're lax on specifying how it's supposed to work (e.g. if/when/how CPU state
<null>
gets reset, the state of CPUs at handover points, etc).
<null>
Many nice properties of PSCI stem from having the exception boundary, so if we don't have that, we need to reconsider how everything's supposed to work
<WindowPain>
null: I was literally just thinking I chose a weird enough name so no one would accidentally mention it :D
<null>
WindowPain: I'd hoped that too, until I started getting messaged by badly written IRC bots
bestouff has quit [Ping timeout: 480 seconds]
bestouff has joined #asahi
thelounge7571340 has joined #asahi
thelounge7571340 has quit [Remote host closed the connection]
<j`ey>
null: Im thinking of basically some sort of reserved region memory where (m1n1 / whatever) can live and then I guess you jump to it (mmu off?). and then it handles similar commands to PSCI_CPU_OFF etc
<null>
Sure; that's roughly inline with what I was thinking
<null>
(MMU off, definitely, unless it's going to promise to save/restore everything for uss)
<marcan>
null: we should probbly move to #asahi-dev
<null>
marcan: tbh, I think this is one for the mailing lists, since there are others who care who don't sit on IRC, but I'll go over there now you've poked :)
bestouff has quit [Read error: Connection reset by peer]
bestouff has joined #asahi
eroux_ has quit [Read error: Connection reset by peer]
eroux has joined #asahi
Moprius has quit [Ping timeout: 480 seconds]
bestouff has quit [Ping timeout: 480 seconds]
bestouff has joined #asahi
thelounge7571340 has joined #asahi
thelounge7571340 has quit [Remote host closed the connection]
bcrumb has quit [Remote host closed the connection]
bcrumb has joined #asahi
<bcrumb>
i will add more to this tomorrow... it is not done, at all .. it needs the actual luks set -upping, but this is just cryptsetup according to asahi rules
<bcrumb>
*arch rules
<bcrumb>
from the minimal OS you set a up a cryptsetup partition and then cp the minimal OS files inside
<idc>
cool
<bcrumb>
once open
<bcrumb>
also the plasma env is useful to configure locale and then when you boot from usb you can load the keymap