wow i have no clue what you wrote
Is there any guide how get HiDPI 2560x1440 and 51240x1440 ?Is it possible only on Intel or also on mac m1 ?
What is the performance on that?
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.
Intel Graphics and 5120x1440 testing in Big Sur
- Thread starter joevt
- Start date
- Sort by reaction score
Is there any guide how get HiDPI 2560x1440 and 51240x1440 ?Is it possible only on Intel or also on mac m1 ?
What is the performance on that?
The patch is for Intel Macs with Intel GPU. It is tested with Coffee Lake (8th gen) CPU but may work with Kaby Lake (7th gen). I don't know if it will work with Skylake (6th gen).wow i have no clue what you wrote
Is it possible only on Intel or also on mac m1 ?
Setup OpenCore, perhaps using OCLP, replace Lilu/WhateverGreen kexts in the kexts folder with my versions. Edit the config.plist with the necessary patches. There's a flag for making the driver validate all modes. My AllRez command has code for setting that - I should probably add a boot-arg to set the flag.
I suppose it might be slightly slower but I haven't done benchmarks.
I haven't tested beyond the 5K timing or beyond the 10K scaling. What kind of modes would someone realistically want from an HBR2 link when Thunderbolt 3 is already supported? 5K60 from LG UltraFine 5K or Apple Studio Display and 5K2K@60Hz from LG 5K2K display already work using Thunderbolt 3 and dual tile modes. I guess getting 6K@34Hz 8bpc from Apple Pro Display XDR would be nice - that would be the simplest achievable mode for single link connection. HDR would require 27Hz but I don't know what is the lowest refresh rate that the XDR can support. If 6bpc were possible, then we could get as high as 45Hz. If we could use the XDR's dual HBR2 mode for anything other than 5K then we could get 60Hz 8bpc and 53Hz 10bpc. Then getting some kind of 8K mode for the Dell UP3218K would be interesting - using single or dual cable connection.
Do we know whether the XDR accepts lower refresh rates by lowering the pixel clock? IIRC its OOTB lower refresh rate timings all use virtually the same pixel clock.
Do we know which (if any) Intel iGPUs can do a height of 4320 or more on macOS?
Last edited:
True, all the 6K timings use ≈1286MHz. But the XDR display can use other timings. For example, all the 5K timings are ≈934MHz and all the 4K timings are 528MHz. The timings are 48 and 60Hz, plus the 1000/1001 versions of those, plus 50Hz. There's also one 1440p60 timing.
I did some more testing with my patch in Ventura.
I can get 5120x2880@37Hz from iGPU of Mac mini 2018 but I can't get higher refresh rate because it's not allowing less than 10bpc such as 8bpc.
6016x3384@27Hz produces a garbled image even though my display can accept 8K input and go as low as 20Hz. The Apple Intel graphics driver says:
[IGFB][INFO ] FB1 Transaction unsupported. Device Space destination rect not in range Input = 6016 x 3384
Capabailities = 5120 x 2880. Looks like I need to make more patches.4320x4320@24Hz outputs black. The display says the mode is 4320x224@24Hz so something is being output. 224 is exactly 4320 minus 4096 so maybe there's a 4096 (4K) height limit.
For scaled modes, I tried 16:9 scaled modes up to 15392x8658 successfully using 4K timings (20Hz - 60Hz but not 594MHz because that exceeds the 10bpc limit) and 5K timings (37Hz). 15424x8676 scaled mode produces a black signal.
15392 x 8658 x 4 bytes per pixel is only 508.4 MB.
15424 x 8676 x 4 = 510.5MB. Maybe there's a near 512MB framebuffer limit. Maybe there's a patch for that (OpenCore or WhateverGreen.kext, Hackintool.app...).
Last edited:
I don't think I'll try to exceed 4096 vertical output limit. It's probably a hardware limit.
I made a patch to get past that error message but the image is still garbled. Same for 5152x2898@25Hz timing. The display detects the resolution and timing correctly, but the image is garbled.
4096x4096@21Hz, 4112x4096@21Hz, 4320x4096@21Hz, and 5120x4096@21Hz all work, so the problem is with the horizontal component beyond 5120 width. Is this a hard limit in the Intel GPU hardware (pre Ice Lake)? Should check Linux driver to see why there's a limit.
Years ago I found an equation for framebuffer size for Skylake GPU (predecessor to Kaby Lake and Coffee Lake). It appears to be the same calculation used by Coffee Lake.
function framebuffersize { echo $1x$2 = $(( (((($1 * 4 + 0x1FF) & 0xfffffe00) * $2 ) + (1024*1024-1)) / 1024 / 1024 )) MB; }The important part is that the number of bytes per row (horizontal pixels x 4 bytes per pixel) is rounded up to the nearest 512 bytes. There's some alternate code that rounds up the row bytes to the nearest 128 bytes but I'm not sure when that gets used. The result is rounded up to the nearest megabyte.
Code:
framebuffersize 15392 8658
15392x8658 = 512 MB (works)
framebuffersize 15424 8676
15424x8676 = 513 MB (black screen)
Code:
framebuffersize 13312 9984
13312x9984 = 507 MB (works)
framebuffersize 13344 10008
13344x10008 = 514 MB (black screen)Linux has a 5120 width limit but I don't know why. I didn't try looking very hard at the code or the documentation - seems like it would take forever without an Intel Graphics for Dummies summary.
There's still a small chance that the Intel Graphics of the Mac mini 2018 can achieve 6K - by using dual tile mode. The Apple Pro Display XDR has a tiled mode for 5K (dual HBR2 connection) and 6K (dual HBR3 connection). Since we have a patch to exceed the 2880 height limit, we can maybe do dual tile 3008x3384 HBR2 to get 6K@53Hz 10bpc RGB. I'm working on a tile EDID override method.
Intel GPU docs at:
https://01.org/linuxgraphics/documentation
https://01.org/linuxgraphics/documentation/hardware-specification-prms
I think for Kaby Lake and Coffee Lake there's just a Configurations pdf and you're supposed to look at Skylake for the rest.
Intel GPU drivers are at:
https://github.com/torvalds/linux
You can do searches for "drm intel 5120"
Seems Ice Lake max width may be limited to 5120 except for bigjoiner thingy which can double that (see intel_mode_valid_max_plane_size) but DSC may be required. bigjoiner is for DislplayPort output only, not HDMI. For Ice Lake, PORT_A can't do bigjoiner (see intel_dp_can_bigjoiner). I don't know what a bigjoiner or a PORT_A is.
Ice Lake max height in the Linux drivers is 4320.
Seems that Ice Lake supports DisplayPort 2.0 link rates 10 Gbps and 13.5 Gbps but not 20 Gbps (see intel_dp_set_source_rates).
WhateverGreen requires Lilu.
Lilu and WhateverGreen require MacKernelSDK.
Make whatever folder structure you like for the three projects.
Get all three projects.
Create symlink of MacKernelSDK inside Lilu.
Build Lilu.
Create symlink of MacKernelSDK and Lilu.kext inside WhateverGreen.
Build WhateverGreen.
Code:
#=========================================================================================
# Get MacKernelSDK project
mkdir -p /Volumes/Work/Programming/KextProjects/MacKernelSDK
cd /Volumes/Work/Programming/KextProjects/MacKernelSDK
git clone https://github.com/joevt/MacKernelSDK joevt-MacKernelSDK
cd /Volumes/Work/Programming/KextProjects/MacKernelSDK/joevt-MacKernelSDK
git fetch
git pull
#=========================================================================================
# Get Lilu project
mkdir -p /Volumes/Work/Programming/KextProjects/Lilu
cd /Volumes/Work/Programming/KextProjects/Lilu
git clone https://github.com/joevt/Lilu.git joevt-Lilu
cd /Volumes/Work/Programming/KextProjects/Lilu/joevt-Lilu
git remote add upstream git://github.com/acidanthera/Lilu.git
git pull upstream master
git fetch
git pull
rm MacKernelSDK
ln -s /Volumes/Work/Programming/KextProjects/MacKernelSDK/joevt-MacKernelSDK MacKernelSDK
#=========================================================================================
# Get WhateverGreen project
mkdir -p /Volumes/Work/Programming/KextProjects/Lilu
cd /Volumes/Work/Programming/KextProjects/WhateverGreen
git clone https://github.com/joevt/WhateverGreen.git joevt-WhateverGreen
cd /Volumes/Work/Programming/KextProjects/WhateverGreen/joevt-WhateverGreen
git remote add upstream git://github.com/acidanthera/WhateverGreen.git
git pull upstream master
git fetch
git pull
ln -s /Volumes/Work/Programming/KextProjects/Lilu/joevt-Lilu/DerivedData/Lilu/Build/Products/Debug/Lilu.kext Lilu.kext
rm MacKernelSDK
ln -s /Volumes/Work/Programming/KextProjects/MacKernelSDK/joevt-MacKernelSDK MacKernelSDKThanks that did the trick after some script adjustments, although I just realised my CPU/GPU is AmberLake-Y with UHD 615 which does 5120x2160 at 50hz in Windows but not in Mac OS and the CPU/GPU is not listed in your patch. Would the same patch you made be possible to work with AmberLake-Y or is this only working with the KBL/SKL graphicsdrivers?
I believe it's for Kaby Lake/Coffee Lake, not Skylake.
What Mac drivers are running on your machine? Check the first post for instructions on Information to collect.
Also, if the display has a 5120x2160 mode in the EDID, then it shouldn't need this patch. Use AllRez to get a list of display modes and to get the EDID and other display/GPU info.
Below is the information for this system. The CPU is a M3-8100Y which is having 591E0000 platform ID. But even with that it doesnt work so I removed all of so it is plain unmodded right now. I could attach Allrez and there I thinkwe have some 5120x2160 resolutions. In Windows using the same connection this computer does 5120x2160 at 50Hz. In MacOS there is no resolution visible above 4096 width. So best it can do is 4096x2160 which the screen confirms. I also took the RAW EDID but couldnt find any 5120x2160 resolution not in macos and not in windows so I guess windows uses it's drivers rather than trust the EDID. It may be the timings allow for such a high but AW EDID doesnt tell.
Code:
Last login: Mon Sep 5 20:25:58 on console
admin@MacBookMini ~ % kextstat | grep Intel | egrep "Graphics|Framebuffer"
Executing: /usr/bin/kmutil showloaded
No variant specified, falling back to release
137 0 0xffffff7f9895a000 0xc3000 0xc3000 com.apple.driver.AppleIntelKBLGraphicsFramebuffer (18.0.8) 19DB1DE9-E17D-384D-A7BB-81B211A77E80 <136 128 120 46 16 15 9 8 7 6 3 1>
142 0 0xffffff7f98859000 0xbf000 0xbf000 com.apple.driver.AppleIntelKBLGraphics (18.0.8) E39587D9-B804-3665-A7B3-29221E85CED5 <136 120 100 16 9 8 7 6 3 1>
admin@MacBookMini ~ % ioreg -lw0 | grep "AAPL,ig-platform-id"
| | | | "AAPL,ig-platform-id" = <00001659>
admin@MacBookMini ~ % ioreg -lw0 | grep '<"Mac'
| "target-type" = <"Mac">
| "compatible" = <"MacBook10,1">
| "product-name" = <"MacBook10,1">
| "model" = <"MacBook10,1">
| "board-id" = <"Mac-EE2EBD4B90B839A8">
| "fmm-computer-name" = <"MacBookMini">
admin@MacBookMini ~ % system_profiler SPHardwareDataType SPDisplaysDataType | sed '/.*Serial.*/d;/.*UUID.*/d'
Hardware:
Hardware Overview:
Model Name: MacBook
Model Identifier: MacBook10,1
Processor Name: Dual-Core Intel Core m3
Processor Speed: 1,6 GHz
Number of Processors: 1
Total Number of Cores: 2
L2 Cache (per Core): 256 KB
L3 Cache: 4 MB
Hyper-Threading Technology: Enabled
Memory: 16 GB
System Firmware Version: 451.120.7.0.0
OS Loader Version: 540.120.3~19
SMC Version (system): 2.42f13
Provisioning UDID: 538B4EA2-DBA4-5474-8D92-CEBF75A14B3E
Graphics/Displays:
Intel UHD Graphics 615:
Chipset Model: Intel UHD Graphics 615
Type: GPU
Bus: Built-In
VRAM (Dynamic, Max): 1536 MB
Vendor: Intel
Device ID: 0x591c
Revision ID: 0x0002
Metal Family: Supported, Metal GPUFamily macOS 2
Displays:
Color LCD:
Display Type: Built-In Retina LCD
Resolution: 2560 x 1600 Retina
Framebuffer Depth: 30-Bit Color (ARGB2101010)
Mirror: On
Mirror Status: Hardware Mirror
Online: Yes
Adapter Type: Unknown
Automatically Adjust Brightness: No
Connection Type: Internal
P40w-20:
Resolution: 2560 x 1080 (UW-UXGA - Ultra Wide - Ultra Extended Graphics Array)
UI Looks like: 2560 x 1080 @ 60.00Hz
Framebuffer Depth: 30-Bit Color (ARGB2101010)
Main Display: Yes
Mirror: On
Mirror Status: Master Mirror
Online: Yes
Rotation: Supported
Connection Type: Thunderbolt/DisplayPort
Television: Yes
admin@MacBookMini ~ % system_profiler SPSoftwareDataType | grep System
System Software Overview:
System Version: macOS 12.5.1 (21G83)
System Integrity Protection: Disabled
admin@MacBookMini ~ %What EDID did you look at? I've attach the decoded info (EDID_LEN_30ae_62c1_1_edid-decode.txt). Ignore #2 it is incomplete. #3 is the MacBook Pro's built-in display.
Your display has 5120x2160 modes (30, 50, 60, 75Hz) in its EDID so it should work without the Lilu/WhateverGreen patch if Apple's support included your GPU. I only have Coffee Lake to test though.
From DisplayPort 1.2, refresh rates 30, 50, 60Hz should work.
There's two 60Hz modes, the one that is 693 MHz should work, not 731 MHz.
I'll check my Mac mini 2018 with Monterey 12.5.1 to see if it still does 5120 modes.
Did you try OpenCore + Lilu + WhateverGreen? Even if it doesn't work, it can provide more info for AllRez. Let me know if you want instructions for that.
My patch still works with Monterey 12.5.1.
I noticed a message when I tried 5120x2160@60Hz 693MHz. It said:
[IGFB][INFO ] Pixel clock (693285188) is greater than max supported CD clock (675000000) on this platformI don't remember seeing that before.
I was able to do 5120x2160@58Hz 670MHz.
The 50Hz mode in the @xayide 's EDID should be ok (at least with my GPU) since it's only 586MHz. I don't know what the max supported CD clock is for his GPU. It's probably the same since it worked in Windows.
Monterey 12.5.1 now accepts 5120x2880@44Hz 673MHz but my display is black.
5120x2880@43Hz 657MHz works fine. It seems the max CD clock is slightly less than 675MHz and greater than 669MHz.
This might explain why I didn't see the CD clock message before: the max pixel clock for HBR2 at 10bpc without DSC or chroma sub sampling is only 576MHz. But now that macOS will do 8bpc, the max pixel clock is 720MHz which is greater than the max CD clock 675MHz.
Hello,
Oddly I used AW Editor to look at both 128, 256 and 384 bytes EDID. None of the modes where found. So I tried online web EDID decoder and it couldnt see them either. I should download/compile a version supporting the latest EDID version and maybe it should have been revealed....
Anyways it seems to be as you say the Amber-Lake Y is actually the same as Kaby Lake. I do use OpenCore + Lilu + WEG. And the screen is connected via USB-C, maybe that complicates things for Mac OS. Anyways what software do you use to try different resolutions? SwitchresX ?
Use edid-decode for decoding EDIDs. It follows all the specs. You can download it and compile it on macOS or Linux.
There's also an online version: https://hverkuil.home.xs4all.nl/edid-decode/edid-decode.html
At least it's using the same drivers.
Yes, SwitchResX. Use it to create custom resolutions and to view timing info of the current resolutions.
USB-C is just DisplayPort with a different connector shape.
Since we're working with a real Mac, I used OCLP 0.4.7 with the Supported Mac option (since Mac mini 2018 is not unsupported). It's mixed with OpenCore 0.8.3.
I've uploaded it to:
https://www.dropbox.com/s/9hegwnbvue4kezh/joevt custom OC 0.8.3 for Mac.zip?dl=0
You can install it to a new FAT partition instead of modifying your EFI.
The main boot file used by OCLP is at System/Library/CoreServices instead of EFI/BOOT/bootx64.efi. I believe the Startup Manager (when you hold Option key at boot) will be able to find this. You can give the partition a unique volume icon and name so you know for sure you are selecting the correct one.
In the config.plist, you'll want to make some changes to boot-args.
If you don't have FireWire or built-in serial port or a serial port PCIe card then change
debug=0x10e to debug=0x102 and maybe remove logtokprintf=2 (leave it in for the first try at least).If you don't have a built-in serial port or a serial port PCIe card then remove
serial=3 serialbaud=115200If you don't have FireWire, then remove
fwkdp=8000 fwkpf=0xf kdp_match_name=firewireFireWire means two Macs connected together with FireWire (can be built-in FireWire or FireWire from Thunderbolt dock or adapter) so that the second Mac can capture kprintf messages from the Mac with the FireWire kprintf boot-args.
Serial means the same thing except with a Serial port. The Mac with the serial kprintf boot-args needs a built-in serial port or a serial port PCIe card (can be connected by Thunderbolt). FireWire is definitely faster. Serial has the advantage of starting earlier in the boot process.
Anyway, when it's done booting, a Lilu log will be created in the /var/log folder. It will appear ≈4 minutes after boot (as specified by the liludump boot-arg). Attach a copy of the result so we can see if the patches were made correctly. Also, post another AllRez output. Also, post result of this command:
sudo dmesg | grep IGFBzip the results first.
I think the size of the dmesg buffer is affected by the msgbuf boot-arg? Try doubling that from 1MB to 2MB.
Updated my Lilu and WhateverGreen forks and tested this patch in Sonoma 14.5.
https://www.insanelymac.com/forum/t...ing-5120x1440/?do=findComment&comment=2820817
https://www.insanelymac.com/forum/t...ing-5120x1440/?do=findComment&comment=2820817