DeviceProperties update to enable 4k, remove userspace dependencies for possible Big Sur

[mgrimace]

Config.plist for testing Big Sur 4k/60 compatibility. Tested on Catalina and 4k/60 working with the DeviceProperties in this branch. Please don't merge, requires stability testing and Big Sur testing but I figured this would be the easiest way for folks to test/review.

Additions to DeviceProperties:

• Dpcd-max-link-rate - Choose a DPCD maximum link rate for your display, where 4K=0x14 (default) or 1080p=0x0a. Related to driving 4k displays over display port (something to do with the link speed to the monitor?) seems relevant
• enable-lspcon-support - to enable DisplayPort to HDMI 2.0 output on some platforms with Intel IGPU
• enable-max-pixel-clock-override - discussed previously as an alternative to problematic enable-hdmi20 userspace patch
• framebuffer-con0-alldata - values added in suggestion/discussion on reddit (I have no current understanding of what these values do).
• framebuffer-con0-enable - enables these con0 properties

Removed:

• enable-hdmi20 - userspace patch previously required for 4k

No changes to previous FrameBuffer settings (e.g., IDs, fbmem, etc.)

[mgrimace]

@fabiannagel - if you're on Big Sur and willing to test, I was able to get 4k/60 tentatively working without the problematic enable-hdmi20 reliance (i.e., broken userspace patch that's not working in Big Sur). I'm not on Big Sur yet myself but this setup is currently working for me on Catalina and might help, or not. Please use caution if you test, it's very early but it might help.

[fabiannagel]

In the meantime, I went back to my old High Sierra Backup to use my Nvidia GPU, so I currently don't have a working Big Sur setup to test this. I gave up after I couldn't even get 4K running on Catalina. So I'm generally skeptical as to how well 4K ability in Catalina w/o userspace patches will translate to Big Sur.

Is your display connected via HDMI or DisplayPort? Are scaling options working properly for you, or do they require additional work? Thanks for your heads up!

[mgrimace]

In the meantime, I went back to my old High Sierra Backup to use my Nvidia GPU, so I currently don't have a working Big Sur setup to test this. I gave up after I couldn't even get 4K running on Catalina. So I'm generally skeptical as to how well 4K ability in Catalina w/o userspace patches will translate to Big Sur.

