#!/usr/bin/ruby | |
# Create display override file to force Mac OS X to use RGB mode for Display | |
# see http://embdev.net/topic/284710 | |
require 'base64' | |
data=`ioreg -l -d0 -w 0 -r -c AppleDisplay` | |
edids=data.scan(/IODisplayEDID.*?<([a-z0-9]+)>/i).flatten | |
vendorids=data.scan(/DisplayVendorID.*?([0-9]+)/i).flatten | |
productids=data.scan(/DisplayProductID.*?([0-9]+)/i).flatten | |
displays = [] | |
edids.each_with_index do |edid, i| | |
disp = { "edid_hex"=>edid, "vendorid"=>vendorids[i].to_i, "productid"=>productids[i].to_i } | |
displays.push(disp) | |
end | |
# Process all displays | |
if displays.length > 1 | |
puts "Found %d displays! You should only install the override file for the one which" % displays.length | |
puts "is giving you problems.","\n" | |
elsif displays.length == 0 | |
puts "No display data found! Are any external displays connected?" | |
puts "\nNote: Apple Silicon (arm64) devices are currently unsupported, as the standard" | |
puts "method of retrieving display information does not work." | |
end | |
displays.each do |disp| | |
# Retrieve monitor model from EDID display descriptor | |
i = disp["edid_hex"].index('000000fc00') | |
if i.nil? | |
monitor_name = "Display" | |
else | |
# The monitor name is stored in (up to) 13 bytes of text following 00 00 00 fc 00. | |
# If the name is shorter than 13 bytes, it is terminated with a newline (0a) and then padded with spaces. | |
monitor_name = [disp["edid_hex"][i + 10, 26].to_s].pack("H*") | |
monitor_name.rstrip! # remove trailing newline/spaces | |
end | |
puts "Found display '#{monitor_name}': vendor ID=#{disp["vendorid"]} (0x%x), product ID=#{disp["productid"]} (0x%x)" % | |
[disp["vendorid"], disp["productid"]] | |
puts "Raw EDID data:\n#{disp["edid_hex"]}" | |
bytes=disp["edid_hex"].scan(/../).map{|x|Integer("0x#{x}")}.flatten | |
puts "Setting color support to RGB 4:4:4 only" | |
bytes[24] &= ~(0b11000) | |
puts "Number of extension blocks: #{bytes[126]}" | |
puts "removing extension block" | |
bytes = bytes[0..127] | |
bytes[126] = 0 | |
bytes[127] = (0x100-(bytes[0..126].reduce(:+) % 256)) % 256 | |
puts | |
puts "Recalculated checksum: 0x%x" % bytes[127] | |
puts "new EDID:\n#{bytes.map{|b|"%02X"%b}.join}" | |
Dir.mkdir("DisplayVendorID-%x" % disp["vendorid"]) rescue nil | |
filename = "DisplayVendorID-%x/DisplayProductID-%x" % [disp["vendorid"], disp["productid"]] | |
puts "Output file: #{Dir.pwd}/#{filename}" | |
f = File.open(filename, 'w') | |
f.write '<?xml version="1.0" encoding="UTF-8"?> | |
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> | |
<plist version="1.0">' | |
f.write " | |
<dict> | |
<key>DisplayProductName</key> | |
<string>#{monitor_name} - forced RGB mode (EDID override)</string> | |
<key>IODisplayEDID</key> | |
<data>#{Base64.encode64(bytes.pack('C*'))}</data> | |
<key>DisplayVendorID</key> | |
<integer>#{disp["vendorid"]}</integer> | |
<key>DisplayProductID</key> | |
<integer>#{disp["productid"]}</integer> | |
</dict> | |
</plist>" | |
f.close | |
puts "\n" | |
end # displays.each |
@aseevlx does this method also solve the problem of HIDPI on external monitors?
@ibehnam I don't know about the HiDPI problem, sorry. The resolution of my main display is 3440x1440 and I don't have the problem of blurry fonts. But I think you can try to create another extension block with "supported" resolution in EW EDID Editor, but that's just my thoughts.
@xeroxoid excellent, I'm very glad you also find this useful.
I also tried to decode the data using system base64 lib, but I saw that it cuts off some of the encoded binary data. So the size of the resulting file is also different: 532 bytes for the file created by the ruby script, and 128 bytes for the file resulting from decoding with system base64. So I haven't tested this approach, but it's very interesting that it works too.
Hey team, just wanted to update you that with macOS 12.4, there seems to be native support for HiDPI on external monitors as well now, without additional modifications:
Source for the news: https://www.reddit.com/r/MacOS/comments/uvsdv8/did_apple_solve_the_hidpi_problem/
Ping @hanoii and @ibehnam who were asking about these issues
Thanks @GetVladimir, this is good news coming from Apple. Although, as the reddit comments mentioned, Apple has only put ≤720p HiDPI resolutions (at least for my 2K monitor with 2560x1440). So, I still use BetterDummy to get by.
There's also a flickering issue with external displays which happens when the M1 mac wakes up from sleep. The solution is to re-plug the HDMI cable, or turn the monitor off and on again.
@ibehnam thank you for the reply and for the confirmation.
The screenshot on the original Reddit post seems to show HiDPI resolutions higher than 720p, but they might be based on a 4K monitor.
Also, good to know regarding the flickering issue workaround, thanks!
How to enable HiDPI on M1 based Macs on any resolution
I have some interesting news: I found a solution to enable HiDPI on M1 based Macs on any resolution, even on 1080p screens, without the need to use mirroring or other workarounds.
Here is an example of HiDPI running on a Dell U2415 monitor that only supports a maximum resolution of 1920x1200:
What you need to do is to edit the com.apple.windowserver.displays.plist file located in
/Library/Preferences/com.apple.windowserver.displays.plist
and change the key <key>Scale</key>
to have a value of 2.
This is an example of how the section in the displays plist file should look like after the change:
<key>CurrentInfo</key>
<dict>
<key>Depth</key>
<integer>8</integer>
<key>High</key>
<real>1200</real>
<key>Hz</key>
<real>60</real>
<key>IsLink</key>
<false/>
<key>OriginX</key>
<real>0.0</real>
<key>OriginY</key>
<real>0.0</real>
<key>Rotation</key>
<integer>0</integer>
<key>Scale</key>
<real>2</real>
<key>Wide</key>
<real>1920</real>
</dict>
Make sure that you change only the Scale key for the monitor that you need, and nothing else.
You can follow the step-by-step video tutorial on how to make the changes in the displays plist file here:
https://www.youtube.com/watch?v=Z1EqH3fd0V4
After that, restart your Mac and you should get HiDPI and noticeably more crisp and anti-aliased text, and the high resolution macOS icons.
An easy way to confirm that the HiDPI changes work is by looking at the Safari icon on the dock. If the HiDPI version of the icon is enabled, it will have a lot more sections in the compass than the low resolution icon. It should look something like this:
Please note that while this might make the image look better even on 1080p screens, they will still be running at 1080p resolution, so the change might not be as drastic as running on a higher resolution screen.
If you have any questions about the procedure, please feel free to contact me or comment below.
Can confirm this patch work to fix my magenta coloured extended display.
Colours now display correctly.
However, the display is now shifted 15% to the right, so that the right edge is cropped off screen.
The only way to regain the lost portion is to adjust overscan in display preferences, to shrink down the overall screen, but this obviously leaves a smaller display with a border around the sides.
What is the script doing, that alters horizontal image shift?
@Shortz79 Do you get any additional options if you check the "Show all resolutions"? Or they are completely gone?
Hi there - I have a lg C1 48 OLED and M1 Mac mini - I would like to get 2k 2560x1440p 120hz HiDpi but having no luck - I can only get the low resolution of 2k on 120hz - any help on how to get HiPi 120hz at 2k?
Hi there - I have a lg C1 48 OLED and M1 Mac mini - I would like to get 2k 2560x1440p 120hz HiDpi but having no luck - I can only get the low resolution of 2k on 120hz - any help on how to get HiPi 120hz at 2k?
The purpose of this script is fixing colors, RGB vs YPbPr. It does not attempt to set resolution or refresh rate.
@law94air I'm not sure if you can set 1440p on 120Hz even with the 2x scaling workaround here (https://gist.github.com/adaugherity/7435890?permalink_comment_id=4207100#gistcomment-4207100)
There doesn't seem to be enough bandwidth on the HDMI port on the M1 Mac mini to support it.
Perhaps other users with that same display can give you a better confirmation
@law94air I'm not sure if you can set 1440p on 120Hz even with the 2x scaling workaround here (https://gist.github.com/adaugherity/7435890?permalink_comment_id=4207100#gistcomment-4207100)
There doesn't seem to be enough bandwidth on the HDMI port on the M1 Mac mini to support it.
Perhaps other users with that same display can give you a better confirmation
I'm using the thunderbolt port connection on Mac to hdmi so enough bandwidth...it's apple restricting Hidpi usage I reckon
@law94air I'm not sure if you can set 1440p on 120Hz even with the 2x scaling workaround here (https://gist.github.com/adaugherity/7435890?permalink_comment_id=4207100#gistcomment-4207100)
There doesn't seem to be enough bandwidth on the HDMI port on the M1 Mac mini to support it.
Perhaps other users with that same display can give you a better confirmation
I am using the thunderbolt 4 port
After an even grosser hack of https://gist.github.com/adaugherity/7435890?permalink_comment_id=4132166#gistcomment-4132166 (at https://gist.github.com/glyph/86421ad155c4f9bf30932205e14974de), I was able to get a display override to work on my M1 machine. I can't figure out how to patch the EDID itself for the life of me, but, I was able to extract the vendor ID and product ID, and create a file called
/Library/Displays/Contents/Resources/Overrides/DisplayVendorID-1e6d/DisplayProductID-774d
with the contents
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>DisplayProductName</key>
<string>LG HDR WQHD+ (107NTQDAV764) NotTV</string>
<key>DisplayVendorID</key>
<integer>7789</integer>
<key>DisplayProductID</key>
<integer>30541</integer>
<key>DisplayIsTV</key>
<false/>
</dict>
</plist>
and with that, System Information.app no longer shows me "Television: Yes", and I See my custom name in Displays.
Sadly this does not make it default to RGB/4:4:4, as far as I can tell.
I tried using the aforementioned AW EDID editor to switch off YUV / YPbPr 422 everywhere I could see it in the UI, and sticking in a IODisplayEDID
key with the base64-encoded modified binary file, and … it seems like maybe it worked? I can force it to go back to YUV422 by switching back to 144Hz which is not promising, but if I leave it at 120 it seems to stay in RGB mode, at least with my testing so far.
it seems like maybe it worked?
Nope. Patched EDID apparently does nothing. Switches back to YUV again when I disconnect for 30 minutes and plug in again. Sigh.
After spending a truly ludicrous amount of time trying to get this to work automatically, I'm curious if anyone else has tried using the edid-patches
key rather than the IODisplayEDID
one on an Apple Silicon machine?
@glyph Yes, I have tested with the edid-patches as well on M1 Mac mini, and all the ones I've tested don't seem to do anything or are ignored completely
@glyph Yes, I have tested with the edid-patches as well on M1 Mac mini, and all the ones I've tested don't seem to do anything or are ignored completely
@GetVladimir Bummer. Thanks for the reply; I think the real answer has got to be Apple fixing this, but gosh it's annoying in the meanwhile.
@GetVladimir Bummer. Thanks for the reply; I think the real answer has got to be Apple fixing this, but gosh it's annoying in the meanwhile.
Don't hold your breath. Sadly its been over 2 years since there have been ARM-based Mac Mini's and this is still an issue. pretty sure Apple couldn't care less about it. Any other platform you can, you know... change your settings, if they aren't auto-detected properly. My solution was to sell mine and never buy another one. Its just ridiculous that people have to deal with this nonsense in a supposedly premium product.
Hi. I have this same / similar issue on my Apple / Mac, that when in HDR mode my HDR-compatible external monitor tinges everything a dull, muted, gray color. Whites are especially noticeable - they're simply not white, they're grey. Turn HDR off and everything is PERFECT again (you know, besides not being able to watch HDR content...). Also, guess what? Booting my Mac to Windows/Boot Camp on the SAME COMPUTER (same cables/screen, everything) and the issue is FIXED - this is solely a macOS issue, seemingly going ALL the way back to Catalina...
YOU HAVE TO REPORT THIS TO APPLE FOR THEM TO FIX IT. Apple support, and their engineering teams have NO RECORD OF THIS ISSUE!!! You have to contact them through their support chat or a phone call (posting here does nothing tbh). FYI, Apple support told me you can start an Official Apple Support ticket even if your computer isn't in the 1-year warranty, or 3-year AppleCare period (just as long as you're using their newest OS, Ventura). I found this all out today since this problem persists on my brand new Mac mini M2 Pro, and when I contacted them they told me all the above (and also told me it was a good idea to post to everybody on the Apple forums and tell them to report this so it gets on their radar, and hopefully gets fixed!!!).
For my particular case, I've tried TWO HDR-compatible Macs (2018 MacBook Pro 15", 2023 Mac mini M2 Pro). Multiple HDMI 2.0 and HDMI 2.1 CERTIFIED HDMI cables. Multiple monitors / 4K TV's (three different brands) and the problem persists... and when Windows 10 is fine on the (Intel based Mac I tested at least) it's a fact it's NOT the hardware, it's a macOS issue. Other articles surmise that the 'Mac outputs incorrect YPbPr colour', since when you manually (though a programming-esque type GitHub-documented process) change it to output RGB the problem is fixed...
Anyway, with my support ticket to Apple they wanted a video or screenshot of this issue... which it's nearly impossible to capture this on video since my iPhone auto-white balances and/or increases brightness for a darker image (so I can't capture just how much darker the HDR image is to the naked eye, and how all my whites are now gray with HDR turned on)... so I literally took my professional X-Rite Colorimeter and took readings with HCFR display calibration software to show them (all live on video) the very large difference between HDR enabled, and disabled. Literally proved that HDR (in the macOS itself) is HALF as bright as SDR... when it should be the complete opposite... I'll report back if there is a fix... but I'm not hopeful... this has been reported THOUSANDS of times all over the net since Catalina in 2019 and it's still not fixed... and somehow Apple says they've never even heard of this issue... (and Apple won't even let me give them links to non-apple websites to show all these people with this same issue... even the sites where they developed a possible fix for it...).
@Dochartaigh You're right, it's been an issue for many years already. Both x86 based and M1/M2 Macs are having the color output issues.
It's also relatively easy to confirm that it's a macOS software related issue, since the same hardware works great on Bootcamp, at least the x86 Macs that we can test.
@Dochartaigh You're right, it's been an issue for many years already. Both x86 based and M1/M2 Macs are having the color output issues.
It's also relatively easy to confirm that it's a macOS software related issue, since the same hardware works great on Bootcamp, at least the x86 Macs that we can test.
Sorry if I seem like I'm spamming with the above... Apple support literally told me to post everywhere (which I'm going through google results now and posting everywhere I see this issue discussed lol) to get people to ACTUALLY CALL APPLE and report this issue... because according to them they've never, ever, seen this issue reported in their internal troubleshooting / problem database... (besides me, reporting it just today).
...I have a hard time believe the above though, because I'm literally going through all 280 of the discussions.apple.com posts about this right now... and so many of those posts have hundreds of people who checked the "me too" button... which means they experience this same issue as well... so I just don't believe that NONE of those other people have ever reported this to apple before...
Anyway, if anybody reads this PLEASE REPORT TO APPLE so they fix this and we don't have to jump through github programming stuff (which is above me tbh...) to fix this. Again, your computer doesn't have to be under Apple warranty/AppleCare, just needs to be running Ventura macOS.
@law94air1976 you can try starting the Mac in safe mode and see if you can delete the override.
Depending on the type of Mac that you use, here are the steps to start in safe mode: https://support.apple.com/en-ie/guide/mac-help/mh21245/mac
Right now im connected with 48gbit (4L12), but with this script, im only allowed for RGB 8bit 60hz. I tried to use another github users edid (both LG tv's but not the same model - and he was running USB-C -> HDMI 2.1, i'm running Displayport 1.4a -> HDMI 2.1).... but with his, I get RGB 10bit 60hz. I know my connection allows for atleast RGB 8bit 120hz and maybe 10bit.
So my question is, what does it take to force 4K 120hz?
Without any script/edid mod, im getting the same 4:2:0 10b 4k 120hz as the rest of the Mac gang.
Dual boot to Windows allows = 4K 444 Full RGB 10/12bit 120hz VRR
I ended up reverting to USB C > DisplayPort for my Dell U2713H monitor to bypass these RGB problems, but now have to switch to USB C > HDMI (reasons too dull to explain).
However, I now can't get the LinkDescription override to work. Each time I modify the com.apple.windowserver.displays.plist file and restart, the file seems to be reset or regenerated to its original unmodified version. This is with the Mac Mini connected to a KVM switch with USB C > HDMI and then HDMI > HDMI on the monitor – I don't know if that's a factor.
Am I missing something obvious here..?
(BTW Apple is well aware of this issue -- I spent 3 months with tech support when I first got my Mac Mini M1 when it first launched trying all sorts of solutions from them, before they eventually stopped replying to me. Still worth reporting, though – you never know.)
@Adlopa thank you for the comment and for the details.
Yes, it's very likely that the Mac detects the KVM switch as a different device each time and assigns it a different UUID. This makes it very hard to add the LinkDescription properly.
If possible, please use an HDMI to HDMI cable for the Mac mini and the monitor and avoid using the KVM or any dock/adapter between the Mac and the Monitor.
I ended up reverting to USB C > DisplayPort for my Dell U2713H monitor to bypass these RGB problems, but now have to switch to USB C > HDMI (reasons too dull to explain).
However, I now can't get the LinkDescription override to work. Each time I modify the com.apple.windowserver.displays.plist file and restart, the file seems to be reset or regenerated to its original unmodified version. This is with the Mac Mini connected to a KVM switch with USB C > HDMI and then HDMI > HDMI on the monitor – I don't know if that's a factor.
Am I missing something obvious here..?
(BTW Apple is well aware of this issue -- I spent 3 months with tech support when I first got my Mac Mini M1 when it first launched trying all sorts of solutions from them, before they eventually stopped replying to me. Still worth reporting, though – you never know.)
Based on the discussion here, you really need to use USB-C -> DisplayPort to be sure this is gonna work properly.
The LinkDescription
workaround used to work well before Ventura, but now even that won't work.
@GetVladimir @shageevan awesome solution indeed.
As I was also stuck at 50Hz when using the custom EDID, I gave it a shot, but for some reason the edid.bin can not be read by AW EDID Editor, it said the file is corrupted.
for some reason the decoding did not work correctly (probably because I use a newer Ruby version
ruby 2.7.4p191
so I just saved the edid string to a file i.e.base64.txt
and runbase64 --decode base64.txt > edid.bin
instead. That worked and I could then read the file in AW EDID Editor.All good, RGB mode on and 100Hz over HDMI working! Thanks.