00:00 <jannau> https://github.com/jannau/linux/tree/asahi-dcp - experimental, I could not mount the root fs with macos 12.0.1 for errors which looked like memory corruption

00:00 <jannau> probably works only on mac minis

00:03 <jannau> porting involved just updating the API to the one documented in m1n1's tracer and powering the output on

00:32 <marcan> _jannau_: it should work with bputil -r (or whatever the reduced mode option was)

00:32 <marcan> bputil will *create* the boot policy for you

00:32 <marcan> and do a bunch of what startup disk does

00:32 <marcan> I'm going to add that to the installer since it's required to insulate us from the phone home requirement

00:32 <marcan> just haven't gotten around to it yet

00:33 <marcan> and yes, I did confirm that the API didn't change in 12.0 final

00:54 <jannau> now that the dcp driver "works" on 12.0 final and 12.1 my interest in 12.0 beta releases has vanished

00:55 <jannau> I tried with to create the boot policy but I don't think I tried bputil -r

00:59 <marcan> jannau: you can't go to permissive mode in 12.x without being paired, but you can go into reduced mode

00:59 <marcan> hence why it's a two-step process

01:00 <marcan> either way last night I think I understood the IPC call stack for the iBoot/disp0 endpoint well enough

01:00 <marcan> going to try writing a python client today

01:00 <marcan> leave it to apple to require 5 protocol layers on top of a mailbox to *turn on the screen from the bootloader*...

01:01 <marcan> (mailbox -> ring buffers -> EPIC header -> sub header -> command header -> shared memory buffers containing commands

01:01 <marcan> )

01:02 <marcan> and for the other endpoints there's like an extra ipcx header layer, but I *think* iBoot doesn't do that? need to look at that function again, I spent all my time figuring out what layer of the protocol stack it sat at

01:03 <marcan> I also found a lot of juicy low level commands in the other endpoints; this is, apparently, how you do things like configure audio modes, send InfoFrames, handle HDCP, DisplayPort training and configuration and link width, etc

01:03 <marcan> so we're probably going to have to implement this EPIC thing in Linux too

01:08 <jannau> sigh, so the complexity might a valid reason to remove hdmi initialization from iboot

01:09 <jannau> experiments/dcp.py probably misses just a setPowerState to work with 12.0 final and 12.1

04:36 <marcan> jannau: nah, iboot still talks to the other endpoints, and it needs to do that on the laptops anyway

11:11 <jannau> the xorg modesetting driver causes swaps without surface which dcp doesn't seem to like

12:07 <kettenis> the terminology always confuses me, but what is it (the xorg modesetting driver) trying to achieve with that?

12:15 <jannau> I would guess it tries to clear the screen or it's simply how it works. I'm not really familiar with drm/kms internals

12:25 <kettenis> and unfortunately the whole drm/kms interface is woefully underdocumented and its internals are changing at a crazy pace

12:34 <jannau> hmm, I think the problem is that it tries to set the current mode again and the dcp driver does a swap if the mode does not change

12:37 <sven> there’s #dri-devel on this server fwiw

17:21 <jannau> Xorg working as well now. the modesetting driver selects a random mode without EDID. for some reason 1400x1050 and setting that mode fails

17:22 <jannau> avoided by marking the best scored mode as preferred

18:52 <marcan> < 02:0x50000000000000

18:52 <marcan> [syslog] * [PIbootInterface.cpp:254]setPowerRequest

18:52 <marcan> > 02:0x50000000000000 (TYPE=0x5, INDEX=0x0)

18:52 <marcan> ok, getting *somewhere* with the iBoot interface

18:52 <marcan> still no video, probably need to work out the setvideomode thing

18:52 <marcan> night, hopefully I can wrap this up tomorrow (at least the prototype, but doing the proper m1n1 version shouldn't be that hard)