Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
So, can any one who has 16 inch intel MacBook and the adapter to provide more details about the links? Say, speed rate, channels, DSC, and so on. Many thanks!

Also, it might be interesting to conduct such a test on rx6x00 on Mac Pro or hackintosh!
What command should I run to output the info you need?
 
I tested on my hackintosh with RX 6800xt via HDMI 2.1 port to my LG CX.

I got ventura running successfully. But macos is sending hdmi 2.0 signal. So i m able to get max 4k/120Hz , no HDR and 8bit TM signal.

I tried 4k/30Hz , i got HDR and 10 bit signal but still TM signal.

I have ordered a DP1.4 to HDMI 2.1 cable. Will report after testing.
 
What command should I run to output the info you need?
Try using the AllRez command from https://github.com/joevt/AllRez
It outputs a lot of DisplayPort info which might be interesting for these adapters.
Download the latest release v1.1 or build with Xcode (on macOS 12.4).
It now includes iogdiagnose and AGDCDiagnose output which might be interesting if they include any info that AllRez did not.
~/Downloads/AllRez > allrez.txt
If you post the result here, zip it first since it's large.
 
Guys. My Ventura dead and I reinstall Monterey 12.2.1. I found I still can use 4k144 with c to hdmi2.1 adapter. Here is the output from allrez.
Try using the AllRez command from https://github.com/joevt/AllRez
It outputs a lot of DisplayPort info which might be interesting for these adapters.
Download the latest release v1.1 or build with Xcode (on macOS 12.4).
It now includes iogdiagnose and AGDCDiagnose output which might be interesting if they include any info that AllRez did not.
~/Downloads/AllRez > allrez.txt
If you post the result here, zip it first since it's large.
 

Attachments

  • allrez-output.zip
    106 KB · Views: 139
  • Like
Reactions: onlinespending
Sorry guys. I think I'm running under yuv422 mode. After I use edid patcher forcing RGB mode. I got only 4K60 and lose HDR option
 
Guys. My Ventura dead and I reinstall Monterey 12.2.1. I found I still can use 4k144 with c to hdmi2.1 adapter. Here is the output from allrez.
I don't see any DisplayPort info. How is the display connected? What GPU? What adapter / cable are you using? Can you post a link?

The AGDCDiagnose output says the built-in display is connected with eDP using HBR2 x4 and the external display is connected with DP SST using HBR3 x4.

I wonder why they don't show DisplayPort info then? Try restarting the computer, and use the AGDCDiagnose command by itself:
/System/Library/Extensions/AppleGraphicsControl.kext/Contents/MacOS/AGDCDiagnose -a > AGDCDiagnose_a.txt 2>&1

Is the MacBook Pro running in clamshell mode? The AllRez output is only showing the external display.

AGDCDiagnose says the GPU is the 5300M which is built into the MacBook Pro 16-inch (2019). I see that it's outputting 3840x2160 144 Hz, 1275.83 MHz, 4:2:0 10bpc, no DSC. This requires at least HBR3 bandwidth, or 24 Gbps FRL.
The AllRez output says the GPU does support DSC which is expected for a AMD Navi GPU but none of the modes in the mode list uses DSC.
The display is supposed to support variable refresh rate (48 - 144Hz) but I guess the DisplayPort info has the VRR setting (MSA_TIMING_PAR_IGNORED) disabled so none of the modes in the mode list has VRR enabled.

According to the EDID, the display appears to be a Titan Legion 27" 4K Mini Led Display P27A6V and it can support up to 48 Gbps FRL which should be able to accept 3840x2160 144Hz 10bpc RGB or 4:4:4.

The display also has a DisplayPort 1.4 input. Can you post AllRez output for that port as well?

Sorry guys. I think I'm running under yuv422 mode. After I use edid patcher forcing RGB mode. I got only 4K60 and lose HDR option
I think you're using 4:2:0, not 4:2:2. If you look at the list of IOFBModes, you'll see that all the modes are 4:2:0 or 4:4:4.
Looking at only the 4:4:4 modes, we see the following (plus some low res 60Hz options):
4K30 297MHz
1440p120 497.75MHz
1080p120 297MHz
All of those support 10bpc which means they can also support HDR.

