201388-A, VMM7100. Flashed => Only 4k120Hz YCBCR444 8b
. Animations on MacOS are also very jittery withit (for example, switching desktops)Let us know what they say!
Last edited:
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
DP/USB-C/Thunderbolt 3/4 to HDMI 2.1 4k@120hz RGB4:4:4 10b HDR with Apple Silicon M1/M2/M3 now possible !
- Thread starter Zorast
- Start date
- Sort by reaction score
. Animations on MacOS are also very jittery withit (for example, switching desktops)Let us know what they say!
When force RGB it’s only run with 4k@30hz. And it looks like laggy to me too! So the VMM6100 is still the best till now.201388-A, VMM7100. Flashed => Only 4k120Hz YCBCR444 8b
Let us know what they say!
Mine did, but signal can be recovered by unplug and plug the cable again. Trying to use a different adaptor and HDMI to see whether it will help
I haven't tried your modded firmware, just because you mentioned it's only for testing and I need this monitor for work. I'm getting 4k 120Hz YCBCR although BetterDisplay is reporting it as 10-bit. For now it's doing what I need it to so I'll stop here unless you have some alternatives I should test.
Plz post screenshot and picture from ure TV that we can confirm its getting 4k@120hz RGB4:4:4 or YCBCR4:4:4
I'm not sure if I missed something but I'm using it with a Dell 32" 4K Moniter - G3223Q not a TV per say. I am still getting the same issue another person mentioned which is that after sleeping the display doesn't seem to pickup the connection till I unplug and plug it back in (this is on the firmware update I got from CableMatters).
I still haven't tried with the modified firmware but I can do if it's safe and won't destroy the display.
I'm currently running it at a lower resolution for HiDPI but it can go to the full 4k resolution.
I still haven't tried with the modified firmware but I can do if it's safe and won't destroy the display.
I'm currently running it at a lower resolution for HiDPI but it can go to the full 4k resolution.
Attachments
@AironMan here is my LG OLED C2 55" VRR report:
Mac Studio M1 Max ==> Thunderbolt 4 ==> Cable Matters 201388-A w/VMM7100 and Spyder_fw_USBC_CM_7.02.130forMac.fullrom firmware ==> HDMI 2.1 port on LG OLED C2. I'm also using your supplied EDID.
First of all: you CAN flash the cable with a Mac!
As mentioned by @Skowt (#291) Synaptics has a different tool for flashing "VmmHIDTool". It is available in MS Store: https://apps.microsoft.com/store/detail/vmmhidtool/9PDS6MLXXS7S and requires no MS account login to download. This tool can be used on a VM via Parallels with a standard Win11 install using the wizard in Parallels:
You simply need to make sure the USB portion of the adapter is passed to the VM. If it doesn't work immediately unplug the USB part of the cable and reconnect it. Then pick to connect to Windows directly.
----------
I'm testing the cable version of the adapter with VMM7100 (https://www.amazon.com/dp/B08QDV5H4M).
I tried flashing the 7.02.130 as well as the firmware posted by @AironMan (#298). One unique thing I saw was that the firmware from AironMan flashes MUCH faster than the .130 and it reports as 7.02.102. However, despite that I don't see good progress:
7.02.130 (same with and w/o EDID hack)
- No RGB mode
- 4K@120 420, no HDR available
- 4K@60 422, HDR available
7.02.102 (same with and w/o EDID hack)
- No RGB mode
- 4K@120 - no signal, no HDR available
- 4K@60 w/o HDR works at 444; with HDR only at 422
(while modifying EDID I used my own, not a pre-made one; I'm using MBP w/M1 Max and LG C2 w/newest webOS)
----------
I played with the "Debug" tab in the Synaptic's tool and it has a very nice function - Dump All registers. On firmware .130 it shows more information than just "FW VERSION" button:
- SST 4 lanes HBR3
- DSC enabled on the DP side
- "DSC decompression enabled" -> suggesting that the chip is stripping DSC when needed, i.e. the lack of reported DSC on the display has nothing to do with Mac using DSC or not
- "3840x2160@119.99Hz YUV444 8bpc" for RX (i.e. DP) suggesting that Mac is using 444
- On the TX (HDMI) side thou: "HDMI2.1 FRL 3Lane 6GHz" ... "3840x2160@119.99Hz YUV420 8bpc" suggesting that negotiation on HDMI fails to reach 444... crappy cable from CM? Sometimes I see "digital snow" or green screen when connected.
As mentioned by @Skowt (#291) Synaptics has a different tool for flashing "VmmHIDTool". It is available in MS Store: https://apps.microsoft.com/store/detail/vmmhidtool/9PDS6MLXXS7S and requires no MS account login to download. This tool can be used on a VM via Parallels with a standard Win11 install using the wizard in Parallels:
You simply need to make sure the USB portion of the adapter is passed to the VM. If it doesn't work immediately unplug the USB part of the cable and reconnect it. Then pick to connect to Windows directly.
----------
I'm testing the cable version of the adapter with VMM7100 (https://www.amazon.com/dp/B08QDV5H4M).
I tried flashing the 7.02.130 as well as the firmware posted by @AironMan (#298). One unique thing I saw was that the firmware from AironMan flashes MUCH faster than the .130 and it reports as 7.02.102. However, despite that I don't see good progress:
7.02.130 (same with and w/o EDID hack)
- No RGB mode
- 4K@120 420, no HDR available
- 4K@60 422, HDR available
7.02.102 (same with and w/o EDID hack)
- No RGB mode
- 4K@120 - no signal, no HDR available
- 4K@60 w/o HDR works at 444; with HDR only at 422
(while modifying EDID I used my own, not a pre-made one; I'm using MBP w/M1 Max and LG C2 w/newest webOS)
----------
I played with the "Debug" tab in the Synaptic's tool and it has a very nice function - Dump All registers. On firmware .130 it shows more information than just "FW VERSION" button:
- SST 4 lanes HBR3
- DSC enabled on the DP side
- "DSC decompression enabled" -> suggesting that the chip is stripping DSC when needed, i.e. the lack of reported DSC on the display has nothing to do with Mac using DSC or not
- "3840x2160@119.99Hz YUV444 8bpc" for RX (i.e. DP) suggesting that Mac is using 444
- On the TX (HDMI) side thou: "HDMI2.1 FRL 3Lane 6GHz" ... "3840x2160@119.99Hz YUV420 8bpc" suggesting that negotiation on HDMI fails to reach 444... crappy cable from CM? Sometimes I see "digital snow" or green screen when connected.
Last edited:
I contacted cable matters on Amazon regarding their USB-C to HDMI adapter asking for the VMM6100 chip, but they've told me that it has been discontinued and won't be restocked anymore which means they will only ship the VMM7100 chip adapters.
Can confirm that - got a similar response + they're shipping VM7100 from https://www.amazon.com/dp/B08MSWMXT4 (201388-GRY).
I was able to get an unofficial word from Synaptics and VMM7100 is meant to be a direct replacement for VMM6100; it's apparently more of a "rev 2" with things that didn't go through for the release of VMM6100, but since it has some new features marketing-wise it got a new name.
Last edited:
Hmmm anything else we can try/test with the VMM7100 to get the full RGB 10-bit 4k 120Hz or are we saying it's impossible at this point in time?
Ok, I've got it working with VMM7100; the connection is stable.
TL;DR:
v7.02.102 is a debug build
Some of the options in the Vmm app are only available with special build of the firmware. The one shared to @AironMan presumably by the support seems to be such a special build. By default the chip offers a few interesting options:
Synaptic chips aren't simple converters
There seems to be a lot of confusion of what the VMM chips are doing looking at this 13 pages thread and the other 40+ pages thread. These Synaptic chips aren't simply passing through the signal - they actually interpret it and re-encode it as needed. This is why what comes in on the DP side (RX) doesn't need to equal the HDMI output (TX) side. This makes debugging problems a bit harder.
Since the datasheet for VMM7100 isn't available to the public I can only rely on observations:
This shows:
What's the deal with EDID?
So, we're not the only ones editing EDID The VMM chips found in these adapters don't pass the EDID 1:1 from the HDMI side to DP. Depending on how the firmware is configured it will do different things. This makes sense as you cannot tell macOS that the display is HDMI as different things will be available with regards to DSC/HDCP/resolutions etc. So us editing EDID here is just patching an issues in the decision tree in the VMM firmware. However, ideally the chip should do the negotiation correctly, but it seems like it's not a trivial task with the number of permutations supported by both DP and HDMI.
Here's my original EDID as reported on the newest official software from CM (v7.02.120) by the VMM itself:
and here's my EDID after flashing the v7.02.102 from #298 (released 2023/03/23):
The differences become visible right away when diffed:
In other words, the new beta firmware enabled FRL signaling in addition to TMDS. FRL allows for proper DSC support... and guess what: FRL is optional in HDMI 2.1 spec. This is a big can of worms of everything-is-optional (see a good article about that).
Since the FRL is now reported correctly, along with ALLM as well which is a great bonus, eliminating manual game mode setting on many TVs, the 4K@120 4:4:4 is possible... and maybe more
In addition, the EDID editing in AW EDID Editor isn't needed because the adapter applies exactly the same changes. If you export EDID on v7.02.102 from BetterDisplay and open it in AW the version will be at 1.4 with Interface: DisplayPort.
Can we get HDR & multiple HDMI protocols
Well, USB-C is a mess but HDMI isn't any better. With HDMI 2.1 we've got a new signaling protocol: FRL. A nice benefit of FRL negotiation is that the bandwidth is known upfront after handshake. There're also handy tables with FRL parameters available. In my example above the HDMI negotiates a full HDMI 2.1:
This is what e.g. LG reports in their "VRR Information"! When you see something like "YCBCR444 8b TM" you know that the HDMI operates in TMDS mode ("TM"). When the FLR mode is active the TV will report something like "YCBCR4448b 4L8", meaning 4 lanes of 8Gb/s each (FLR4 mode). It's worth mentioning that this bandwidth has nothing to do with Mac's Thunderbolt bandwidth.
vs.
The adapter, as you can see above can negotiate more rates as well: some slower (3L3, 3L6, 4L6) and some slower (4L10, 4L12). The means its capabilities are up to full 48Gb/s, that is the max bandwidth for current HDMI 2.1 spec. In FLR6 (48Gb, 4L12) the HDR is certainly possible, as we can get 4K@120Hz 4:4:4 12 bit. Even FLR5 (40Gb, 4L10) allows for 4K@120 4:4:4 10 bit. So far so good, but this is just the HDMI side - we know that adapter can (or at least reports) do it.
To make it work the DP side, negotiated on the Thunderbolt port, must also be able to send such a signal. My VMM7100 reports "RX: SST 4lane HBR3 mode", with DSC being enabled and used on the v7.02.102 from #298. With HBR3 the bandwidth available (25.92Gb/s) allows for maximum of 4K@98Hz 4:4:4 10b when DSC isn't used (~26Gb/s). To achieve 4K@120Hz 10b either 4:2:2 or DSC must be used (~32.27Gb / 1.5 ~= 21.5Gb/s).
Thus, HDR with 4K@120Hz looks to be possible, if I'm reading tables on Wikipedia correctly.
Can we get VRR?
In the negotiation of HDMI the VMM reports "VRR_min: 0, VRR_max: 0", suggesting that VRR isn't supported or enabled. Can this be changed? Well, probably Synaptics configuration does contain an option for that. Carefully reading the "Spyder" (codename for Vxx7100 class of chips) press release it seems like Intel was able to drive "4K120 gaming TVs with VRR support". This is probably TBD with CableMatter engineers. It's possible that there's some bug causing VRR to be disabled with DSC.
Cables are everything!
4K@120 is a lot of data and it really pushes cables to the limit. While looking through the debug log from VMM7100 you can clearly see that the chip not only negotiates parameters but also tests the link physical capabilities, indirectly testing both cables. When everything goes well you will see something like that in the debug log:
I tested a box of cables and even the "2.1 supposedly-certified high-ultra-speed" ones are unstable. The HDMI connection can fail in many peculiar ways, especially when adapters are involved. The VMM chip really tries to negotiate something usable over flat-out failing:
CM adapter vs cable
Did I mention that "cables are everything"? Well, the CM adapter with HDMI cable doesn't seem to be very stable. Most of the time the CM cable will either fail HDMI training for 4L8 or will simply downgrade to 4:2:0. I was able to get full 4K@120 4:4:4 8b with FRL 4L8 a few times, but it was short-lived and ended up with "digital snow" after under a minute, multiple link retrains and a failure in the end.
CM adapter, running the exact same firmware, works perfectly and is stable given a good HDMI-HDMI cable. Thus my personal recommendation is to avoid CableMatters 201362-GRY-1.8m-E (male USB-C => male HDMI). The software side is working correctly, but the HDMI cable attached to the adapter doesn't seem to be good enough to work to the full potential of VMM7100. This obviously may change in the future.
Cautionary Tale: Backups aren't always working
VMM7100 seems to be hard to brick as it uses two A/B flash banks. However, using "Save to file" and then "Load to FLASH" doesn't always work. Thus, restoring original firmware may not be possible in some instances.
------
I'm going to bed - if is screwed up something let me know
TL;DR:
- You will get 4K@120 YCBCR444 8b 4L8 [more on the last part later]
- 10b isn't supported and there's no HDR as of now
- RGB doesn't work but 4:4:4 is identical
- You need firmware v7.02.102 from #298 (released 2023/03/23)
- Tested on CM 201388-GRY
- It is the standard non-slim male USB-C => female HDMI
- This does not work on 201362-GRY-1.8m-E (male USB-C => male HDMI) and most likely no firmware can fix that
- No EDID editing needed on macOS
- If it doesn't work replace your HDMI cable, even if it's "2.1 certified"
v7.02.102 is a debug build
Some of the options in the Vmm app are only available with special build of the firmware. The one shared to @AironMan presumably by the support seems to be such a special build. By default the chip offers a few interesting options:
- Reading firmware details (Debug => "FW version" button)
- Reading final negotiated TX and RX parameters (Debug => "I/O Timing info" button)
- Reading EDID ("EDID" tab)
- Following negotiation sequence (Debug => "Debug message" button); this one as the app warns isn't available in retail firmwares
Synaptic chips aren't simple converters
There seems to be a lot of confusion of what the VMM chips are doing looking at this 13 pages thread and the other 40+ pages thread. These Synaptic chips aren't simply passing through the signal - they actually interpret it and re-encode it as needed. This is why what comes in on the DP side (RX) doesn't need to equal the HDMI output (TX) side. This makes debugging problems a bit harder.
Since the datasheet for VMM7100 isn't available to the public I can only rely on observations:
- DP and HDMI negotiations are performed independently and common mode with the lowest conversion effort is picked
- The chip is able to perform HDCP internally on both sides
- DSC can be passed through, but it doesn't have to be. The chip is able to decompress the signal on the DP, convert it, and recompress it on the HDMI side. Depending on the computer+display configuration the DSC parameters supported may be different with no common set. In this case the chip itself in logs will print "TX SST DSC passthrough not supported." and re-negotiate DSC as needed on TX and RX.
- There's some color conversion capability
- HDMI negotiation is finicky due to HDCP. Often time the negotiation will determine 4K@120 4:2:0 as the maximum supported, but the HDCP will fail. In such cases the display will often show "No Signal"
- Mac can output 4K@120 4:4:4 but the HDMI side may negotiate it down to 4:4:0 or even 4:2:0. This causes frustration as it seems like something is broken on the macOS side. In fact however nothing is wrong with the DP on macOS - the chip simply decides to negotiate it down due to HDMI interference.
- Bottom line: do not rely on just your display or BetterDisplay reporting something! These ideally should match but don't need to match, even if everything is working correctly.
- Frame rate cannot be converted and must match on both sides (that becomes important later, see cables section below)
Code:
RX: SST 4lane HBR3 mode, DSC ON FEC ON, FEC enabled, Lock sts: 001000f0
Symbol error recently: 8000 8000 8000 8000, in 1s: 8000 8000 8000 8000
HDCP 2.2 : , TYPE 0, state 0, flag 0, event: 0
RFRM0: 3840x2160@119.99Hz YUV444 8bpc, pixel clock: 1187.9MHz, Audio enabled, state 8
Audio: 2 channel 48.0KHz 24bits LPCM audio
HT: 4400, VT: 2250, HA: 3840, VA: 2160, HS: 384, VS: 82, HSW: 88, VSW: 10, HPOL: 0, VPOL: 0
DSC1.2 stream: PIC 3840x2160, Slice 960x2160, 16.0 BPP, Compress ratio: 1.5:1
Chunk 1920, Line 8, RGB 0, S422: 0, VBR 0, BP 1, Ctrl bc000012, Sts 00
DSC decompression enabled
HDCP status from source: HDCP 2.2 encryption enabled, TYPE 0 content stream
TX0: HPD ON, HDMI2.1 FRL 4Lane 8GHz, output enabled
3840x2160@119.99Hz YUV444 8bpc, pixel clock: 1187.9MHz, Audio enabled
HT: 4400, VT: 2250, HA: 3840, VA: 2160, HS: 384, VS: 82, HSW: 88, VSW: 10, HPOL: 0, VPOL: 0
HDCP 2.2 : Encryption enabled, state 0, flag 0, event 0This shows:
- Separate negotiation with DSC on both DP and HDMI
- The reason why YUV and not RGB is negotiated may be related to DSC optimization. Looking at the DSC & FEC overview docs it clearly specifies that RGB sources are converted to YUV at the start of DSC flow (see slide 14). Presumably converting it back to RGB for HDMI would be just a waste of resources (4:4:4 and RGB are functionally equivalent)
- It clearly states that the stream is recompressed ("DSC decompression enabled")
What's the deal with EDID?
So, we're not the only ones editing EDID
The VMM chips found in these adapters don't pass the EDID 1:1 from the HDMI side to DP. Depending on how the firmware is configured it will do different things. This makes sense as you cannot tell macOS that the display is HDMI as different things will be available with regards to DSC/HDCP/resolutions etc. So us editing EDID here is just patching an issues in the decision tree in the VMM firmware. However, ideally the chip should do the negotiation correctly, but it seems like it's not a trivial task with the number of permutations supported by both DP and HDMI.Here's my original EDID as reported on the newest official software from CM (v7.02.120) by the VMM itself:
Code:
Base block:
Product name: LG TV SSCR2, Product ID: GSM C0C8
Serial No: 16843009, Manufacture date: 1th week, 2022
Support range, VSync: 24-120Hz, HSync: 30-255KHz, Pixel clock: <=600MHz
Preferred timing: 3840x2160@60Hz, Pixel clock: 594000KHz, H/V Total: 4400/2250
Detail timing: 2560x1440@120Hz, Pixel clock: 497750KHz, H/V Total: 2720/1525
Supported standard timing list:
640x480@60Hz, 800x600@60Hz, 1024x768@60Hz, 1152x864@60Hz,
1280x1024@60Hz, 1920x1080@60Hz,
CEA externsion block
Support feature: under scan, audio, YCbCr 4:4:4, YCbCr 4:2:2,
Support 29 video formats: 3840x2160p@60Hz, 3840x2160p@50Hz,
4096x2160p@60Hz, 4096x2160p@50Hz,
1920x1080p@60Hz, 1920x1080p@50Hz, 1280x720p@60Hz,
1280x720p@50Hz, 1920x1080i@60Hz, 1920x1080i@50Hz, 720x480p@60Hz,
720x480p@60Hz, 720x576p@50Hz, 1920x1080p@24Hz, 1920x1080p@25Hz,
1920x1080p@30Hz, 720(1440)x576i@50Hz, 3840x2160p@24Hz, 3840x2160p@25Hz,
3840x2160p@30Hz, 4096x2160p@24Hz, 4096x2160p@25Hz, 4096x2160p@30Hz,
1920x1080p@120Hz, 1920x1080p@100Hz,
Support up to 2 channel Linear PCM audio
Support audio frequency(Hz): 32K, 44.1K, 48K,
96K, 192K,
HF-VSDB: Max_TMDS_Character_Rate 600MHz, SCDC_Present, DC_30bit_420,
DC_36bit_420,
FRL is not supported. VRR_min: 0, VRR_max: 0,
DSC:
DSC_MAX_Slice: Not support, DSC_Max_FRL_Rate: Not support, total chuck byte: 1K Support YCbCr 4:2:0 video formats: 3840x2160p@60Hz, 3840x2160p@50Hz,
4096x2160p@60Hz, 4096x2160p@50Hz, 1920x1080p@60Hz, 1920x1080p@50Hz,
1280x720p@60Hz, 1280x720p@50Hz,and here's my EDID after flashing the v7.02.102 from #298 (released 2023/03/23):
Code:
Base block:
Product name: LG TV SSCR2, Product ID: GSM C0C8
Serial No: 16843009, Manufacture date: 1th week, 2022
Support range, VSync: 24-120Hz, HSync: 30-255KHz, Pixel clock: <=1190MHz
Preferred timing: 3840x2160@60Hz, Pixel clock: 594000KHz, H/V Total: 4400/2250
Detail timing: 2560x1440@120Hz, Pixel clock: 497750KHz, H/V Total: 2720/1525
Supported standard timing list:
640x480@60Hz, 800x600@60Hz, 1024x768@60Hz, 1152x864@60Hz,
1280x1024@60Hz, 1920x1080@60Hz,
CEA externsion block
Support feature: under scan, audio, YCbCr 4:4:4, YCbCr 4:2:2,
Support 29 video formats: 3840x2160p@60Hz, 3840x2160p@50Hz, 3840x2160p@120Hz,
3840x2160p@100Hz, 4096x2160p@60Hz, 4096x2160p@50Hz, 4096x2160p@120Hz,
4096x2160p@100Hz, 1920x1080p@60Hz, 1920x1080p@50Hz, 1280x720p@60Hz,
1280x720p@50Hz, 1920x1080i@60Hz, 1920x1080i@50Hz, 720x480p@60Hz,
720x480p@60Hz, 720x576p@50Hz, 1920x1080p@24Hz, 1920x1080p@25Hz,
1920x1080p@30Hz, 720(1440)x576i@50Hz, 3840x2160p@24Hz, 3840x2160p@25Hz,
3840x2160p@30Hz, 4096x2160p@24Hz, 4096x2160p@25Hz, 4096x2160p@30Hz,
1920x1080p@120Hz, 1920x1080p@100Hz,
Support up to 2 channel Linear PCM audio
Support audio frequency(Hz): 32K, 44.1K, 48K,
96K, 192K,
HF-VSDB: Max_TMDS_Character_Rate 600MHz, SCDC_Present, DC_30bit_420,
DC_36bit_420,
FRL@ 3/6 Gbps 3 lanes, 6/8/10/12 Gbps 4 lanes. ALLM, VRR_min: 0, VRR_max: 0,
DSC: DSC_10bpc, DSC_12bpc, DSC_Native_420, DSC_1p2,
DSC_MAX_Slice: 4(340Mhz), DSC_Max_FRL_Rate: 6 Gps(4Ln), total chuck byte: 6K Support YCbCr 4:2:0 video formats: 3840x2160p@60Hz, 3840x2160p@50Hz,
3840x2160p@120Hz, 3840x2160p@100Hz, 4096x2160p@60Hz, 4096x2160p@50Hz,
4096x2160p@120Hz, 4096x2160p@100Hz,The differences become visible right away when diffed:
In other words, the new beta firmware enabled FRL signaling in addition to TMDS. FRL allows for proper DSC support... and guess what: FRL is optional in HDMI 2.1 spec. This is a big can of worms of everything-is-optional (see a good article about that).
Since the FRL is now reported correctly, along with ALLM as well which is a great bonus, eliminating manual game mode setting on many TVs, the 4K@120 4:4:4 is possible... and maybe more
In addition, the EDID editing in AW EDID Editor isn't needed because the adapter applies exactly the same changes. If you export EDID on v7.02.102 from BetterDisplay and open it in AW the version will be at 1.4 with Interface: DisplayPort.
Can we get HDR & multiple HDMI protocols
Well, USB-C is a mess but HDMI isn't any better. With HDMI 2.1 we've got a new signaling protocol: FRL. A nice benefit of FRL negotiation is that the bandwidth is known upfront after handshake. There're also handy tables with FRL parameters available. In my example above the HDMI negotiates a full HDMI 2.1:
Code:
FRL@ 3/6 Gbps 3 lanes, 6/8/10/12 Gbps 4 lanes. ALLM, VRR_min: 0, VRR_max: 0,
DSC: DSC_10bpc, DSC_12bpc, DSC_Native_420, DSC_1p2,
DSC_MAX_Slice: 4(340Mhz), DSC_Max_FRL_Rate: 6 Gps(4Ln)This is what e.g. LG reports in their "VRR Information"! When you see something like "YCBCR444 8b TM" you know that the HDMI operates in TMDS mode ("TM"). When the FLR mode is active the TV will report something like "YCBCR4448b 4L8", meaning 4 lanes of 8Gb/s each (FLR4 mode). It's worth mentioning that this bandwidth has nothing to do with Mac's Thunderbolt bandwidth.
The adapter, as you can see above can negotiate more rates as well: some slower (3L3, 3L6, 4L6) and some slower (4L10, 4L12). The means its capabilities are up to full 48Gb/s, that is the max bandwidth for current HDMI 2.1 spec. In FLR6 (48Gb, 4L12) the HDR is certainly possible, as we can get 4K@120Hz 4:4:4 12 bit. Even FLR5 (40Gb, 4L10) allows for 4K@120 4:4:4 10 bit. So far so good, but this is just the HDMI side - we know that adapter can (or at least reports) do it.
To make it work the DP side, negotiated on the Thunderbolt port, must also be able to send such a signal. My VMM7100 reports "RX: SST 4lane HBR3 mode", with DSC being enabled and used on the v7.02.102 from #298. With HBR3 the bandwidth available (25.92Gb/s) allows for maximum of 4K@98Hz 4:4:4 10b when DSC isn't used (~26Gb/s). To achieve 4K@120Hz 10b either 4:2:2 or DSC must be used (~32.27Gb / 1.5 ~= 21.5Gb/s).
Thus, HDR with 4K@120Hz looks to be possible, if I'm reading tables on Wikipedia correctly.
Can we get VRR?
In the negotiation of HDMI the VMM reports "VRR_min: 0, VRR_max: 0", suggesting that VRR isn't supported or enabled. Can this be changed? Well, probably Synaptics configuration does contain an option for that. Carefully reading the "Spyder" (codename for Vxx7100 class of chips) press release it seems like Intel was able to drive "4K120 gaming TVs with VRR support". This is probably TBD with CableMatter engineers. It's possible that there's some bug causing VRR to be disabled with DSC.
Cables are everything!
4K@120 is a lot of data and it really pushes cables to the limit. While looking through the debug log from VMM7100 you can clearly see that the chip not only negotiates parameters but also tests the link physical capabilities, indirectly testing both cables. When everything goes well you will see something like that in the debug log:
Code:
00:00:17:094 Measured clock close to MVID based clock: 593971133 593953857
00:00:17:141 RX0 measured pixel clk: 593971133Hz, stable: 1
....
00:00:20:297 Enter tx_hdmi_frl_link_training: 0 1 1 6
00:00:20:672 TX0 FRL training success at the 4lane 8GHz
....
00:00:22:250 Nothing error, enable both audio and video: 00003700I tested a box of cables and even the "2.1 supposedly-certified high-ultra-speed" ones are unstable. The HDMI connection can fail in many peculiar ways, especially when adapters are involved. The VMM chip really tries to negotiate something usable over flat-out failing:
- You can get negotiation failure overall with no signal on the screen
- Some cables are so bad that 4K@120 at any chroma subsampling fails
- You will see
Can't lower down the link rate, retry same link ratemultiple times in the log
- Downgrade to 4:2:0
- With mediocre cables you can sometimes get 4:4:4 but sometimes during link training 4:2:0 is negotiated
- This is the most annoying to debug, especially if the cable works 7/10 times
- Sometimes the handshake fails completely and you get a fully green screen on the HDMI; this can also happen when HDCP fails
- Links at 4K@120 4:4:4 but randomly stops working
- This is usually accompanied with the the stuff working initially but randomly starts displaying a full-screen random colorful pixels
- It seems like the predictor for that is unstable training, with many re-trainings on the TX side, that eventually end up with:
Code:00:01:31:344 tx0 FRL link training failed due to unknown reason: 255 00:01:31:359 FRL mode link training failed: ff 00:01:31:375 Enter tx_hdmi_frl_link_training: 0 1 1 6 - Since the link is using DSC it seems to fail first with
DSC0 status changed: from 00000000 to 01000000. It's most likely happening due to some FEC threshold being crossed, causing the DSC PLL to just give up and force re-negotiation. - After multiple retrains it sometimes end up with
TX0 FRL training success at the 4lane 6GHz- this is significantly lower than "4lane 8Ghz" seen in the good cable scenario
CM adapter vs cable
Did I mention that "cables are everything"? Well, the CM adapter with HDMI cable doesn't seem to be very stable. Most of the time the CM cable will either fail HDMI training for 4L8 or will simply downgrade to 4:2:0. I was able to get full 4K@120 4:4:4 8b with FRL 4L8 a few times, but it was short-lived and ended up with "digital snow" after under a minute, multiple link retrains and a failure in the end.
CM adapter, running the exact same firmware, works perfectly and is stable given a good HDMI-HDMI cable. Thus my personal recommendation is to avoid CableMatters 201362-GRY-1.8m-E (male USB-C => male HDMI). The software side is working correctly, but the HDMI cable attached to the adapter doesn't seem to be good enough to work to the full potential of VMM7100. This obviously may change in the future.
Cautionary Tale: Backups aren't always working
VMM7100 seems to be hard to brick as it uses two A/B flash banks. However, using "Save to file" and then "Load to FLASH" doesn't always work. Thus, restoring original firmware may not be possible in some instances.
------
I'm going to bed - if is screwed up something let me know
Last edited:
Really nice!Ok, I've got it working with VMM7100; the connection is stable.
TL;DR:
- You will get 4K@120 YCBCR444 8b 4L8 [more on the last part later]
- 10b isn't supported and there's no HDR as of now
- RGB doesn't work but 4:4:4 is identical
- You need firmware v7.02.102 from #298 (released 2023/03/23)
- Tested on CM 201388-GRY
- It is the standard non-slim male USB-C => female HDMI
- This does not work on 201362-GRY-1.8m-E (male USB-C => male HDMI) and most likely no firmware can fix that
- No EDID editing needed on macOS
- If it doesn't work replace your HDMI cable, even if it's "2.1 certified"
v7.02.102 is a debug build
Some of the options in the Vmm app are only available with special build of the firmware. The one shared to @AironMan presumably by the support seems to be such a special build. By default the chip offers a few interesting options:
- Reading firmware details (Debug => "FW version" button)
- Reading final negotiated TX and RX parameters (Debug => "I/O Timing info" button)
- Reading EDID ("EDID" tab)
- Following negotiation sequence (Debug => "Debug message" button); this one as the app warns isn't available in retail firmwares
Synaptic chips aren't simple converters
There seems to be a lot of confusion of what the VMM chips are doing looking at this 13 pages thread and the other 40+ pages thread. These Synaptic chips aren't simply passing through the signal - they actually interpret it and re-encode it as needed. This is why what comes in on the DP side (RX) doesn't need to equal the HDMI output (TX) side. This makes debugging problems a bit harder.
Since the datasheet for VMM7100 isn't available to the public I can only rely on observations:
The timings dump gives some details about that:
- DP and HDMI negotiations are performed independently and common mode with the lowest conversion effort is picked
- The chip is able to perform HDCP internally on both sides
- DSC can be passed through, but it doesn't have to be. The chip is able to decompress the signal on the DP, convert it, and recompress it on the HDMI side. Depending on the computer+display configuration the DSC parameters supported may be different with no common set. In this case the chip itself in logs will print "TX SST DSC passthrough not supported." and re-negotiate DSC as needed on TX and RX.
- There's some color conversion capability
- HDMI negotiation is finicky due to HDCP. Often time the negotiation will determine 4K@120 4:2:0 as the maximum supported, but the HDCP will fail. In such cases the display will often show "No Signal"
- Mac can output 4K@120 4:4:4 but the HDMI side may negotiate it down to 4:4:0 or even 4:2:0. This causes frustration as it seems like something is broken on the macOS side. In fact however nothing is wrong with the DP on macOS - the chip simply decides to negotiate it down due to HDMI interference.
- Bottom line: do not rely on just your display or BetterDisplay reporting something! These ideally should match but don't need to match, even if everything is working correctly.
- Frame rate cannot be converted and must match on both sides (that becomes important later, see cables section below)
Code:RX: SST 4lane HBR3 mode, DSC ON FEC ON, FEC enabled, Lock sts: 001000f0 Symbol error recently: 8000 8000 8000 8000, in 1s: 8000 8000 8000 8000 HDCP 2.2 : , TYPE 0, state 0, flag 0, event: 0 RFRM0: 3840x2160@119.99Hz YUV444 8bpc, pixel clock: 1187.9MHz, Audio enabled, state 8 Audio: 2 channel 48.0KHz 24bits LPCM audio HT: 4400, VT: 2250, HA: 3840, VA: 2160, HS: 384, VS: 82, HSW: 88, VSW: 10, HPOL: 0, VPOL: 0 DSC1.2 stream: PIC 3840x2160, Slice 960x2160, 16.0 BPP, Compress ratio: 1.5:1 Chunk 1920, Line 8, RGB 0, S422: 0, VBR 0, BP 1, Ctrl bc000012, Sts 00 DSC decompression enabled HDCP status from source: HDCP 2.2 encryption enabled, TYPE 0 content stream TX0: HPD ON, HDMI2.1 FRL 4Lane 8GHz, output enabled 3840x2160@119.99Hz YUV444 8bpc, pixel clock: 1187.9MHz, Audio enabled HT: 4400, VT: 2250, HA: 3840, VA: 2160, HS: 384, VS: 82, HSW: 88, VSW: 10, HPOL: 0, VPOL: 0 HDCP 2.2 : Encryption enabled, state 0, flag 0, event 0
This shows:
- Separate negotiation with DSC on both DP and HDMI
- The reason why YUV and not RGB is negotiated may be related to DSC optimization. Looking at the DSC & FEC overview docs it clearly specifies that RGB sources are converted to YUV at the start of DSC flow (see slide 14). Presumably converting it back to RGB for HDMI would be just a waste of resources (4:4:4 and RGB are functionally equivalent)
- It clearly states that the stream is recompressed ("DSC decompression enabled")
What's the deal with EDID?
So, we're not the only ones editing EDID
Here's my original EDID as reported on the newest official software from CM (v7.02.120) by the VMM itself:
Code:Base block: Product name: LG TV SSCR2, Product ID: GSM C0C8 Serial No: 16843009, Manufacture date: 1th week, 2022 Support range, VSync: 24-120Hz, HSync: 30-255KHz, Pixel clock: <=600MHz Preferred timing: 3840x2160@60Hz, Pixel clock: 594000KHz, H/V Total: 4400/2250 Detail timing: 2560x1440@120Hz, Pixel clock: 497750KHz, H/V Total: 2720/1525 Supported standard timing list: 640x480@60Hz, 800x600@60Hz, 1024x768@60Hz, 1152x864@60Hz, 1280x1024@60Hz, 1920x1080@60Hz, CEA externsion block Support feature: under scan, audio, YCbCr 4:4:4, YCbCr 4:2:2, Support 29 video formats: 3840x2160p@60Hz, 3840x2160p@50Hz, 4096x2160p@60Hz, 4096x2160p@50Hz, 1920x1080p@60Hz, 1920x1080p@50Hz, 1280x720p@60Hz, 1280x720p@50Hz, 1920x1080i@60Hz, 1920x1080i@50Hz, 720x480p@60Hz, 720x480p@60Hz, 720x576p@50Hz, 1920x1080p@24Hz, 1920x1080p@25Hz, 1920x1080p@30Hz, 720(1440)x576i@50Hz, 3840x2160p@24Hz, 3840x2160p@25Hz, 3840x2160p@30Hz, 4096x2160p@24Hz, 4096x2160p@25Hz, 4096x2160p@30Hz, 1920x1080p@120Hz, 1920x1080p@100Hz, Support up to 2 channel Linear PCM audio Support audio frequency(Hz): 32K, 44.1K, 48K, 96K, 192K, HF-VSDB: Max_TMDS_Character_Rate 600MHz, SCDC_Present, DC_30bit_420, DC_36bit_420, FRL is not supported. VRR_min: 0, VRR_max: 0, DSC: DSC_MAX_Slice: Not support, DSC_Max_FRL_Rate: Not support, total chuck byte: 1K Support YCbCr 4:2:0 video formats: 3840x2160p@60Hz, 3840x2160p@50Hz, 4096x2160p@60Hz, 4096x2160p@50Hz, 1920x1080p@60Hz, 1920x1080p@50Hz, 1280x720p@60Hz, 1280x720p@50Hz,
and here's my EDID after flashing the v7.02.102 from #298 (released 2023/03/23):
Code:Base block: Product name: LG TV SSCR2, Product ID: GSM C0C8 Serial No: 16843009, Manufacture date: 1th week, 2022 Support range, VSync: 24-120Hz, HSync: 30-255KHz, Pixel clock: <=1190MHz Preferred timing: 3840x2160@60Hz, Pixel clock: 594000KHz, H/V Total: 4400/2250 Detail timing: 2560x1440@120Hz, Pixel clock: 497750KHz, H/V Total: 2720/1525 Supported standard timing list: 640x480@60Hz, 800x600@60Hz, 1024x768@60Hz, 1152x864@60Hz, 1280x1024@60Hz, 1920x1080@60Hz, CEA externsion block Support feature: under scan, audio, YCbCr 4:4:4, YCbCr 4:2:2, Support 29 video formats: 3840x2160p@60Hz, 3840x2160p@50Hz, 3840x2160p@120Hz, 3840x2160p@100Hz, 4096x2160p@60Hz, 4096x2160p@50Hz, 4096x2160p@120Hz, 4096x2160p@100Hz, 1920x1080p@60Hz, 1920x1080p@50Hz, 1280x720p@60Hz, 1280x720p@50Hz, 1920x1080i@60Hz, 1920x1080i@50Hz, 720x480p@60Hz, 720x480p@60Hz, 720x576p@50Hz, 1920x1080p@24Hz, 1920x1080p@25Hz, 1920x1080p@30Hz, 720(1440)x576i@50Hz, 3840x2160p@24Hz, 3840x2160p@25Hz, 3840x2160p@30Hz, 4096x2160p@24Hz, 4096x2160p@25Hz, 4096x2160p@30Hz, 1920x1080p@120Hz, 1920x1080p@100Hz, Support up to 2 channel Linear PCM audio Support audio frequency(Hz): 32K, 44.1K, 48K, 96K, 192K, HF-VSDB: Max_TMDS_Character_Rate 600MHz, SCDC_Present, DC_30bit_420, DC_36bit_420, FRL@ 3/6 Gbps 3 lanes, 6/8/10/12 Gbps 4 lanes. ALLM, VRR_min: 0, VRR_max: 0, DSC: DSC_10bpc, DSC_12bpc, DSC_Native_420, DSC_1p2, DSC_MAX_Slice: 4(340Mhz), DSC_Max_FRL_Rate: 6 Gps(4Ln), total chuck byte: 6K Support YCbCr 4:2:0 video formats: 3840x2160p@60Hz, 3840x2160p@50Hz, 3840x2160p@120Hz, 3840x2160p@100Hz, 4096x2160p@60Hz, 4096x2160p@50Hz, 4096x2160p@120Hz, 4096x2160p@100Hz,
The differences become visible right away when diffed:
View attachment 2180524
In other words, the new beta firmware enabled FRL signaling in addition to TMDS. FRL allows for proper DSC support... and guess what: FRL is optional in HDMI 2.1 spec. This is a big can of worms of everything-is-optional (see a good article about that).
Since the FRL is now reported correctly, along with ALLM as well which is a great bonus, eliminating manual game mode setting on many TVs, the 4K@120 4:4:4 is possible... and maybe more
In addition, the EDID editing in AW EDID Editor isn't needed because the adapter applies exactly the same changes. If you export EDID on v7.02.102 from BetterDisplay and open it in AW the version will be at 1.4 with Interface: DisplayPort.
Can we get HDR & multiple HDMI protocols
Well, USB-C is a mess but HDMI isn't any better. With HDMI 2.1 we've got a new signaling protocol: FRL. A nice benefit of FRL negotiation is that the bandwidth is known upfront after handshake. There're also handy tables with FRL parameters available. In my example above the HDMI negotiates a full HDMI 2.1:
Code:FRL@ 3/6 Gbps 3 lanes, 6/8/10/12 Gbps 4 lanes. ALLM, VRR_min: 0, VRR_max: 0, DSC: DSC_10bpc, DSC_12bpc, DSC_Native_420, DSC_1p2, DSC_MAX_Slice: 4(340Mhz), DSC_Max_FRL_Rate: 6 Gps(4Ln)
This is what e.g. LG reports in their "VRR Information"! When you see something like "YCBCR444 8b TM" you know that the HDMI operates in TMDS mode ("TM"). When the FLR mode is active the TV will report something like "YCBCR4448b 4L8", meaning 4 lanes of 8Gb/s each (FLR4 mode). It's worth mentioning that this bandwidth has nothing to do with Mac's Thunderbolt bandwidth.
View attachment 2180522 vs. View attachment 2180523
The adapter, as you can see above can negotiate more rates as well: some slower (3L3, 3L6, 4L6) and some slower (4L10, 4L12). The means its capabilities are up to full 48Gb/s, that is the max bandwidth for current HDMI 2.1 spec. In FLR6 (48Gb, 4L12) the HDR is certainly possible, as we can get 4K@120Hz 4:4:4 12 bit. Even FLR5 (40Gb, 4L10) allows for 4K@120 4:4:4 10 bit. So far so good, but this is just the HDMI side - we know that adapter can (or at least reports) do it.
To make it work the DP side, negotiated on the Thunderbolt port, must also be able to send such a signal. My VMM7100 reports "RX: SST 4lane HBR3 mode", with DSC being enabled and used on the v7.02.102 from #298. With HBR3 the bandwidth available (25.92Gb/s) allows for maximum of 4K@98Hz 4:4:4 10b when DSC isn't used (~26Gb/s). To achieve 4K@120Hz 10b either 4:2:2 or DSC must be used (~32.27Gb / 1.5 ~= 21.5Gb/s).
Thus, HDR with 4K@120Hz looks to be possible, if I'm reading tables on Wikipedia correctly.
Can we get VRR?
In the negotiation of HDMI the VMM reports "VRR_min: 0, VRR_max: 0", suggesting that VRR isn't supported or enabled. Can this be changed? Well, probably Synaptics configuration does contain an option for that. Carefully reading the "Spyder" (codename for Vxx7100 class of chips) press release it seems like Intel was able to drive "4K120 gaming TVs with VRR support". This is probably TBD with CableMatter engineers. It's possible that there's some bug causing VRR to be disabled with DSC.
Cables are everything!
4K@120 is a lot of data and it really pushes cables to the limit. While looking through the debug log from VMM7100 you can clearly see that the chip not only negotiates parameters but also tests the link physical capabilities, indirectly testing both cables. When everything goes well you will see something like that in the debug log:
Code:00:00:17:094 Measured clock close to MVID based clock: 593971133 593953857 00:00:17:141 RX0 measured pixel clk: 593971133Hz, stable: 1 .... 00:00:20:297 Enter tx_hdmi_frl_link_training: 0 1 1 6 00:00:20:672 TX0 FRL training success at the 4lane 8GHz .... 00:00:22:250 Nothing error, enable both audio and video: 00003700
I tested a box of cables and even the "2.1 supposedly-certified high-ultra-speed" ones are unstable. The HDMI connection can fail in many peculiar ways, especially when adapters are involved. The VMM chip really tries to negotiate something usable over flat-out failing:
I'm not a chip designer, but I asked around in the office where I work with ASIC people. Apparently doing such a buffering to downsample from e.g. 120 on DP to 60 on HDMI wouldn't be as simple as taking every other frame. It doesn't seem that VMM7100 supports that. Thus, if the HDMI cable isn't up to the task the only thing the chip can do is attempt to use DSC and/or downgrade to 4:2:0, but it will still need to keep 4K@120.
- You can get negotiation failure overall with no signal on the screen
- Some cables are so bad that 4K@120 at any chroma subsampling fails
- You will see
Can't lower down the link rate, retry same link ratemultiple times in the log- Downgrade to 4:2:0
- With mediocre cables you can sometimes get 4:4:4 but sometimes during link training 4:2:0 is negotiated
- This is the most annoying to debug, especially if the cable works 7/10 times
- Sometimes the handshake fails completely and you get a fully green screen on the HDMI; this can also happen when HDCP fails
- Links at 4K@120 4:4:4 but randomly stops working
- This is usually accompanied with the the stuff working initially but randomly starts displaying a full-screen random colorful pixels
- It seems like the predictor for that is unstable training, with many re-trainings on the TX side, that eventually end up with:
Code:00:01:31:344 tx0 FRL link training failed due to unknown reason: 255 00:01:31:359 FRL mode link training failed: ff 00:01:31:375 Enter tx_hdmi_frl_link_training: 0 1 1 6- Since the link is using DSC it seems to fail first with
DSC0 status changed: from 00000000 to 01000000. It's most likely happening due to some FEC threshold being crossed, causing the DSC PLL to just give up and force re-negotiation.- After multiple retrains it sometimes end up with
TX0 FRL training success at the 4lane 6GHz- this is significantly lower than "4lane 8Ghz" seen in the good cable scenario
CM adapter vs cable
Did I mention that "cables are everything"? Well, the CM adapter with HDMI cable doesn't seem to be very stable. Most of the time the CM cable will either fail HDMI training for 4L8 or will simply downgrade to 4:2:0. I was able to get full 4K@120 4:4:4 8b with FRL 4L8 a few times, but it was short-lived and ended up with "digital snow" after under a minute, multiple link retrains and a failure in the end.
CM adapter, running the exact same firmware, works perfectly and is stable given a good HDMI-HDMI cable. Thus my personal recommendation is to avoid CableMatters 201362-GRY-1.8m-E (male USB-C => male HDMI). The software side is working correctly, but the HDMI cable attached to the adapter doesn't seem to be good enough to work to the full potential of VMM7100. This obviously may change in the future.
Cautionary Tale: Backups aren't always working
VMM7100 seems to be hard to brick as it uses two A/B flash banks. However, using "Save to file" and then "Load to FLASH" doesn't always work. Thus, restoring original firmware may not be possible in some instances.
------
I'm going to bed - if is screwed up something let me know
Yeah iam also think the CM HDMI Cable are not good enough to reach that Bandwidth. In OP i mentioned to use an official 48 Gbps Certified Cable. In other Hand the MOUSHU Adapter running with VMM6100 and over 1M HDMI cable can run 4:4:4 4k@120hz 10b ! I will not spend more time in VMM7100 anymore, i think it is not possible since i tested a lot of them. The best with VMM7100 u can get is 4:4:4 4k@120hz 8bit non HDR
Last edited:
I mean we bought from Amazon expecting the VMM6100 but received the VMM7100. I don't live in the US either so returning it is going to be a lot more pain than it's worth.
Very frustrating but is what it is.
The issue is these 1m ones aren't available anymore. The 1.5m may or may not work. Also, AliExpress is a complete trash:
Last edited:
We have to ask another guys here which version they buy. I think it was the 1,5M or 2M version.
The biggest problem seems to be that VMM6100-based cables/adapters are completely unavailable in any major retailers in the US. There're some for ~$25 on eBay but shipped directly from China, so there's no guarantees what we get - the situation may be similar like with the CM cables as VMM6100 is being discontinued overall.
I have an email chain with CM so maybe they can explain if 7100 & RGB isn't possible at all or that's a temporary setback.
8K @ 30Hz 4K @ 120Hz USB C Typ-C zu HDMI-Kompatibel Kabel zink-legierung version C zu HD Kabel Für TV display projektor Thunderbolt 3 - AliExpress 44
Smarter Shopping, Better Living! Aliexpress.com
Iam also in contact with them, but like I say before, they spend Month and it does still not work correctly. They dont know why the vmm6100(With special Firmware Version) works and why the vmm7100 not.
I just got another one.... -A.
Also, you may not want to force RGB color over 4:4:4 when DSC is used. This will cause internal color conversion and may result in worse results. You can learn a lot about the VMM chip capabilities from the HID tool itself.