02:44 <marcan> amada95: three separate subsystems. speakers are on the way and we don't need any extra hands right now. povik is working on mics, that involves AOP/LEAP. webcam is completely unrelated and involves reverse engineering the ISP firmware command interface first, then implementing all that.

02:45 <marcan> jannau: do you think there's a chance the DISP0 routing stuff was always there on M1 too, and it's just that iBoot always initialized it for us since it used to have HDMI out support back in the day?

02:46 <marcan> I ask because I *do* know iBoot talks to EPIC endpoints other than the iboot one AFAIK, and we have binaries for iBoot on M1, so I can throw it in ghidra if you think it might be useful.

02:46 <marcan> but if we know for a fact M2 is different and not just missing more init code, that might not be useful

05:29 <amada95> Thanks for the info! I'll keep an eye on the wiki for any yaks in need of shaving :)

07:01 <sven> DCP doesn’t go through the crossbar on M1

07:02 <sven> but it does on M2 so there’s certainly something different

08:25 <jannau> see 'dp-switch-ufp-endpoint' in dcp and dcpext in j473's adt

08:31 <jannau> not entirely sure how the crossbar/switch works though. the dp2hdmi converter has no dpxbar so switching seems to be entirely controlled by dcp*

08:33 <jannau> marcan: if you're looking with ghidra it would help to find out under which conditions dcp logs: "syslog: [nifiedPipeline.cpp:6906]VideoInterface::Plug callback: AP not ready yet, mark hot-plug pending"

08:39 <jannau> if you want to try I can push m1n1 with dptx and 13.2 tracing

08:54 <sven> does DCP have the dptx endpoints? There’s that init connection call or however it’s called that also takes the target ATC as arguments

09:00 <jannau> yes, it has (only looked at M2) and that works. but that looks more like an output mux. each atc has its own crossbar for dp-altmode and the two thunderbolt dp tunnels

09:10 <sven> yeah, I just assumed that you set that output mux to „dp2hdmi“ and then it just works

09:11 <sven> and at least on m1 the dptx endpoints for DCP just don’t exist and that connectTo call sounds like the proper place to setup the routing

09:11 <sven> just guessing here though since I only have this m1 ;)

09:14 <jannau> dptx on m2's dcp works like on dcpext

09:16 <sven> makes sense since it needs to be able to route to atcphy as well

09:16 <jannau> there is either something missing or it doesn't work with the iboot interface, see the "AP not ready yet" syslog message

09:16 <sven> oh, dptx never worked correctly with the iboot interface for me fwiw

09:17 <sven> iirc I either never got modes or hotplug just didn’t go through

09:17 <sven> I tried to debug that for days and then when I switched to the real iomfb it worked almost immediately

09:59 <marcan> well it works on laptops so there is *some* way to do it

10:11 <sven> my comments only refer to m1 fwiw

10:11 <sven> And dptx is only present on dcpext there

10:26 <ChaosPrincess> is there a way to block writes to a memory location with m1n1? i want to change some writes into nops and see what breaks

10:32 <ChaosPrincess> nvm, found it