[sinfulprogeny]

> that the Mac cannot do Display Stream Compression at the Dell's native 6144 x 3456,

Can't, or won't? M1 MacBook pros for some reason can't do 4k120 over hdmi unless you buy a specific usbc-hdmi adapter and fool it into thinking it's displayport (or something like that, I'm paraphrasing. You can find info if you search for cablematters DDC 4k120 m1.)

[wtallis]

There's no "fool it into thinking it's displayport". What you're describing is having the Mac actually literally emit a DisplayPort signal, and a separate device converting that to an HDMI signal. The USB-C HDMI Alt mode standard was never implemented by any real products, and all USB-C to HDMI converters are active adapters that consume DisplayPort signals and emit HDMI signals. Not all of those support HDMI 2.1, which introduced a drastically different signalling mode for HDMI in order to support much higher data rates (and also added display stream compression, further increasing the maximum resolution and refresh rate capabilities).

[thejazzman]

You're missing the point -- you have to use custom firmware on those adapters or Apple still only puts out 4k60

I went deep on this last night shopping for a cable

[wtallis]

The custom firmware isn't actually all that interesting of a point, because slightly broken display behavior is extremely common if you look closely at anything other than normal everyday TV resolutions and refresh rates.

USB-C/DP to HDMI adapters often need to do some amount of rewriting EDID information because they need to be transparent to the host computer and the display, so it's the adapter that's responsible for ensuring that modes that cannot be handled on both sides of the adapter are not advertised to the PC. When you layer that complexity on top of the existing minefield of ill-conceived EDID tables widespread in monitors, on top of the limitations of macOS (limited special-case EDID handling, little to no manual overrides/custom mode settings), it would be more surprising if there weren't some common use cases that theoretically ought to work but are simply broken. Applying the necessary EDID patch via adapter firmware is simply the easiest option where macOS is involved.

Even on Windows with a DP cable directly from GPU to display it's not all that rare to need a software override for EDID in order to use modes that ought to work out of the box (eg. I have a recent Dell monitor that cannot simultaneously do HDR and variable refresh rate out of the box).

[brigade]

That "some reason" is that a standard DP-to-HDMI 2.1 protocol converter can't negotiate beyond HDMI 2.0 link rates without the host computer knowing about and doing FRL training on the HDMI side. Completely unrelated to any limitations related to 6144 x 3456.

[lxgr]

Couldn’t the adapter do that?

[brigade]

As I understand it, automatic fallback/limitation to HDMI 2.0 speeds was desired by VESA in the event of using an 18gbps cable or other signal integrity issue, so ultimately they chose to require the host to be more aware of HDMI for the converter to enable HDMI 2.1 speeds rather than requiring the converter to be smart.

[lxgr]

Displayport to HDMI 2.1 adapters already seem quite complex: https://www.paradetech.com/products/ps196/

Is the problem expressing the maximum supported bandwidth end-to-end, i.e. not as a function of the DP channel quality that the source sees?

[brigade]

Yes, as a specific example, if the HDMI sink wants DSC, maximizing the quality (minimizing the compression ratio) fundamentally cannot be done without knowing the end-to-end bandwidth.