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
chadmed_ has joined #asahi-dev
kesslerdupont has quit [Ping timeout: 480 seconds]
user982492_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kesslerdupont has quit [Ping timeout: 480 seconds]
kesslerdupont has joined #asahi-dev
kesslerdupont has quit [Ping timeout: 480 seconds]
kesslerdupont has joined #asahi-dev
kesslerdupont has quit [Ping timeout: 480 seconds]
kesslerdupont has joined #asahi-dev
cylm has joined #asahi-dev
<cy8aer>
chadmed_: Yes it is userspace of course. And yes filtering makes the sound better of course. I just run easy effects for my headphones with a multiband compressor and a limiter. But the sound will not get better if I would do another filtering/compressing stuff afterwards, it will just pump up.
<cy8aer>
chadmed_: What I meant was: How much should the sound be pre-enhanced. If it is done to hard the end user will have problems to do more adjusting on top of the adjusting done from the preset. Or am I wrong there?
<cy8aer>
And - of course - I would be happy if someone does the adjusting for me. If it sounds good I will then not play around with a filter anyways.
<cy8aer>
chadmed_: And you do your adjusting with the little help of sound studio equipment, right?
<chadmed_>
cy8aer: sure there are diminishing returns but thats not really what we're trying to do here. you can "layer" as much DSP as the hardware can handle, users can put whatever effects they want on top of what we do so long as it doesnt overload either the speakers themselves or the digital signal chain
<chadmed_>
and my philosophy on how much we should do on our end has been clear from day one - we do enough to turn our 6-way mess of microspeakers into a passably good stereo system
<chadmed_>
what users do beyond that is up to them
<chadmed_>
and no ive done it all by ear except for initially collecting some frequency response curves from the individual elements (each woofer and tweeter) as a visual guide
<chadmed_>
but i wouldnt call what i used "studio" equipment
<chadmed_>
but the way REW works is you collect a frequency response curve and then apply theoretical filters to that as a visual aid
<chadmed_>
but all the tuning beyond that initial crude work has been by ear
<cy8aer>
chadmed_: Ok, your intention is to just do the chassis correction (classical: which you would expect in a speaker in hardware when you buy them)
<chadmed_>
yeah pretty much. as ive always said im not one for fancy schmancy DSP transfer function spatial audio bullshit
<chadmed_>
i just want a good sounding set of stereo speakers
<chadmed_>
whatever people want to put on top of that is their business
<cy8aer>
Yep, that would be great for me as an end user.
<chadmed_>
if we wanted all that fancy crap i would have put more effort into figuring out what macos does beyond "oh its all just coreaudio AUs and obfuscated parameters into them"
<cy8aer>
So then I am looking forward for a real good sound 🙂
<chadmed_>
soon(tm)
<chadmed_>
the safety daemon needs a fair bit of work
<cy8aer>
yes I know, I have been observing your work for some time now.
<chadmed_>
but its the kind of work that is now beyond what i can currently do and what i have time to learn how to do
chadmed_ has quit [Remote host closed the connection]
kesslerdupont has quit [Ping timeout: 480 seconds]
kesslerdupont has joined #asahi-dev
bps has joined #asahi-dev
kesslerdupont has quit [Ping timeout: 480 seconds]
kesslerdupont has joined #asahi-dev
nsklaus has joined #asahi-dev
mkurz has joined #asahi-dev
kesslerdupont has quit [Ping timeout: 480 seconds]
kesslerdupont has joined #asahi-dev
tobhe has joined #asahi-dev
tobhe_ has quit [Ping timeout: 480 seconds]
kesslerdupont has quit [Ping timeout: 480 seconds]
<handlerug>
hm, say I want to look at making VRR work. I probably should look around with m1n1 in hypervisor mode and check the packets the macOS drivers send, right?
<marcan>
correct, use the DCP tracing stuff
* handlerug
dusts off his old trusty Core i5 laptop
kesslerdupont has joined #asahi-dev
<marcan>
folding in the t602x stuff into the main branches now
kesslerdupont has quit [Ping timeout: 480 seconds]
<marcan>
and next I'm going to try to fix the stupid genpd thing with on-at-boot domains
<_jannau_>
handlerug: there are 3 or 4 timestamp fields in IOMFBSwapRec. all timestamps are iirc in 24MHz resolution. not all timestamp files are always used. I think at boot only a single one is used
<handlerug>
interesting
<_jannau_>
not sure if that is the preferred swap time or just the current AP time
kesslerdupont has joined #asahi-dev
<marcan>
jannau: how are you feeling about 13.3 DCP? once lina gets the GPU to parity I think it's time for a release for the new macbooks at least. I don't plan on pushing 13.3 for previous chips *yet*, we can leave that for a bit later.
<j`ey>
and that corresponds to struct dcp_swap in drivers/gpu/drm/apple/iomfb.h, right _jannau_ ?
<marcan>
if the timestamps are 24MHz they should match the AIC timer / ARMv8 timer counter
<_jannau_>
DCP request APs calender_time at startup but I would expect problems under the HV, or maybe not since DCP might just too fast
<marcan>
(which is a bit annoying on Linux because that is abstracted out behind the clock subsystem... in a pinch you could read the timer register directly to get the current time in the right domain)
<marcan>
_jannau_: are they in calendar time though?
<marcan>
almost everything in these SoCs uses the AIC timer for basic timing, and DCP's timer would also be synced to that
<_jannau_>
I don't remember
<marcan>
calendar time is a bit different and I would expect it to be used only for more specific stuff
<handlerug>
calendar time can't be RTC, right?
<handlerug>
would be weird to use that
<marcan>
there's probably some weird reason DCP cares about calendar time, but it's probably not for VRR timing related stuff
<marcan>
calendar time should be UNIX time
<_jannau_>
I can't remember what calender time was but afaik it was not seconds since epoch
<_jannau_>
s/afaik/iirc/
<marcan>
might be nanoseconds or something
<_jannau_>
marcan: did you see my PR, with the DCP changes there I feel somewhat confident about 13.3 DCP but I only tested on t8103/t6002
<marcan>
are those different from what was in the bringup branch?
<_jannau_>
only functional difference is D212 -> D208 update_backlight_factor_prop
kesslerdupont has quit [Ping timeout: 480 seconds]
<_jannau_>
the ADT has a region with something like 0x24ec98000, size 0x120000
<_jannau_>
for j493
<marcan>
yeah but that doesn't make any sense, SRAM start is aligned
kesslerdupont has joined #asahi-dev
<marcan>
DCP changes look good
<marcan>
I'm just going to guess it starts at c by analogy to t602x
<marcan>
_jannau_: you have a bad comment reindent, other than that pcie change looks good. I'll fix it,.
<_jannau_>
thanks, with that change and kettenis t6020 uboot branch we can enable pcie in uboot
<_jannau_>
asmedia xhci works in linux whether uboot has or misses its firmware
<marcan>
excellent :)
<marcan>
might punt on enabling pcie on release packages until a bit later, but we'll put it into the next update at the latest
<marcan>
(I also want to try to fix the asmedia firmware load, it's not reliable...)
kesslerdupont has quit [Ping timeout: 480 seconds]
<marcan>
pushed with your changes
<marcan>
ok, genpd next
<sven>
one more week until work finally calms down a bit again so that I can continue with the typec mess :)
<marcan>
:D
<marcan>
ChaosPrincess: so about adp, even though it's ostensibly the same hardware as some older iphones, I don't think we should pretend we know that for sure at this point. I'd use a more specific compatible like apple,t8103-dfr-display-pipe.
<marcan>
I also think we should consider how to let userspace tell it apart, because even if they're the same hardware the use case is *very* different
<marcan>
how are we stopping xorg/kde/etc from treating it as a display (or even the primary display) right now?
<ChaosPrincess>
we dont
<marcan>
ok, so we need a way to do that, and one that can be disabled for iphones where it *is* the primary display
<ChaosPrincess>
well, the idea is that the userspace daemon will grab it and somehow prevent it from being grabbed by kde
<marcan>
that's called a race condition
<marcan>
no go
<marcan>
we need *some* way to stop regular compositors from binding to it
<ChaosPrincess>
also, arguably, i want it to be able to be grabbed by kde, since you can drag a small panel there and use it for whatever
<marcan>
this might be a question for #dri-devel :)
<marcan>
well, that right now is horribly broken in KDE
<marcan>
which is all the more reason to disable it by default
<marcan>
and then if KDE fixes the touch bar use case, they can do whatever they need to do to actively opt in
<marcan>
I don't expect for this to be reasonably useful with the current state of things on most compositors, and if people want to experiment they should opt in with some module arg or something
<marcan>
but the default should be nothing touches the touch bar except our daemon
<handlerug>
I have M1 Max so it's 12.3 for me. thanks!
<_jannau_>
tracing / m1n1 dcp testing is not ready / in place for 13.3
<marcan>
yeah
<ChaosPrincess>
also, our daemon kinda does not exist yet
<marcan>
I know, but it will have to for this to be shippable by default
<marcan>
I mean I don't mind merging your driver, but I'm not going to enable it in release builds until we solve these issues :p
<_jannau_>
I haven't even updated my horrible 13.2 support to 13.3 yet
<ChaosPrincess>
rn its in a 'ready for someone to start writing a driver', not in 'shippable' state
<ChaosPrincess>
so thats fine
<marcan>
(if nobody else does I can probably cook up said daemon in an evening... but it sounds like the kind of thing lots of other people could have fun doing too)
<_jannau_>
kms has a property with the promising name "non-desktop" but that is intended for VR displays
<ChaosPrincess>
+ the whole part where this is my first time writing a drm driver, so expect code to not be great
<marcan>
_jannau_: is it *only* intended for VR displays though?
<marcan>
I would not expect any VR solution to bind to a random unknown screen, so that may be perfectly fine
<marcan>
(VR requires precise knowledge of the target)
<_jannau_>
we've signed up Knedlik for writing the daemon
<marcan>
cool :)
<_jannau_>
kwin started to ignore non_desktop displays 2 years ago
kesslerdupont has joined #asahi-dev
kesslerdupont has quit [Quit: leaving]
kesslerd1pont has joined #asahi-dev
<marcan>
that sounds good to me
<kesslerd1pont>
chadmed: is there a git repo for the speaker safetyd? I see one on github under your name. I want to offer help and if there is anything I can do let me know.
<chadmed>
i think marcan forked it when he was working on it
<marcan>
jannau: this might be why you were failing to resume... was that outside the HV by any chance?
<marcan>
that would go very badly if the console remains active
<marcan>
(and you have serial)
<marcan>
that's a UART driver bug, it needs special handling for this
<_jannau_>
yes, resume failed outside of HV
<marcan>
_jannau_: was that with no_console_suspend?
<_jannau_>
yes
<marcan>
ok, then it was almost certainly this
<marcan>
I'll fix it
<marcan>
... lol, I don't even know if I can fix it
<marcan>
as far as I can tell the genpd core just unconditionally powers domains off in the suspend path? what?
<marcan>
and there's no way for devices to stop that?
MajorBiscuit has joined #asahi-dev
<povik>
:D
Knedlik has joined #asahi-dev
<Knedlik>
I'm guessing no one noticed my last msg... I'm getting an "unexpected argument" of "--size_t-is-usize" when trying to build the pkgbuild with the touchbar PRs
Knedlik has quit [Remote host closed the connection]
<psykose>
classic new bindgen
<marcan>
Knedlik: just drop that flag from whatever Makefile it's in
Knedlik has joined #asahi-dev
<Knedlik>
Do you by any chance have an idea where the makefile could be? I believe you can do than on the terminal?
<j`ey>
Knedlik: rust/Makefile
<_jannau_>
Knedlik: try to build the kernel first in a git checkout. if it builds there you can use your changes as additional patches in the PKGBUILD
<Knedlik>
Ah, I'll try it in a sec, thanks a lot
<Knedlik>
If I use the PKGBUILD, it should automatically install that stuff, right?
<_jannau_>
no, you have to manually install it with `sudo pacman -U $file`
<Knedlik>
Ah, the file I assume will be somewhere in the build dir?
Knedlik has quit [Remote host closed the connection]
knedlik_ is now known as Knedlik
MajorBiscuit has quit [Ping timeout: 480 seconds]
cylm has joined #asahi-dev
cylm_ has quit [Ping timeout: 480 seconds]
abd has joined #asahi-dev
abd has quit [Ping timeout: 480 seconds]
<marcan>
jannau: lol answer to the serial console thing from #armlinux: other platforms have one-off hacks for this in the genpd driver
<marcan>
sorry, not dealing with that particular yak right now, someone else can pick up the fight of how to add a driver->genpd hook to disable genpd shutdown on suspend selectively :p
kesslerd1pont has quit [Ping timeout: 480 seconds]
<marcan>
in the meantime, I guess just use the hypervisor to debug suspend stuff or just don't use no_console_suspend or if you actually have a serial console just make the PD always-on as a one-off hack
abd has joined #asahi-dev
<marcan>
ChaosPrincess: found the bug
abd has quit [Read error: Connection reset by peer]
kesslerd1pont has joined #asahi-dev
<marcan>
jannau: lol, now the problem is suspend breaks DCP for the same reason (because we got rid of RPM and now genpd is still powering it down on suspend without the right things happening first)
<marcan>
siiiigh
<_jannau_>
I saw. I wonder what happends if we set GENPD_FLAG_ALWAYS_ON from suspend()
<marcan>
I was about to do that lol
<_jannau_>
I was thinking of serial
korreckj328 has joined #asahi-dev
<marcan>
the problem logically is it's not a counter so if you have multiple devices doing that it will be a bit dodgy
<marcan>
but in practice it will work
abd has joined #asahi-dev
abd has quit [Remote host closed the connection]
<_jannau_>
I'll look at redoing the runtime-pm change. I hope it will be simpler if I ignore the component stuff and handle bind()/unbind() as p[robe()/release()
<marcan>
_jannau_: GENPD_FLAG_ACTIVE_WAKEUP and device->power.wakeup_path seems slightly less ugly
<marcan>
it's basically the feature we want, just by a different name
<Knedlik>
Guys if I ever decide to rebuild the kernel from scratch on my M1 macbook.... stop me
<Knedlik>
I'm building for what, an hour now?
<marcan>
um... that doesn't sound right
<ChaosPrincess>
did you try to build distro kernel or sth
<Knedlik>
I just ran makepkg -s
<j`ey>
Knedlik: do you mean the actual build, or just getting everyting setup?
<_jannau_>
does makepkg default to '-j 1'?
<Knedlik>
I mean the actual build
<marcan>
Knedlik: bet you didn't set your MAKEFLAGS properly
<marcan>
MAKEFLAGS="-j8" in /etc/makepkg.conf
<marcan>
you're building single-core
<Knedlik>
Should I stop and try building with more cores?
<marcan>
yeah
<Knedlik>
-j2 it seems is the default
<marcan>
ok, still :p
<Knedlik>
Ok, trying with 8
<_jannau_>
the distro package is not ideal since it does almost 2 kernel builds
___nick___ has joined #asahi-dev
<marcan>
_jannau_: I'll try the wakeup trick
<Knedlik>
Actual build started now at 16:40 UTC, so let's see how long it takes
<Knedlik>
Uhhh I forgot to restart the terminal, could that be a problem?
<marcan>
restart the terminal?
<marcan>
why would you need to do that?
<Knedlik>
Idk, for the change in the file to take effect? Or is it not taken as an environment variable?
<Knedlik>
Seems faster after a terminal restart tbh
<marcan>
no, it is loaded when you run `makepkg`
<Knedlik>
huh
korreckj328 has quit [Quit: Leaving.]
<marcan>
jannau, ChaosPrincess: the DCP/uart sleep issues (and genpd issues) should *hopefully* all be fixed now.
<marcan>
and I should get some sleep
mkurz has quit [Read error: Connection reset by peer]
mkurz has joined #asahi-dev
MajorBiscuit has joined #asahi-dev
MajorBiscuit has quit [Ping timeout: 480 seconds]
___nick___ has quit []
___nick___ has joined #asahi-dev
___nick___ has quit []
___nick___ has joined #asahi-dev
<Knedlik>
Okay so after like an hour, I'm building the fs/ folder
<Knedlik>
Guys I'm not sure how much I will or won't be able to work on the touchbar thing, as someone ruined a bit of my existing work and I'll have to work quite a bit to get it back to the original state. I hope you understand.
<jn>
upstream API changes? (just curious about the ruining)
<Knedlik>
Unfortunately, this was human error
<Knedlik>
Someone completely destroyed my studio's discord server
<marcan>
Knedlik: are you sure you set the MAKEFLAGS properly? did you uncomment the line?
<marcan>
sorry about the discord :(
<Knedlik>
Are you telling me there was a comment I didn't see?
<Knedlik>
Oh my god I'm blind as a blank cartridge
* handlerug
has been downloading the 12.3 pkg for 9 hours already :P
<ChaosPrincess>
so, since i got ignored in dri-devel, anyone knows what am i doing wrong with reporting the display mode? i am calling drm_cvt_mode(connector->dev, size >> 16, size & 0xFFFF, 60, true, false, false); and getting a 48-ish fps display mode instead of 60
<ChaosPrincess>
handlerug: where you downloading it from