I'm skeptical myself! Both the stable and my experimental version do technically provide 4k in Catalina, but one issue I've discovered in this experimental version that there is no output to my second monitor (likely related to the con settings (I've only addressed con0). I don't have enough knowledge/understanding yet to fix/troubleshoot the con settings and provided them 'as-is' in case other folks have suggestions/expertise to add.

Is your display connected via HDMI or DisplayPort? Are scaling options working properly for you, or do they require additional work? Thanks for your heads up!

DisplayPort. I'm on the SFF version of the OptiPlex 7020 and I have two DP out ports. I have my primary monitor (27" 4k/60) plugged into the port corresponding to con0 in my config.plist, and a secondary (1080p) monitor in the other port. re. Scaling on 4k, I run the default which I believe scales visually to 1920x1080. I haven't explored this on the experimental branch but I personally never needed other scaling options (I like the larger effective text for my eyes/vision).

I've gone back to the stable version (Zearp's version) for the time being while I read up on con settings, but work/life is kicking my butt at the moment so I haven't had too much time to follow this thread further. If anyone has any suggestions/ideas I'd be happy to try. Of note, 4k is possible on Big Sur with manual patching and works fine as-is on Catalina. My intention here is to find the optimal DeviceProperties settings to provide a long-term working solution for 4k regardless of OS version (i.e., in this case by removing the user-space dependencies, which could get fixed in time anyways).

[mgrimace]

I have removed the con0-alldata patch entirely and tidied up the deviceproperties as best I could. As it is, 4k/60 is working on my default monitor in Catalina. My second monitor, (the one that usually shows up as 'iMac'/internal) has no output (blank). I tried to resolve this by setting con0 and con1 to 'enabled' but no luck. I'm still reading about connection settings, and I think the missing piece is declaring the con settings. I'll tinker with that (I think they used to be included in an old build), and if it works I'll submit an update. Otherwise, this has been updated to remove any sketchy patching and so far just has certain key properties enabled.

[mgrimace]

I'm able to resolve 4k on one monitor (on Catalina). However, I haven't had success enabling a second monitor. I can get second monitor support/working with con-enable settings, but as soon as I do, I lose 4k on the primary monitor. I've poured through the Dortania and WEG guides but I can't quite figure out the right specific connector settings (e.g., bus, port, etc) for the two DP ports - assuming that's even the missing piece here. I've also tried the force-online boot arg, this enables the second monitor but again loses 4k.

I'll close this pull, if folks want to try 4k on single monitor feel free to test. It should be relatively stable (no janky patching required) but I can't get second monitor working on this config. If anyone with a better sense of con settings/DeviceProperties has any other ideas let me know.

Tl;DR 4k works with these device properties but we lose second monitor. Enabling second monitor loses 4k. No stable config where I can do both at this time.

[zearp]

@mgrimace The latest build of WhateverGreen has phased out the enable-hdmi20 property and replaced it with max-pixel-clock. I'm not sure if this means 4k is now working in Big Sur and I also don't know if this means that if we replace them in the current config 4k remains working on Catalina. Could you try swapping them and check if 4k still works? I don't want update to the latest builds and break 4k for those on Catalina.

[mgrimace]

Could you try swapping them and check if 4k still works? I don't want update to the latest builds and break 4k for those on Catalina.

Would you be able to put together a test branch with the newest builds of WEG, etc.? I can then trial it on my setup (Catalina, 4k, dual monitor via DP, no dGPU), swap in the max-pixel-clock property, and report back my findings. That way the only thing I'm changing are values the config in case I screw up any of other parts?

[zearp]

I confused myself a bit here, deleted my previous posts to avoid any further confusion lol.

The PR was merged a while ago, so we probably already use a version containing it but just in case I made a fresh build using all the current sources and edited the config too. It should be a matter of copying over your serials so your iCloud won't complain and replace your current EFI with the one attached.

EFI-enable-max-pixel-clock-override.zip

[mgrimace]

It should be a matter of copying over your serials so your iCloud won't complain and replace your current EFI with the one attached.

Tested, this does break 4k on Catalina. The only changes that I made to the posted EFI were adding my serials, and replacing my USB port map kext. It defaulted back to the unscaled 2560x1600 resolution which was the original pre-patch/pre-fix problem.

There should still be a way to do it. I had some partial success on previous attempts, but it is beyond my ability to problem-solve (e.g., it looked like we needed to define the connector settings and incorporate some other properties). As it is, the previous stable build works so caution to anyone with 4k moving forward to avoid WEG updates if the enable-hdmi20 property is indeed removed!

[zearp]

Maybe I didn't enable it properly, don't think I did but just in case can you give it another with -igfxmpcz added to the boot flags?

I'm not sure if the property will be removed or just depreciated. Removing it could break 4k for many people who rely on it in Catalina and earlier.

I did map the connectors out in the beginning, at the time without them I got kernel panics but that was due to bugs. It's relatively easy to map them in Hackintool but I don't really know if it would do anything regarding 4k.

My main monitor has been glitching out lately so I might jump on the 4k train. Could use the extra real estate and chip in with getting 4k working properly on old and new macOS with the same patches.

[mgrimace]

Maybe I didn't enable it properly, don't think I did but just in case can you give it another with -igfxmpcz added to the boot flags?

Tried, still broken/capped at 2560x1600. I saw on a reddit post that another 9020 user had their Device properties set with:

• framebuffer-stolenmem = 00003001
• framebuffer-fbmem = 00009000

I tried those values just as a 'why not' and the resolution dropped to 1080p, but it made me wonder then if the current stolenmem/fbmem values are capping the resolution rather than a particular property? If we could safely increase those values (to a proper value/ratio) we might be able to bump up the resolution to 4k manually that route (rather than piling on other properties)? I don't know what those values could/should be, but I do know that there's some rules here that I don't quite understand for how to set these: https://github.com/acidanthera/WhateverGreen/blob/master/Manual/FAQ.IntelHD.en.md

My rational for connectors was that I was able to get 4k working by piling on a few other properties (above) but that somehow disabled my second monitor output. This led me to attempt to define the connectors properly (and I had read other's had success by doing this with HD4600 on other hardware) but I never made any progress there.

So possible targets - revisit fbmem/stolenmem values?

[zearp]

The connectors when I mapped them out are still in some old commits not 100% sure if I did that correctly but at the time it did fix the panics after waking ups that were caused by a bug somewhere else.

Those fbmem/stolenmem entries are only needed when you're unable to change the DVMT pre-allocation, but we can change that. I do think the hdmi20 option isn't going away until something can fully replace what it did. Specially for those opting to stay on Catalina for now. Can't image how many people rely on that feature to work.

It wouldn't be the end of the world if newer build did actually remove it though. It's not like WEG isn't stable on Catalina and earlier so we can just use whatever last version still had the feature. There's really no need to upgrade anything EFI related once everything works. The current EFI could be used and just left there until Catalina gets no more security updates. The chance a Cataline upgrade at this point breaks things is so small.

I do like to keep track of the latest stuff though, but it's not always worth it to run the bleeding edge or spend too much time keeping track of everything. Specially if you just want to run a stable macOS and not tinker all the time its more than enough to check once every 1-2 months for any big changes or things you want to add to your config. It's where this repo will head towards too, not many major changes in any components for a while. A few new config entries that we didn't need, I added them but left them all disabled haha.

[mgrimace]

The connectors when I mapped them out are still in some old commits not 100% sure if I did that correctly but at the time it did fix the panics after waking ups that were caused by a bug somewhere else.

I tried those (found the old commit) in some of my testing but ran into some road blocks and eventually abandoned that line of investigation (I'm not certain connectors were the barrier, but I figured it wouldn't hurt to try and map those out).

Those fbmem/stolenmem entries are only needed when you're unable to change the DVMT pre-allocation, but we can change that. I do think the hdmi20 option isn't going away until something can fully replace what it did. Specially for those opting to stay on Catalina for now. Can't image how many people rely on that feature to work.

Re. fbmem/stolenmem, the weird part was the original solution to get 4k working was to define those values even though it shouldn't be necessary since we set DVMT manually in the bios. We basically just used the values found in the janky 4k "patch" - I'm wondering now if perhaps these could be "upped" in some regard. I don't know to what values, or how to code those values properly, but I'm happy to test if you have suggestions!.

It wouldn't be the end of the world if newer build did actually remove it though. It's not like WEG isn't stable on Catalina and earlier so we can just use whatever last version still had the feature. There's really no need to upgrade anything EFI related once everything works

So true, we have achieved some very nice stability here! My drive here is that I do believe 4k without enable-hdmi20 is solvable (without manual patching) with the right values/properties. I'll keep tinkering away at it, and if you do pick up a 4k monitor and/or have any suggestions I'm happy to test!

[zearp]

From what I understand WEG only uses those things for the DVMT stuff. They mention it in their fav and link to a Russian forum post, Google can sort of translate it toi give you an idea whats its about.

Here is the forum link: https://www.applelife.ru/threads/intel-hd-graphics-3000-4000-4400-4600-5000-5500-5600-520-530-630.1289648/page-169#post-750369

The post suggests that it is really only used to slim down the framebuffer on machines that can't have the size expanded. Maybe it has side effects but I wouldn't mess with it as (like the post mentions) it can lead to the graphics driver wanting to write to a space that doesn't really exist which can lead to glitches or crashes.

I've asked if the hdmi20 option will remain, I might have misunderstood it completely and the pixel clock settings are not meant to replace hdmi20 but simply be something used on newer macOS and hdmi20 will remain in there for anything before Big Sur.

I wonder if you make a new map how it compares to the one I did. It's been so long ago and I'm not 100% sure I mapped all the ports properly and disabled any unused frame buffers ports. Disabling those is not required but good to do when you can. I'll have to revisit the OSXLatitude forum thread on Haswell patching to brush up on its done manually. The forum seems down at the moment.

I do think we can disable one, when I check on this 7020 it shows 3 but it should really show just 2. One for each DP port.

zearp@localhost ~ % ioreg -l | grep "class AppleIntelFramebuffer"
    | |   | +-o AppleIntelFramebuffer@0  <class AppleIntelFramebuffer, id 0x1000003c4, registered, matched, active, busy 0 (605 ms), retain 20>
    | |   | +-o AppleIntelFramebuffer@1  <class AppleIntelFramebuffer, id 0x1000003c5, registered, matched, active, busy 0 (593 ms), retain 22>
    | |   | +-o AppleIntelFramebuffer@2  <class AppleIntelFramebuffer, id 0x1000003c6, registered, matched, active, busy 0 (548 ms), retain 19>

I don't think any of that will have influence on 4k stuff, as it works fine without disabling unused frame buffer ports but it can't harm to dot the i's here and do it all by the book and set up the connectors and ports properly.

[zearp]

Oh, I just got a notification that vit9696 replied to my question and he said we might need to up the frequency by adding max-pixel-clock-frequency to the frame buffer config, it defaults to 675000000 (675mhz).

You can try adding that field to the config and increase the default frequency bit by bit until it hopefully works. I'd try small increments cuz I dunno if setting this very high can cause issues. I'm not sure how much more speed is needed. Might need 700mhz or 680mhz or something else, there's only one way to find out.

I assume the type needs to be a string and not data or something else.

He also linked to the HDMI in UHD resolution with 60FPS part of the WEG FAQ which has a little more info on how it works.

If you can try out some frequency values that would be awesome. I wonder how many reboots it takes to find the magic number that makes 4k work again with the new parameter lol. Good luck and thanks for helping out!

[mgrimace]

If you can try out some frequency values that would be awesome. I wonder how many reboots it takes to find the magic number that makes 4k work again with the new parameter lol. Good luck and thanks for helping out!

Thanks for looking into this! Ok, I tried 675 (specified manually, just in case) - I copied your code above and used string as the type. Specifically, max-pixel-clock-frequency and the string value 675000000 (note: 6 zeroes). I incremented up to 775 (i.e., 775000000, skipping a few here and there) with no visible change.

I then jumped to 875000000 to try and see if there was an upper bound that would work, but on the verbose login it said "max-pixel-clock-frequency ... (something here I forget)... unexpected format". I didn't notice this with the previous values. Double checked there was no typo, same error

I'm not sure if there's an upper limit to this, or my syntax was wrong, or what. I did a quick search and couldn't find any clear documentation on how to manually specify the value (e.g., if it should be data, string, number).

[zearp]

The documentation is still sparse, from reading the PR the Dortania guide writers got pinged but maybe they need to do their own testing before publishing new parts of guide covering and explaining this for mere mortals like us haha.

The PR code itself for getting the custom frequency looks like this;

IOKit::getOSDataValue<uint32_t>(info->videoBuiltin, "max-pixel-clock-frequency", maxPixelClockFrequency);

It may need be a number not a string but I'm just thinking out loud.

[mgrimace]

The documentation is still sparse, from reading the PR the Dortania guide writers got pinged but maybe they need to do their own testing before publishing new parts of guide covering and explaining this for mere mortals like us haha.

Ha agreed! Are there any guidelines for syntax with straight numbers? I somewhat arbitrarily tried 675, 800 and no change (i.e., no 4k). I'm not sure what to do next to move this testing forward, if you have any ideas/direction I'm happy to keep trying though!

[zearp]

It's supposed to be put in hertz, so the full long number. I think there's a max which would probably trigger the error message you saw earlier. I have no idea how you can verify the current clock freq. Without that we don't know for sure if the new clock freq was applied.

My guess it would show in the logs, might need a debug version and some boot flags or gfx-tool that comes with WEG can read some stuff too but I've only used that a very long time ago so not sure if it can read those clocks. It should log it )plus a lot more) when using debug versions and required boot flags hopefully.

[mgrimace]

It's supposed to be put in hertz, so the full long number. I think there's a max which would probably trigger the error message you saw earlier. I have no idea how you can verify the current clock freq. Without that we don't know for sure if the new clock freq was applied.

I tried number 675000000 and 775000000, no 4k.

I also tried the properties/boot args found on this project: https://github.com/varszegimarcell/Optiplex-3020-Hackintosh-OpenCore/tree/main/EFI/OC. It's from an Optiplex 3020 but they appeared to have swapped in a processor with HD4600 rather than the HD4400. The DeviceProperties were the same as ours previously, with enable-hdmi20 and framebuffer-unifiedmem removed, and the following boot-args were added (and tested): -igfxmpc -igfxcdc -igfxdvmt. No 4k.

I also tested/re-tested some other properties:

• enable-dpcd-max-link-rate-fix (enabled)
• dpcd-max-link-rate (data, 14000000) - why? "Choose a DPCD maximum link rate for your display, where 4K=0x14 (default) or 1080p=0x0a." Related to driving 4k displays over display port.
• enable-lspcon-support (enabled) - why? "to enable DisplayPort to HDMI 2.0 output on some platforms with Intel IGPU". I thought this might also replicate some of the enable-hdmi20 functionality, but mostly just guessing at this point.

No 4k with these properties added either unfortunately.

[zearp]

Thanks for testing!

Unifiedmem just forces 2gb vram, the OpenCore docs say best to not use it but I seem to recall 4k worked better with it. By default it will allocate 1.5gb vram. I'm not sure if macOS scales it up but Window does. Not sure if any hard limit exist. The option can be safely removed on my 1080p installs.

I'm about to buy this portable 4k (3840x2160) screen, not sure if I will run it unscaled all the time but I sure wanna be able to run in native 4k even if things look smaller they should be very sharp with such a high ppi. It was pretty hard to find one that can run in single cable mode but according to reviews this one can.

I've also seen "4k" screens advertised that do 3200x1800 max, I have no idea if those will work if we get proper 4k working. The prices are the same so I'm getting proper 4k. Hopefully it arrives soon and without any pixel defects... my biggest fear lol. Luckily Amazon has a good return policy.

[mgrimace]

I'm about to buy this portable 4k (3840x2160) screen, not sure if I will run it unscaled all the time but I sure wanna be able to run in native 4k even if things look smaller they should be very sharp with such a high ppi. It was pretty hard to find one that can run in single cable mode but according to reviews this one can.

That's exciting! Enjoy it and well-deserved. I personally need the 4k for on-screen text (reading/writing), it makes a huge difference for me in terms of clarity.

I've also seen "4k" screens advertised that do 3200x1800 max, I have no idea if those will work if we get proper 4k working. The prices are the same so I'm getting proper 4k. Hopefully it arrives soon and without any pixel defects... my biggest fear lol. Luckily Amazon has a good return policy.

It makes sense to get "true" 4k, I imagine non-standard resolutions would be a headache. I think part of the problem here is my limited understanding of what I'm doing (e.g., mostly copy-paste) and I'm hopeful that if/when you get a 4k we'll be able to resolve 4k in a way that is stable for both Catalina and Big Sur.

[zearp]

I'm hoping to see some improvements in that area too. Even scaled down to 1440p or 1080p a 4k display should produce a better more crisp image due the high ppi.

I saw your other post where you tagged me, I don't recall reading about the need to change the other dvmt setting, but its been a while and sure can't hurt to try it out.

0x4F3F1         One Of: DVMT Total Gfx Mem, VarStoreInfo (VarOffset/VarName): 0x264, VarStore: 0x2, QuestionId: 0x219, Size: 1, Min: 0x0, Max 0x0, Step: 0x0 {05 A6 4F 04 50 04 19 02 02 00 64 02 10 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00}
0x4F417             One Of Option: 128M, Value (8 bit): 0x1 {09 0E 51 04 00 00 01 00 00 00 00 00 00 00}
0x4F425             One Of Option: 256M, Value (8 bit): 0x2 {09 0E 52 04 00 00 02 00 00 00 00 00 00 00}
0x4F433             One Of Option: MAX, Value (8 bit): 0x3 (default) {09 0E 53 04 30 00 03 00 00 00 00 00 00 00}
0x4F441         End One Of {29 02}

Also noticed low power mode being enabled by default, disabling that on a desktop should be fine but I have no clue if it would contribute anything.

0x4F443         One Of: Gfx Low Power Mode, VarStoreInfo (VarOffset/VarName): 0x209, VarStore: 0x2, QuestionId: 0x21A, Size: 1, Min: 0x0, Max 0x0, Step: 0x0 {05 A6 AB 04 AC 04 1A 02 02 00 09 02 10 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00}
0x4F469             One Of Option: Enabled, Value (8 bit): 0x1 (default) {09 0E C2 03 30 00 01 00 00 00 00 00 00 00}
0x4F477             One Of Option: Disabled, Value (8 bit): 0x0 {09 0E C3 03 00 00 00 00 00 00 00 00 00 00}
0x4F485         End One Of {29 02}

I'll run some basic benchmarks and change them both and then run them again.

[zearp]

Ah, that was silly. Ours is already set to MAX by default, it was right there in the IFR but I didn't notice and still booted into the modified grub shell and when I verified the current setting noticed it was on. I did disable low power mode though. Same results in the benchmarks with or without low power enabled. It might not do anything at all.

[zearp]

Quick update, receive screen but haven't gotten far yet. I stumbled on a different issue where hot plugging my cable from the top in to the bottom (nearest to ps/2 ports) dp port results in a freeze. Not even a panic a full freeze. I tried some connector configs and also without them and also tried applying enable-hdmi-dividers-fix to no avail. I'd like to be able to swap the dp cable from one to another without a freeze. Re-plugging the cable in the top port only works fine.

All that was without even connecting the 4k screen, when I connect the 4k screen stand-alone I make it till it loads the guy then I get a black screen, there is still signal no power saving is triggered. This also happens with different configurations. Very odd, the screen works fine on my NUCs either via usb-c or hdmi.

I'm trying to sort out the hot plugging first so I know there won't be a freeze when I connect the 4k screen as 2nd screen. I'm not sure if its even possible. DisplayPort can be fussy with hotplug but I think I had this working before with the connectors setup properly. But somehow it doesn't work anymore. I tried the old map too.

I'm still on Catalina btw, but I also added the frequency options, also didn't make any difference. I can't get macOS to work with my 4k screen at all. I'll try Windows later just as sanity check lol. If these things work in Widows then we should be able to make it work in macOS. Maybe this screen is not working properly on this Dell. I'll update more later.

[zearp]

I did notice some Lilu/WEG messages in the logs about not being able to execute certain commands when using all these options. Not everything works I guess. As for lspcon, we don't have that on these Dells. It requires an additional chip to do the conversion to hdmi 2.0.

My NUCs have it and you need add at least two entries in the config to enable it, one to enable it in general and an entry for each connector you want to enable it on. For the NUC only the hdmi port needs it enabled. The usb-c port uses DisplayPort-alternate or something like that.

[zearp]

Got another notification from the thread you tagged me in. I don't think he does anything special to make 4k work. It might just work on his machine but it sure has nothing to do with the config. I had similar experience on my NUCs where the 4k screen "just works". Be it using usb-c or hdmi.

He is using double DVMT patches btw, one with stolenmem and one by enabling Ice Lake patches on a Haswell platform. All the while doing that on Dell that can have the DVMT sizes changed via a UEFI shell so none of those patches would be needed. I doubt the Ice Lake patches do anything at all. We have Haswell not Ice Lake. The other properties he posted we've already tried and didn't do anything helpful as far as I recall.

I'll give the 4k screen another try today but I think it doesn't like me converting DisplayPort to hdmi. I might return it and swap it out for one that has mini DisplayPort, usb-c and normal hdmi instead. There's some other issues with the screen that make me want to return it. On my NUCs I didn't need any special setting for 4k to work, even had some HiDPI entries in system preferences.

How annoying would it be if your screen is the issue and not the config? I hope to be able to answer that question if I can get my 4k screen to work properly with a converted DisplayPort signal. I might need to enable some DisplayPort -> hdmi patches. But I'll get to that when I get to it haha.

What I don't understand is that hot plugging something in the 2nd DisplayPort causes a freeze. Not a panic but a freeze. Thats pretty weird to me and none of the fixes for freezes are working. I don't know if this could even be fixed. If I connect a screen at boot time to the 2nd port it works fine.

Just ran some hotplug tests, where DP1 is port on top and DP2 port at bottom (near ps2/) when standing on its side.

Booting with my screen connect to DP1:

• Re-plugging in same port works fine
• Swapping to DP2 causes freeze

Booting with my screen connected to DP2:

• Re-plugging in same causes freeze
• Swapping to DP1 works fine

It appears DP2 can't hotplug. This is without any connectors setup and yesterday even with connectors setup I got same results. I tried a few connector setups, they all acted the same. I'm not even sure if it does anything at all lol. The connectors should be setup a DisplayPort if anything and we only have 2. I've attached Hackintool connecters page for both DP1 and DP2 just in case it comes in handy later.

Another thing I noticed, when I use DP1 I get audio over DisplayPort but when using DP2 there's no audio over DisplayPort.

So I guess for my 4k testing I need to connect my main screen to DP2 so I can test on DP1 without having to ponder if it crashed due to the screen or due to the hotplug event.

Did you get similar results on yours?

Without the connectors setup they show up as hdmi, with connectors added to the config and set too DisplayPort they show up as such but the behaviour is the same. It might be purely cosmetic or I don't notice it because I use a DisplayPort to hdmi cable to connect to my Samsung screen (which I been using since the start of this project). I do have an old screen with DisplayPort, I can try that too but personally don't think that would do much other than give a little bit more information.

[zearp]

Ok, this might become a micro blog, but as expected with the 4k screen on DP1 and my Samsung on DP2 both work but no audio on my Samsung.

The 4k screen has 1600x900 as max resolution but this is with a pretty simple frame buffer config. I'll try and get 4k to work in this setup and see how it goes. For the moment I'll accept that DP2 can't deal with hotplug events and save that one for later.

I do have hdmi20 enabled but it doesn't do anything. I'm also still in Catalina.

Big Sur rant: I have changed the SMBIOS on my Dells so they stop nagging me to upgrade. I don't want Big Sur as my main OS mainly due to the design elements being huge and things like asking permission for notifications now requires two clicks to deny the app. I know I'm weird but those things annoy me greatly from UX perspective. Why change an action that took 1 click in Catalina to an action that requires two click in Big Sur? Makes no sense although it is a small issue. All the small Big Sur issues add up to an OS I rather not use.

I will now try some patches and see what does what. I'll be back in a couple or a dozen of reboots haha.

[zearp]

Just made yet another new connectors map, somehow my Samsung screen doesn't work at all now. Re-plugging it causes a panic instead of freeze so I guess that progress but I don't get why the Samsung screen remains off. I'll have to experiment with the connecters and see if I can enable both DP ports and disable the 3rd frame buffer for good measure.

panic(cpu 0 caller 0xffffff8014645a1a): Kernel trap at 0xffffff7f985b2a0c, type 14=page fault, registers:
CR0: 0x000000008001003b, CR2: 0x0000000000004030, CR3: 0x000000001e316000, CR4: 0x00000000001626e0
RAX: 0xc6dc4b96ab8600f0, RBX: 0x0000000000000000, RCX: 0xffffff8015023454, RDX: 0x0000000100000000
RSP: 0xffffff8204f53e70, RBP: 0xffffff8204f53ea0, RSI: 0xffffff8204f53c7e, RDI: 0xffffff81d63b4000
R8:  0x0000000000000000, R9:  0x0000000000000000, R10: 0x0000020000011000, R11: 0x000000000030000c
R12: 0x0000000000000000, R13: 0x0000000000000000, R14: 0x0000000000000003, R15: 0xffffff803cf58000
RFL: 0x0000000000010202, RIP: 0xffffff7f985b2a0c, CS:  0x0000000000000008, SS:  0x0000000000000010
Fault CR2: 0x0000000000004030, Error code: 0x0000000000000000, Fault CPU: 0x0, PL: 0, VF: 1

Backtrace (CPU 0), Frame : Return Address
0xffffff8204f538d0 : 0xffffff801451963d 
0xffffff8204f53920 : 0xffffff8014653ae5 
0xffffff8204f53960 : 0xffffff801464566e 
0xffffff8204f539b0 : 0xffffff80144bfa40 
0xffffff8204f539d0 : 0xffffff8014518d07 
0xffffff8204f53ad0 : 0xffffff80145190f7 
0xffffff8204f53b20 : 0xffffff8014cc01cc 
0xffffff8204f53b90 : 0xffffff8014645a1a 
0xffffff8204f53d10 : 0xffffff8014645718 
0xffffff8204f53d60 : 0xffffff80144bfa40 
0xffffff8204f53d80 : 0xffffff7f985b2a0c 
0xffffff8204f53ea0 : 0xffffff7f985a53a9 
0xffffff8204f53ee0 : 0xffffff8014c2bc5d 
0xffffff8204f53f30 : 0xffffff8014c2a52e 
0xffffff8204f53f70 : 0xffffff8014c29b26 
0xffffff8204f53fa0 : 0xffffff80144bf13e 
      Kernel Extensions in backtrace:
         com.apple.driver.AppleIntelFramebufferAzul(14.0.7)[5C601677-46CE-3441-8224-8628D1DA3ECA]@0xffffff7f98582000->0xffffff7f986e8fff
            dependency: com.apple.iokit.IOPCIFamily(2.9)[017B6656-0279-38F7-917D-97CB6A21AC33]@0xffffff7f94f12000
            dependency: com.apple.iokit.IOACPIFamily(1.4)[651110C7-82F0-3264-88EC-E16ED04032B8]@0xffffff7f94f09000
            dependency: com.apple.iokit.IOAcceleratorFamily2(438.7.4)[7505C559-03C6-3BE9-A7C2-00CCE2353C38]@0xffffff7f984b4000
            dependency: com.apple.iokit.IOReportFamily(47)[59CB26A7-FF64-3102-A964-24CA0986D77F]@0xffffff7f94e49000
            dependency: com.apple.AppleGraphicsDeviceControl(5.2.7)[1D8FF45D-0447-391E-9E3E-DD926F8D981E]@0xffffff7f98578000
            dependency: com.apple.iokit.IOGraphicsFamily(576.1)[88D3A235-5CA8-39D6-977F-3BE4ABFDAEC8]@0xffffff7f98463000

BSD process name corresponding to current thread: kernel_task
Boot args: -v chunklist-security-epoch=0 -chunklist-no-rev2-dev

Mac OS version:
19H524

Kernel version:
Darwin Kernel Version 19.6.0: Tue Jan 12 22:13:05 PST 2021; root:xnu-6153.141.16~1/RELEASE_X86_64
Kernel UUID: 64F23D6D-4C30-3FC4-B7C2-9EE0BBA0D29A
Kernel slide:     0x0000000014200000
Kernel text base: 0xffffff8014400000
__HIB  text base: 0xffffff8014300000
System model name: iMac14,3 (Mac-77EB7D7DAF985301)
System shutdown begun: NO
Panic diags file available: YES (0x0)

System uptime in nanoseconds: 77200815610

I might also try applying patches directly to the kext if this leads nowhere. With the direct patches I can be 100% sure they're applied. For testing this should be fine and in the worst case we end up with 2 kext patches. Easy to add both to the config and then the user can enable/disable as needed. But ideally we get this to work using WEG properties.

I might also try changing the SMBIOS just to see if the newer model behaves differently. Don;t think that matters though. I'll also boot up my Windows to go so I can sanity check if this can work at all.

[zearp]

Resumed messing about with this after having dinner, trying stand alone now. With the default config pretty much all resolution result in a black display but I can use VNC to connect just fine. I've not tried all but it seems the only resolution that works from the list is 1080p. Even 1920x1080 didn't work despite 1080p is the same resolution. I'm faintly hearing the Twilight Zone theme playing.

I like the low resolution notice.

[zearp]

Even at 30hz nothing except 1080p is working. Also tried some of the new WEG properties. Time to check in Windows!

[mgrimace]

Ha! It seems you've fallen down the same rabbit hole! I think it's because it seems like it should be possible and that it's just a matter of finding the right settings, but who knows!

Did you get similar results on yours?

Strange, no, something seems off on mine (index is showing -1 for my secondary display). I don't know how to read Hackintool and posted screenshots below. For context, I'm using the latest stable EFI release, with no modifications (only serials + USB map kext), on Catalina.

My hardware:

• DP 1 (topmost DP port): HP Envy (27" 4k), shows as HP Envy 27 in Displays. I typically select "default for display" resolution, which appears to be the same scaling "looks like" 1980x1020p if I pick scaled.

• DP 2 (second DP port down, closer to VGA): HP E222 (24" 1080p, vertical orientation), shows as iMac in Displays

Here's the Hackintool screenshots, note that DP2 index -1, and shows "HP Envy" in description for some reason. Different options appear checked as well.

• Displays with correct hardware listed

• DP1 (HP Envy 27)

• DP2 (HP E2222, showing up weird)

I had similar experience on my NUCs where the 4k screen "just works". Be it using usb-c or hdmi.

That definitely seems to be the case, unfortunately was hoping for a fresh lead there but doesn't look like much different than what we're doing (except the redundancies in DVMT).

What I don't understand is that hot plugging something in the 2nd DisplayPort causes a freeze.

Would that make sense if DP2 is the port that's recognized as an internal display? My display in DP2 (physically the lowest port) shows as "iMac". In some of my earlier tests when I was able to get 4k on DP1 but no output on DP2, turning the DP2 monitor off/on would hard-crash (reboot) the system. This seems consistent to both of us.

So I guess for my 4k testing I need to connect my main screen to DP2 so I can test on DP1 without having to ponder if it crashed due to the screen or due to the hotplug event.

That makes sense, my 4k is in DP1. I've been able to turn the screen off/on with no difficulties. When 4k doesn't work, the screen still displays, but shows as an unscaled 2600xsomething resolution.

Ok, this might become a micro blog, but as expected with the 4k screen on DP1 and my Samsung on DP2 both work but no audio on my Samsung.

Ha! My 4k has no audio or even an audio jack, unfortunately I can't test or help here.

The 4k screen has 1600x900 as max resolution but this is with a pretty simple frame buffer config. I'll try and get 4k to work in this setup and see how it goes. For the moment I'll accept that DP2 can't deal with hotplug events and save that one for later.

Strange it doesn't work out-of-the-box with the default EFI/config, I'd assume something to do with the HDMI v. DP (?)

Big Sur rant

Generally agreed! I updated my laptop (actual MacBook) and there's a few things I like (DNS profiles for ad-blocking are a great alternative to Pi-Hole, which is a totally separate topic). But yes, overall it appears that design aesthetic is taking priority over function (towards the mobile design language that doesn't make sense on larger screen in non-touch environment). My testing is motivated because I feel like it should be possible (and I'm slowly learning a lot), rather than any particular drive to get to Big Sur.

With the default config pretty much all resolution result in a black display but I can use VNC to connect just fine. I've not tried all but it seems the only resolution that works from the list is 1080p. Even 1920x1080 didn't work despite 1080p is the same resolution. I'm faintly hearing the Twilight Zone theme playing.

That's bizarre, on the default config I never experience black screens, when 4k doesn't work it just outputs lower. The only time I had black screen was when I was messing around with connectors (which I didn't fully understand, but I pulled from the Dortania guide for that rather than doing anything with Hackintool, and this whole area is still very confusing to me).

Even at 30hz nothing except 1080p is working

Probably worth mentioning that "working" in my case is 4k/60hz, and AMD freesync "on" appears on screen after reboot.

So strange though, if there's any ways I can help test let me know! I appreciate your work in this, my fear was that I was missing something obvious but it looks like that's not the case.

[mgrimace]

Also, it does look like there's something off/wrong on my monitor in DP2 from the above screenshots. I don't know if this is contributing to my lack of success. Practically speaking, both monitors are displaying as expected at the moment, but it does look like somethings off on my end.

[zearp]

After doing a bunch of more testing I think there are few thing to note.

• Dell specs say the maximum DP output is 3840x2160 @ 60hz
• Dell specs say the maximum hdmi output is 2560x1600 @ 60hz or 4069x2302 @ 24hz

I think the DP max only applies on DP -> DP connections, hdmi limits apply when the signal is converted.

I was able to run my 4k screen at 4069x2302 @ 30hz using a DP -> hdmi cable.

I was unable to get 2560x1600 @ 60hz to work despite the Dell spec saying it should be supported.

I'm unable to test DP -> DP as my 4k screen lacks DisplayPort connections.

Going by dates and specs it appears our Dells have DisplayPort version 1.2 cuz 1.3 was approved after the 7020 came to market and the v1.1a spec can't do 4k. This also means our ports support MST but macOS doesn't support that so trying options there is pretty pointless.

https://www.displayport.org/pr/vesa-introduces-displayport-v1-2-the-most-comprehensive-and-innovative-display-interface-available/

https://vesa.org/uncategorized/vesa-releases-displayport-1-3-standard/

Side note: I think it's funny a screen sold to me as 3840x2160 max happily ran 4069x2302 @ 30hz. I tried to test on another machine if the screen can do that @ 60hz but in both macOS and Windows there was no option to even select 4069x2302. On much newer machines, no clue why on the Dell that same resolution worked, albeit flickery.

[zearp]

@mgrimace just got your replies as I refreshed the page after submitting my reply haha. Will respond to them in more detail a bit, just a quick question were you able to actually get 4k @ 60hz to work in Windows? And was that using DP -> DP or DP -> hdmi?

[mgrimace]

@mgrimace just got your replies as I refreshed the page after submitting my reply haha. Will respond to them in more detail a bit, just a quick question were you able to actually get 4k @ 60hz to work in Windows? And was that using DP -> DP or DP -> hdmi?

Ha yes, I was just looking at all this now! Both monitors are connected DP>DP, no HDMI. Other relevant hardware, I'm on a Dell 7020 sff, no dGPU.

I have not tested 4k in Windows on this machine, I don't have it set up to dual boot (and don't really know how). Got the machine refurbished and Windows came on an old platter HDD. Before swapping in the SSD for my Hackintosh I just used my old 1080p monitor (DP->DP) for initial setup/BIOS update. Then, pulled the HDD and did everything from scratch on the new SSD. No other hardware modifications made.

[zearp]

Cool, so on paper your should be able to get 4k output using DP -> DP in macOS. Both the DisplayPort and Dell spec conform that, to try in Windows you can d/l a trial iso for free and use free tools like Rufus to make a Windows to go disk or stick (stick has to be fast). The 7020s all have Win7 Pro licenses which also work in Widows 10 so it might even activate itself hah. That is if you wanna test it in Windows as sanity check to see it working at 4k @ 60hz.

As far a it goes for me, I have no idea if I'm being limited by hdmi conversion or not. This box has no hdmi ports and resolution specs for models with dGPU are listed separate from iGPU specs (see image from the tech guide). So I assume the hdmi limits listed apply when using conversion. My only option is to return this one and get something with DisplayPort. I was planning on returning this one anyways as it has some annoyances and it gets stuck in power saving mode from time to time.

The 7020 SFF is the best. The previous 7010 comes in an even smaller package, (usff) slightly larger but not as tall as a NUC they make great Hackintosh too but harder to find and more expensivenot worth it compared to 7020 unless you want a box small enough to mount behind the screen. But then I would suggest to buy a brand new NUC. For some reason refurb usff boxes are priced much higher.

I also agree that it should work, it's a matter of the right settings. Especially if it works fine in Windows. Those connectors do have some influence on things but I'm not certain they stand in the way of getting 4k to work. Not when running the 4k screen as only screen for sure. It will figure out those connectors at boot time, most likely doing that now too. Which would explain why Hackintool displays them as it does.

With the connector settings you can change which screen is detected as internal by setting the bus id to 0x0 (I could be wrong but I think thats what 0x0 does). I'll read that Dortania page. I want to setup the connectors properly and get rid of the extra frame buffer anyways. Always wanted to sort that out properly. Everything should work without connectors in a single monitor setup and might only be needed for certain dual screen setups.

The road to 4k is long and winded, let's hope it's not a dead end lol.

[mgrimace]

Cool, so on paper your should be able to get 4k output using DP -> DP in macOS

Absolutely, and I should clarify that I am getting 4k/60 on our current EFI/config in Catalina successfully.

The 1980x1080p scaling thing I referred to above (and in my screenshot) I believe is called HiDPi, to make everything appear larger (e.g., text etc) without sacrificing clarify/resolution. If I select "scaled" instead of "default for display" and 4k is working, I have 4 boxes that let me choose between larger text and more space. There are no "resolutions" to choose from. Regardless of scaling options selected, my monitor is outputting 3840x2160 60hz via DP.

If 4k is not working, then selecting "scaled" instead just presents a list of resolutions as in your screenshots, maxing out at 2600x1400 on this monitor (fuzzy/grainy and small text, no scaling).

With 4k working, if I select the right-most "more space" option it will present in unscaled 4k, but that makes everything too tiny for me to read. When I plug the same 4k monitor into my actual-macbook (via the USB-C port) the "default for display" appears at the same size and scale (i.e., looks like 1080p in size but higher resolution/clarity).

However, on my actual-macbook I have more higher resolution scaling options available (and I do believe this was another subtle problem identified previously by another user; our Hackintosh setup should offer the same higher levels of scaling but it doesn't for some unknown reason).

If this all seems counter-intuitive, 4k makes the text crisper crisper to read, larger interface items, etc., even when scaled to 1080p "sizes".

The road to 4k is long and winded, let's hope it's not a dead end lol.

Definitely not dead! 4k with scaling does work on Catalina. It all seems to hinge on enable-hdmi20 which should be replicable.

With the connector settings you can change which screen is detected as internal by setting the bus id to 0x0 (I could be wrong but I think thats what 0x0 does). I'll read that Dortania page. I want to setup the connectors properly and get rid of the extra frame buffer anyways. Always wanted to sort that out properly. Everything should work without connectors in a single monitor setup and might only be needed for certain dual screen setups.

For my daily usage the "internal" designation doesn't really affect anything (I don't hot-plug the monitor and I can turn it off/on without freezing/crashing).

Do you have any idea why what should be DP2 is showing as index -1 on mine? If I understand that correctly only my con0 (index 1) and con1 (index 2) are enabled. How am I even getting anything on DP2 (assuming it's con2, it should show up as index 3 like yours??). Even stranger, I only have one red highlight, index2 but both monitors are currently on, connected to DP1 and DP2, and working!

Bizarre!

[mgrimace]

I should add when my 27" 4k is connected via DP to DP2 ("internal") it shows up in "displays" as iMac Retina rather than as HP Envy. From what I can tell if a display is successfully realized as "retina" then it presents with scaling vs resolutions.

[zearp]

Thank you for clarifying!

Then everything seems to work as it should, or not work to depending on how you look at it.

I'm then also sure my issue is the conversion, it matches up nicely with my testing. So in order to get 4k to work on Catalina we can conclude it requires DP -> DP unless for you it also works with the hdmi input. If that doesn't work too it confirms my tests.

I'm surprised you have free sync working, I've seen people claim macOS doesn't support it. I don't know what benefits free sync will give if not playing games but maybe I misunderstand what it does.

I don't have any Dells with Big Sur but thats an easier fix than finding one of these portable screens with DisplayPort and hdmi and usb-c, cuz I do those for other machines. My guess if when I find one and connect it up using DP -> DP it will work like yours on 4k @ 60hz. I now recall knowing the crux of the issue but somehow it escaped me. It's coming back now. User space patching is broken on Big Sur, hdmi20 doesn't work there and the new frequency settings did't do anything for you. Thats correct right?

I didn't get options like you did when running stand-alone most likely due to conversion. I just got the list under scaled, which does the same like you said. It also does that on the NUC. OSD confirms its runs at 4k but workable screen can be set to 1440p or 1080p or whatever.

Those indexes are prolly not important, to set them you edit them in Hackintool, a 'long click' is needed to edit most field, pressing enter works for the indexes. If its set to -1 and you generate a config it will add connectors and null out the ones set to -1 which will result in them not working. Which is what its supposed to do for -1. Setting them both to 1 should be the correct setting, 1 = DisplayPort. Bus id's always remains 0x04 and 0x06 for the DP ports. Pipe count seems to be for ordering them, it doesn't seem to matter much in my testing. You can enable a hotplug reboot fix that will create a framebuffer-con0-alldata entry that sets up all the connectors and also sets the pipecount to 18.

I guess that (all data entry) can also be used to setup the connectors properly which will probably fix how Hackintool displays them. Hackintool is a bit awkward sometimes, like when you setup all the connectors manually it doesn't always create all the entries and/or still leaves frame buffers enabled when I disabled them on purpose. Doing this map manually is the way to go.

Some other settings like enabling enable-hdmi-dividers-fix which is supposed to help with 4k @ 30hz when using hdmi 1.4 don't apply to us. Like lspcon and some other fixes and properties. I have and will still try them cuz hdmi20 isn't supposed to help us but somehow it does lol. I'll go and read the Dortania write up now and then try make a map using their method. I'll also have to grab the latest build of Big Sur though I won't be able to test anything until I also have a screen that can talk to the Dell without any conversion.

[zearp]

Oh, one more thing, you can edit those connectors and if you get the config right it will become red and show what its connected to. Try setting the index to 1 and it should show as connected.

[zearp]

According to IOreg the 3 frame buffers we have are @0, @1 and @2. All three of them are set to connector type 00 04 00 00 which is DisplayPort, @0 is either something internal or VGA. @1 is the top DP port and @2 the bottom one, I can only get audio to work on @1. This is with and without any connectors setup in the config. These default should be fine, disabling @0 is not needed just something I would like since it's not needed and guides/how-to's mention its best to disable unused frame buffers.

[zearp]

Our frame buffer:

ID: 0D220003, STOLEN: 32 MB, FBMEM: 19 MB, VRAM: 1536 MB, Flags: 0x00000402
TOTAL STOLEN: 52 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 116 MB, MAX OVERALL: 117 MB (123219968 bytes)
Camellia: CamelliaDisabled (0), Freq: 5273 Hz, FreqMax: 5273 Hz
Mobile: 0, PipeCount: 3, PortCount: 3, FBMemoryCount: 3
[1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x00000087 - ConnectorDP
[2] busId: 0x04, pipe: 10, type: 0x00000400, flags: 0x00000087 - ConnectorDP
[3] busId: 0x06, pipe: 8, type: 0x00000400, flags: 0x00000011 - ConnectorDP

Patch target:

01050900 00040000 87000000
02040A00 00040000 87000000
03060800 00040000 11000000

I'm just spamming here to keep track of stuff.

[zearp]

This should be the default frame buffers in "all data" format for the config:

I will test this and then start adjusting it, if that works then the connectors should be setup properly. You can also change the index by editing the first 2 numbers. I did fix the last entry.

The defaults look good in Hackintool tool, at least everything matches up:

A few more reboots to go.

[mgrimace]

So in order to get 4k to work on Catalina we can conclude it requires DP -> DP

Agreed, I don't have HDMI to test, but that stands to reason based on your tests.

I'm surprised you have free sync working, I've seen people claim macOS doesn't support it. I don't know what benefits free sync will give if not playing games but maybe I misunderstand what it does.

Me too to be honest, I think its only benefit is for gaming (my understanding is that it dynamically scales the frame rate up and down ≤60hz to match the game's input to keep everything smooth)

User space patching is broken on Big Sur, hdmi20 doesn't work there and the new frequency settings did't do anything for you. Thats correct right?

That's exactly correct! Hence working on Catalina, but not on Big Sur. As it is, I've been investigating alternatives to hdmi20 on Catalina with the goal of finding a set of properties that works across both versions (i.e., so users can reliable use this EFI for 4k regardless of MacOS version). It stands to reason (to me) that if I can get 4k working on Catalina without hdmi20, then it should work on Big Sur.

To set them you edit them in Hackintool, a 'long click' is needed to edit most field, pressing enter works for the indexes.

Ah thank you! That worked. I also read up on things here: https://www.tonymacx86.com/threads/guide-general-framebuffer-patching-guide-hdmi-black-screen-problem.269149/ which gave a lot of info on how/why things work. In my understanding, index1 = con0 = unused?, index2 = con1 = DP1, index 3= con2 = DP2 (internal). You can then define each con's type. I set my DP2 to index3 (i.e., corresponding to con2) in Hackintool, and it's now showing up properly!

I presume that to mean when we map connectors, you'd want to specify your con1 as HDMI using framebuffer-con1-type = 00080000 where 0008000 = HDMI, and 0004000 = DP. Though, actually maybe not because it is a physical DP connection. I think this is used when the hardware doesn't match the FrameBuffer profile (e.g., here: https://github.com/acidanthera/WhateverGreen/blob/master/Manual/FAQ.IntelHD.en.md - we are using the 0300220D Azul connector profile via platformID)

ID: 0D220003, STOLEN: 32 MB, FBMEM: 19 MB, VRAM: 1536 MB, Flags: 0x00000402 TOTAL STOLEN: 52 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 116 MB, MAX OVERALL: 117 MB (123219968 bytes) Camellia: CamelliaDisabled (0), Freq: 5273 Hz, FreqMax: 5273 Hz Mobile: 0, PipeCount: 3, PortCount: 3, FBMemoryCount: 3 [1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x00000087 - ConnectorDP [2] busId: 0x04, pipe: 10, type: 0x00000400, flags: 0x00000087 - ConnectorDP [3] busId: 0x06, pipe: 8, type: 0x00000400, flags: 0x00000011 - ConnectorDP 01050900 00040000 87000000 02040A00 00040000 87000000 03060800 00040000 11000000

This makes sense the BusID 05 doesn't actually exist on our hardware but is showing up as a DP connector. This is index 1, so I guess con0 could be disabled to free up any resources dedicated to that non-existent port.

Here's the Dortania info for connector/BUS patching though I don't fully understand the Port aspect of it and the difference between Port and BusID. I believe you can find the Ports via Hackintool but I'm confused here - https://dortania.github.io/OpenCore-Post-Install/gpu-patching/intel-patching/busid.html#parsing-the-framebuffer

The mapping syntax appears to be **XXYY**0A00 000**4**0000 87000000 based on the patch target info

xx = new port YY = new bus 00040000 = connector and could be changed to HDMI by switching to 00080000

So, unchanged, my con1 (DP1) should be: framebuffer-con1-alldata | Data | 02040A00 00040000 87000000

Interestingly unpatched, my con1 (DP1) is showing up with the correct busID (04) but pipe 18, and port 06

[zearp]

Booted up using above config results in unexpected values. I expected it to remain the same since it's setup like default but I ended up with -1 like you did.

No worries though, I'll configure each entry as I think it should be. The Dortania guide seems to suggest we have to increase the conX numbers by one. I'll try that too. I also don't fully understand it all but I sure can try and see what happens which is half of the fun!

[mgrimace]

No worries though, I'll configure each entry as I think it should be. The Dortania guide seems to suggest we have to increase the conX numbers by one. I'll try that too. I also don't fully understand it all but I sure can try and see what happens which is half of the fun!

Ha you and me both and it looks like we're working on the same thing! Agreed, if we match the PlatformID profile, then it should look like what you posted. That's what I did earlier when I played around with mapping the connectors, which is why I probably ended up with the -1. My best guess is that our ports don't match the hardware profile of the actual Mac this is taken from, and we would have to change/patch in the correct port for index3 in particular (no idea what we would change it to). Apparently, if you click in Hackintool it'll show you the port it's on and my index2 is showing up on port 06, but index3 is showing up port 00 which can't be right. This is where I got lost.

I believe we can safely disable con0 since it is unused but would need testing.

[mgrimace]

This should be the default frame buffers in "all data" format for the config:

I will test this and then start adjusting it, if that works then the connectors should be setup properly. You can also change the index by editing the first 2 numbers. I did fix the last entry.

The defaults look good in Hackintool tool, at least everything matches up:

A few more reboots to go.

OH, quick catch, your con2 says framebuffer-con2-type and I believe should be framebuffer-con2-alldata - that might explain the -1/errors.

[zearp]

My thoughts exactly. On pretty much all of it.

I'm going to disable con0 and set con1 and con2 the same except for bus id, hopefully that makes both ports work with audio too as bonus.

I also agree mapping DP ports as hdmi is not the way to go. The conversion of the signals is always done by the cables. Thats most likely also why the cheaper ones are directional. My DP -> hdmi cable can not convert hdmi -> DP. It only has one chip in the connector somewhere. I'm not even sure if bi-directional DP <-> hdmi exist.

PS: I fixed that typo after I noticed it on the screenshot.

[zearp]

Setting bus id to 00 for con0 doesn't disable it and according to Hackintool it's still using bus id 0x05. It seems to do nothing.

I'm not sure if changing the bus-id for the other entries will resolve the freeze and sometimes a panic when using the other DP port. I'll also try that regardless. And maybe null out the whole con0 entry to try and get rid of that thing.