<alyssa>
not sure why the DCP is crashing for you when unplugging HDMI
<alyssa>
that works ok for me (on 11.x firmware, I'm scared to upgrade :-p)
<alyssa>
then again, having both 11.x and 12.x coexist for a bit might be a good idea to check that I didn't screw up the versioning
<jannau>
alyssa: it's possible that I broke something or hotplug has to be handled differently with macos 12
<jannau>
with the installer it's at least somewhat reasonable to add a 11.x install before updating to macos 12.1. it needs 2.5G and a copy of the 11.x kmutil
<alyssa>
jannau: both are possible, yes
<jannau>
I was considering if I should keep the 11.4 to 11.6 support for testing. I postponed that for now
<alyssa>
not that I documented it, but the idea with the dcpep tables is that each version gets a table
<alyssa>
and then the apple_dcp struct has a pointer to a table
<alyssa>
that pair of pointers gets set based on firmware version at probe time
<alyssa>
and then any dcp call/back goes through the table pointed to
<alyssa>
on one hand that means two layers of indirection for every call/back
<alyssa>
on the other that means overhead is constant regardless of how many firmware versions we support
<alyssa>
(and this makes it easy to handle cases where semantics stay the same but the numbering is shuffled)
<jannau>
yes, the pointer tables are reasonable, the struct changes are more annoying
<alyssa>
yeah..
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<alyssa>
don't have a good sol'n there
<jannau>
I fear there is none, make the structs version dependent and use unions if they are embedded
<alyssa>
unions don't help if the sizes change..
<alyssa>
in userspace we do crazy metaprogramming to do this stuff with 0 overhead
<alyssa>
that won't fly in the kernel, and also doesn't matter :-p
<jannau>
they help a little with embedding struct dcp_swap_submit_req_11_4 and dcp_swap_submit_req_12_0 in struct apple_dcp
<alyssa>
ah, sure
<alyssa>
i don't know
<alyssa>
i really don't have cycles to work on dcp / m1 kernel stuff right now
<jannau>
no problem, I'll spend some time to improve it
<alyssa>
don't feel obligated
<Jamie[m]1>
waiting for apple to release a superscalar alyssa
<alyssa>
Alyssa is a SIMT architecture with a very large warp size
<alyssa>
Excellent throughput but branching destroys performance.
user982492 has joined #asahi-dev
phiologe has joined #asahi-dev
PhilippvK has quit [Ping timeout: 480 seconds]
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kov has quit [Quit: Coyote finally caught me]
kov has joined #asahi-dev
user982492 has joined #asahi-dev
Dcow has joined #asahi-dev
Dcow has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<marcan>
ok, modesetting works (I think)
<marcan>
now I just need to swap...
Dcow has joined #asahi-dev
Dcow has quit []
akemin_dayo has quit [Ping timeout: 480 seconds]
opticron has quit [Ping timeout: 480 seconds]
opticron has joined #asahi-dev
<marcan>
so you know how iBoot initializes a fake framebuffer at iPhone 5 resolution when there is no display, or now always on >12 on the Mini?
<marcan>
I think I can reuse the existing framebuffer allocation/IOMMU mapping, if I can find the IOVA... I'll probably have to walk the DART page tables for that
<marcan>
I think it's oversized enough to handle 1080p
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
user982492 has joined #asahi-dev
<j`ey>
marcan: yay! gg
user982492_ has joined #asahi-dev
user982492 has quit [Ping timeout: 480 seconds]
jeffmiw has joined #asahi-dev
aleasto has joined #asahi-dev
user982492_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kgarrington has joined #asahi-dev
kgarrington has quit [Remote host closed the connection]
<alyssa>
marcan: why would iBoot make a framebuffer allocation if it doesn't mode set anymore?
<marcan>
alyssa: dummy fb
<marcan>
what I don't know is why it's larger than the actual dimensions in the bootargs *shrug*
<alyssa>
parsing boot args is so much work /s
<alyssa>
marcan: my next question is why the iBoot interface supports YUV
<alyssa>
and.. ooh.. AGX tiling..
<alyssa>
(or AGX compression I guess)
<marcan>
alyssa: *shrug*
<marcan>
alyssa: it also supports getting and setting properties, brightness, color matrix
<marcan>
it's... surprisingly complete
<marcan>
but has gaps, like the mode structure sucks and is missing lots of details
<alyssa>
wild
<alyssa>
marcan: now that you've looked through EPIC stuff
<alyssa>
any idea how hard e.g HDMI audio is?
<marcan>
alyssa: EPIC isn't that hard, but it's just completely different from the existing DCP stuff
<marcan>
I'm streaming a m1n1 EPIC implementation right now...
<marcan>
not sure what backs the audio though
<marcan>
the infoframe stuff is EPIC
<marcan>
actual audio streaming is some other story
<marcan>
(different hardware)
<alyssa>
bah :p
<alyssa>
hmmmmm do I work on the GPU driver or do literally anything else...
<Jamie[m]1>
you gotta stop asking such a biased audience
<Jamie[m]1>
which is to say: gpu driver :3
<alyssa>
hmmmmMmmm
* alyssa
kinda just wants to lay down
<Jamie[m]1>
hmmm that is also appealing
<alyssa>
alas
akemin_dayo has joined #asahi-dev
MajorBiscuit has joined #asahi-dev
aleasto has quit [Quit: Konversation terminated!]
aleasto has joined #asahi-dev
MajorBiscuit has quit [Quit: WeeChat 3.3]
aleasto has quit [Remote host closed the connection]
aleasto has joined #asahi-dev
aleasto has quit [Remote host closed the connection]
aleasto has joined #asahi-dev
aleasto has quit [Quit: Konversation terminated!]
aleasto has joined #asahi-dev
aleasto has quit []
aleasto has joined #asahi-dev
aleasto has quit []
aleasto has joined #asahi-dev
<alyssa>
marcan: the COMPAREs for timing mode, i think the <= / >= is flipped for the 60Hz and 1920 pixel checks?
<marcan>
it's not
<marcan>
it's excluding >60Hz and >1080p
<marcan>
or rather demoting
<alyssa>
...why is that beneficial?
<marcan>
because I can't test larger :p
<alyssa>
~sounds like a you problem~ :-p
<marcan>
at least on my crappy capture card it brings up virtual 4K modes and there is no indication that they're virtual in this interface
<marcan>
feel free to test 4K, but whatever you do needs to not do that on my card :p
<j`ey>
do we need 4k for grub? :P
<alyssa>
j`ey: yes! :p
<marcan>
considering m1n1 is memcpying the framebuffer around for every log, we probably don't
<jannau>
might be beneficial to shrink the fb and configure 2x upscaling for high DPI displays
<marcan>
eh, could be, but is the DCP upscaling going to be that much better than the display's for a bootloader?
<j`ey>
I'd like that, Im finding the m1 air screen too small
<jannau>
the imac announces just the native mode with almost a 12M pixel display
<alyssa>
dcp scaling sounds like your friend there yes
aleasto has quit [Quit: Konversation terminated!]
King_InuYasha has joined #asahi-dev
<jannau>
trying to select 1920x1080@60 seems to be the least bad option with the limited information provided
<jannau>
for both monitors I tried knowing the native resolution is the only method I see to select the correct mode
<jannau>
but it manages to display something on an old dell 4:3 display and list the native mode 1600x1200@60. macos 11 iboot didn't initialize that display