Hi, I recently Prime-Day bought a new-for-2023 4K LG 43" "SMART Display" monitor (43SQ700S) and have it connected to a 13" MacBook Pro, 2020 model with the quad-core i7, 4 Thunderbolt 3 ports. I've been trying to get it to run at 4K 60Hz with pixel-accurate color (RGB or YCbCr 4:4:4) and am pulling my hair out. This is a relatively pedestrian requirement in today's day and age, so I'm in disbelief and feel I must be missing something. Googling led me to a lot of threads here, re: the M1s but also other assorted threads, and I've both learned a lot and have attempted to use some of the tools suggested/recommended by user @joevt. I've run out of knowledge though and would love some further advice.
The monitor is aimed at the dual-use PC/TV market, so connectivity is through HDMI or USB-C. The former is connected through a relatively new Anker multiport dongle, the latter is direct. The two connections give different results, but neither are pixel-accurate. I think this might be a limitation/defect in the firmware of this particular model monitor (more on that later) and I should return it for something else, but I'm trying to positively understand if that's the case and that requires understanding how exactly the computer is trying to talk to the monitor.
First off, the monitor has no way through the menus etc... to see the input format details. I tried finding ways to get into the service menu, but I wasn't able to find anything that works for this model; I think it's just too new. I am observing the color sampling using the popular test image from RTINGS.com. I've attached some close-up photos of the different behaviors to illustrate what I'm seeing. They're thumbnailed to keep this post readable, but view them full-sized to see the pixel detail and focus on the last two red/blue samples.
4K 30Hz displays accurate per-pixel color over either input. That's great, but 30Hz isn't.
4K 60Hz over HDMI is terrible. I believe this is YCbCr 4:2:0.
4K 60Hz over USB-C is quite usable, but adjacent red and blue pixels still show artifacts (definitely view the image full-sized). I believe this is YCbCr 4:2:2, or possibly some kind of weird internal LG format since it doesn't look as bad as I'd expect 422 to look; but it's definitely not 444.
I first found @joevt 's EDIDUtil.sh and used that and edid-decode to explore. I initially latched onto the fact that the monitor is 10bpc, which just toes over the maximum bandwidth line vs 8bpc for some types of connections (according to Wikipedia; I'm not an expert). I tried making an EDID override, first using a popular patch-edid.rb Ruby script to strip out all of the non-RGB modes. It appeared the EDID override was being used (by virtue of seeing the custom override name in the Display settings), but the image showed the same red/blue artifacts. I then used EDIDUtil to strip that EDID down to 8bpc, and again the EDID was being used but the artifacts remained.
This whole time I was guessing as to what was being sent to the monitor, because the output of AGDCDiagnose had changed sometime between when many of the posts were written (2021-ish) and now (running Ventura 13.4.1) and didn't seem to list the bpc or encoding. Eventually, I discovered @joevt 's newer AllRez tool, and was able to get some more meaningful information.
I've attached a zip with AllRez output for 3 configurations: using the HDMI connection, using the USB-C connection, and using the USB-C connection but with the "RGB 8bpc only" EDID override installed. I poured through the output and am confused by some things.
1) The HDMI connection is using 2 lanes of HBR3, which shouldn't be enough bandwidth for 4K 60Hz 10bpc RGB or 444 (although it looks like it has DSC support, but isn't using it?). However the CURRENT MODE in the AllRez output claims to be 4K 60Hz RGB, with 3 of the API calls claiming 10bpc and 1 claiming 8bpc. The display appears to my eyeballs to be 420. I found a line "startup-timing" in the associated framebuffer object that claims 4K 60Hz 10bpc but BT709 colorimetry and 420 encoding. So, I'm not sure what's actually being sent over the wire... is it the framebuffer timing since that matches what I'm seeing on the screen? Or the CURRENT MODE which claims to be something that shouldn't fit into 2 lanes of HBR3? There's so much data here, I'm probably missing something.
2) The USB-C connection (DP Alternate Mode I assume) with the "native" EDID uses 4 lanes of HBR2, which should be just enough for 4K 60Hz 10bpc in RGB or 444 over DisplayPort I think. The CURRENT MODE again shows 4K 60Hz 10bpc/8bpc RGB, but the framebuffer startup-timing shows 4K 60Hz 8bpc RGB. Either of those would be fine, but unfortunately, the red/blue artifact is clearly observable on the screen (whereas it's crystal clear when run at 4K 30Hz).
3) The USB-C connection with the "8bpc RGB-only" override EDID uses the same 4 lanes of HBR2. Same CURRENT MODE as before, but the framebuffer shows 4K 60Hz 8bpc 444 BT709. As in the previous case, either of those options would look OK, but it has the identical blue/red artifacts. This one is weird because despite appearing to use the override and showing a different framebuffer encoding than when native, the EDID info and modes dumped by AllRez still show 10bpc and non-RGB encodings available. So it's possible I messed something up when creating the override.
I don't really care about the HDMI connection, but I don't understand what's going on with either of the USB-C scenarios. Is what's being sent over the wire the mode shown in CURRENT MODE, or the framebuffer startup-timing? If it's the framebuffer, then either of the USB-C connections "should" provide true per-pixel color, which it visibly doesn't.
The only sort-of-explanation I have comes from some information shown in the monitor's on-screen display (below). There's a page describing the "Deep Color" setting, which needs to be enabled to support higher bandwidth connections in LG monitors (I had it enabled in "4K" mode for all of these tests). There is a table that shows what encodings are supported at different bit depths (none of this is in the manual, by the way). 8-bit depth supports 420, 422, 444, and RGB, but 10-bit only shows support for 420 and 422, no 10-bit 444 or RGB. No idea why, it should have the bandwidth.
So my hypothesis is that this is just a limitation (or bad engineering) of what is a relatively cheap monitor (for 43" 4K). The monitor is advertising it is 10bpc-capable, the Mac is supplying it with 10bpc, but some limitation of the firmware/hardware in the monitor means you can only get 420 or 422 at 10bpc. It would seem like if the source could be forced to supply 8bpc, then the monitor might accept 444 or RGB; but it's asinine that LG would produce a monitor that tells the source to send 10bpc when it doesn't support 444 or RGB at that depth. I'd much rather sacrifice color depth than chroma resolution.
This is a long post but I wanted to be thorough regarding all the things I've tried. If anyone can definitively answer how to interpret the AllRez output to know what's actually being sent over the wire, that would be helpful. I'm leaning towards there being nothing wrong with the Mac setup, and the product is just inexplicably designed. It might be something they fix with an update, but I'm not willing to bet (or wait) on that. FWIW, plugging a Windows 10 laptop into it via USB-C results in the same red/blue artifacts at 60Hz, fine at 30Hz. This experience is extra-disappointing because I have another LG 43" (43UD79-B) at another location that works just fine at 4K 60Hz, and it's from 2017.
Thanks for reading!
The monitor is aimed at the dual-use PC/TV market, so connectivity is through HDMI or USB-C. The former is connected through a relatively new Anker multiport dongle, the latter is direct. The two connections give different results, but neither are pixel-accurate. I think this might be a limitation/defect in the firmware of this particular model monitor (more on that later) and I should return it for something else, but I'm trying to positively understand if that's the case and that requires understanding how exactly the computer is trying to talk to the monitor.
First off, the monitor has no way through the menus etc... to see the input format details. I tried finding ways to get into the service menu, but I wasn't able to find anything that works for this model; I think it's just too new. I am observing the color sampling using the popular test image from RTINGS.com. I've attached some close-up photos of the different behaviors to illustrate what I'm seeing. They're thumbnailed to keep this post readable, but view them full-sized to see the pixel detail and focus on the last two red/blue samples.
4K 30Hz displays accurate per-pixel color over either input. That's great, but 30Hz isn't.
4K 60Hz over HDMI is terrible. I believe this is YCbCr 4:2:0.
4K 60Hz over USB-C is quite usable, but adjacent red and blue pixels still show artifacts (definitely view the image full-sized). I believe this is YCbCr 4:2:2, or possibly some kind of weird internal LG format since it doesn't look as bad as I'd expect 422 to look; but it's definitely not 444.
I first found @joevt 's EDIDUtil.sh and used that and edid-decode to explore. I initially latched onto the fact that the monitor is 10bpc, which just toes over the maximum bandwidth line vs 8bpc for some types of connections (according to Wikipedia; I'm not an expert). I tried making an EDID override, first using a popular patch-edid.rb Ruby script to strip out all of the non-RGB modes. It appeared the EDID override was being used (by virtue of seeing the custom override name in the Display settings), but the image showed the same red/blue artifacts. I then used EDIDUtil to strip that EDID down to 8bpc, and again the EDID was being used but the artifacts remained.
This whole time I was guessing as to what was being sent to the monitor, because the output of AGDCDiagnose had changed sometime between when many of the posts were written (2021-ish) and now (running Ventura 13.4.1) and didn't seem to list the bpc or encoding. Eventually, I discovered @joevt 's newer AllRez tool, and was able to get some more meaningful information.
I've attached a zip with AllRez output for 3 configurations: using the HDMI connection, using the USB-C connection, and using the USB-C connection but with the "RGB 8bpc only" EDID override installed. I poured through the output and am confused by some things.
1) The HDMI connection is using 2 lanes of HBR3, which shouldn't be enough bandwidth for 4K 60Hz 10bpc RGB or 444 (although it looks like it has DSC support, but isn't using it?). However the CURRENT MODE in the AllRez output claims to be 4K 60Hz RGB, with 3 of the API calls claiming 10bpc and 1 claiming 8bpc. The display appears to my eyeballs to be 420. I found a line "startup-timing" in the associated framebuffer object that claims 4K 60Hz 10bpc but BT709 colorimetry and 420 encoding. So, I'm not sure what's actually being sent over the wire... is it the framebuffer timing since that matches what I'm seeing on the screen? Or the CURRENT MODE which claims to be something that shouldn't fit into 2 lanes of HBR3? There's so much data here, I'm probably missing something.
2) The USB-C connection (DP Alternate Mode I assume) with the "native" EDID uses 4 lanes of HBR2, which should be just enough for 4K 60Hz 10bpc in RGB or 444 over DisplayPort I think. The CURRENT MODE again shows 4K 60Hz 10bpc/8bpc RGB, but the framebuffer startup-timing shows 4K 60Hz 8bpc RGB. Either of those would be fine, but unfortunately, the red/blue artifact is clearly observable on the screen (whereas it's crystal clear when run at 4K 30Hz).
3) The USB-C connection with the "8bpc RGB-only" override EDID uses the same 4 lanes of HBR2. Same CURRENT MODE as before, but the framebuffer shows 4K 60Hz 8bpc 444 BT709. As in the previous case, either of those options would look OK, but it has the identical blue/red artifacts. This one is weird because despite appearing to use the override and showing a different framebuffer encoding than when native, the EDID info and modes dumped by AllRez still show 10bpc and non-RGB encodings available. So it's possible I messed something up when creating the override.
I don't really care about the HDMI connection, but I don't understand what's going on with either of the USB-C scenarios. Is what's being sent over the wire the mode shown in CURRENT MODE, or the framebuffer startup-timing? If it's the framebuffer, then either of the USB-C connections "should" provide true per-pixel color, which it visibly doesn't.
The only sort-of-explanation I have comes from some information shown in the monitor's on-screen display (below). There's a page describing the "Deep Color" setting, which needs to be enabled to support higher bandwidth connections in LG monitors (I had it enabled in "4K" mode for all of these tests). There is a table that shows what encodings are supported at different bit depths (none of this is in the manual, by the way). 8-bit depth supports 420, 422, 444, and RGB, but 10-bit only shows support for 420 and 422, no 10-bit 444 or RGB. No idea why, it should have the bandwidth.
So my hypothesis is that this is just a limitation (or bad engineering) of what is a relatively cheap monitor (for 43" 4K). The monitor is advertising it is 10bpc-capable, the Mac is supplying it with 10bpc, but some limitation of the firmware/hardware in the monitor means you can only get 420 or 422 at 10bpc. It would seem like if the source could be forced to supply 8bpc, then the monitor might accept 444 or RGB; but it's asinine that LG would produce a monitor that tells the source to send 10bpc when it doesn't support 444 or RGB at that depth. I'd much rather sacrifice color depth than chroma resolution.
This is a long post but I wanted to be thorough regarding all the things I've tried. If anyone can definitively answer how to interpret the AllRez output to know what's actually being sent over the wire, that would be helpful. I'm leaning towards there being nothing wrong with the Mac setup, and the product is just inexplicably designed. It might be something they fix with an update, but I'm not willing to bet (or wait) on that. FWIW, plugging a Windows 10 laptop into it via USB-C results in the same red/blue artifacts at 60Hz, fine at 30Hz. This experience is extra-disappointing because I have another LG 43" (43UD79-B) at another location that works just fine at 4K 60Hz, and it's from 2017.
Thanks for reading!
Last edited:
