<Dcow>
prepared apple-cpufreq for power-profiles-daemon, so now we (I) can switch governors in DE ;)
<Dcow>
backend*
<Dcow>
it's syncing all the cpu clusters to one of values: performance, schedutil, powersafe
<Dcow>
marcan: would you like to include this to release?
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Dcow>
or asahi at all
<marcan>
dcow: not now, maybe later
<Dcow>
ok, I need to sleep now, then I'll cleanup code and push somewhere
<Dcow>
also, is schedutil is good choice for "Balanced" preset?
<marcan>
probably
<Dcow>
there are also "conservative ondemand userspace" so I wasn't sure about that.
<chadmed>
all the governors kinda suck with heterogeneous systems except for schedutil, especially once we sort out EAS
<nicolas17>
dcow: what is that screenshot=
<Dcow>
nicolas17: Asahi Linux with Gnome + switchable power profiles due to my work
<nicolas17>
ah gnome, that looks suspiciously similar to macOS control center in overall design :P
<nicolas17>
chadmed: I bet there's a bunch of userspace work to be done too, like hinting the scheduler to run "background" tasks on e-cores
<Dcow>
chadmed: I am not that aware of overall state, but I get used to switch power profiles from UI on my previous laptop. Also, in lina's streams she get valuable performace boost after switching to 'performace' (I think schedutil is default one). So, there is difference, at least right now.
<nicolas17>
speaking of which, how can I manually make a process run only on e-cores or only on p-cores? CPU affinity?
<nicolas17>
I had cases like a queue of task X to run on each of a dozen files, and when each is done, enqueue task Y to run on the result of that... and if X is slower than Y, then the Y queue could starve, and maybe running X on p-cores and Y on e-cores could improve overall utilization
<Dcow>
I'll clean up and push later, but in case someone very intrested or want to review (my C is rusty, so ...)
* Dcow
going to sleep...
mac456 has joined #asahi-dev
<marcan>
really the only two options that make any sense are "schedutil" and "performance"
<marcan>
"performance" for when you just want to burn power
<marcan>
"powersave" is pretty much useless unless you literally want to throttle apps into being slower to save some battery, which is rarely an actual useful choice
<marcan>
it only works if you're actively using the CPUs. if you're just doing normal bursty desktop work, "schedutil" is likely to save more power.
<marcan>
ondemand/conservative are legacy stuff for ancient platforms and are completely useless here
<chadmed>
the other thing is that only schedutil takes into account each core's capacity for work. all the others have no awareness of heterogeneity which makes them doubly useless here
<marcan>
yup
<marcan>
well, this is just cpufreq, so "powersave" is perfectly appropriate either way :p
<marcan>
er sorry
<marcan>
"performance"
<marcan>
I assume the scheduler still knows about core capacity even if you use that cpufreq governor
<chadmed>
yeah
<chadmed>
but youre mad if you daily performance, especially with energy prices the way they are :P
<marcan>
eh, it might make sense for a build server or whatever, it's not like it disables wfi
<marcan>
I could see myself using it on a desktop, especially with audio involved
<marcan>
definitely not on battery though
<marcan>
ok, I think we're going to punt the jack initial hang thing until later, it's trivial enough to just include in the release notes
<marcan>
let me fix the calamares wallpaper and spin new images
<marcan>
ohh I just noticed something, the trackpad isn't going into Mac mode on M2
<marcan>
I think it's always been like that
<marcan>
libinput config thing
<marcan>
let's see
<tpw_rules>
what is the pulseaudio patch about?
mac456 has quit [Ping timeout: 480 seconds]
<tpw_rules>
(also does this mean the kernel keeps the speakers safe now?)
<chadmed>
broken UCM handling and no the safety situation hasnt changed since the m2 machine let the magic smoke out
<tpw_rules>
i guess i'm not sure what difference that makes to the average user
<marcan>
the pulseaudio patch unbreaks jack hotplug volume handling
<chadmed>
the UCM stuff is needed for headphone jack hotplug switching and to automatically set some stuff in alsamixer so that users dont need to faff about in it
<tpw_rules>
so it's only really for those brave enough to risk their speakers
<marcan>
??
<marcan>
no it's for everyone with headphones
<chadmed>
no its needed for pulse to know where the hardware mixer is for the headphone jack and stuff like that too
<marcan>
I'm confused, we've been talking about the headphones jack this whole time lol
<tpw_rules>
i guess i'm thinking what is there to switch if only the headphone jack works. but there is stuff like bt i guess
<marcan>
nothingness
<marcan>
when nothing is plugged in you get a dummy output
<marcan>
but also it is needed to handle volume controls properly
<nicolas17>
I just realized didn't ever try audio on asahi
<nicolas17>
ah, the only MTP I know is Media Transfer Protocol which seemed very irrelevant :D
<marcan>
Multi-Touch Processor is my best guess
<marcan>
spooky, my iMac now dims when idle for a while
<marcan>
calamares background fixed
<marcan>
xHCI is broken on the iMac though... wonder what's up with that
<marcan>
worked after a cold boot. I know we bork with drivers lacking firmware update. I really need to figure out how to cold reset it properly...
<marcan>
oh, it fails after a reboot. ouch.
<marcan>
okay.
<marcan>
we need to fix that.
mac456 has joined #asahi-dev
<marcan>
... and it works with the hypervisor?
<marcan>
and not outside it, lovely
nicolas17 has quit [Quit: Konversation terminated!]
capta1nt0ad has quit [Remote host closed the connection]
Graypup_ has quit [Quit: meow]
Graypup_ has joined #asahi-dev
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<marcan>
let's see if this helps...
Graypup_ has quit [Quit: meow]
Graypup_ has joined #asahi-dev
mac456 has quit [Ping timeout: 480 seconds]
kode54 has quit [Quit: Ping timeout (120 seconds)]
kode54 has joined #asahi-dev
cylm has quit [Quit: WeeChat 3.6]
<marcan>
looks like it's fixed, we were missing some busy polling
<marcan>
ok. time to build new images, and write a blogpost?
weitcis has quit [Remote host closed the connection]
bisko has joined #asahi-dev
weitcis has joined #asahi-dev
weitcis_ has joined #asahi-dev
weitcis has quit [Read error: Connection reset by peer]
weitcis_ has quit [Remote host closed the connection]
<marcan>
images up
SSJ_GZ has joined #asahi-dev
<sven>
marcan: uh, yes. dcpext is still highly unstable
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<marcan>
sven: it was just the entry in the device tree, which I think jannau had in a bits branch at some point? I wasn't sure why that was there
<sven>
yeah, I’d just remove that for now
<sven>
someone needs to start daily driving that thing to get it stable
<sven>
and I’m kinda afraid that someone will be jannau and me
StupidYui has joined #asahi-dev
<phire>
by dcpext, you mean displayport over usb?
<phire>
if so, I'm tempted to start daily driving
<sven>
it’s gonna be quite horrible fwiw
<sven>
and you get to fix lots of bugs
<phire>
could be worth it, if I get to use a larger display :)
<phire>
do most of the bugs will occour around boot, connect, disconnect and screen sleep/wake? Or is it just flakly 100% of the time?
<sven>
for me it was mostly in those cases but I haven’t even used this with anything more than a tty yet
<marcan>
calamares/touchpad fixes smoke tested on M2
<marcan>
if nothing else comes up, I think we're good for release, I just need to write the progress report
bisko has joined #asahi-dev
<phire>
though, more important for me and my daily driving is 4k pages + gpu. I haven't caught up with the current situation, but my understanding is those are on completly seperate expermental branches, and probally fundementally incompatable without hacking at mm?
<marcan>
gpu uses the shmem allocator which is deep kernel code assuming the page size, so fixing that will probably be "fun"
<marcan>
I guess lina could either drop the shmem helper entirely or hack on a flag to somehow ensure 16K backing pages, but I'm not even sure how practical that is given the idea of shmem
<marcan>
so maybe it needs an entire new GEM helper/allocation backend
<sven>
I guess the gpu mmu only does 16k as well?
<marcan>
yeah
<phire>
yes. But we do control all allocations for it
<sven>
phire: the 4K patch is limited to dma-iommu
<sven>
it’s quite neat actually. I just haben rebased it because people kept using it and preparing it for end users despite me telling them not so
<sven>
*havent
<phire>
and you would rather a better solution exists than just rebasing it?
<phire>
marcan: I guess in the long term, shmem will need to be fixed to support mixed page sizes
<marcan>
phire: if we make it easy for people to use 4K kernels people will stop fixing broken 16K apps
<marcan>
I don't want to do that until the GPU stuff is shipping and lina gets around to figuring out a solution for the page size issue
<marcan>
that's when 4K kernels will start to make sense
<marcan>
phire: and to be clear, the shmem stuff is literally tmpfs, so you're talking about making the kernel's core tmpfs/shmem code support some kind of page folio business / aligned allocations (it already supports huge pages but that's special), or replacing it with something else
<marcan>
not sure which one makes more sense
<marcan>
lina probably needs to talk to the DRM people about that
<phire>
guess I'd need to do so much research if I want to help push mixed page support. I haven't actually done any kernel dev in like 15 years, so I'm a bit lost
<marcan>
you mean like mixed userspace processes?
<phire>
well, each process has to be either 4k or 16k
<marcan>
yeah, that's... a big project
<marcan>
(and everyone related to MM I've casually mentioned that to recoiled in horror)
<phire>
I'm kind of with you that I want broken 16k apps to be fixed. But some apps are never going to support 16k pages, so I'm gready and want both
<marcan>
yes, but those apps are all foreign/emulated apps and 99% of that category is games and so there's no point until the GPU stuff is there and supports 4K pages
<mps>
sven: nice, where is your rebased 4K patch (I need sometimes to use f2fs and boot older kernels when working with mmc/sdcard for my arm SBCs)
<sven>
^— exhibit a why I don’t publish it
<marcan>
+1 month for 4K support?
<sven>
I’ve switched to exponential increase, so *2
<marcan>
:D
<mps>
F2FS developers still didn't reported any progress on fixing driver with 16K page size
<mps>
I can still boot old asahi kernel with 4K page size patch applied
<marcan>
maybe you should ask them about that then, instead of bugging sven about the patch
<marcan>
or maybe you should just use a VM for f2fs stuff
<mps>
I asked them but nothing worked yet
<marcan>
because F2FS is solidly in the "no excuse to be broken on 16K" list and I have zero interest in supporting or providing 4K support for that
<marcan>
so just please stop asking
<marcan>
if anything F2FS's continued brokenness is all the more reason to delay 4K support, because it means 16K-broken code still exists
<mps>
I don't ask sven to work on it (or you), just asked if it is published somewhere, nothing else
<phire>
is there any at all reason to support 4k pages within the kernel?
<mps>
I don'r like to 'force' anyone to work on anything
<mps>
s/don'r/don't/
<marcan>
no, other than the fact that 16K HW / 16K kernel / 4K user is a much harder problem than 16K HW / 4K kernel / 4K user
<marcan>
well, that and that the kernel's idea of page size is hardcoded
<marcan>
and we do want default distro kernels to work some day
<mps>
yes, I understand you, and because that I don't want to force anyone to work on my 'pet peaves'
<phire>
doesn't seem to be your pet peave. looks more like marcan/sven's
<mps>
for me everything else is quite fine for working machine
<marcan>
powerpc people said they failed at getting people to fix userspace for larger page size support. even Red Hat gave up on ARM I think, for desktop stuff.
<marcan>
we've actively gotten a bunch of things fixed
<marcan>
it's working, the pain is getting people to fix stuff
<marcan>
the result is a better ecosystem for everyone, and I'm in no rush to stop giving them reasons to improve ;)
<marcan>
so sorry, it's going to be 16K until we run out of software that doesn't support it that isn't an emulator of some sort
<mps>
of the programs I use and tried everything works very fine with 16K
arnd_ has quit []
arnd has joined #asahi-dev
MajorBiscuit has joined #asahi-dev
<chadmed>
im suspicious that no ones added new broken software to the list on the wiki. i feel like therell be a point that we hit a critical mass of users and that list will just explode with stuff
r0ni has quit [Remote host closed the connection]
<chadmed>
or, more likely, everyone just does everything through a browser these days and chromium is now fixed
MajorBiscuit has quit []
<dottedmag>
Isn't it pretty uncommon to rely on page size? allocators care, and jemalloc is fixed (so we might have a trickle of less-known software that embeds jemalloc), JIT-compilers care and they are fixed too. This leaves games/emulators.
MajorBiscuit has joined #asahi-dev
<chadmed>
youd hope but therell be some weird esoteric things
<chadmed>
even on the x86 side this sort of never-got-updated-to-work-with-the-spec type stuff comes up sometimes
<chadmed>
i spent about 8 hours trying to figure out why a brother printer driver would just silently drop print data and spit out blank pages a while ago and it turned out to be because their linux drivers, even for new printers, are 32 bit only
<chadmed>
this isnt documented anywhere and it felt like going back to the 2000s, having to google _just_ the right phrase to find the _one_ forum post that says "yeah you need lib32 or it just silently fails"
<chadmed>
therell be plenty of stuff like this that people will want fixed once there are users trying to run it
amarioguy2 has joined #asahi-dev
amarioguy has quit [Ping timeout: 480 seconds]
<maz>
all the 4k-only crap in a guest, problem solved.that's where I run emacs these days.
<marcan>
it's a seriously viable solution too, given what I've heard about upcoming GPU virtualization stuff
<marcan>
like you could seriously just run games in a thin VM and use 9p or whatever to share the filesystem and the GPU stuff to share GEM buffers with the host and it all probably will just work with the right amount of duct tape and feel like native apps
<marcan>
(tl;dr on the new gpu virt stuff if I understood it correctly: just run the native driver in the VM and paravirtualize the UAPI)
<maz>
as long as you don't trap too much, there is no reason why a VM would be too slow. device assignment solves that. you just get extra SW complexity to manage a stage-2 on the IOMMU side.
<marcan>
you'd trap for the equivalent of every guest GPU submission ioctl, which is already a trap anyway, so probably a not-terrible constant factor
<marcan>
maz: there's no stage 2 here, device assignment doesn't work
<maz>
hmmm. there is HW out there that doesn't require a trap on submission (the HW implements VFs to can be directly controlled by the guest).
<marcan>
(and is impossible to implement safely for this gpu)
<marcan>
but UAPI paravirtualization makes a zillion times more sense for this kind of use case
<marcan>
and can be implemented safely as long as you can map guest contexts to host contexts, since by definition at that layer you already need safe context isolation
<maz>
this is starting to look a lot like virtio-gpu
<marcan>
virtio-gpu is serialization AIUI
<marcan>
which means mesa runs on the host
<marcan>
this has mesa running on the guest
<marcan>
it just means each guest process looks like a host process as far as the GPU is concerned, and you can have as many VMs and guest processes as you want
<maz>
well, that's the portability vs performance trade-off.
<marcan>
yes, but this is in principle portable to most modern GPU drivers with little work, because it's based on the existing process isolation concept
<marcan>
I think the idea is that only the guest kernel would need changes, not guest userspace
<marcan>
and on the host side I think you can even get away with minor or no kernel changes depending on the driver? not sure
<marcan>
in principle it's just funneling an ioctl interface from the guest to the host
<maz>
the thing I really dislike about this is that you are creating a Linux-specific API at the hypervisor level. if the hypervisor needs to interpret this, that's a pretty large attack surface. mujltiply this by the number of CPU architectures out there...
<maz>
if, on the other hand, this is blindly forwarded to userspace, then I have no objection.
<marcan>
does the hypervisor even need to do anything?
<marcan>
qemu could just call the native ioctls
<marcan>
I'm not sure if there's some minor mm stuff to deal with, but I don't see much of a surface on the host hypervisor kernel
<marcan>
(other than the existing UAPI attack surface which... well, let's just say doesn't have a great track record on legacy GPUs, but that's already a big problem VMs or not, and maybe Lina's Rust driver will do better there)
<maz>
as I said, if this is just about a kick all the way down to userspace, and for userspace to peek at a shared buffer, there is 0 effort on the hypervisor side, which suits me.
<marcan>
I think so, yeah
<marcan>
I haven't read up on this in detail but AIUI all of the significant shenanigans would be in the qemu/guest kernel side, to forward those ioctls and manage buffer mapping
<marcan>
I'm not sure how mapping guest memory works? I think the GPU stuff just uses mmap(), so you'd need a way to forward such a mmap() on the host into guest IPA space (and then the guest would forward it into a given process' VA space)
<marcan>
that's about it for memory I think
<maz>
yeah, you'd need some scatter-gather mechanism for the GPU to linearize buffers.
<marcan>
buffer allocation would be done on the host
<marcan>
(I'm sure there's fun memory usage accounting issues here but eh, that's a solvable problem)
<maz>
huh. that's pretty terrible.
<maz>
it means that the IPA space changes from under the guest's feet...
<marcan>
wouldn't fundamentally be different from a PCI aperture though?
<marcan>
I dunno I might be making stuff up but this is the way I imagine it works
<maz>
unless you start doing carve-outs for the buffers to appear into.
<marcan>
yeah, exactly, you'd have to carve out a chunk of GPU IPA space where buffers go
<marcan>
that would from a VM point of view be device memory for the vgpu I imagine
<maz>
something like that.
<maz>
(this is starting to look a lot like $work, and I'm going to look away for a bit... ;-)
<marcan>
lol
<marcan>
well, other people are already working on this :p
<maz>
and I'm glad, less to do on my side! :D
<marcan>
I just look forward to this hopefully solving the 4K problem in a way that is much more likely to be a good solution for people playing games on asahi :p
<maz>
Emacs, man, Emacs!
<marcan>
lol
<maz>
ah, talking about graphics. has there been a significant change in the asahi kernel between 6.0 and 6.1 that makes X trip over on M2?
<marcan>
I just tested the latest 6.1 tag on M2 in a fresh install and it works well
<maz>
yeah, it's not a fresh install. everything is working well with 6.0, and I compiled my own 6.1 kernel. all OK except for X (VTs are OK).
<marcan>
weird
<maz>
I saw that there is an APPLEDRM config, but didn't investigate that.
<marcan>
not supported on M2 yet, so skip that for now
<maz>
I'll diff the X logs when I get a chance.
<marcan>
alright, I have a progress report to write, let's see if I can get it done in a couple hours
Mrmaxmeier has quit [Quit: Ping timeout (120 seconds)]
Mrmaxmeier has joined #asahi-dev
wiizzard has quit [Quit: Bridge terminating on SIGTERM]
m5zs7k has quit [Max SendQ exceeded]
MajorBiscuit has quit [Max SendQ exceeded]
m5zs7k has joined #asahi-dev
MajorBiscuit has joined #asahi-dev
<sven>
sounds good to me
Dementor has quit [Quit: Ping timeout (120 seconds)]
Dementor has joined #asahi-dev
<_jannau_>
marcan: USB3 benchmark: Susperspeed+ Gen 2x1 (10 Gbps, jmicron based) nvme ssd adapter: 920 MB/s (M1), 990 MB/s (M1 Max/M2) (sequenctial read), faster than the same HW under macOS
<marcan>
niiice
<marcan>
can I toot that? (or do you want to?)
<_jannau_>
feel free to. I measured around 750 MB/s on macOS but didn't spend effort to validate that
<sven>
unfortunately atcphy probably can't take credit for that since it's likely just something more efficient inside dwc3 or vfs or whatever :D
<sven>
I do configure atcphy to usb3-only while xnu always uses usb3+dp unless you coerce it but I really doubt that makes a difference
<_jannau_>
it shouldn't make a difference and if it does apple has take the blame
<sven>
yeah, it's much more likely xnu is just less efficient somewhere along the rest of the way
<marcan>
_jannau_: you're @janne on treehouse, right?
<_jannau_>
marcan: yes, I didn't realy had time to set the account up yet
<marcan>
cool :)
phire has quit [Quit: No Ping reply in 180 seconds.]
phire has joined #asahi-dev
phire has quit [Quit: No Ping reply in 180 seconds.]
<j`ey>
with the USB3/atc etc changes, is the DT still compatible if you dont build the new drivers? seemed like u-boot had issues with the DT and the ATC node
<sven>
unfortunately not inside linux
phire has joined #asahi-dev
<sven>
dwc3 will fail to probe if it sees a phy = <...> reference and there's no phy available
<sven>
but there's no good way to prevent that :(
<kettenis_>
I think linux and u-boot behave the same in that respect
<j`ey>
ah, guess I have to add some more stuff to my .config then
<kettenis_>
OpenBSD is a bit more forgiving in that respect
<j`ey>
which driver in drivers/usb/dwc3 do we use?
<sven>
hmm?
<sven>
dwc3 is a single driver
<kettenis_>
there are different "glue" drivers though
<sven>
oh.. those
Dcow has joined #asahi-dev
<sven>
none of them
<j`ey>
oh I just noticed there was a bunch of dwc3-* files, like qcom etc
<j`ey>
ok
<sven>
I think some of them are hacks and/or legacy code because they didn't want to implement a phy
Dcow has quit []
phire has quit []
Dcow has joined #asahi-dev
phire has joined #asahi-dev
phire has quit []
phire has joined #asahi-dev
phire has quit []
phire has joined #asahi-dev
<povik>
i think the headphone issue is worse than believed
<povik>
pulseaudio fails to resume the sink anytime it suspends it after a period of inactivity
turo has quit []
<povik>
weird thing is, we didn't bump pulseaudio AFAIK
<marcan>
ChaosPrincess: around?
<ChaosPrincess>
hey
<marcan>
ChaosPrincess: how do you want to be credited for the fpwm stuff?
<marcan>
(name & link if any)
<ChaosPrincess>
as ChaosPrincess, thats it
<marcan>
cool
phire has quit []
turo has joined #asahi-dev
<marcan>
ChaosPrincess: any comments on it? personally I think you did a really good job mapping out the "magic" bits and such. it's a simple driver but I want to highlight that a lot of effort goes into these things too.
phire has joined #asahi-dev
<marcan>
(also was this your first kernel driver, or first RE work like this?)
<ChaosPrincess>
my previous kernel work was trying to port the wii linux from 2.something kernels to newer, without much success, so you can say its the first :P
<marcan>
fair :)
<marcan>
also, pronouns?
<ChaosPrincess>
and for RE - 1. run m1n1, 2. poke at macos, 3. bang head against desk a lot. 4. ?????? 5. profit, sometimes
<marcan>
yup, that's how it goes :)
<ChaosPrincess>
they/them, but do not care much, use whatever.
<marcan>
works for me
<sven>
hm, did anyone test what happens with usb3 in device mode btw? does that just work?
<sven>
i don’t think I ever traced macOS to see if it configures the phy differently
<kettenis_>
does macOS even offer device mode functionality?
<marcan>
it does
<marcan>
you get a network
<povik>
huh
<marcan>
(it's also used during restores and looks like an iPhone then, though they crippled it to USB2 only at some point for some reason)
<ChaosPrincess>
isn't that tb networking, not usb device mode?
<marcan>
it can be both
<sven>
pretty sure it’s usb
<marcan>
pretty sure it can do both
<marcan>
if you use a USB cable you get USB networking
<sven>
I thought tb was sone different mode but maybe I misremember
<ChaosPrincess>
but that is usb4 only, no?
<sven>
*some
<marcan>
no, it's standard usb2/3 device
<marcan>
works with an A to C cable
<povik>
networking as in IP networking, right?
<marcan>
yes
<ChaosPrincess>
what device class then?
<sven>
yes
<marcan>
probably CDC Ethernet? I don't remember exactly
<sven>
I think it was that
<ChaosPrincess>
i know about tb host to host networking, but usb is new to me
<marcan>
apple used to have their own bespoke ethernet nonsense in the bad old iPhone days but I assume it's standard now
<marcan>
it's also the supported replacement for "target disk mode" which is no longer a thing
<marcan>
you connect to recoveryOS and get a samba share or something
<marcan>
(yes really)
<sven>
I’ve seen it on my Linux laptop early on when I was implementing dwc3 in m1n1
<marcan>
yeah, I've seen it too
<sven>
ohhh… that target disk thing is what I remember in tbt mode probably
<marcan>
ChaosPrincess: it's no different from a USB-ethernet dongle using standard classes
phire has quit [Quit: No Ping reply in 180 seconds.]
<ChaosPrincess>
thats certainly a way to implement it
<kettenis_>
marcan: with restore you mean DFU mode? That isn't realy macOS isn't it?
<marcan>
yeah that's gone
<marcan>
it's all networking now
<marcan>
kettenis_: no, I mean restore mode which is the third step after DFU mode
<marcan>
which is just macOS on the device side
<marcan>
(running from a ramdisk)
<marcan>
DFU itself is a bespoke USB iBoot protocol
<marcan>
as is the second iBoot/iBSS stage
<marcan>
third stage is macOS
<marcan>
and uses the iPhone sync protocol stuff / usbmuxd (which I wrote like 10 years ago lol)
<marcan>
which *itself* is a cursed fake-TCP-over-USB because of course
<marcan>
literally using TCP packet headers (but no IP)
<sven>
lol
<povik>
someone's idea of fun
phire has joined #asahi-dev
phire has quit [Quit: No Ping reply in 180 seconds.]
capta1nt0ad has joined #asahi-dev
phire has joined #asahi-dev
phire has quit []
phire has joined #asahi-dev
<povik>
marcan: we can disable pulseaudio's suspend-on-idle for the release
<marcan>
is that breaking something?
<povik>
yeah, that's what's the cause for the broken-until-replug state
<povik>
and it breaks after any period of idleness
phire has quit []
<povik>
it doesn't seem to be anything broken in kernel, at least as far i can tell, speaker-test does work while pulseaudio is locked up trying to resume
tobhe_ has joined #asahi-dev
<mps>
povik: yes, I don't use pulseadio and don't have propblem with sound
<mps>
kernel works fine
<mps>
with suspend/resume I meant to say
tobhe has quit [Ping timeout: 480 seconds]
<povik>
this is unrelated to suspend/resume of the machine
phire has joined #asahi-dev
<mps>
ah, ok then
<povik>
suspend is what pulseaudio calls when it disables a sink until its needed
<mps>
aha
<marcan>
povik: any idea what causes it?
<marcan>
I don't recall that happening earlier
phire has quit [Quit: No Ping reply in 180 seconds.]
<povik>
no idea, haven't seen it either (or is that the youtube playback stuck issue from way back?)
<povik>
i am looking around in pulseaudio code but nothing concrete yet
phire has joined #asahi-dev
<jannau>
it looks similar to the youtube being issue, i.e. it reproduces the behavior. pipewire doesn't show the same behavior on the same machine
<povik>
anyway commenting out load-module suspend-on-idle (or similar) in pulseaudio conf works as a workaround
tobhe has joined #asahi-dev
<povik>
i'm surprised the audio servers seem to have good supply of issues to throw at us
<povik>
the jack should be not unlike any other laptop
tobhe_ has quit [Ping timeout: 480 seconds]
<povik>
or rather... not unlike any other jack :|
phire has quit [Quit: No Ping reply in 180 seconds.]
<marcan>
I should mention the modeset/xorg/vblank thing I guess
phire has joined #asahi-dev
<jannau>
and I forgot modeset for external displays which are not 1920x1080
<marcan>
jannau: updated to mention the modeset APIs/xfce issue
<marcan>
reworded a bit
phire has quit []
<marcan>
povik, sven, ChaosPrincess, jannau, chadmed and whoever else wants, feel free to review if you have some time
<marcan>
I want to hit the post (& repo/OS image deploy) button at 23:00 or so if possible :)
<marcan>
(in ~45m)
phire has joined #asahi-dev
<sven>
probably won't have time but the atcphy part sounded good to me
<sven>
please just don't mention external displays very prominently yet. i've already had at least three very enthusiastic people asking me in /msg how to set that up who didn't quite realize how broken it is right now
<maz>
the good news is that this pushes the release date to the year 4097, give or take.
sentinal8473 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<sven>
:D
<chadmed>
plenty of time to get it working well ;0
<marcan>
sven: it's one sentence, hope it's not too much :)
<sven>
that's fine
<sven>
i've tweeted/tooted it already but these progress reports usually get much more attention
<marcan>
rephrased a bit: It also paves the way for the (still incomplete) external display support (over Type C/DisplayPort) that Sven has been working on, [...]
<marcan>
hope that makes it clear
<sven>
yeah, that's fine
phire has quit [Quit: No Ping reply in 180 seconds.]
<chadmed>
the semiquaver thing took me a couple of seconds to get but the post looks good to me!
<j`ey>
marcan: read it all, lgtm
<j`ey>
chadmed: hehe yeah,. i almost said there was a duplicate title :p
<chadmed>
my eyes literally glazed over, dunno how much of that to attribute to being sick, being exhausted, or 1000 iq humour
<jannau>
marcan: CS42L84 is in the m2 macbook pro 13" as well: s/M2 MacBook Air/M2 MacBooks/
phire has joined #asahi-dev
phire has quit []
<jannau>
maybe make "please don't suspend with mounted USB drives" bold
<dottedmag>
and blinking
<chadmed>
and when you hover over it your cursor becomes a flaming skull
<povik>
> (though they won't be able to use hardware volume controls, but since the data format is 24-bit PCM, software volume control is perfectly acceptable here).
<povik>
macos doesn't use the hw vol controls at all btw
<ChaosPrincess>
lgtm on the post, just need a clickbait title :P
<Dcow>
marcan: "run some rests on my MacBook Air M2" in audio section
phire has quit []
<povik>
hah
<povik>
> sometimes the headphones won't work if initially connected on boot, or after an idle period.
<povik>
the idle period is actually rather short
phire has joined #asahi-dev
<povik>
marcan: are you for doing the no-suspend workaround?
<povik>
it's annoying how quickly it breaks
<povik>
i would rather we fix it
<povik>
although not sure if we can do that easily -- i assume old pulseaudio configuration is retained on package upgrade
<marcan>
yeah, it would be
<marcan>
though we already carry a pulseaudio patch
<marcan>
let me look a bit, sigh
<povik>
hm, so if we do the change to default conf now, new installs would have the workaround but we wouldn't be able to remove it for users in the future once the underlying issue is fixed
<marcan>
yeah, let's not do it that way
<povik>
an option is disabling installation of the module
<marcan>
I'd rather patch the PA package
<povik>
yeah, that's what i mean
<povik>
i guess it's all part of the one package
phire has quit [Quit: No Ping reply in 180 seconds.]
phire has joined #asahi-dev
<povik>
we can always do last minute switch to pipewire :D
<kujeger>
sorry to interrupt, but pipewire does not suffer from the problem, did I read that correctly? if so, maybe suggest switching to it?
<kujeger>
hah
<amarioguy2>
thanksgiving break coming up, should be able to get those sep docs much more up to speed
amarioguy2 is now known as amarioguy
<amarioguy>
sorry being inactive on this i swear uni can give you just the most work at times...
<_jannau_>
last second switching to pipewire seems to be a bad idea as well. it seems to works for me though
phire has quit [Quit: No Ping reply in 180 seconds.]
<_jannau_>
patching pulseaudio looks like the preferable option even if that is hard-coding no-suspend instead of reading it from the config. we can control that via package updates
<povik>
yeah, that seems like the reasonable option
phire has joined #asahi-dev
<povik>
i guess marcan is looking for a way to do it right now
<marcan>
I'm looking at PA for a bit
<marcan>
if I don't find an easy fix, pipewire I guess
<povik>
i found out unsuspend is never called, neither sink_set_state_in_io_thread_cb with PA_SINK_RUNNING
<marcan>
I see a message saying it goes active, then idle right after that
<marcan>
I don't see the sink becoming active again at all?
<povik>
that's after you start some playback client?
<marcan>
yeah
phire has quit [Quit: No Ping reply in 180 seconds.]
phire has joined #asahi-dev
<marcan>
yeah I dunno, it just does nothing, I have no idea
<marcan>
pipewire it is then
<povik>
lol
<marcan>
it's what we'll use for the speakers anyway
<marcan>
I already fixed one PA bug that's been there for a year, I don't know why it's so broken for us but I'm not getting much confidence on the future of PA
<povik>
does pulseaudio get uninstalled if you change the dependency of the meta package?
<marcan>
I think I can make it conflict
<povik>
what do i need to install to test the new setup? pipewire and what more?
<marcan>
pipewire-audio pipewire-pulse I think
<marcan>
those will trigger the conflict and users will be prompted for the removal
<povik>
and wireplumber or media-session, no?
<_jannau_>
what happens if you simple build the pa package without module-suspend-on-idle?
<marcan>
wireplumber is already there on my system
<marcan>
also just did it and rebooted and things Just Work lol
<marcan>
yeah okay pipewire it is then (yay last minute decisions)
<povik>
ok, let's do it here
phire has quit []
<marcan>
let me test bluetooth
<povik>
seems to work well here, too
phire has joined #asahi-dev
<marcan>
bt works, auto switching works
<Tramtrist>
pipewire scares me how it just works
<marcan>
let me try s2idle
chadmed_ has joined #asahi-dev
<chadmed_>
ive been dogfooding pipewire + DSP et al for ages and it all works with no issues
<chadmed_>
hotplug/switching works in the default stereo audio profile
<marcan>
s2idle works
<marcan>
bye bye PA
<Tramtrist>
👍
<povik>
farewell!
* povik
waves
<Dcow>
I got keyboard issues after s2idle on -edge/j316c a few times. it's basically render keyboard unusable, looks like it's repeating space character infinitely. It's impossible to switch to another tty from GDM(due keyboard not working) so I didn't obtain dmesg yet.
<Dcow>
I've had to reboot device with power button holding
<marcan>
edge issues in the edge tracker bug please
<dottedmag>
Dcow: can you access this machine remotely if this happens?
sentinal8473 has joined #asahi-dev
<Dcow>
dottedmag: I think yes, but I didn't setup ssh on machine yet
<Dcow>
marcan: I will post there once I get dmesg logs. I though now it's a good time to just say it out loud.
<marcan>
no joke, this is just smoother than PA in every way
<povik>
not dramatic enough :p
<Dcow>
it's also default to Fedora, so...
<zzywysm>
mps: the solution to the f2fs problem seems obvious to me: submit a patch that doesn't let you enable CONFIG_F2FS_FS if CONFIG_ARM64_16K_PAGES or CONFIG_ARM64_64K_PAGES is enabled
<zzywysm>
mps: make the shame explicit
<Dcow>
ps maybe add some chapter about Alt Distros, i.e. Fedora getting work done?
<Dcow>
zzywysm: sounds like a good plan to me
<marcan>
Dcow: I think that's best left for the next one, this one's getting long already
<marcan>
and by then it might even be official
<marcan>
new meta in asahi-dev
<sven>
pretty sure that f2fs already complains if its block size is != PAGE_SIZE
<zzywysm>
sven: the complaining should happen at compile-time, not runtime
<povik>
huh, how did it work for me without pipewire-alsa?
<povik>
maybe that's the libasound front for clients
<marcan>
it is
<marcan>
we weren't installing pulseaudio-alsa until now either
<marcan>
but it sounds like a good idea
<marcan>
(I needed it for speaker-test)
<povik>
ah, that's why speaker-test seemed to circumvent pulseaudio without any convincing
<mps>
zzywysm: no, I already talked with drivers authors, one of them told me that they would probably fix f2fs to work with 16K pages but didn't 'defined' when
<zzywysm>
mps: in the meantime, the kernel config system should accurately reflect the (lack of) code compatibility
<mps>
zzywysm: yes, this makes sense
<ahdeb[m]>
|| CONFIG_COMPILE_TEST
<marcan>
upgrade worked on the M1 MBA, worked as intended
<povik>
we are getting there!
<marcan>
going to build new images again
chadmed_ has quit [Remote host closed the connection]
sentinal8473 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<marcan>
uploading
joske has joined #asahi-dev
chadmed_ has joined #asahi-dev
<joske>
marcan: read the progres report, and as always, well written and very detailed. Even though I'm following asahi development closely, I still learned a lot!
<sven>
that's not a proper fix though, it just makes f2fs only work on 16k PAGE_SIZE machines
<marcan>
I think I'm going to sync asahi-dev to asahi now, looks like that path is well-tested enough
<marcan>
(while OS images upload)
<kh>
sven: Hey, at least it works
<sven>
okay, maybe let me rephrase that: it won't even allow you to mount pages created on a 4k kernel when you're running a 16k kernel
<kh>
Yeah but people previously were saying that f2fs should be blocked on 16k kernels altogether...
<sven>
yes, on the upstream kernel where that patch wouldn't be accepted anyway
<sven>
also, does that even touch the kernel? it looks like it just changes something in the userspace tools
<maz>
also, none of that is kernel code. this looks like userspace tooling only.
<sven>
but I guess they have another patch for the kernel to allow it?
<kh>
Yes that's a change to a userspace tool and I don't think there's any kernel changes required for it
<sven>
uhh...
<sven>
but the kernel currently hardcodes the f2fs blocksize to 4k
<marcan>
I think we can drop the mkinitcpio override right? I have systems with a newer one that work fine
<marcan>
oh wait, it's already dropped from dev
sentinal8473 has joined #asahi-dev
<marcan>
the package file was just still there
<marcan>
asahi-dev synced to asahi, pulseaudio overrides dropped, and PKGBUILDs repo now has a `stable` branch synced to main at this point
<marcan>
installer should be updated. let me do one more from-scratch install test...
<marcan>
(dev installer that is)
<kh>
sven: Oh, idk then
<jannau>
marcan: yes, mkinitcpio can be dropped, there was an mkinitcpio upstream release with compressed kernel support, which we don't even need anymore
<marcan>
yeah, it was already dropped
<marcan>
just had a stray package file confusing me
<marcan>
hasn't been in the actual repo for a while
<marcan>
reinstalling on M2
joske has quit [Quit: Leaving]
<mps>
kh: I hope that when asahi get merged to mainline then f2fs developers will have more incetive to make it working with 16K pages. At least one of them (Chao Yu) told me in private mail that he is interested to make it work
<marcan>
jannau: oh, I see we still have the "screen brightness drop to min on dpms restore" bug
<marcan>
(though now at least you can just hit a brightness key
<marcan>
adding it to the -edge tracker
<jannau>
ah, yes. I made no change to restore the brightness on reactivating the display. curse of not using a device where the problem occurs
<marcan>
can fix it later, no worries
<marcan>
argh the install is taking forever, curse you international intertubes
<marcan>
(the CDN is really slow when first fetching from origin...)
chadmed_ has quit [Remote host closed the connection]
<opticron>
one nit on the release post, ChaosPrincess' and ChaosPrincess's both exist in the "Backlight, Book I" chapter and I think the latter is correct
<marcan>
the former should be correct if my English doesn't fail me
<marcan>
or is that only for plurals?
<marcan>
maybe it's one of those things where people can't agree
<marcan>
yeah, google says "both"
<marcan>
fixed (will take a minute to update)
<marcan>
alright, I should get some sleep...
<marcan>
hope nothing explodes ;)
<_jannau_>
nothing should be that critical that it can't wait until tomorrow. good night
<blazra>
ChaosPrincess: For the fpwm: Have some of my reverse engineered "magic" bits helped?
rowanG337 has quit [Remote host closed the connection]
<ChaosPrincess>
Split into Enable/output enable, and pointing out that reading back the current state is possible did help.
beeblebrox has quit [Ping timeout: 480 seconds]
uallas has joined #asahi-dev
uallas has left #asahi-dev [#asahi-dev]
<marcan>
ah, first thing I missed: should've disabled CONFIG_BACKLIGHT_GPIO entirely in -edge
<marcan>
not sure if it's causing issues, but it's definitely wrong
kh has quit [Quit: Konversation terminated!]
<jannau>
it still turns off the backlight completely but I think kde guesses the correct backlight
<marcan>
huh, I broke simpledrm on -edge by turning off that config? not entirely sure how...
<marcan>
looks like now it loads but super late?
<marcan>
as if the dependency was still being blocked on?
<marcan>
anyway it's in -dev only
<marcan>
going to sleep for real now, not the time to debug this :p
<jannau>
is it probed after 10 seconds? could be probe dependencies inferred from the devicetree and giving up after 10 seconds
<marcan>
I think so, yeah
<marcan>
jannau: what code does that?
<marcan>
ah, found it. argh.
<marcan>
TIL this is a thing[
<sven>
there’s a 10s deferral delay? hah
<sven>
so it just gives up then?
<marcan>
looks like it
<marcan>
not sure where the delay comes from, but I found the OF code that scans the properties and creates device links
<marcan>
I'm tempted to just #ifdef it out on the simpledrm backlight support thing
<marcan>
ugly hack but then again this whole thing is going away when DCP is on by default
<sven>
drivers/base/dd.c maybe
<marcan>
the scanning is in drivers/of/property.c
<povik>
ha, yeah, was an interesting find for me as well
<povik>
the deferral timeout
<sven>
there’s a timeout that’s set to 10s
<sven>
whenever modules are enable which kinda makes sense maybe
<marcan>
building a new kernel while I brush my teeth... :p
<marcan>
I just hacked it out specifically for backlight
<marcan>
ok, it's fixed
<marcan>
also I think my M1 MBA was getting pretty warm in sleep mode and I think eating battery... methinks there's a problem here, need to debug
<marcan>
synced to asahi repo
<marcan>
hope I didn't explode anything (the non-edge kernel update should be a no-op)
<marcan>
good night!
___nick___ has joined #asahi-dev
___nick___ has quit []
___nick___ has joined #asahi-dev
<marcan>
oh whoops, asmedia didn't init this one time on my iMac :(
<marcan>
and now it froze on boot? did I just manage to like regress half the world with this?
<marcan>
ok now it worked
<marcan>
I have no idea
<marcan>
good night for real now
rqou_ has joined #asahi-dev
<rqou_>
sven: re backlog question about usb3 in device mode: when you had first posted atcphy months and months ago, gadget mode did *not* work (neither usb2 nor usb3). i have not tested the current version
<rqou_>
nice work on the release / progress report!
millenialhacker has joined #asahi-dev
<millenialhacker>
qq: Has anyone experienced keyboard/mouse problems when booting Asahi 6.1 RC3?
<jannau>
on which device?
<millenialhacker>
I'm unable to login on my Macbook Pro M1 Pro
<jannau>
reboot, there are occasional probe errors with spi-hid or the hid drivers
<millenialhacker>
weird thing, it used to work fine a week ago, I just worked on OSX this week, and now when I tried to boot keyboard doesn't work.
<millenialhacker>
I rebooteed three times, all of them the same
<as400>
millenialhacker: go to another console and restart sddm. This should help
<millenialhacker>
before that I got a weird wifi card error, so no network, but keyboard worked, I rebooted to solve wifi/bt error, and wifi boot up properly but no keyboard / mouse once I landed in GDM.
<millenialhacker>
as400, control + alt + FXX does not work either
<millenialhacker>
keyboard works fine until grub
<millenialhacker>
after grub boots Linux it's gone
<millenialhacker>
Gentoo hates me :D
<as400>
Oh crap
<millenialhacker>
I can connect an external keyboard, but I just wanted to know if it was a known issue
<sven>
rqou_: ah, pity. it’s probably still broken then
<sven>
guess I’ll have to convince macOS to go into device mode and see what it does differently
millenialhacker has quit [Remote host closed the connection]
millenialhacker has joined #asahi-dev
leitao has joined #asahi-dev
leitao has quit []
amarioguy2 has joined #asahi-dev
MajorBiscuit has quit [Ping timeout: 480 seconds]
stsmwg has joined #asahi-dev
millenialhacker has quit [Ping timeout: 480 seconds]
nicolas17 has joined #asahi-dev
tobhe_ has joined #asahi-dev
millenialhacker has joined #asahi-dev
tobhe has quit [Ping timeout: 480 seconds]
millenialhacker has quit [Ping timeout: 480 seconds]
millenialhacker has joined #asahi-dev
tobhe has joined #asahi-dev
tobhe_ has quit [Ping timeout: 480 seconds]
jvzr has joined #asahi-dev
millenialhacker has quit [Ping timeout: 480 seconds]
<sven>
okay, wtf, I just had access to the tbt pcie and everything else but now I rebooted and now the same kernel results in SErrors again?!
mkurz has joined #asahi-dev
millenialhacker has joined #asahi-dev
jluthra has quit [Remote host closed the connection]
jluthra has joined #asahi-dev
leitao has joined #asahi-dev
millenialhacker has quit [Ping timeout: 480 seconds]
___nick___ has quit [Ping timeout: 480 seconds]
mkurz has quit [Quit: Leaving]
millenialhacker has joined #asahi-dev
amarioguy2 has quit [Ping timeout: 480 seconds]
<povik>
where in linux tree should a driver for the LEAP coprocessor go?
<povik>
i am not clear on the difference between drivers/platform/apple and drivers/soc/apple
leitao has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
millenialhacker has quit [Ping timeout: 480 seconds]
<cyrozap>
Hi, all! I just read the recent progress report, and the part about the ASMedia firmware loading functionality really interested me. I've been working on my own ASMedia USB host controller RE project for a couple years now (https://github.com/cyrozap/asmedia-xhc-re), and from my research, the only ASMedia USB host controllers I found that include hardware-based firmware upload over PCIe (functionality
<cyrozap>
or they have it disabled by default. So, I have a few questions: 1) Which ASmedia USB host controller is Apple using in their devices? 2) Has the firmware upload protocol that Apple is using been documented anywhere? 3) Which Apple models contain these ASMedia USB host controllers? 4) Is there a way to download the macOS XNU kernel binary (which the post said contains the ASMedia firmware) directly
<cyrozap>
from Apple and extract the firmware myself?
<sven>
povik: soc for stuff that will only ever run on apple Silicon SoCs (e.g. rtkit), platform for things that are also useful for older apple machines (x86 macs etc.) imho
<povik>
(including the extraction of the asmedia firmware itself)
wikwity has joined #asahi-dev
beeblebrox has joined #asahi-dev
<cyrozap>
povik, jannau: Thank you both, that's really helpful information! I'm surprised to see they're using a bog-standard ASM3142, and not some special part customized by Apple. And the mask ROM firmware version (0x010250090816, normally written like 160809_50_02_01) confirms that, since that's the same version I see with the ASM2142 and ASM3142 chips I have.
amarioguy2 has quit [Ping timeout: 480 seconds]
<ChaosPrincess>
Made a step 1 to having a 'reboot to macos' command - nvram read/write tool. seems to be working, but i do not recommend using it if you are not ready to do a dfu restore https://github.com/WhatAmISupposedToPutHere/asahi-nvram
millenialhacker has quit [Ping timeout: 480 seconds]
<nicolas17>
ChaosPrincess: any progress on M2 nvram?
<ChaosPrincess>
absolutely none, i do not have a m2
amarioguy2 has joined #asahi-dev
wikwity has quit [Remote host closed the connection]
<cyrozap>
Oh, interesting... Looking at the kernel code, it looks like ASMedia moved the direct MMIO access functionality from the PCI config space to BAR0. And so the only other differences in the process are really just some MMIO address and bit field changes, which makes sense since the ASM2142 and later use a different range of addresses for their MMIO compared to the ASM1142 and earlier. And I know for
<nicolas17>
is it possible to configure the Mac to boot to the OS selector?
<nicolas17>
default boot OS = "none, ask me every time"
<cyrozap>
So, uh, thanks, Apple, for using functionality in ASMedia's newer host controllers that no other system vendors seem to be using. And big thanks to marcan for doing the RE work on that--you've saved me a lot of time and energy :)
<ChaosPrincess>
i do not think thats possible, os picker is actually full macos that runs the 'os picker' app, which then sets the apple equivalent of BootNext and reboots
<cyrozap>
btw, if anyone has any questions about the ASMedia USB host controllers, I've done a lot of in-depth RE of them, so feel free to ask!
millenialhacker has quit [Ping timeout: 480 seconds]
millenialhacker has joined #asahi-dev
stsmwg has quit [Quit: Lost terminal]
millenialhacker has quit [Ping timeout: 480 seconds]
SSJ_GZ has quit [Ping timeout: 480 seconds]
loop0 has joined #asahi-dev
weitcis has joined #asahi-dev
amarioguy2 has quit [Ping timeout: 480 seconds]
millenialhacker has joined #asahi-dev
loop0 has quit [Quit: WeeChat 3.7.1]
weitcis_ has joined #asahi-dev
weitcis has quit [Read error: Connection reset by peer]