13:58 <alyssa> marcan: Do we know why the DCP exists? IIRC the early (S5L) iPhones managed the display directly from the AP, the DCP was added for some presumably good technical reason. Do we know what it is? (And recursively, why the DCP has a copro of its own)

13:59 <alyssa> It doesn't necessarily change our lives at this point (if specific functionality can only be done with the DCP), I just am trying to understand what motivated Apple to design the copro at all

14:25 <marcan> alyssa: we do not

14:25 <marcan> and the fact that there is a whole driver kext for *M1* silicon that does not use DCP suggests that was certainly in the cards at some point

14:26 <alyssa> which kext was that..?

14:26 <marcan> one good reason, though, would be to allow the main CPU to go to sleep for extended periods of time. I wouldn't at all be surprised if DP/HDMI protocol bullshit required the DCP to wake up for every frame under some circumstances.

14:26 <marcan> (even if no swap requests were made)

14:27 <marcan> see AppleMobileDispH13G-DCP.kext vs AppleMobileDispH13G.kext

14:28 <alyssa> Alright

14:28 <alyssa> FWIW AppleMobileDispH13G-DFR.kext is for the touch bar

14:28 <alyssa> So plausibly it uses both kexts depending which display

14:28 <marcan> ah, I was wondering about DFR

14:28 <marcan> IIRC the display hardware for that thing is different

14:28 <marcan> so that makes sense

14:29 <marcan> I don't think DCP has anything to do with the touch bar

14:29 <alyssa> Dynamic Function Row

14:29 <marcan> ha

14:30 <marcan> also see IOMobileGraphicsFamily.kext vs IOMobileGraphicsFamily-DCP.kext

14:30 <marcan> which have the other half of the driver

14:31 <marcan> you can piece together the DCP firmware from existing kexts, e.g. parts of IOAVFamily.kext are in there too

14:33 <marcan> AppleMCDP29XX.kext is in there too etc

14:36 <marcan> look for all the *Proxy.kext ones too; those are proxies to specific DCP endpoints

14:37 <marcan> seems the RPC system for those is called "EPIC" and I hope it's less insane than the main DCP one

14:55 <alyssa> This is horrifying, you know?

14:56 <marcan> alyssa: *shrug* nothing surprises me any more

14:58 <alyssa> marcan: I just..

14:59 <alyssa> If I were an upstream DRM maintainer with no especial interest in Apple, and if the patches were coming from @apple.com developers, it'd be a "hard no" unless there was an _overwhelming_ reason to have the layers of crap.

15:00 <marcan> of course it would be

15:00 <marcan> but we don't have that luxury :p

15:00 <marcan> it is completely evident this was made for macos and only for macos

15:02 <alyssa> ..so I'm wondering how upstream will feel about this from @marcan.st and @rosenzweig.io addresses :|

15:03 <marcan> I mean... it's either this or no M1 support

15:03 <marcan> so far nobody hates me in #dri-devel at least

15:04 <alyssa> They haven't seen the RPC list yet ;-P

15:04 <marcan> I did paste the RPC dump there

15:05 <j_ey> it might be possible that not all of the RPC is needed? maybe a subset can be used?

15:06 <sven> or "just" reverse engineer that RTKit firmware crap and write a driver that does MMIO pokes :P

15:06 <alyssa> "just"

15:09 <marcan> sven: you wanna sign up to write the displayport training and bandwidth calculation code?

15:09 <marcan> :p

15:10 <marcan> both of those are on my list of things I sure hope I don't have to touch because I don't even know how you would cleanroom that

15:10 <marcan> (without docs)

15:12 <sven> i.. uh... so maybe that RPC protocol isn't as ugly as it looks :P

15:12 <alyssa> lololol

15:25 <marcan> sven: to be fair it's not *that* bad. I think we can ignore a lot of the crap macos calls

15:26 <marcan> and a lot of the callbacks are bullshit, like registering/looking up iokit stuff that just has to return "true"

15:27 <marcan> https://mrcn.st/p/W4ijTdUF like the beginning of that boils down to "return true" crap, a bunch of property updates, and then another big nested callback where the AP starts doing stuff

15:27 <marcan> and that stuff is more init calls with no args, some memory management thing, and that's about it

15:28 <marcan> then there's the big dcpav prop dump

15:28 <marcan> and that's the end of init

15:28 <marcan> then there's thrashing because for some reason it detects a display hotplug (this might be related to HDCP crap or my capture card)

15:29 <marcan> then finally more easy no-arg calls, a writeDebugInfo thing we can surely ignore, some power management stuff, and finally IOMobileFramebufferAP::set_digital_out_mode which again causes a big prop thrash

15:30 <marcan> then it stats doing swaps; the first time it does some interesting things with configuring the color matrices etc, there's also a generic "set_block_dcp" which might well be raw reg writes

15:30 <marcan> and that's it, then it starts submitting surface updates

15:32 <marcan> the set_block_dcp stuff looks like float arguments, which is interesting

17:45 <alyssa> marcan: So you'll have reference code in mini by Tuesday? 😉

17:46 <alyssa> And then have it cleaned up by Friday morning so I can wrap it with DRM stuff and have the patch set merged to drm-misc-next by Sunday night? 🙃

17:46 <TheLink> sounds like programming oss is like working for a black company

17:48 <alyssa> ?

18:30 <cyrozap> I think TheLink is referring to this: https://en.wikipedia.org/wiki/Black_company_(Japanese_term)

18:34 <alyssa> cyrozap: Ahhhh

18:34 <alyssa> TheLink: actually programming oss is a lot of waiting for other people to review your code

18:34 <alyssa> more so than actually writing code

18:35 <TheLink> I was just making fun of your proposed schedule for marcan

18:35 <TheLink> I'll frfrain from doing son again, sorry

18:36 <TheLink> *refrain

18:36 <TheLink> *so

18:37 <jn> TheLink: jokes and humor are ok, we just failed to undestand this one

18:38 <TheLink> yeah, my anime "knowledge" sometimes gets in the way of getting the message thru ;)

18:46 <alyssa> Making fun is okay, I'm just a boring North American :-p

19:39 <TheLink> Germans aren't supposed to be funny so that might be it, too :)