R1811 Driver Board (DP1.4 DSC) with iMac15,1 and MacBookPro18,3
So just got the driver board in about an hour ago so haven't done extensive testing, but from first impressions everything looks to be doing well with the iMac15,1 panel using my 14" MacBook Pro.
At least from first testing, 10bit/DSC does look to be functional:
View attachment 1949638
However using
@joevt's AllRes utility, I see that only 8bit is set (full report attached below):
Code:
{ Monitor 1
Monitor 1 - current mode by CGS = 26
38: id:38:0x00000026 2560x1440@60.000Hz 60Hz (dens=2.0) active:5120x2880 resolution:183x183 64bpp 16bpc 3cpp rowbytes:20480 depthFormat:7 IOFlags:2000007 flags:2000007 encoding:--------RRRRRRRRGGGGGGGGBBBBBBBB refreshRate.unk0.unk1:003c0000.0000.00000001
Monitor 1 - current mode by CGDisplayCopyDisplayMode
38: id:0x00000026 2560x1440@60.000Hz (dens=2.0) active:5120x2880 resolution:183x183 64bpp 16bpc 3cpp rowbytes:20480 IOFlags:2000007 flags:(gui usable,hw safe,ui suitable,) depthFormat:7 encoding:--------RRRRRRRRGGGGGGGGBBBBBBBB
Monitor 1 - current mode by CGDisplayCurrentMode
38: id:0x00000026 2560x1440@60.000Hz (dens=2.0) active:5120x2880 resolution:183x183 32bpp 8bpc 3cpp rowbytes:20480 IOFlags:2000007 flags:(gui usable,hw safe,øøøøø) depthFormat:ø encoding:ø
} Monitor 1
So a little confused why the image seems to be rendering at 10bit correctly while the preview window is rendering at 8bit (which is expected).
With regards to using it as a normal monitor, it's honestly great. One of the brightest and most colourful monitors I've ever used. I went for the DP1.4 DSC board namely because I heard DDC is more reliable, which I can confirm is the case. Only real complaint is the fan, a bit noisy so will most likely swap it for a Noctua fan at some point. My temporary solution is to not use the USB-C port (as the 65w charging really heats it up)
However the strangest issue I noticed this morning is that the 5k iMac will max the fans out and throttle itself if you unplug the display. I hadn't thought this could be an issue, which kinda defeats the whole purpose of keeping the iMac alive but headless. Fan control didn't work and saw kernel task at 250%+. Will try to mess around on the weekend with that.
Bonus pick of the system in use:
View attachment 1949654
I haven't seen AllRez output from M1 Macs before. M1 Macs do display modes differently than Intel Macs.
On your M1 Mac:
- All the methods (CGDisplayAvailableModes, CGDisplayCopyAllDisplayModes, CGSGetDisplayModeDescriptionOfLength) return 79 modes and the id matches the mode number.
- CGDisplayAvailableModes reports them all as 8bpc but the other two report 16bpc.
On Intel Macs:
- CGDisplayAvailableModes returns a single mode for each resolution and reports 8bpc for all of them. The modes do not include info about pixels (depthFormat, encoding). The mode numbers are odd numbered.
- CGDisplayCopyAllDisplayModes returns two modes for each mode from CGDisplayAvailableModes. One for 8bpc and one for 10bpc. The modes include info about pixels (depthFormat, encoding). The even numbered modes are 8bpc and the odd numbered modes are 10bpc.
- CGSGetDisplayModeDescriptionOfLength returns all modes (modes that have flags 0x200000 = kDisplayModeValidForMirroringFlag or 0x01000000 = kDisplayModeValidForAirPlayFlag were not included in the other two methods).
I think these are reporting bpc and bpp for the framebuffer, not the output format. The info for the output format is stored elsewhere.
On Intel Macs, the id for each mode is a hex number like this: 0x8000@### where @ is a digit that increases each time modes are chosen for the display (such as after wake from sleep).
The id refers to a detailed timing structure that can be obtained from the IOFrameBuffer of the display. This structure has timing info (active pixels, blanking pixels, ...) and a single pixel output format (RGB or YCbCr, bpc, DSC) so there must be a different detailed timing structure for each pixel output format.
On M1 Macs, I'm not sure if the id refers to something else. The IOFrameBuffers exist only for compatibility. They don't include the detailed timing structures.
Instead of IOFrameBuffer, M1 Macs use IOMobileFramebuffer. In IOMobileFramebuffer, the timing info is separate from the pixel output format (color mode) so I guess it's more efficient that way. Each timing has a list of color modes instead of just a single color mode.
Since you have an M1 Mac, you should try my other tools:
https://gist.github.com/joevt/e862b0088ef58b9144877d01401bcee8
https://gist.github.com/joevt/0c75b42171b3fb1a5248b4e2bee8e4d0
You can use ioreg.pl to output ioreg as json if you uncomment the
dumpstruct($root{"_9_children"});
line.
time perl -CSDA -Mutf8 -0777 ~/Downloads/ioreg.pl < ioreg_m1max.24gpu.64gb.2tb.txt > ioreg_m1max_parsed.txt
It will take a few minutes (8 minutes).
Or you can use M1MacTimings.sh which takes ioreg as plist for input which can be converted more quickly to json (I like json better than plist because it's easier to read and less verbose).
I'm still working on AllRez. I've added some E-DDC, DDC/CI (MCCS) stuff, and am looking at adding DisplayPort stuff. I don't know if I'll add M1 Mac stuff.