Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

toke lahti

macrumors 68040
Original poster
Apr 23, 2007
3,332
525
Helsinki, Finland
In the past info about video connection to a display told about bit depth and chroma subsampling in System Information.
Not any more.

How to get that info?

I need to verify is my mac driving my tv in RGB or YCbCr.
The tv (UE49KU6645) does not tell that.
I want to calibrate the tv properly and it should be done with same format that my mac will use with it.
 
ioreg can show a list of display modes (TimingElement) and a list of color modes (ColorElement) for each display mode. It shows which display mode is being used but doesn't show which color mode is being used?
I think AllRez can dump all the info from ioreg https://github.com/joevt/AllRez but it's not formatted well.
The information from ioreg can be parsed using the info at
https://forums.macrumors.com/threads/diy-5k-monitor-success.2253100/post-32093817
Hmm - where's the DSC target bits per pixel? It's usually 12 bpp but can be lower on Apple Silicon Macs. A patch is required for Intel Macs to change the dscTargetBPP preference.
With Intel Macs, a DetailedTimingInformation in AllRez includes the output color info for the display mode and the DSC target bits per pixel.

I would look for hidden APIs that can return the info for Apple Silicon Macs.

Have a look at @waydabber 's BetterDisplay.app. It has a command line interface. Does the following command list all the timing elements and color elements per timing element? I haven't tried it since I don't have an Apple Silicon Mac.
Code:
betterdisplaycli get -n=DISPLAYNAME -connectionModeListAll

I'm not sure if BetterDisplay is describing framebuffer color info or output color info.
 
Hi all, this command lists timings and connection level color mode elements macOS deems viable (based on the EDID and available bandwidth), so it's not about framebuffer color representation options.

The

Code:
betterdisplaycli get -n=DISPLAYNAME -connectionMode

will show the current configuration, for example:

Code:
11929753937963126528 - 3840x2160 120.00Hz Variable 10bit SDR YCbCr 4:4:4 Limited SRGB

One can switch to a mode using `set` and `connectionMode=<identifier>`

The app's Color Mode menu also lists current and available options for the current timing and provides a way to switch easily.

For example:

Screenshot 2025-11-05 at 10.50.18.png
 
  • Love
Reactions: toke lahti
BetterDisplay (app) is great!
Much easier to find possible combinations than command line!

@waydabber, Feature suggestion:
In BD, we could have the signal specs visible at all times (optionally of course) in the bottom of the dropdown menu or in own window or popup-menu:
  1. Resolution
  2. Refresh rate
  3. Bit depth
  4. RGB / YCbCr
  5. Chroma subsampling
  6. SDR / HDR
  7. Full / limited range
  8. HiDPI
  9. Maybe even a pixel clock? (MHz)
I just had an extensive cable testing with my M1pro-mbp with this Samsung TV.
Turns out, that with amazonBasics dp-hdmi cable with fullDP-usbc adapter, I can get 3840x2160, 60Hz, 10bit, RGB (4:4:4), HDR10, full range.

From mbp's hdmi output I can only get 30Hz.

And with cheapo "jsaux" hdmi-usbc adaptor (printed 4kUHD on it...) same 30Hz, but not even HDR!

And now I can continue to calibrate the tv with simple combination of:
  1. RP4
  2. PgenOS
  3. windows laptop
  4. Pg_client / HCFR
Sadly, seems to be, that all my cheap hdmi switchers are limited to 300 MHz pixel clock...
 
Last edited:
so it's not about framebuffer color representation options
Is there a separate command line or UI for framebuffer color representation?
Could there be a situation where framebuffer is 10bpc RGB but is output to 8bpc 4:2:2 (using dithering) or similar color transformations?
 
Is there a separate command line or UI for framebuffer color representation?
Could there be a situation where framebuffer is 10bpc RGB but is output to 8bpc 4:2:2 (using dithering) or similar color transformations?

There is a separate display mode list `get -displayModeList`, which will show the framebuffer color depth, but for natively connected displays that is almost always 10bpc. For more detailed data for the current mode one can look the "Current Display Mode" section under Display Information….

The framebuffer bit depth and connection color mode bit depth can be different. Apple Silicon Macs can simply downscale the color depth or bridge the gap using GPU dithering (this can actually be toggled for some connections by changing the relevant framebuffer ioreg property which the DCP – the thing in the Apple Silicon chip that actually creates the output signal from the framebuffer – seems to honor instantly).

The app can't query the possible or actual DSC average payload per pixel (although this can be calculated from the available bandwidth) - as for the DSC target bpp I think it is (or should be) the same as the color mode's bit depth. But I may have my terminology wrong. :)
 
How do you get available bandwidth?

I think the color mode bit depths are bpc while DSC target is bpp.
You can have 10 bpc (30 bpp) compressed to 12 bpp (the default) or even 8 bpp (for when 12 bpp is not enough compression).
 
Yes, you are right.

When a display connects the following info can be intercepted from `AppleDCPDPTXController` (this is an example for a TV connecting at 4K@120Hz).

Code:
AppleDCPDPTXController::validateVideo Validating link @ 4 lanes and 8100000000Gbps
AppleDCPDPTXController::validateVideo Color: depth=10bpc encoding=3 [YCbCr 4:4:4] range=1 [Limited] colorimetry=1 [BT.709]
AppleDCPDPTXController::validateVideo Horizontal: total=4400 frontPorch=176 syncWidth=88 backPorch=296 active=3840
AppleDCPDPTXController::validateVideo Vertical: total=2250 frontPorch=8 syncWidth=10 backPorch=72 active=2160 syncRate=60.0000Hz
AppleDCPDPTXController::validateVideo Timing: pixelClock=594000000 interlaced=0 split=0
AppleDCPDPTXController::validateVideo Link: usableLinkBandwidth=25312113767bps < totalLinkBandwidth=25920000000bps
AppleDCPDPTXController::validateVideo Link: dsc=NO dsc.bpp=0.0000 videoBandwidth=17820000000bps usableBandwidth=25312113767bps
AppleDCPDPTXController::getBandwidthRatio videoBandwidth=17820000000bps linkBandwidth=25920000000bps bandwidthRatio=0.6875

Notice the connection level mode info, DSC use and DSC BPP (it should be specified there if DSC is in use, in this example it is not), the usable and bandwidth required bandwidth (`videBandwidth`) and the resulting bandwidth ratio for this video mode.

Also various other details can be intercepted from the negatioation process and even link training details.
 
Yes, you are right.

When a display connects the following info can be intercepted from `AppleDCPDPTXController` (this is an example for a TV connecting at 4K@120Hz).

Code:
AppleDCPDPTXController::validateVideo Validating link @ 4 lanes and 8100000000Gbps
AppleDCPDPTXController::validateVideo Color: depth=10bpc encoding=3 [YCbCr 4:4:4] range=1 [Limited] colorimetry=1 [BT.709]
AppleDCPDPTXController::validateVideo Horizontal: total=4400 frontPorch=176 syncWidth=88 backPorch=296 active=3840
AppleDCPDPTXController::validateVideo Vertical: total=2250 frontPorch=8 syncWidth=10 backPorch=72 active=2160 syncRate=60.0000Hz
AppleDCPDPTXController::validateVideo Timing: pixelClock=594000000 interlaced=0 split=0
AppleDCPDPTXController::validateVideo Link: usableLinkBandwidth=25312113767bps < totalLinkBandwidth=25920000000bps
AppleDCPDPTXController::validateVideo Link: dsc=NO dsc.bpp=0.0000 videoBandwidth=17820000000bps usableBandwidth=25312113767bps
AppleDCPDPTXController::getBandwidthRatio videoBandwidth=17820000000bps linkBandwidth=25920000000bps bandwidthRatio=0.6875

Notice the connection level mode info, DSC use and DSC BPP (it should be specified there if DSC is in use, in this example it is not), the usable and bandwidth required bandwidth (`videBandwidth`) and the resulting bandwidth ratio for this video mode.

Also various other details can be intercepted from the negatioation process and even link training details.
That's great info. You mention how to see AppleDCPDPTXController using the log show command in the BetterDisplay Discord.

dsc.bpp has a decimal point because it can be specified in 16ths of a pixel.
10 bpc = 30 bpp.
videoBandwidth is pixelClock*bpp = 594 MHz * 30 bpp = 17.82 Gbps.
linkBandwidth is 4 lanes * 8.1 GTps * 8b/10T = 25.92 Gbps.
bandwidthRatio is videoBandwidth / linkBandwidth = 17.82 / 25.92 = 68.75%

I don't know what usableLinkBandwidth is. I wonder what it's accounting for and how it's calculated? Is it for FEC? Usually FEC is used only when DSC is enabled? The timing is HDMI but the link is 4 lanes of DisplayPort HBR3. Is there a MST hub in the chain?
usableLinkBandwidth is 97.6547599035494% of totalLinkBandwidth.
totalLinkBandwidth is 1.024015625032174% of usableLinkBandwidth.
The difference is 607886233 which is 2.4015625032174% of usableLinkBandwidth or 2.3452400964506% of totalLinkBandwidth.
 
> You mention how to see AppleDCPDPTXController using the log show command in the BetterDisplay Discord.

Yes, one can use this command to get kernel logs related to anything "DCP" (the component of the Apple Silicon chip that manages display connections and produces the actual video signal from the framebuffer).

Code:
log show --last 2m --info --predicate "processImagePath CONTAINS 'kernel' AND senderImagePath CONTAINS 'DCP'"

> Is there a MST hub in the chain?

AppleSilicon outputs DP only I think, but this particular connection was using an M3 Max MBP's HDMI port (connected to an LG OLED TV). Afaik there is a Parade DisplayPort to HDMI protocol converter chip built into the MacBook that's doing the conversion.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.