Don't use EDID patcher. That probably just removes everything from the EDID including the high refresh rate modes. You need to use a different EDID editor or something that won't affect parts of the EDID that you don't want to change.
You can try my script at https://gist.github.com/joevt/32e5efffe3459958759fb702579b9529
Custom Resolution Utility (CRU) for Windows is a good editor.
I guess you wan't to remove the 4:2:0 info from the EDID to see if that will expand the list of modes that are 4:4:4 or RGB.
Max pixel clock for HBR3 x4 without DSC is up to 1080MHz for 8bpc and 864MHz for 10bpc.

The CoreDisplay framework (used by WindowServer) reads Displays overrides files from /Library or /System for fields such as ProductName, EDID, scaled modes, etc. that SwitchResX can override. In the past I mentioned that there are other fields in the Displays overrides files that might affect DisplayPort settings for a display (for example, the disableDSC or disableFEC fields). However, the DisplayPort fields are read by dislaypolicyd instead of CoreDisplay. displaypolicyd only reads these fields from the default override file location in /System. In Catalina and later, it is not easy to modify files in /System. Therefore, I created a WhateverGreen patch (in my Lilu/WhateverGreen GitHub forks) to make coredisplayd read override files from /Library instead of /System (you have to copy the override vendor folders to the new location to make sure everything works as before). I haven't tested it yet - I think user process patches are working on my iMac 2013 but not my Mac mini 2018. Both are running Monterey 12.4.
 
  • Like
Reactions: jdjingdian
I don't see any DisplayPort info. How is the display connected? What GPU? What adapter / cable are you using? Can you post a link?

The AGDCDiagnose output says the built-in display is connected with eDP using HBR2 x4 and the external display is connected with DP SST using HBR3 x4.

I wonder why they don't show DisplayPort info then? Try restarting the computer, and use the AGDCDiagnose command by itself:
/System/Library/Extensions/AppleGraphicsControl.kext/Contents/MacOS/AGDCDiagnose -a > AGDCDiagnose_a.txt 2>&1

Is the MacBook Pro running in clamshell mode? The AllRez output is only showing the external display.

AGDCDiagnose says the GPU is the 5300M which is built into the MacBook Pro 16-inch (2019). I see that it's outputting 3840x2160 144 Hz, 1275.83 MHz, 4:2:0 10bpc, no DSC. This requires at least HBR3 bandwidth, or 24 Gbps FRL.
The AllRez output says the GPU does support DSC which is expected for a AMD Navi GPU but none of the modes in the mode list uses DSC.
The display is supposed to support variable refresh rate (48 - 144Hz) but I guess the DisplayPort info has the VRR setting (MSA_TIMING_PAR_IGNORED) disabled so none of the modes in the mode list has VRR enabled.

According to the EDID, the display appears to be a Titan Legion 27" 4K Mini Led Display P27A6V and it can support up to 48 Gbps FRL which should be able to accept 3840x2160 144Hz 10bpc RGB or 4:4:4.

The display also has a DisplayPort 1.4 input. Can you post AllRez output for that port as well?


I think you're using 4:2:0, not 4:2:2. If you look at the list of IOFBModes, you'll see that all the modes are 4:2:0 or 4:4:4.
Looking at only the 4:4:4 modes, we see the following (plus some low res 60Hz options):
4K30 297MHz
1440p120 497.75MHz
1080p120 297MHz
All of those support 10bpc which means they can also support HDR.

Don't use EDID patcher. That probably just removes everything from the EDID including the high refresh rate modes. You need to use a different EDID editor or something that won't affect parts of the EDID that you don't want to change.
You can try my script at https://gist.github.com/joevt/32e5efffe3459958759fb702579b9529
Custom Resolution Utility (CRU) for Windows is a good editor.
I guess you wan't to remove the 4:2:0 info from the EDID to see if that will expand the list of modes that are 4:4:4 or RGB.
Max pixel clock for HBR3 x4 without DSC is up to 1080MHz for 8bpc and 864MHz for 10bpc.

The CoreDisplay framework (used by WindowServer) reads Displays overrides files from /Library or /System for fields such as ProductName, EDID, scaled modes, etc. that SwitchResX can override. In the past I mentioned that there are other fields in the Displays overrides files that might affect DisplayPort settings for a display (for example, the disableDSC or disableFEC fields). However, the DisplayPort fields are read by dislaypolicyd instead of CoreDisplay. displaypolicyd only reads these fields from the default override file location in /System. In Catalina and later, it is not easy to modify files in /System. Therefore, I created a WhateverGreen patch (in my Lilu/WhateverGreen GitHub forks) to make coredisplayd read override files from /Library instead of /System (you have to copy the override vendor folders to the new location to make sure everything works as before). I haven't tested it yet - I think user process patches are working on my iMac 2013 but not my Mac mini 2018. Both are running Monterey 12.4.
I think my hdmi2.1 adapter is using Synaptics VM7100.
And recently I always run my mbp in clamshell mode.
Screen Shot 2022-06-22 at 19.54.44.png
 

