chadmed has quit [Remote host closed the connection]
chadmed has joined #asahi-dev
yuyichao_ has quit [Ping timeout: 480 seconds]
jbowen has joined #asahi-dev
jbowen has quit [Ping timeout: 480 seconds]
yuyichao_ has joined #asahi-dev
PhilippvK has joined #asahi-dev
jbowen has joined #asahi-dev
jbowen has quit [Ping timeout: 480 seconds]
ChristianOndaatje[m] has joined #asahi-dev
jbowen has joined #asahi-dev
jbowen has quit [Ping timeout: 480 seconds]
the_lanetly_052 has joined #asahi-dev
espo has joined #asahi-dev
chadmed has quit [Read error: No route to host]
chadmed has joined #asahi-dev
jbowen has joined #asahi-dev
jbowen has quit [Ping timeout: 480 seconds]
pbc has joined #asahi-dev
pbc has quit [Ping timeout: 480 seconds]
Major_Biscuit has joined #asahi-dev
Major_Biscuit has quit [Ping timeout: 480 seconds]
<maz>
jannau: the only solution I have so far is to hack grub to provide a different DTB per kernel. i really hope we won't have to do that too often...
<kettenis>
won't work, since you'd miss the modifications that m1n1 makes
<kettenis>
although with the minimal hardware support that 5.16 and 5.17 have you may actually get away with that
<ChaosPrincess>
oh, so thats why wifi broke on my machine when i tried to override the dtb
IbrahimMAkrab[m] has joined #asahi-dev
<maz>
kettenis: yeah, this is a massive hack, and it may not even be reliable (nothing says that the CPU release addresses are constants).
klaus has joined #asahi-dev
Major_Biscuit has joined #asahi-dev
jbowen has joined #asahi-dev
MajorBiscuit has joined #asahi-dev
Major_Biscuit has quit [Ping timeout: 480 seconds]
jbowen has quit [Ping timeout: 480 seconds]
<jannau>
bummer, I guess for 5.17 we need a way to force APPLE_PMGR_PWRSTATE on. Not sure how exactly, I guess every driver using device nodes with "power-domains" needs to to depend on APPLE_PMGR_PWRSTATE
<jannau>
the kernel still works without APPLE_PMGR_PWRSTATE but is mostly useless since no hardware is available
gabuscus has quit [Ping timeout: 480 seconds]
gabuscus has joined #asahi-dev
aleasto has joined #asahi-dev
roxfan has quit [Remote host closed the connection]
roxfan has joined #asahi-dev
<kettenis>
how do other SoCs make sure their clock/reset/powerdomain drivers are enabled?
<kettenis>
isn't it just a matter of something like:
<kettenis>
default y if ARCH_APPLE
<kettenis>
in the appropriate Kconfig file?
<chadmed>
thats how broadcom does it at least, afaik
<sven>
pretty sure we already have default ARCH_APPLE for APPLE_PMGR_PWRSTATE
<_jannau_>
I think the default Y is already there
<chadmed>
ARCH_APPLE already enables all the mission critical stuff. the only thing i had to enable myself was ANS2
<chadmed>
we should probably turn that on automatically if ARCH_APPLE and NVME are both set to Y. i doubt anyones going to want to compile in nvme and not have ans2 come with it
espo_ has joined #asahi-dev
espo__ has joined #asahi-dev
espo has quit [Ping timeout: 480 seconds]
espo_ has quit [Ping timeout: 480 seconds]
chadmed has quit [Read error: Connection reset by peer]
chadmed has joined #asahi-dev
espo_ has joined #asahi-dev
espo has joined #asahi-dev
espo__ has quit [Ping timeout: 480 seconds]
espo_ has quit [Ping timeout: 480 seconds]
espo has quit [Quit: Leaving]
chadmed has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #asahi-dev
* alyssa
tries to boot new kernel
<alyssa>
did the err way to boot change why is m1n1 mad at me
<alyssa>
jannau: ^
<alyssa>
m1n1 is spamming exceptions at me trying to boot
<alyssa>
oh right need to chainload m1n1 maybe
<alyssa>
ok, chainloading m1n1 first now I am stuck at the Asahi logo ..
<alyssa>
interestingly my USB lights up so I guess Linux did boot a little bit
<alyssa>
oh right DCP firmware ABI
<_jannau_>
alyssa: still using 11.x? revert 6d4a4d359928ad15084b1addd965d2b78bb8635c and bcc0fa44ebd5ce11c2b1964b0952cf918965f5b1
<alyssa>
yep right
<alyssa>
wondering why git rebase -i is giving me ridiculous things
<alyssa>
oh the merge commits ok
<alyssa>
Now is probably the time to update to 12.x but one thing at atime
<alyssa>
_jannau_: it works! :-)
<alyssa>
5.16.0-asahi-next-20220108m1+
<alyssa>
No Wi-Fi, mumble
<alyssa>
new name okay
<alyssa>
I guess I should really use marcan's extractor now
<_jannau_>
someone is slacking on the smc gpio driver, so the wifi device has to be enabled either by pcie_enable_devices.py in proxyclient/experiments or u-boot
<alyssa>
_jannau_: I already had smc.py in m1n1 for that :-p
<alyssa>
"ImportError: attempted relative import with no known parent package" grumble
<_jannau_>
ah, ok then it is one of the needed files for the brcmfmac driver, not just the firmware
<alyssa>
python3 -m firmware.wifi i guess
jbowen has joined #asahi-dev
<alyssa>
ummmm
<_jannau_>
also make sure you have the user space fallback firmware loader disabled. the driver ask for so many alternate names that the 1 minute timeouts results in waiting over 15 minutes until all firmware is loaded
<alyssa>
*thinking*
<alyssa>
that sounds.. not great...
<alyssa>
why is DCP not coming up now... it was a boot ago
<alyssa>
gah now it's not
yuyichao_ has quit [Ping timeout: 480 seconds]
<alyssa>
it boots under the hypervisor >.<
<alyssa>
wtf...
<alyssa>
Oh, fun. Got the back trace. enumerate_modes is crashing
<alyssa>
trying to load modes[best_id].mode.type if I'm reading the assembly right
<alyssa>
Oh, I see the bug
<jannau>
you have virtual modes with an higher score than non-virtual modes?
<alyssa>
jannau: Possibly, but the actual issue is sillier
<alyssa>
still seeing cs42l42 fail probing, also mca says "no rx DMA channel at /soc/mca/route{2} (lookip returned -19)"
<alyssa>
err
<povik>
that mca message is mca being happy, just doesn't know how to express it
<alyssa>
povik: so why don't I have any alsa devices hm
<povik>
because cs42l42 failed to probe obviously :-p
<alyssa>
ah well
<alyssa>
and that's failing because errrrrr
<povik>
you tell me
<alyssa>
"No cache used with register defaults set" maybe
<povik>
no that's ok
<alyssa>
and then Get Device ID failed
<Glanzmann>
alyssa: Are you on the latest and gratest 12.0.1 stub?
<alyssa>
Glanzmann: No, this is still 11.x .. which I thought worked but maybe not, was trying to do one breaking thing at a time
<Glanzmann>
alyssa: I'm not sure if that is a problem, but that is what I would try. On my mini with the config on the desktopkernel wiki page, sound works.
<povik>
i don't think that probe issue can be related to config
<povik>
just alyssa being unlucky with that codec i2c breakage that still haunts us
<alyssa>
i do have the touch
<alyssa>
meh whatever, DCP+wifi works that's good enough
<alyssa>
out of spoons
willemml has joined #asahi-dev
willemml has quit [Remote host closed the connection]
willemml has joined #asahi-dev
willemml has quit []
willemml has joined #asahi-dev
Gaspare has joined #asahi-dev
espo has joined #asahi-dev
espo has quit [Ping timeout: 480 seconds]
the_lanetly_052__ has joined #asahi-dev
Gaspare has quit [Read error: Connection reset by peer]
the_lanetly_052 has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #asahi-dev
espo has joined #asahi-dev
okt has left #asahi-dev [#asahi-dev]
MajorBiscuit has quit [Ping timeout: 480 seconds]
<jannau>
wow, adding a cursor plane in the dcp driver just works
<Glanzmann>
jannau: What is a cursor plane? Do you have a screenshot?
<jannau>
dcp has 3 or 4 planes which are composited and blended together in hardware. one is the primary plane which holds the framebuffer of what you consider the screen content
<jannau>
without cursor plane that frame buffer has constantly updated when the mouse cursor moves
<jannau>
the cursor plane holds just the mouse. those to planes are then blended in hw. that means neither of the buffers have to be updated on mouse moves. only the position of the mouse cursor overlay is updated
<jannau>
doesn't work 100% though, the mouse cursor can not be moved completelt to the right or bottom edge
<sven>
i vaguely remember alyssa talking about that issue (and maybe even suggesting a workaround)
<sven>
something about create a bigger cursed by passing that plane maybe? It’s been a while
<sven>
*cursor
<sven>
and s/passing/padding/ :(
<jannau>
I remember that as well, the cursor fb can't move off screen iirc
willemml has quit [Quit: willemml]
willemml has joined #asahi-dev
___nick___ has joined #asahi-dev
___nick___ has quit []
willemml has quit [Quit: willemml]
___nick___ has joined #asahi-dev
willemml has joined #asahi-dev
willemml has quit [Quit: willemml]
<j`ey>
jannau: sounds interesting, does drm have some native concept for a cursor plane, or how do you hook it up?
<agraf>
jannau: Nice, does that work automatically with xv as well? :) I remember that was the mechanism of the day ~20 years ago to overlay video inside a window quickly. Feels so out of touch now that everything is texture rendered
<agraf>
jannau: Also, what happens when you move towards the edge? It just won't keep moving, so the cursor stays fully displayed while it should be half hidden?
<jannau>
agraf: xv == xvideo extension? hopefully not with the cursor plane. but we can support overlay planes and wayland compositors should support that. I forgot most details about X11 already
<agraf>
jannau: if it only has 4 total, that leaves 2 generic overlay panes to use, no? :)
<agraf>
And yes, xvideo. Obviously not with the cursor pane but with a generic one. But I assumed you implement generic pane support in the DRM driver?
<jannau>
the cursor remains fully on the screen and is not clipped. it is just not rendered when the cursor fb needs to be clipped
yamii has quit [Quit: WeeChat 3.3]
<agraf>
Oh, so the whole screen stops rendering?
<jannau>
we are not sure if there 3 or 4 planes. the horrid dcp co-processor API had only 3 planes in 11.x but has 4 in 12.x
<sven>
Wasn’t there some limitation where the DCP could only blend two planes and macOS just ended up fusing the cursor into the bg plane?
<sven>
or maybe it was three :D
<jannau>
so it's possible that only the dcp in the m1 pro/max have 4 planes
<jannau>
I think nobody has looked into it yet
<sven>
yeah, or maybe the hardware supports 4 but the DCP firmware didn’t and they fixed that
<jannau>
I haven't check what happens on macos with vidoe playback
<sven>
I vaguely remember that there was some way to force it to blend the cursor in software
<jannau>
there was some cursed behavior wrt the cursor and blending, maybe macos switches to sw blending when the cursor is clipped
<sven>
hm.. could be
<jannau>
agraf: I assume just the cursor is not rendered. desktop was static so I can't tell if it's updated
<j`ey>
was it marcan that streamed some cursor/dcp stuff? I remember something with a pink cursor
<agraf>
jannau: I see :). Well, definitely something you can work around by blending manually I guess. Or fiddling with the overlay plane's size & contents.
<jannau>
yes, it's only the cursor that vanishes. video playback on the primary plane is not affected
<jannau>
just lying about the width and height of the cursor buffer doesn't seem to work
timokrgr has quit [Quit: User left the chat]
chadmed has joined #asahi-dev
timokrgr has joined #asahi-dev
chadmed has quit [Ping timeout: 480 seconds]
<alyssa>
jannau: I wrote support for cursor planes in the DCP driver, then deleted the part where I actually add a cursor plane because it's broken as you discovered shortly there after.
<alyssa>
sven: I believe the M1 has 2 planes only, although the 11.x ABI has 3 and 12.x ABI has 4. I imagine M1 Pro/Max has 3 or 4 planes.
<krbtgt>
xv? sure, i wanna view some PNGs on my Sun3
<alyssa>
jannau: The problem is not clipping /per se/, broken clipping is a symptom of the real hardware limitation -- DCP planes must be at least 64x64
<alyssa>
(or maybe it was 32x32, forget the details)
<alyssa>
at the same time, DCP doesn't allow partially off screen planes so we're forced to shrink the width/height when clipping
<alyssa>
The interaction of those constraints means that sufficient clipping causes planes to shrink below the minimum size.
<alyssa>
...which causes wonky scaling or faulting (depending on conditions).
chadmed has joined #asahi-dev
<alyssa>
There are a few ways to workaround but they're all ugly so I was planning to delay overlay/cursor plane support until after the core mode set code is merged.
MajorBiscuit has joined #asahi-dev
willemml has joined #asahi-dev
klaus has quit [Quit: Lost terminal]
<jannau>
can we easily overallocate the framebuffer? i.e. allocate 128x128 if userspace wants a 64x64 cursor, expose only the bottom right quadrant as cursor and keep the rest transparent?
<jannau>
that would be the least ugly solution I can think of
<alyssa>
mmh
<alyssa>
when I thought through it, I ran into other difficulties unless I eat the cost of blitting in edge cases
aleasto has quit [Quit: Konversation terminated!]
<alyssa>
although... overallocating /at the start/ and playing games with the stride and playing games with the coordinate system... for linear planes (which includes cursors)... might actually work?
<alyssa>
That saves the blit, needs some more gymnastics for memory management but... yes, in principle I think that approach is ok, nice one :)
<jannau>
probably still worth postponing it to after the initial merge
<alyssa>
yeah, I think so
<alyssa>
I woul really love to see this driver cleaned up and merged ... I can't say I would love it enough to finish that work myself though 😅