02:06 <marcan> from those reports I'm kind of getting the feeling the iBoot mode selection is "pick from a list of hardcoded modes or bail"

02:06 <marcan> which would explain it failing on a bunch of screens

11:12 <kettenis> I must say that even the DCP iBoot interface looks hopelessly complicated

11:13 <kettenis> is the DCP OS interface significantly worse?

13:06 <marcan> kettenis: the DCP OS interface uses nested callback chains and requires a lot more back and forth to do the same thing

13:07 <marcan> and it's more complex marshalling including nested json-like structures in two different binary serializations

13:10 <kettenis> so yes ;)

13:20 <marcan> kettenis: at least the iBoot interface is stable-ish, I think. at least it looks that way.

13:20 <marcan> the OS one can randomly change its ABI entirely with macOS releases

13:28 <alyssa> kettenis: the DCP OS interface is stuff of nightmares

16:29 <sven> huh, looks like the DCP stuff infinite loops or crashes early on when used with <12 (yeah, yeah, I’ll finally upgrade after fixing that)

16:32 <jannau> 11.x without connected display?

16:36 <sven> yes. I think I found the issue

16:36 <sven> dcp crashes and then afk_recv infinite loops

16:39 <sven> https://github.com/AsahiLinux/m1n1/pull/146 should at least prevent m1n1 from getting stuck in an infinite loop

16:40 <sven> yup. DCP crashes with "TTY> rtkit(dcp): Message 1: unsupported subpacket version" but I'm not gonna fix that

16:46 <jannau> it works on 12.0 and timeouts after 2 seconds without connected display. so far dcp was ready after 400 ms with all displays so we should be able reduce the timeout

16:47 <kettenis> sven: works for me on the mini

16:47 <kettenis> TTY> display: Display is already initialized (1920x1080)

16:48 <sven> disconnect your screen

16:48 <kettenis> ah

16:48 <kettenis> missed that detail

16:49 <jannau> I wonder what happens if someone connects a screen with iphone5 dimensions

16:49 <sven> it'll still crash DCP with that fix but at least the proxy continues to work :D

16:50 <sven> jannau: it should just reinitialize that screen then, shouldn't it?

19:32 <kettenis> marcan: I've created a pull request with a change to make m1n1 add the u-boot,dm-pre-reloc properties needed for U-Boot

19:33 <kettenis> that we we don't have to add them to the device trees beforehand

19:51 <jannau> sven: have you seen "xhci_hcd 0000:02:00.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state." before? possibly related to the dart changes in the dcp branch. I see that with 12.0 but not with 12.1. dcp dt nodes are commented out

19:53 <sven> huh, no, I don’t think I ever saw that

19:54 <jannau> err, it's with the usb-a ports so I guess nevermind. if it's dart related it would be PCIe

20:07 <sven> i guess it's just the usb curse again

20:10 <jannau> maybe just a dying usb device

20:12 <alyssa> sven: there goes the "iBoot protocol is stable" theory :v

20:13 <sven> I’m just glad that DCP isn’t my problem ;)

20:15 <alyssa> sven: grumble mumble

20:15 <alyssa> you know I said I was going to work on the M1 GPU driver this afternoon

20:16 <alyssa> mmmaybe i should work on Mali GPUs instead

21:53 <jevinskie[m]> marcan: I’m curious as to why m1n1 is built with -mgp-regs/no FP. Is it not as simple as disabling FP instruction trapping?