10:44 <j_ey> marcan: that looks like someting good for a stream ^_^

10:45 <j_ey> (also your hexdump has colours now, fancy)

10:45 <j_ey> or is that a diff.. cool

11:07 <marcan> j_ey: it's been in proxyutils since the dark ages, pretty sure it dates back to the wii or at least wii u

11:07 <marcan> RegMonitor :)

11:07 <marcan> though I'm using it on shared memory here, made a few changes to have it read memory through the DART translation

11:07 <marcan> also added ASCII (didn't need that for registers)

11:07 <j_ey> cool, in fact i think I vaugely remember seeing it from some of the earliest streams now

11:07 <j_ey> but anyway, doesnt make it less cool >:D

11:07 <marcan> yeah, I used it with AIC

11:08 <marcan> I'll do a stream shortly

11:08 <marcan> I mostly solved all the mysteries of the IOP commands; it really is all in shared memory, there are just separate blocks and the pages aren't physically contiguous

11:09 <marcan> diffing big chunks in IOVA address space instead of dumping just the head page made everything show up

11:09 <marcan> there are at least two if more more command/buffer protocols involved here :p

11:09 <marcan> so now time to implement that

11:10 <marcan> the whole thing is uber slow now because I dump *all* of the endpoing buffers in their entirety on *every* command :D

11:10 <j_ey> well it's not like you need to interact with macOS much, I hope!

11:10 <marcan> not for the startup stuff, and once I have the actual command protocol interpreted it'll be much lighter of course

11:10 <marcan> right now it's just dump the world every time to see what's moving

13:53 <bloom> marcan: woot woot

14:03 <bloom> marcan: The IOKit parsing thing scares the living bajeebus out of me.

14:05 <bloom> Though maybe with luck we only need to ingest a small, fixed subset to avoid an entire parser (in favour of just some magic offsets etc)? I don't know, I really don't want to see a string-indexed hash table in the middle of the display driver.

14:20 <marcan> bloom: hardcoding offsets is a no-go, that's going to break badly with firmware changes

14:20 <marcan> we might be able to get away with a reduced parser that only follows the expected parts of the structure and ignores the rest though

17:16 <j_ey> marcan: did you get anywhere in the last 1-2hours of the stream?

17:19 <marcan> j_ey: I think I got the general idea for messages right, though some things are still a bit strange

17:19 <marcan> all pushed

17:20 <marcan> https://hub.marcan.st/t/dcplog.txt if anyone wants to stare at it

17:21 <j_ey> mfw text makes your browser stutter a little

17:22 <j_ey> marcan: is the goal of this more about the IOP / mailbox stuff, than dcp?

17:23 <j_ey> Im not sure exactly what settings / commands you'd need from DCP

17:23 <marcan> both

17:23 <marcan> we still need to implement DCP

17:24 <j_ey> cya

17:47 <bloom> marcan: Do we err have to deal with DCP fw updates? I guess so but that really sucks.

17:48 <bloom> I worry in general about linux drivers being a moving target if we can't pin a specific version .. and if the fw is non-redistributable i guess we can't ...

17:51 <bloom> marcan: I'm still not sure your shared mem stuff is right

17:51 <bloom> 00000000 44 69 73 70 6c 61 79 50 69 70 65 53 74 72 69 64 |DisplayPipeStrid|

17:51 <bloom> 00000010 65 52 65 71 75 69 72 65 6d 65 6e 74 73 00 72 61 |eRequirements.ra|

17:51 <bloom> 00000030 52 54 4b 53 54 41 43 4b 52 54 4b 53 54 41 43 4b |RTKSTACKRTKSTACK|

17:51 <bloom> 00000020 6d 65 74 65 72 73 00 4b 52 54 4b 53 54 41 43 4b |meters.KRTKSTACK|

17:51 <bloom> RTKSTACK is very clearly not part of the message ...

17:51 <bloom> Unless the whole message is /just/ the string "DisplayPipeStrideRequirements" and nothing else.

17:52 <marcan> bloom: seems to be just that string

17:52 <marcan> don't ask me why

17:52 <bloom> fair enough

17:52 <marcan> I think it might be a registry notification

17:52 <marcan> "this property changed"

17:52 <bloom> so just missing a size field somewhere?

17:53 <marcan> it's 00 terminated

17:53 <marcan> probably a fixed sized uninitialized buffer they strcpied a string into or whatever

17:53 <bloom> awful ;p

17:53 <j_ey> RTK STACK?

17:53 <j_ey> RT Kit Stack?

17:53 <marcan> that seems to be what they fill the stack with

17:53 <bloom> j_ey: RTKit stack, that's their version 0xDEADBEEF

17:53 <marcan> yes

17:53 <bloom> "ADP is generic pipe"

17:54 <bloom> What's ADP?

17:54 <bloom> "Generic pipe"

17:54 <bloom> not helpful

17:54 <j_ey> ceci n'est pas une generic pipe

17:54 <marcan> bloom: we can pin the version btw

17:54 <marcan> AIUI Apple tends to leave their OSes up forever, and M1s don't have hard call home requirements, you can run OSes in permissive mode

17:55 <marcan> so all we need to do is have our installer slurp the blobs from their site if it comes to that

17:55 <bloom> j_ey: lolololol

17:55 <bloom> marcan: ack

17:55 <marcan> (but I kind of hope this is backwards compatible to some extent)