Attachments

  • output.zip
    530.2 KB · Views: 95
  • output-cToDp.zip
    23.3 KB · Views: 91
I think my hdmi2.1 adapter is using Synaptics VM7100.
And recently I always run my mbp in clamshell mode.
The USB-C to DP output from AGDCDiagnose shows DisplayPort info. The display supports DSC for 4K 144Hz mode. This would be better than the HDMI 2.1 input for macOS since macOS is dumb.
Need AllRez output for this connection mode to decode the DSC registers properly. I should add a method to decode DPCD from AGDCDiagnose output...

The display is connected using HBR3 x4 without DSC at 3840x2160 60Hz, 10bpc RGB. If you want to try to get DSC working with DisplayPort for 4K144 (and also VRR since VRR doesn't work from HDMI adapters?), then you need to install OpenCore and my Lilu/WhateverGreen and then try to force enable DSC with an override file. But I haven't finished testing this and there's an issue getting the patch applied on my Mac mini 2018 (Lilu/WhateverGreen patches are in RAM so they are not permanent).

It looks like you updated macOS? You were using an older version before. I think you said you were running 12.2.1. Now you're running 12.4?
The HDMI 2.1 Adapter now shows DisplayPort info in the AGDCDiagnose output. It would be interesting to see if AllRez now also can show DisplayPort info for the adapter?
The output shows a Synaptics VMM7100 (the OUI 144-204-036 = "Synaptics, Inc" and the last two bytes 113-000 = 0x71 0x00 = VMM7100)
It doesn't show DSC support. Does it need a firmware update? Or did they purposefully remove DSC support? The VMM7100 is supposed to support DSC.
https://www.synaptics.com/products/video-interface-ics
I had to update the firmware on some of my Synaptics VMMxxxx adapters / MST hubs to get DSC support (For Windows and Catalina - I think Apple defaults DSC to disabled in Big Sur and later?).
Do you have a link for the adapter you bought? Did they advertise DSC support? Maybe AllRez will show more info.
The adapter is connected using HBR3 x4 at 3840x2160 144Hz, 10bpc 4:2:0, just like your previous HDMI 2.1 adapter test.
 
  • Like
Reactions: devrimer
1. I bought the adapter from taobao (China mainland), but I cant find link on alibaba. (The seller dont know what is DSC)
2. I reinstall my mac with 12.2.1 recovery and upgrade to 12.4.
3. I would like to try your Lilu/WhateverGreen patch. How can I do that ?
The USB-C to DP output from AGDCDiagnose shows DisplayPort info. The display supports DSC for 4K 144Hz mode. This would be better than the HDMI 2.1 input for macOS since macOS is dumb.
Need AllRez output for this connection mode to decode the DSC registers properly. I should add a method to decode DPCD from AGDCDiagnose output...

The display is connected using HBR3 x4 without DSC at 3840x2160 60Hz, 10bpc RGB. If you want to try to get DSC working with DisplayPort for 4K144 (and also VRR since VRR doesn't work from HDMI adapters?), then you need to install OpenCore and my Lilu/WhateverGreen and then try to force enable DSC with an override file. But I haven't finished testing this and there's an issue getting the patch applied on my Mac mini 2018 (Lilu/WhateverGreen patches are in RAM so they are not permanent).

It looks like you updated macOS? You were using an older version before. I think you said you were running 12.2.1. Now you're running 12.4?
The HDMI 2.1 Adapter now shows DisplayPort info in the AGDCDiagnose output. It would be interesting to see if AllRez now also can show DisplayPort info for the adapter?
The output shows a Synaptics VMM7100 (the OUI 144-204-036 = "Synaptics, Inc" and the last two bytes 113-000 = 0x71 0x00 = VMM7100)
It doesn't show DSC support. Does it need a firmware update? Or did they purposefully remove DSC support? The VMM7100 is supposed to support DSC.
https://www.synaptics.com/products/video-interface-ics
I had to update the firmware on some of my Synaptics VMMxxxx adapters / MST hubs to get DSC support (For Windows and Catalina - I think Apple defaults DSC to disabled in Big Sur and later?).
Do you have a link for the adapter you bought? Did they advertise DSC support? Maybe AllRez will show more info.
The adapter is connected using HBR3 x4 at 3840x2160 144Hz, 10bpc 4:2:0, just like your previous HDMI 2.1 adapter test.
 

Attachments

  • AllRez output(hdmi&dp).zip
    214.4 KB · Views: 169
1. I bought the adapter from taobao (China mainland), but I cant find link on alibaba. (The seller dont know what is DSC)
2. I reinstall my mac with 12.2.1 recovery and upgrade to 12.4.
3. I would like to try your Lilu/WhateverGreen patch. How can I do that ?
could you share the product name of your adapter? thx
 
Guys. My Ventura dead and I reinstall Monterey 12.2.1. I found I still can use 4k144 with c to hdmi2.1 adapter. Here is the output from allrez.
So, you are confirming that, under MacBook pro 16 inch intel and the VMM7100-based adapter mentioned above, you can achieve 120hz 4k in Monterey 12.2.1, right?
 
So, you are confirming that, under MacBook pro 16 inch intel and the VMM7100-based adapter mentioned above, you can achieve 120hz 4k in Monterey 12.2.1, right?
In Monterey 12.2.1 and 12.4. I can achieve 4k 144hz in 4:2:0 mode with vmm7100 adapter to my hdmi2.1 monitor.
 
In Monterey 12.2.1 and 12.4. I can achieve 4k 144hz in 4:2:0 mode with vmm7100 adapter to my hdmi2.1 monitor.
Thanks for your reply. It is interesting. I will try to purchase the same adapter and have some try.

Btw, is the display stable on your adapter (without random black screen filcker or other issues)? Thanks.
 
1. I bought the adapter from taobao (China mainland), but I cant find link on alibaba. (The seller dont know what is DSC)
2. I reinstall my mac with 12.2.1 recovery and upgrade to 12.4.
3. I would like to try your Lilu/WhateverGreen patch. How can I do that ?
For DSC support you should try Catalina. It might have DSC enabled by default so you could get 4K144 10bpc RGB via DisplayPort. But Catalina doesn't have VRR support.

The two new AllRez outputs both have DisplayPort DPCD info now. But it's strange that the included AGDCDiagnose output in each new AllRez output doesn't show DPCD. It's like sometimes it works and sometimes it doesn't and maybe if you keep trying then DPCD will appear in both sections... I don't know.

The AllRez output for the DP connection of the display has one VRR mode for 2560x1440 144Hz for HDR and SDR. It seems that macOS doesn't enable VRR unless the resolution can reach the max refresh rate of 144Hz. None of the other resolutions appear to have 144Hz option. I suppose you could add custom resolutions with 144Hz refresh rate using SwitchResX to get more VRR modes, such as 1920x1080 144Hz.
It's sad that the DP connection didn't get a 4:2:0 144Hz mode from macOS. Actually, the EDID says that DisplayPort doesn't support 4:2:0 but it does support 4:2:2 which should support 4K144 10bpc.
One problem is that the 4K144 mode for DP uses pixel clock 1339.63 MHz instead of the 1275.83 MHz used for the HDMI connection. You need a custom timing of less than 1296 MHz for 4:2:2 to possibly support 4K144 at 10bpc. You can create custom timings with SwitchResX, but even with that, macOS might not choose to enable 4:2:2. That would require another patch.

The AllRez output for the HDMI connection of the display has some interesting info in the DPCD info describing some of the capabilities of the HDMI 2.1 adapter.
It says it's connected using FRL (PCON_HDMI_LINK_MODE = PCON_HDMI_MODE_FRL)
I think it says it supports up to 48 Gbps (PCON_HDMI_FRL_TRAINED_BW)
It supports format conversion (FORMAT_CONVERSION) (RGB {6, 8, 10, 12 bpc}, YCbCr 4:4:4, YCbCr 4:2:2, YCbCr 4:2:0 {8, 10, 12 bpc} )
It supports resolutions up to 10K wide.
It supports pixel clock 2200 MHz (MAX_PIXEL_RATE) But since the adapter doesn't have DSC enabled, you're limited to 2160 MHz using 4:2:0 8bpc. That should be enough for 8K60 (but not HDMI timing, it needs to be CVT-RB timing) or 4K228. Even if you updated the firmware of the adapter to support DSC, you would still be limited to 2160 MHz unless you change the DSC target BPP from the macOS default 12bpp to 11bpp which should be possible but not useful until we know how to enable DSC modes.

If you want to try my OpenCore Lilu/WhateverGreen combo, then
- Copy the attach files to an EFI partition or a new HFS+ partition (≈200 MB in size). The EFI folder and the System Folder should be at the root of the partition.
- Copy all the VendorID-* folders from /System/Library/Displays/Contents/Resources/Overrides to /Library/Displays/Contents/Resources/Overrides
- Install the attached override file I created for your display
- Boot the computer holding the Option key to get into the Apple Startup Manager (bootpicker). Select OpenCore. Press Return to boot into OpenCoe (hold the Control key if you want to make it the default). In the OpenCore bootpicker, choose your macOS partition (Monterey). It should boot into macOS with Lilu and WhateverGreen running. If you run AllRez now, then you should be see some extra info that wasn't there before.
- After a couple minutes from boot, a Lilu log file will appear in /var/log/. It will indicate if the RAM patches were successful. If not, then I need to fix something.
The CableMatters 201388 uses the VMM 6100.
jdjingdian's adapter uses the VMM 7100.
The VMM6100 doesn't support DSC either (I thought it did?). Actually, The VMM6100 appears as an MST hub with a downstream device. AllRez is able to read the DPCD of MST connected devices. The output shows that the downstream device of the VMM6100 supports DSC. I've attached an example (I don't have a HDMI 2.1 display so there's no mention of FRL). Maybe the VMM7100 is similar but AllRez failed to reach the downstream device in jdjingdian's examples? One difference between the VMM6100 and the VMM7100 is that the VMM6100 reports 2 downstream ports (with nothing connected to the second port) while the VMM7100 reports only 1. But that shouldn't affect the result of the LINK_ADDRESS request? I don't know enough about DisplayPort to be sure. There's no access to the VMM**** data sheets so I don't know what to expect from each. There's no access to the DisplayPort 1.4 and related specs (but the DisplayPort 1.2 spec can be found online) so info about DSC, and PCONs is lacking. We have to depend on Linux drivers for info.
 

Attachments

  • joevtOpenCoreTest1.zip
    14.6 MB · Views: 102
  • DisplayVendorID-3103.zip
    1.2 KB · Views: 113
  • allrezCableMatters.txt.zip
    138.7 KB · Views: 128
After using your patch, still only get 4k60 on DP, however it seems to work at RGB only mode when using DP port.
For DSC support you should try Catalina. It might have DSC enabled by default so you could get 4K144 10bpc RGB via DisplayPort. But Catalina doesn't have VRR support.

The two new AllRez outputs both have DisplayPort DPCD info now. But it's strange that the included AGDCDiagnose output in each new AllRez output doesn't show DPCD. It's like sometimes it works and sometimes it doesn't and maybe if you keep trying then DPCD will appear in both sections... I don't know.

The AllRez output for the DP connection of the display has one VRR mode for 2560x1440 144Hz for HDR and SDR. It seems that macOS doesn't enable VRR unless the resolution can reach the max refresh rate of 144Hz. None of the other resolutions appear to have 144Hz option. I suppose you could add custom resolutions with 144Hz refresh rate using SwitchResX to get more VRR modes, such as 1920x1080 144Hz.
It's sad that the DP connection didn't get a 4:2:0 144Hz mode from macOS. Actually, the EDID says that DisplayPort doesn't support 4:2:0 but it does support 4:2:2 which should support 4K144 10bpc.
One problem is that the 4K144 mode for DP uses pixel clock 1339.63 MHz instead of the 1275.83 MHz used for the HDMI connection. You need a custom timing of less than 1296 MHz for 4:2:2 to possibly support 4K144 at 10bpc. You can create custom timings with SwitchResX, but even with that, macOS might not choose to enable 4:2:2. That would require another patch.

The AllRez output for the HDMI connection of the display has some interesting info in the DPCD info describing some of the capabilities of the HDMI 2.1 adapter.
It says it's connected using FRL (PCON_HDMI_LINK_MODE = PCON_HDMI_MODE_FRL)
I think it says it supports up to 48 Gbps (PCON_HDMI_FRL_TRAINED_BW)
It supports format conversion (FORMAT_CONVERSION) (RGB {6, 8, 10, 12 bpc}, YCbCr 4:4:4, YCbCr 4:2:2, YCbCr 4:2:0 {8, 10, 12 bpc} )
It supports resolutions up to 10K wide.
It supports pixel clock 2200 MHz (MAX_PIXEL_RATE) But since the adapter doesn't have DSC enabled, you're limited to 2160 MHz using 4:2:0 8bpc. That should be enough for 8K60 (but not HDMI timing, it needs to be CVT-RB timing) or 4K228. Even if you updated the firmware of the adapter to support DSC, you would still be limited to 2160 MHz unless you change the DSC target BPP from the macOS default 12bpp to 11bpp which should be possible but not useful until we know how to enable DSC modes.

If you want to try my OpenCore Lilu/WhateverGreen combo, then
- Copy the attach files to an EFI partition or a new HFS+ partition (≈200 MB in size). The EFI folder and the System Folder should be at the root of the partition.
- Copy all the VendorID-* folders from /System/Library/Displays/Contents/Resources/Overrides to /Library/Displays/Contents/Resources/Overrides
- Install the attached override file I created for your display
- Boot the computer holding the Option key to get into the Apple Startup Manager (bootpicker). Select OpenCore. Press Return to boot into OpenCoe (hold the Control key if you want to make it the default). In the OpenCore bootpicker, choose your macOS partition (Monterey). It should boot into macOS with Lilu and WhateverGreen running. If you run AllRez now, then you should be see some extra info that wasn't there before.
- After a couple minutes from boot, a Lilu log file will appear in /var/log/. It will indicate if the RAM patches were successful. If not, then I need to fix something.

The CableMatters 201388 uses the VMM 6100.
jdjingdian's adapter uses the VMM 7100.
The VMM6100 doesn't support DSC either (I thought it did?). Actually, The VMM6100 appears as an MST hub with a downstream device. AllRez is able to read the DPCD of MST connected devices. The output shows that the downstream device of the VMM6100 supports DSC. I've attached an example (I don't have a HDMI 2.1 display so there's no mention of FRL). Maybe the VMM7100 is similar but AllRez failed to reach the downstream device in jdjingdian's examples? One difference between the VMM6100 and the VMM7100 is that the VMM6100 reports 2 downstream ports (with nothing connected to the second port) while the VMM7100 reports only 1. But that shouldn't affect the result of the LINK_ADDRESS request? I don't know enough about DisplayPort to be sure. There's no access to the VMM**** data sheets so I don't know what to expect from each. There's no access to the DisplayPort 1.4 and related specs (but the DisplayPort 1.2 spec can be found online) so info about DSC, and PCONs is lacking. We have to depend on Linux drivers for info.
 

Attachments

  • lilu+allrez+adgcdiagnose.zip
    221.5 KB · Views: 136
After using your patch, still only get 4k60 on DP, however it seems to work at RGB only mode when using DP port.
The displaypolicyd and CoreDisplay patches are not getting applied (the counters at the end of the log are zero), just like on my Mac mini 2018. They seem to get applied on my iMac 2013. Maybe it's a T2 chip difference? I'll have to look into this further.
Otherwise, I'm glad you didn't have problem installing OpenCore/Lilu/Whatevergreen. I'll try to make a fix.

Even though the displaypolicyd and CoreDisplay user patches weren't applied successfully, AllRez shows 28 more modes were added in the DP case. It seems that the "Scaled resolutions base" setting that you see in SwitchResX was changed from 1920x1080 to 3840x2160. Did you change something? 3840x2160 is the correct "Scaled resolutions base" for a 4K display. Maybe the difference is my override file that I provided which has DisplayPixelDimensions set. I think this might be what SwitchResX changes for its "Scaled resolutions base" setting. I guess "DisplayPixelDimensions" is one of the fields loaded by CoreDisplay instead of displaypolicyd, so it doesn't need the displaypolicyd patch. I wonder why your previous DP tests had 1920x1080 as the "Scaled resolutions base"? The EDID for the DisplayPort connection of the display (use edid-decode -cC --skip-sha to view this) shows 1920x1080 is set as the native resolution. That's probably why. The EDID decode output has these warnings (among others):
Code:
FAIL: Native progressive timings are a mix of several resolutions.
FAIL: Missing DisplayID Product Identification Data Block.
FAIL: Missing DisplayID Display Parameters Data Block.
FAIL: Missing DisplayID Display Interface Features Data Block.
FAIL: DisplayID expects at least one preferred timing.

The IOFramebuffer kernel patches were applied successfully, so now we see more attribute info in the AllRez output shown in the IOFBAttributes section. It shows the latest set/get for each attribute. This is maybe better than the gtrace info that iogdiagnose and AGDCDiagnose show because those might get filled with thousands of the same attribute so you can't see what other attributes were accessed.

No significant changes appear in the new HDMI AllRez output (except for the addition of the IOFBAttributes section). I guess this means the EDID for the HDMI connection of the display doesn't have the same problems as the EDID for the DisplayPort.

One problem with your display (and my Acer XV273K) is that the product ID is the same for the DisplayPort connection and the HDMI connection, so an EDID override created by SwitchResX for the DisplayPort connection will get used for the HDMI connection and vice versa. This might be useful if you want to test the EDID from one connection with the other connection. To make SwitchResX create an EDID override, create a custom timing such as 4K 115Hz. In your case, the file will be named "DisplayYearManufacture-2022-DisplayWeekManufacture-20" (this year and week naming convention is used by WindowServer/CoreDisplay but is not used by displaypolicyd). If you don't want EDID overrides for one connection to affect the other, then you could add a suffix to the name of an override file you want to save for later (e.g. "DisplayYearManufacture-2022-DisplayWeekManufacture-20 HDMI"). Then remove the suffix from the file name when you want to use the override file again. Disconnect and reconnect the display when you want to load the new override file.
 
  • Like
Reactions: jdjingdian
The displaypolicyd and CoreDisplay patches are not getting applied (the counters at the end of the log are zero), just like on my Mac mini 2018. They seem to get applied on my iMac 2013. Maybe it's a T2 chip difference? I'll have to look into this further.
Otherwise, I'm glad you didn't have problem installing OpenCore/Lilu/Whatevergreen. I'll try to make a fix.

Even though the displaypolicyd and CoreDisplay user patches weren't applied successfully, AllRez shows 28 more modes were added in the DP case. It seems that the "Scaled resolutions base" setting that you see in SwitchResX was changed from 1920x1080 to 3840x2160. Did you change something? 3840x2160 is the correct "Scaled resolutions base" for a 4K display. Maybe the difference is my override file that I provided which has DisplayPixelDimensions set. I think this might be what SwitchResX changes for its "Scaled resolutions base" setting. I guess "DisplayPixelDimensions" is one of the fields loaded by CoreDisplay instead of displaypolicyd, so it doesn't need the displaypolicyd patch. I wonder why your previous DP tests had 1920x1080 as the "Scaled resolutions base"? The EDID for the DisplayPort connection of the display (use edid-decode -cC --skip-sha to view this) shows 1920x1080 is set as the native resolution. That's probably why. The EDID decode output has these warnings (among others):
Code:
FAIL: Native progressive timings are a mix of several resolutions.
FAIL: Missing DisplayID Product Identification Data Block.
FAIL: Missing DisplayID Display Parameters Data Block.
FAIL: Missing DisplayID Display Interface Features Data Block.
FAIL: DisplayID expects at least one preferred timing.

The IOFramebuffer kernel patches were applied successfully, so now we see more attribute info in the AllRez output shown in the IOFBAttributes section. It shows the latest set/get for each attribute. This is maybe better than the gtrace info that iogdiagnose and AGDCDiagnose show because those might get filled with thousands of the same attribute so you can't see what other attributes were accessed.

No significant changes appear in the new HDMI AllRez output (except for the addition of the IOFBAttributes section). I guess this means the EDID for the HDMI connection of the display doesn't have the same problems as the EDID for the DisplayPort.

One problem with your display (and my Acer XV273K) is that the product ID is the same for the DisplayPort connection and the HDMI connection, so an EDID override created by SwitchResX for the DisplayPort connection will get used for the HDMI connection and vice versa. This might be useful if you want to test the EDID from one connection with the other connection. To make SwitchResX create an EDID override, create a custom timing such as 4K 115Hz. In your case, the file will be named "DisplayYearManufacture-2022-DisplayWeekManufacture-20" (this year and week naming convention is used by WindowServer/CoreDisplay but is not used by displaypolicyd). If you don't want EDID overrides for one connection to affect the other, then you could add a suffix to the name of an override file you want to save for later (e.g. "DisplayYearManufacture-2022-DisplayWeekManufacture-20 HDMI"). Then remove the suffix from the file name when you want to use the override file again. Disconnect and reconnect the display when you want to load the new override file.
So, I was wondering, the reason jdjingdian can achieve 4k144hz by a typec-hdmi converter on a macbook pro which we cannot before is just that the vmm7100 (and CM adapter uses 6100)?
 
So, I was wondering, the reason jdjingdian can achieve 4k144hz by a typec-hdmi converter on a macbook pro which we cannot before is just that the vmm7100 (and CM adapter uses 6100)?
I wouldn't make any conclusions without trying both on the same setup.
 
@desert0616 @joevt
I have TCL r648 and Samsung Q80T TV, both of them are equipped with HDMI 2.1 port. I use the VMM7100 adapter but still got 4K60 only, and the system recognizes them as TV and the connection type is "HDMI" while using the HDMI 2.1 Monitor connection type recognize as "Thunderbolt/DP".
so far:
1. Intel 16inch Mac with vmm6100 adapter connect to a TV on Ventura : SUCCESS
2. Intel 16inch Mac with vmm7100 adapter connect to a TV on Monterey : FAIL
3. Intel 16inch Mac with vmm7100 adapter connect to a Monitor with HDMI2.1 port on Monterey : SUCCESS
Screen Shot 2022-06-24 at 23.25.21.png
 

Attachments

  • outputs.zip
    322.3 KB · Views: 82
The displaypolicyd and CoreDisplay patches are not getting applied (the counters at the end of the log are zero), just like on my Mac mini 2018. They seem to get applied on my iMac 2013. Maybe it's a T2 chip difference? I'll have to look into this further.
I found the problem. Replace Lilu/WhateverGreen that you installed from my OpenCore folder with the attached versions. Then we'll see if the DispalyPort fields of the override are read and have any affect. We may need to look at displaypolicyd logs in /var/log/displaypolicy and the Lilu log in /var/log
 

Attachments

  • joevttestLiluWhateverGreen.zip
    849.1 KB · Views: 79
@desert0616 @joevt
I have TCL r648 and Samsung Q80T TV, both of them are equipped with HDMI 2.1 port. I use the VMM7100 adapter but still got 4K60 only, and the system recognizes them as TV and the connection type is "HDMI" while using the HDMI 2.1 Monitor connection type recognize as "Thunderbolt/DP".
so far:
1. Intel 16inch Mac with vmm6100 adapter connect to a TV on Ventura : SUCCESS
2. Intel 16inch Mac with vmm7100 adapter connect to a TV on Monterey : FAIL
3. Intel 16inch Mac with vmm7100 adapter connect to a Monitor with HDMI2.1 port on Monterey : SUCCESS
For the TCL r648, the DPCD in the AllRez output says that it is connecting using TMDS (HDMI 2.0) instead of FRL (HDMI 2.1) which makes sense since you're using a 4K60 mode.
The same thing happened with the previous HDMI AllRez output for the 4K144 display when you were using 4K60 mode. I guess it switches to FRL when you do 4K144. TMDS is limited to less than 133Hz.
However, the 4K144 display had modes with pixel clock up to 1275MHz in the AllRez output. The TCL r648 has modes only up to 594MHz. I think you need to make some TV settings changes to show higher bandwidth modes.
For 8K60, the default HDMI pixel clock of 2376MHz exceeds the 2200 Mp/s of the adapter, but maybe a custom timing using CVT-RB2 would work (2069 MHz) (4:2:0 8bpc).
For 8K30 the default HDMI pixel clock of 1188MHz is less than what you achieved for the 4K144 mode of the 4K1144 display. I don't know why macOS didn't allow this mode by default. Maybe try adding it as a custom timing using SwitchResX.
The r648 has a 4K120 mode as well as those 8K modes in the EDID but it wasn't accepted by macOS.
The r648 supports DSC.

The q80t is a 4K display supporting up to 4K120 (but macOS didn't accept anything over 594 MHz). It doesn't say anything about FRL or DSC.
 
Registered to post that I found this new-ish hub from Club3D that has specifications which might seem promising: https://www.club-3d.com/en/detail/2597

I reached out to their support asking about compatibility with an 16" M1 Max MBP. I highly doubt this will work given the findings here, but I may just grab it to add another data point for the discussion.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.