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]

I’ll start working my way through con2, if the correct busid in our case is something other than 06, it should just be a matter of testing 02. 02, 04, 05, and 06 are the only allowable busIDs for DP. 06 seems to result in a -1, and 04 and 05 are already taken. Unless we can remap 05 to con2? Still reading and I’ll test in the morning.

[zearp]

Good call on the bus-id! I totally missed that when reading the guide yesterday. It would make the most sense that the default bus-id is whats causing freezes and sometimes a panic when hot plugging DP2. Only a few options to test so even without fully understanding it we can try them and see which combination works. The number of options is not that large with our dual DP ports. I wonder if @0 is internal or the VGA. I'd like to have a go at VGA too at some point since HD4x00 can in some cases still drive VGA, but it has to do the conversion cuz macOS can't. Either way thats just for fun haha.

Let me know your findings! Feels like getting the connectors setup is a good step and after some pondering my guess is that somehow someway the new frequency override thing isn't working properly. I also think it should be possible to use those new properties to make 4k work on Catalina like hdmi20 does now.

My first step would be to use debug versions of OpenCore, Lilu and WEG and see whats going on. I did notice some WEG errors when I tried these new properties. Something about not being able to send or execute a command. Lili/WEG may need additions and/or fixes before it works on the HD4600. Knowing exactly whats going on when each property is applied is crucial. Debug logs should show that + a lot more.

I'm going to be posting the screen back to Amazon today and later browse some more, I recall spotting 4k ones that had a mini DisplayPort on them. I'm confident it didn't work for me cuz converting the DisplayPort 1.2 signal to hdmi has some limitations. DisplayPort 1.2 can't be converted into hdmi 2.0 so it stays at hdmi 1.4 which has a max of 4k at an eye watering 30hz. The theory makes sense and the tests seem to confirm the theory. In a way we're lucky Dell used DisplayPort cuz hdmi 2.0 wasn't approved until late 2015. We'd be forced to add a dGPU to get 4k @ 60hz if they'd opted to add 2x hdmi instead.

[mgrimace]

Let me know your findings! Feels like getting the connectors setup is a good step and after some pondering my guess is that somehow someway the new frequency override thing isn't working properly. I also think it should be possible to use those new properties to make 4k work on Catalina like hdmi20 does now.

I tested by adding the following values to our default (working) config.plist on Catalina

Default PlatformID values:

framebuffer-con0-enable 01000000
framebuffer-con1-enable 01000000
framebuffer-con2-enable 01000000
framebuffer-con0-alldata 01050900 00040000 87000000
framebuffer-con1-alldata 02040A00 00040000 87000000
framebuffer-con2-alldata 03**06**0800 00040000 11000000

Tested alternative BusID for Con2 (=DP2) at BusID 02.

framebuffer-con0-enable 01000000
framebuffer-con1-enable 01000000
framebuffer-con2-enable 01000000
framebuffer-con0-alldata 01050900 00040000 87000000
framebuffer-con1-alldata 02040A00 00040000 87000000
framebuffer-con2-alldata 03**02**0800 00040000 11000000

2nd monitor (1080p) is working in DP2 with both BusIDs. This is generally expected "DisplayPort is the most flexible. BusIDs 0x02, 0x04, 0x05, 0x06 are permitted. Any of these values should work on any motherboard." (source).

In both tests my Pipe says 18 on index 2, and 8 on index 3. Those are incorrect according to the PlatformID table. I will test specifying those manually via framebuffer-conX-pipe

In both cases, after a reboot in Hackintool the index shows -1 and BusID 06. I'm not sure what this means (e.g., if the patch isn't being applied properly, or if Hackintool is not reading my changes for some reason).

When I manually change index to 3, the row lights up red which is expected behaviour for a connected display. It could be that we need to specify that there are 3 ports via framebuffer-portcount (but I haven't figured out the proper syntax for the data for this yet, or if that's even the issue).

[mgrimace]

Zero change in Hackintool when I specify the pipes manually using the following:

framebuffer-con0-pipe 09000000
framebuffer-con1-pipe 10000000
framebuffer-con2-pipe 08000000

Nothing I have done has resulted in any changes in Hackintool. I still get the -1 index instead of index 3, BusIDs are 05, 04, 06, and pipes are 18, 18, 8. Does order matter under DeviceProperties? Am I missing something? Cue up that Twilight Zone music again. Screenshot of complete section:

[mgrimace]

Also, did a quick hot-plug test, mostly for the satisfaction of yanking out the plug at this point. I can unplug my DP2 monitor without freezing or crash (with either BusID 02 or 06). Both screens momentarily turn black, then my monitor on DP1 resumes. Plugging back in, same effect - both black for a second or two, then both resume.

[zearp]

Very interesting findings! I wonder why mine on bus id 6 does cause a freeze, it's pretty consistent. I'll go repeat your tests here and see what happens. I can boot up fine in single screen with either port. But only DP1 accept re-plugging after boot. Id I boot with it connected to DP2 and then plug it into DP1 it works. It doesn't the other way around. Maybe my Samsung screen does something it doesn't like. I need to test it with another screen connected to DP not to hdmi with conversion. Conversion can introduce so many weird issues.

It might be better to check in IOreg (search for iGPU then delete the search term to reveal the correct entries). Hackintool sometimes hides the current settings with a toggle in the top menu under Patch -> Apply current settings. If I toggle that the connectors and other things change around. I also tried the Azul entry with seems to disables everything but 2 DP entries. I didn't test any of that though, just played around with the patch settings to see what they do haha. To prevent Hackintool hiding or not displaying something correctly checking directly in IOreg is the best.

Everything should be there, some is a bit hidden/requiring scrolling. I'm not sure where the index value is hidden. Bus and connector type are in there the other ones must be too, maybe named a bit differently.

[zearp]

@mgrimace The order of those entries don't matter. Afaik the only order that matters in the config is the kext loading. VirtualSMC, Lilu and maybe others need to be loaded before ones that need those kexts to function. Makes sense.

[zearp]

Ah, the IGPU entry itself has all the all-data and other WEG stuff currently applied. Still didn't find the index though!

[zearp]

Some progress to report in the audio department. Setting DP2's flags to 87000000 makes audio work on that port too. If only everything was that simple. Speaking of flags, apart for hovering over the options in Hackintool I didn't find much information these. Seems to do some magic.

Hot plugging still freezes but it might be due to the conversion, going to test with a screen that has DP input now. I'm cheap skate so most of my screens only have hdmi/vga and rarely dvi of DP.

I been trying to remove con0 but no matter what I try it still shows up. I can set the port limit to 2 but then it just removed port 3. So I guess we'll need t remap it so the DP ports become con0/con1 and then setting the port limit to 2 should get rid of the vga port. I check a terminal command:

% ioreg -l | grep "class AppleIntelFramebuffer"
    | |   | +-o AppleIntelFramebuffer@0  <class AppleIntelFramebuffer, id 0x100000323, registered, matched, active, busy 0 (546 ms), retain 18>
    | |   | +-o AppleIntelFramebuffer@1  <class AppleIntelFramebuffer, id 0x100000324, registered, matched, active, busy 0 (536 ms), retain 17>
    | |   | +-o AppleIntelFramebuffer@2  <class AppleIntelFramebuffer, id 0x100000325, registered, matched, active, busy 0 (538 ms), retain 20>

Once I get rid of it I'll save that config and medially add it back cuz I also brought a vga cable. I'm going all out despite it mist likely not going to wok there some reports of HD4x00 being able to pull it off. If I get it to work I will buy an old crt monitor. We used to have these giant Sun screens at work, real backbreakers.

More than 30 kilo's, they were pretty decent for its time as long as you didn't have to move them 😅

[mgrimace]

Some progress to report in the audio department. Setting DP2's flags to 87000000 makes audio work on that port too. If only everything was that simple. Speaking of flags, apart for hovering over the options in Hackintool I didn't find much information these. Seems to do some magic.

That's interesting, I actually tried that as well (admittedly as a copy-paste typo than a purposeful trial). In my case, the result was a black screen on DP2. Note that my main monitor still connected and working at DP1, so perhaps it's a dual-screen issue, just caution with changing the flags. Specifically, I set con2's flags to 87000000 (and no other changes to all-data).

Hot plugging still freezes but it might be due to the conversion, going to test with a screen that has DP input now. I'm cheap skate so most of my screens only have hdmi/vga and rarely dvi of DP.

That would be my guess (conversion issue vs., settings). Other than my 4k monitor splurge most of my setup is refurb/off-lease, luckily the old Dell monitors are DP :) I totally get it!

I been trying to remove con0 but no matter what I try it still shows up.

I'm not sure we need to remove it technically, it would free up some resources but it shouldn't break or prevent anything from working. A potential option to do this could be specifying things manually vs., via -alldata by using framebuffer-conX-index and framebuffer-conX-busid for each connector. For example, we could set con2 as index 1 and see what happens? It looks like we could map the software connector (conX) to a different physical port. I'm still a bit murky on index vs connector vs port but what I found below seems to clear it up somewhat:

"Once we have determined the physical port mappings for the motherboard, we provide this information to MacOS by filling out a simple Framebuffer Table. Because a maximum of 3 external video ports are supported by MacOS, we can define up to 3 software connectors or "cons". Any software connector can be mapped to any physical video port. The 3 software connectors are called con0, con1, and con2. The 3 physical ports 5, 6, and 7 are available to us as software Indexes 1, 2, and 3.

• Software Index 1 always refers to physical Port 5.
• Software Index 2 always refers to physical Port 6.
• Software Index 3 always refers to physical Port 7.

HDMI and DVI are considered to be the same. Set Type to HDMI for both HDMI and DVI physical ports. DP and VGA are considered to be the same. Set Type to DP for both DP and VGA physical ports." (source

If I get it to work I will buy an old crt monitor. We used to have these giant Sun screens at work, real backbreakers.

Hilarious, I absolutely remember those, I had an old 19" "flat-screen" ViewSonic that was an absolute unit! LOL.

[zearp]

I tried your suggestions, I got these results:

In IOreg the VGA ports remains on @0 no matter what but other things did change a bit. Funnily enough both screen work but the 2nd screen isn't highlighted red and it also doesn't change if I manually edit the index to other values. Both screens work in mirror and extended modes so I have no idea why or if its a problem Hackintool can't detect it.

Current config:

I don't think it's possible to make DP1 connect to @0 and DP2 to @1. But maybe I'm wrong, I tried a lot of settings and bus id's to no avail but with some funky results, a few times all screens remained black but vnc worked. Another time it froze at the final section before showing the login, pressing a key made the picture brighter (not the screen). Never seen that before. Some kernel panics which always are the same, and some freezes like before.

Regarding audio, DP1 still takes precedence if two screens are connected for me but booting when with a screen stand alone in DP2 it does work. I was kind hoping to end up with 2 audio devices but alas. Not yet and maybe not possible.

On our machines DP1 connects to port 6 so I guess setting the index to 2 for that port is pretty much set in stone, same for DP2 which connects to port 7 and needs index 3.

I didn't retest hot plugging yet, had my fill of freezes for today haha.

[zearp]

Btw have you found any useful documentation about the flags? Thats stil remains a mystery to me.

[zearp]

Caved in and tried some hot plugging which now seems to work without causing a freeze or panic using above config. Both when booting with single and dual monitors. I tried a bunch of combinations and all seems good. Audio is still acting a bit weird after hot plugging but not important at the moment.

[mgrimace]

Thank you for all this testing! I don't have too much to add really at this stage. Unfortunately no info re. flags, total mystery to me other than it's vaguely important to make it match when using all-data.

It makes sense that we can't make DP1 and DP2 connect to different ports. I envision this more of a 'mapping' thing (like USB) than a rerouting.

I see in your current config that you have con2 disabled (BusID 00) and the type as 10000000 vs. 0040000, but it looks like this config was a test to remap the indexes/ports(?) anyways. I'm guessing you probably reset it all back to 'normal' anyways (though I'm not entirely sure my understanding of 'normal' is even accurate).

This is how I'd interpret 'normal', and these are my underlying assumptions (which I'm nor sure are correct)

• con0, index 1, BusID 05, Pipe 09, Type DP (00040000)
• con1, index 2, BusID 04, Pipe 10, Type DP (00040000)
• con2, index 3, BusID 06 (or 02), Pipe 08, Type DP (00040000)

What I'll do next is spell them all out manually line-by-line (vs all-data), but I'm at a loss where to go next to get back to 4k. Unless just having this all mapped will somehow make the other settings work

[zearp]

Haha yeah, I was trying to see what happened when using the bus id/etc of the vga port on con2, it did something but in IOreg there's still 3 frame buffers and @0 was the vga. I changed the type for my clarity so I know which one is which in the config. When I did my Dell laptop setting bus id to 0 and index to FF did remove the actual frame buffer but somehow its not working here.

The flags are mystery, copying DP1 flags to DP2 did make audio work when used in single mode. Dual mode always seems to prioritise DP1 for audio.

I'm not sure how much it helps for 4k, getting the types setup might help for poor souls like me using conversion. I get random glitches in normal when set to hdmi, with type set I only get a quick glitch on boot once. I also got a lot of glitches when messing with the bus id's. I'm waiting for my money back so I can get another screen with a DP port too this time.

[mgrimace]

I'm not sure how much it helps for 4k, getting the types setup might help for poor souls like me using conversion.

Ok, it definitely does help with 4k, check this out!

• The Dell m3800 has working 4k/60 using the HD4600 on Big Sur (from a discussion I had on reddit.) Here's the post the properties are a hot mess and the con all-data has way too much going on, but I figured out that there is a "normal" all-data syntax in there towards the end of all data
• I stole the flags from the "working" framebuffer 07010000, figuring we can't change the pipe/port/bus, so why not the flags?
• When I replace the 87000000 and 11000000 flags with 07010000 in framebuffer-conX-alldata 4k works without enable-hdmi20 (with enable-max-pixel-clock-override added)

The problem

• If I replace all the connector flags with this, 4k works, but DP2 stops working (2nd monitor doesn't turn on).
• When I keep con1 flags set as 07010000, but change con2 back to either 11000000 or 87000000, both monitors turn on, but I lose 4k.

Conclusions?

• Flags?!?!
• 4k is indeed possible without enable-hdmi20 but without the right connector settings/flags, it's either 4k or both ports working, but it's progress.

Next tests?

• I'm going to try reverting DP1 back to normal flags and try swapping my 4k monitor to DP2 and see if that does anything.
• ???

[mgrimace]

Additional test, specified 3 ports just in case using framebuffer-portcount 03000000 just in case something I did turned off a port somehow. No change.

[mgrimace]

Ok bizarre test/result. I changed the flag on con2 to 07010000, put con1 back to 87000000 and swapped the monitor plugs. Basically, tested 4k on con2 instead of con1 with the new flags on con2. No 4k at all, DP1 didn't even turn on.

No change.

When I swapped the monitors back and rebooted, DP1 (old/normal flags) = 4k WORKS. It shouldn't. But it is because the second monitor (DP2 with the new flags) is disabled.

This means it's not the flags that's enabling 4k, it's disabling the second monitor that's enabling 4k. To me, that speaks to some kind of bandwidth, video memory type thing as a potential target to fix 4k. It doesn't have enough to drive both 4k and two monitors when enable-hdmi20 is disabled.

[zearp]

Good findings, it may very well be true that without hdmi20 or setting frequencies 4k will work in single display mode and that for dual screens some hackery it needed. Though on paper each DP port should be able to output 4k. Dual 4k should be possible too.

But since macOS doesn't fully understand whats going on we have to guide and kick it around. I'm not sure if it helps but I been reading up on manual patching and want to try extracting the frame buffer from the machine itself. Who knows maybe it's different from the default (though I doubt it). I just want to try and see what happens.

Been reading one of the main sources for all this info; Piker Alpha's blog. It has a lot of info but all very technical. Still interesting to glance over or read in detail. I hope that building the frame buffer patches from scratch might reveal something. But it might not and just become a fun afternoon project. I also wanna check the bus-id and such in Windows just to see what that uses.

The patches are probably doing some magic on the ports bandwidth thats needed for dual screen if one screen is 4k. It makes sense. I've ran dual 1080p for a while and it was fine but adding a 4k one might increase the bandwidth demand and our frame buffer patches can't provide that without hdmi20 or a working frequency patch. I don't know if there are other ways to setup a bandwidth allocation. I's a pretty specific area of frame buffer patching that I've seen pretty much nothing on.

Documentation on anything beyond stolenmem patching is very sparse and usable hidden in comments in code. Tonight Iwill play around with WEG tools and see where it leads. I'm intrigued by this tool. Hope to have some updates tonight.

[zearp]

Here are all the frame buffers for the HD4600:

AppleIntelFramebufferAzul.kext

ID: 0C060000, STOLEN: 64 MB, FBMEM: 16 MB, VRAM: 1024 MB, Flags: 0x00000004
TOTAL STOLEN: 209 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 209 MB, MAX OVERALL: 210 MB (220737536 bytes)
Camellia: CamelliaDisabled (0), Freq: 5273 Hz, FreqMax: 5273 Hz
Mobile: 0, PipeCount: 3, PortCount: 3, FBMemoryCount: 3
[0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000030 - ConnectorLVDS
[1] busId: 0x05, pipe: 9, type: 0x00000004, flags: 0x00000004 - ConnectorDigitalDVI
[2] busId: 0x04, pipe: 9, type: 0x00000800, flags: 0x00000082 - ConnectorHDMI
00000800 02000000 30000000
01050900 04000000 04000000
02040900 00080000 82000000

ID: 0C160000, STOLEN: 64 MB, FBMEM: 16 MB, VRAM: 1024 MB, Flags: 0x00000004
TOTAL STOLEN: 209 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 209 MB, MAX OVERALL: 210 MB (220737536 bytes)
Camellia: CamelliaDisabled (0), Freq: 5273 Hz, FreqMax: 5273 Hz
Mobile: 0, PipeCount: 3, PortCount: 3, FBMemoryCount: 3
[0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000030 - ConnectorLVDS
[1] busId: 0x05, pipe: 9, type: 0x00000004, flags: 0x00000004 - ConnectorDigitalDVI
[2] busId: 0x04, pipe: 9, type: 0x00000800, flags: 0x00000082 - ConnectorHDMI
00000800 02000000 30000000
01050900 04000000 04000000
02040900 00080000 82000000

ID: 0C260000, STOLEN: 64 MB, FBMEM: 16 MB, VRAM: 1024 MB, Flags: 0x00000004
TOTAL STOLEN: 209 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 209 MB, MAX OVERALL: 210 MB (220737536 bytes)
Camellia: CamelliaDisabled (0), Freq: 5273 Hz, FreqMax: 5273 Hz
Mobile: 0, PipeCount: 3, PortCount: 3, FBMemoryCount: 3
[0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000030 - ConnectorLVDS
[1] busId: 0x05, pipe: 9, type: 0x00000004, flags: 0x00000004 - ConnectorDigitalDVI
[2] busId: 0x04, pipe: 9, type: 0x00000800, flags: 0x00000082 - ConnectorHDMI
00000800 02000000 30000000
01050900 04000000 04000000
02040900 00080000 82000000

ID: 04060000, STOLEN: 64 MB, FBMEM: 16 MB, VRAM: 1024 MB, Flags: 0x00000004
TOTAL STOLEN: 209 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 209 MB, MAX OVERALL: 210 MB (220737536 bytes)
Camellia: CamelliaDisabled (0), Freq: 5273 Hz, FreqMax: 5273 Hz
Mobile: 0, PipeCount: 3, PortCount: 3, FBMemoryCount: 3
[0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000030 - ConnectorLVDS
[1] busId: 0x05, pipe: 9, type: 0x00000004, flags: 0x00000004 - ConnectorDigitalDVI
[2] busId: 0x04, pipe: 9, type: 0x00000800, flags: 0x00000082 - ConnectorHDMI
00000800 02000000 30000000
01050900 04000000 04000000
02040900 00080000 82000000

ID: 04160000, STOLEN: 64 MB, FBMEM: 16 MB, VRAM: 1024 MB, Flags: 0x00000004
TOTAL STOLEN: 209 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 209 MB, MAX OVERALL: 210 MB (220737536 bytes)
Camellia: CamelliaDisabled (0), Freq: 5273 Hz, FreqMax: 5273 Hz
Mobile: 0, PipeCount: 3, PortCount: 3, FBMemoryCount: 3
[0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000030 - ConnectorLVDS
[1] busId: 0x05, pipe: 9, type: 0x00000004, flags: 0x00000004 - ConnectorDigitalDVI
[2] busId: 0x04, pipe: 9, type: 0x00000800, flags: 0x00000082 - ConnectorHDMI
00000800 02000000 30000000
01050900 04000000 04000000
02040900 00080000 82000000

ID: 04260000, STOLEN: 64 MB, FBMEM: 16 MB, VRAM: 1024 MB, Flags: 0x00000004
TOTAL STOLEN: 209 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 209 MB, MAX OVERALL: 210 MB (220737536 bytes)
Camellia: CamelliaDisabled (0), Freq: 5273 Hz, FreqMax: 5273 Hz
Mobile: 0, PipeCount: 3, PortCount: 3, FBMemoryCount: 3
[0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000030 - ConnectorLVDS
[1] busId: 0x05, pipe: 9, type: 0x00000004, flags: 0x00000004 - ConnectorDigitalDVI
[2] busId: 0x04, pipe: 9, type: 0x00000800, flags: 0x00000082 - ConnectorHDMI
00000800 02000000 30000000
01050900 04000000 04000000
02040900 00080000 82000000

ID: 0D260000, STOLEN: 64 MB, FBMEM: 16 MB, VRAM: 1024 MB, Flags: 0x00000004
TOTAL STOLEN: 209 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 209 MB, MAX OVERALL: 210 MB (220737536 bytes)
Camellia: CamelliaDisabled (0), Freq: 5273 Hz, FreqMax: 5273 Hz
Mobile: 0, PipeCount: 3, PortCount: 3, FBMemoryCount: 3
[0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000030 - ConnectorLVDS
[1] busId: 0x05, pipe: 9, type: 0x00000004, flags: 0x00000004 - ConnectorDigitalDVI
[2] busId: 0x04, pipe: 9, type: 0x00000800, flags: 0x00000082 - ConnectorHDMI
00000800 02000000 30000000
01050900 04000000 04000000
02040900 00080000 82000000

ID: 0A160000, STOLEN: 64 MB, FBMEM: 16 MB, VRAM: 1024 MB, Flags: 0x00000004
TOTAL STOLEN: 209 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 209 MB, MAX OVERALL: 210 MB (220737536 bytes)
Camellia: CamelliaDisabled (0), Freq: 2777 Hz, FreqMax: 2777 Hz
Mobile: 0, PipeCount: 3, PortCount: 3, FBMemoryCount: 3
[0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000030 - ConnectorLVDS
[1] busId: 0x05, pipe: 9, type: 0x00000004, flags: 0x00000004 - ConnectorDigitalDVI
[2] busId: 0x04, pipe: 9, type: 0x00000800, flags: 0x00000082 - ConnectorHDMI
00000800 02000000 30000000
01050900 04000000 04000000
02040900 00080000 82000000

ID: 0A260000, STOLEN: 64 MB, FBMEM: 16 MB, VRAM: 1024 MB, Flags: 0x00000004
TOTAL STOLEN: 209 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 209 MB, MAX OVERALL: 210 MB (220737536 bytes)
Camellia: CamelliaDisabled (0), Freq: 2777 Hz, FreqMax: 2777 Hz
Mobile: 0, PipeCount: 3, PortCount: 3, FBMemoryCount: 3
[0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000030 - ConnectorLVDS
[1] busId: 0x05, pipe: 9, type: 0x00000004, flags: 0x00000004 - ConnectorDigitalDVI
[2] busId: 0x04, pipe: 9, type: 0x00000800, flags: 0x00000082 - ConnectorHDMI
00000800 02000000 30000000
01050900 04000000 04000000
02040900 00080000 82000000

ID: 0A260005, STOLEN: 32 MB, FBMEM: 19 MB, VRAM: 1536 MB, Flags: 0x0000000F
TOTAL STOLEN: 52 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 116 MB, MAX OVERALL: 117 MB (123219968 bytes)
Camellia: CamelliaDisabled (0), Freq: 2777 Hz, FreqMax: 2777 Hz
Mobile: 1, PipeCount: 3, PortCount: 3, FBMemoryCount: 3
[0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000030 - ConnectorLVDS
[1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x00000087 - ConnectorDP
[2] busId: 0x04, pipe: 9, type: 0x00000400, flags: 0x00000087 - ConnectorDP
00000800 02000000 30000000
01050900 00040000 87000000
02040900 00040000 87000000

ID: 0A260006, STOLEN: 32 MB, FBMEM: 19 MB, VRAM: 1536 MB, Flags: 0x0000000F
TOTAL STOLEN: 52 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 116 MB, MAX OVERALL: 117 MB (123219968 bytes)
Camellia: CamelliaDisabled (0), Freq: 2777 Hz, FreqMax: 2777 Hz
Mobile: 1, PipeCount: 3, PortCount: 3, FBMemoryCount: 3
[0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000030 - ConnectorLVDS
[1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x00000087 - ConnectorDP
[2] busId: 0x04, pipe: 9, type: 0x00000400, flags: 0x00000087 - ConnectorDP
00000800 02000000 30000000
01050900 00040000 87000000
02040900 00040000 87000000

ID: 0A2E0008, STOLEN: 64 MB, FBMEM: 34 MB, VRAM: 1536 MB, Flags: 0x0000021E
TOTAL STOLEN: 99 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 227 MB, MAX OVERALL: 228 MB (239611904 bytes)
Camellia: CamelliaV1 (1), Freq: 1388 Hz, FreqMax: 1388 Hz
Mobile: 1, PipeCount: 3, PortCount: 3, FBMemoryCount: 3
[0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000030 - ConnectorLVDS
[1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x00000107 - ConnectorDP
[2] busId: 0x04, pipe: 10, type: 0x00000400, flags: 0x00000107 - ConnectorDP
00000800 02000000 30000000
01050900 00040000 07010000
02040A00 00040000 07010000

ID: 0A16000C, STOLEN: 64 MB, FBMEM: 34 MB, VRAM: 1536 MB, Flags: 0x0000001E
TOTAL STOLEN: 99 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 227 MB, MAX OVERALL: 228 MB (239611904 bytes)
Camellia: CamelliaDisabled (0), Freq: 1388 Hz, FreqMax: 1388 Hz
Mobile: 1, PipeCount: 3, PortCount: 3, FBMemoryCount: 3
[0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000030 - ConnectorLVDS
[1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x00000107 - ConnectorDP
[2] busId: 0x04, pipe: 10, type: 0x00000400, flags: 0x00000107 - ConnectorDP
00000800 02000000 30000000
01050900 00040000 07010000
02040A00 00040000 07010000

ID: 0D260007, STOLEN: 64 MB, FBMEM: 34 MB, VRAM: 1536 MB, Flags: 0x0000031E
TOTAL STOLEN: 99 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 227 MB, MAX OVERALL: 228 MB (239616000 bytes)
Camellia: CamelliaDisabled (0), Freq: 1953 Hz, FreqMax: 1953 Hz
Mobile: 1, PipeCount: 3, PortCount: 4, FBMemoryCount: 3
[0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000030 - ConnectorLVDS
[1] busId: 0x05, pipe: 11, type: 0x00000400, flags: 0x00000107 - ConnectorDP
[2] busId: 0x04, pipe: 11, type: 0x00000400, flags: 0x00000107 - ConnectorDP
[3] busId: 0x06, pipe: 3, type: 0x00000800, flags: 0x00000006 - ConnectorHDMI
00000800 02000000 30000000
01050B00 00040000 07010000
02040B00 00040000 07010000
03060300 00080000 06000000

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

ID: 0A2E000A, STOLEN: 32 MB, FBMEM: 19 MB, VRAM: 1536 MB, Flags: 0x000000D6
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
[0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000011 - ConnectorLVDS
[1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x00000087 - ConnectorDP
[2] busId: 0x04, pipe: 10, type: 0x00000400, flags: 0x00000087 - ConnectorDP
00000800 02000000 11000000
01050900 00040000 87000000
02040A00 00040000 87000000

ID: 0A26000A, STOLEN: 32 MB, FBMEM: 19 MB, VRAM: 1536 MB, Flags: 0x000000D6
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
[0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000011 - ConnectorLVDS
[1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x00000087 - ConnectorDP
[2] busId: 0x04, pipe: 10, type: 0x00000400, flags: 0x00000087 - ConnectorDP
00000800 02000000 11000000
01050900 00040000 87000000
02040A00 00040000 87000000

ID: 0A2E000D, STOLEN: 96 MB, FBMEM: 34 MB, VRAM: 1536 MB, Flags: 0x0000040E
TOTAL STOLEN: 131 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 227 MB, MAX OVERALL: 228 MB (239607808 bytes)
Camellia: CamelliaDisabled (0), Freq: 5273 Hz, FreqMax: 5273 Hz
Mobile: 0, PipeCount: 3, PortCount: 2, FBMemoryCount: 2
[1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x00000107 - ConnectorDP
[2] busId: 0x04, pipe: 10, type: 0x00000400, flags: 0x00000107 - ConnectorDP
01050900 00040000 07010000
02040A00 00040000 07010000

ID: 0A26000D, STOLEN: 96 MB, FBMEM: 34 MB, VRAM: 1536 MB, Flags: 0x0000040E
TOTAL STOLEN: 131 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 227 MB, MAX OVERALL: 228 MB (239607808 bytes)
Camellia: CamelliaDisabled (0), Freq: 5273 Hz, FreqMax: 5273 Hz
Mobile: 0, PipeCount: 3, PortCount: 2, FBMemoryCount: 2
[1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x00000107 - ConnectorDP
[2] busId: 0x04, pipe: 10, type: 0x00000400, flags: 0x00000107 - ConnectorDP
01050900 00040000 07010000
02040A00 00040000 07010000

ID: 04120004, STOLEN: 32 MB, FBMEM: 0 bytes, VRAM: 1536 MB, Flags: 0x00000000
TOTAL STOLEN: 1 MB, TOTAL CURSOR: 0 bytes, MAX STOLEN: 1 MB, MAX OVERALL: 1 MB
Camellia: CamelliaDisabled (0), Freq: 0 Hz, FreqMax: 0 Hz
Mobile: 0, PipeCount: 0, PortCount: 0, FBMemoryCount: 0

ID: 0412000B, STOLEN: 32 MB, FBMEM: 0 bytes, VRAM: 1536 MB, Flags: 0x00000000
TOTAL STOLEN: 1 MB, TOTAL CURSOR: 0 bytes, MAX STOLEN: 1 MB, MAX OVERALL: 1 MB
Camellia: CamelliaDisabled (0), Freq: 0 Hz, FreqMax: 0 Hz
Mobile: 0, PipeCount: 0, PortCount: 0, FBMemoryCount: 0

ID: 0D260009, STOLEN: 64 MB, FBMEM: 34 MB, VRAM: 1536 MB, Flags: 0x0000001E TOTAL STOLEN: 99 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 99 MB, MAX OVERALL: 100 MB (105385984 bytes)
Camellia: CamelliaDisabled (0), Freq: 1953 Hz, FreqMax: 1953 Hz
Mobile: 1, PipeCount: 3, PortCount: 1, FBMemoryCount: 1
[0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000030 - ConnectorLVDS
00000800 02000000 30000000

ID: 0D26000E, STOLEN: 96 MB, FBMEM: 34 MB, VRAM: 1536 MB, Flags: 0x0000031E
TOTAL STOLEN: 131 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 323 MB, MAX OVERALL: 324 MB (340279296 bytes)
Camellia: CamelliaV2 (2), Freq: 1953 Hz, FreqMax: 1953 Hz
Mobile: 1, PipeCount: 3, PortCount: 4, FBMemoryCount: 3
[0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000030 - ConnectorLVDS
[1] busId: 0x05, pipe: 11, type: 0x00000400, flags: 0x00000107 - ConnectorDP
[2] busId: 0x04, pipe: 11, type: 0x00000400, flags: 0x00000107 - ConnectorDP
[3] busId: 0x06, pipe: 3, type: 0x00000800, flags: 0x00000006 - ConnectorHDMI
00000800 02000000 30000000
01050B00 00040000 07010000
02040B00 00040000 07010000
03060300 00080000 06000000

ID: 0D26000F, STOLEN: 96 MB, FBMEM: 34 MB, VRAM: 1536 MB, Flags: 0x0000001E
TOTAL STOLEN: 131 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 131 MB, MAX OVERALL: 132 MB (138940416 bytes)
Camellia: CamelliaV2 (2), Freq: 1953 Hz, FreqMax: 1953 Hz
Mobile: 1, PipeCount: 3, PortCount: 1, FBMemoryCount: 1
[0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000030 - ConnectorLVDS
00000800 02000000 30000000

Maybe experimenting with platform id's can do something. One that matches better if any, and hopefully configures thoe 'magic' things like flags and such better.

I also think we don't need to spoof the device id anymore as ours is natively supported. It's a left-over from when I tried to make it work on i3's too. But I gave up on the HD4400 and just bought i5's on eBay. Such a headache those 4400's, literally too due to its glitching lol.

[zearp]

Can confirm device-id spoofing is not needed for the HD4600. Don't think it hurts, just one more thing that can be stripped from the config.

[mgrimace]

Thanks! I stepped back and tried a few trials as well, mostly to confirm:

Config: Current EFI with enable-hdmi20 changed to enable-max-pixel-clock override. "Default" connector settings added as well.

Test 1: 4k monitor plugged into DP2, 1080p monitor removed/unplugged (usually in DP1). Result: 4k on DP2 monitor

Test 2: then, tried to plug in 1080p after boot into DP1 (hoping 4k would "stick" on DP2 monitor) Result 2: both monitors refresh, 1080p comes on and 4k drops resolution to 2600x1400 (loses 4k).

Test 3: toggle monitors on/off to see if that fixes resolution Result 3: no change (no crashes though either)

Test 4: trialled this https://github.com/avibrazil/RDM to try and manually change resolution back to 4k. Source, from this reddit discussion where another user was able to get dual 4k on HD4600. Result 4: no 4k resolution available in menubar

I don't think this adds anything new per se, but I wanted to rule out anything obvious that I might have missed earlier!

[zearp]

My main concern right now is that the replacement for enable-hdmi20 doesn't seem to work at all. It's not working with Catalina and not with Big Sur, despite us trying manual clocks speeds. On paper it should just work, at least with Catalina. I think it may be needed to open a WEG issue for this. As far as I understand enable-max-pixel-clock-override should be a drop-in replacement for enable-hdmi20. But our testing shows this isn't the case, not with Big Sur and not with Catalina.

For my other hackintosh project this might also become a problem due to a very rare issue with enable-hdmi20 on the NUC where it can crash the WindowServer which in turn might log out you. Of course I didn't buy another 4k portable screen yet cuz I can't find one with a DP port for a reasonable price. I might just look on the 2nd hand market for something very cheap just for testing.

Btw I'm not a 100% certain that enable-max-pixel-clock-override can simply replace enable-hdmi20 in the config and the functionality should be the same. It's what I gathered from the sparse documentation about this feature but nothing conclusive.

[zearp]

Rambling thinking out loud post coming up lol.

From the WEG FAQ:

• enable-max-pixel-clock-override modifies the IODisplayTimingRange structure and raises the max pixel clock limit to 675 MHz
• enable-hdmi20 patches CheckTimingWithRange in CoreDisplay.framework to skip validation of the pixel clock

This would imply that since enable-hdmi20 works on Catalina, simply skipping the validation of the pixel clock is enough to make 4k work and would also imply the default pixel clock (whatever it is) is fine.

Overriding the pixel clock doesn't seem to either not work or not applied. I don't know how to see the current pixel clocks. I did notice some WEG messages when booting when I had the portable screen here. Will probably require a debug version to see more details.

It would be nice if there was a way to check the pixel clock so we know if it's changed at all and then we can also see if custom values are applied. I will do some searching to see if its possible to check that clock speed and then do some testing setting the clock and also check if custom clock speeds work.

Its pretty essential to find out if the clock speed actually changes cuz if it does change and doesn't work it would mean this method is not feasible for this Dell. Simply skipping validation is enough on Catalina and as things look now setting a clock speed isn't doing anything on Catalina. This also means the easiest solution is to manually patch out the validation of the clock speed for Big Sur.

[zearp]

I found a headless hdmi dongle that can fake 4k on my NUC. Will mess around with that one on an Optiplex later. Might not be suitable but worth a try. It's a lot cheaper than a screen 😅

Oh, snap I forgot hdmi might be hard-limited. I'll give it a go regardless.

[zearp]

Of course the dongle doesn't work in a DisplayPort to hdmi converter dongle, despite that dongle claiming 4k @ 60hz conversion from DP 1.2 or higher. Dongle overload perhaps haha.

Then, the only DisplayPort dummy with fast delivery I can find can't deliver on it's 60hz promise. Something like this shouldn't be hard but somehow all these DP dummy's can't "emulate" 4k @ 60hz.

I wonder why they don't exist or very hard to find cuz they exist for hdmi. A nice and cheap way to test 4k, my cheap eBay hdmi dongle can do it. I will check eBay again later, my search-fu might be off today!

[mgrimace]

Its pretty essential to find out if the clock speed actually changes cuz if it does change and doesn't work it would mean this method is not feasible for this Dell. Simply skipping validation is enough on Catalina and as things look now setting a clock speed isn't doing anything on Catalina. This also means the easiest solution is to manually patch out the validation of the clock speed for Big Sur.

That's a fascinating finding! I appreciate all you're doing here and don't really have anything new to add at this point other than thanks for digging into this further. Also, very interesting re. dongles, that wasn't even something that I was aware that existed but makes sense to test it prior to jumping into expensive hardware (like a new 4k monitor).

I don't really know where to go from here, but that makes sense that if the real reason enable-hdmi20 is working is to skip validation of the pixel clock then at least we have a target going forward (which is huge since I was mostly just trying things at random). I would add that enable-max-pixel-override is partly working because it does enable 4k (on one monitor), but where it falls apart is connecting that second monitor. So there's something there (as in, it must change the clock speed, in my testing adding/removing that property does add/remove 4k on single monitor output). But clearly not fully replicating the function. It's also quite possible that I'm complicating the testing and it could be my own hardware or something obvious I'm missing or doing wrong on my end. Is there a property that would simply skip pixel clock validation that I can test as an alternative on my end?

[zearp]

Wow a Tonymac moderator just blatantly stole my whole EFI and posted it as his own. Pretty brazen!

File in question: https://www.tonymacx86.com/attachments/0-6-9-oc-efi-zip.520341/

Notice inside the config there's this block:

I added that block myself a long time ago, so in other OS's you won't see Acidanthera as manufacturer. I have recently removed the block cuz it doesn't pass the OpenCore validation tool anymore. None of those fields are defaults.

This is pretty low if I'm perfectly honest. A user sharing my work without credit would be one thing. But this is a moderator who posts advertisements disguised as posts like this one who literally just zipped up my EFI and posted it in his thread, claiming he made it. Really disgusting behaviour. Specially if that moderator is an adult.

This kind of behaviour is why people dislike Tonymac.

I added these fields around June last year: https://github.com/zearp/OptiHack/blob/4119d4f4e1c509bfc7dfe73730fccbdb49f70cf7/EFI/OC/config.plist#L573-L587

Smh.

[mgrimace]

Ugh, I'm so sorry to hear that, this is immensely frustrating.

[mgrimace]

Is this the same mod that was asking to use your config in some sort of prefab tool they were putting together?

[zearp]

Haha, no that was a user. That app is kind of weird. even comes with remote access for certain people who're allowed to push changes to those who have the app installed.

I'm not really frustrated just annoyed people do this, specially someone who's an official on one of the larger hackintosh websites out there. I don't really care who clones or forks but simply taking the repo and zipping it up to pass it off as your own is kind of lame to use an old internet term.

Today I'm going to start with Monterey testing. I think disabling compatibility is the best way to go as it only disables the check the installer does when installing. Using a different SMBIOS for a totally different h/w platform might lead to more issues. Plus I'm not really sure of all the things SMBIOS does. But we know it does things like video frequencies and voltages.

Just needed to get this "thievery" of my chest haha. Btw I still haven't found a real DP dongle that can do 4k @ 60hz. I'm starting to think they don't exist despite some claiming they can do it, the reviews always correct those claims. Too bad cuz its great for 4k testing without having to buy a 4k monitor.

[davidAlaBer]

Amazing :(

El 14 jun 2021, a las 15:34, mgrimace @.***> escribió:

 Is this the same mod that was asking to use your config in some sort of prefab tool they were putting together?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[zearp]

Adding some more info to the pile. Did some experimenting with flags to get dual screen to work. I didn't have 2 DisplayPort monitors to work with, things might work fine with 2 DisplayPort capable screens.

• The DisplayPort screen must be connect to DP2 (port closest to vga) in order for the 2nd screen to work when using a DP -> hdmi cable/dongle
• Dual screen only works with the CNUnknownFlag_10 bit set.
• With no flags (all zero) set the DP -> hdmi connected screen remains off, no matter what bus-id is used
• Without CNUnknownFlag_10 set dual screen can not be made to work, at least not with mixed DisplayPort and hdmi screens.
• Hot plugging without CNUnknownFlag_10 set results in panics/freezes (need to collect some panic logs)
• Hot plugging with CNUnknownFlag_10 set results in freely hot plugging the DP ports in single screen mode and to the same port in dual screen
• With CNUnknownFlag_10 set audio of dp/hdmi does not work anymore
• With CNUnknownFlag_10 set the connected display shows up as internal

After searching for info on this CNUnknownFlag_10 I found others ran into the exact same thing. Info is sparse but it seems to set the screen as internal. Both my screens showed up as internal so it does that, but also does more since it fixes crashes/panics.

I've tried too many flag combinations to recount but nothing would make audio + hotplug/dual screen work at the same time. And this is only the first bit of the flags haha. All zero's gives working audio but no working hotplug/dual screen. Enabling only the flag makes it all work but breaks audio. I also tried mixing of flags, giving one connector some and the other one others.

There are a lot more bits to set in the flag section but I can't find any good info on it, and I don't know if flags could sort this out.

If you're bored can you try these flags out on your dual DP setup @mgrimace?

I also noticed earlier on in this thread you got 4k to work with flags, but they were other bits than just the first. It might be one of the other flags that can be found in Hackintool that sort it out. On Framebuffer page there are some (FBDisableHighBitrateMode2), but also DPCD max link rate stuff. I didn't look into that yet. But on paper our DP ports have enough b/w to each handle 4k. Maybe setting the HBR rate via a patch can help? I still have no 4k screen to help out with this. But they seem like interesting options to explore.

It was fun trying these things out but I feel kind of bummed out we may have to choose between hotplug/dual screen without panics or hassle, or audio over dp/hdmi and having to tweak/mess about to get dual screen work. At least as far as my dp+hdmi screen setup goes. Hopefully it all works with 2x DP screens.

The most valuable info on flags I found in here: https://github.com/acidanthera/WhateverGreen/blob/master/Manual/IntelFramebuffer.bt

And an issue where two others found out what I did after my testing: https://github.com/acidanthera/bugtracker/issues/442

I think if I have to choose I would opt to use the flag and lose audio over dp/hdmi even if it shows both connected screens as internal (also on the Mac mini SMBIOS, I tried both). It's better to have no panics or crashes when re-plugging a cable. Pretty much all screens have crappy speakers too.

The only use cases I can think of to prefer having audio over hdmi to work are either single screen applications like when connected to a tv/media centre. Or maybe if you need to use the headphone jack on the screen cuz the computer is too far away. Now we know how it works it shouldn't be much of an issue. The end user can easily set it to what they prefer like the layout-id.

Default to using the flag and if anyone needs audio over dp/hdmi they can change the flags of the port they need it on to all zero's. At the cost of maybe dual screen and hotplugging causing crashes/panics. Maybe those can be resolved, I need to collect some logs but reading the issue about it just confirms how much of blackhole these flags and such are. This is far beyond surface level frame buffer patching.

Personally I'm fine with either but prefer the flag as it results in not panics or crashes. I run dual screen mainly for audio stuff and would not even think about using speakers in the screens or the headphone jack on the screen or the Dell for that matter. I have an interface for that haha.

One last thing, really getting rid of the vga frame buffer was a lot easier than expected. Setting the bus-id to 00 already fixed some lag after login with the Mac mini SMBIOS but simply not defining it and only setting up the two DP ports and then limit the frame buffers to 2 made it go away. It's not in IOReg anymore. It's gone. I'll update the config later.

Let me know what you make of my findings and ramblings and also what you think makes the most sense as default flags.

[zearp]

If real, this would make for a funky looking iMac.

[mgrimace]

If you're bored can you try these flags out on your dual DP setup @mgrimace?

Hi, your logic makes absolute sense (even if the flag functions remain a bit of a mystery). FWIW getting rid of the VGA framebuffer by limiting the frame buffers to 2 is an elegant solution! I'd be happy to test out flags again, is there a config you want me to test in particular so we're on the same page? I've only been able to partly follow the threads/discussions so I may have missed it earlier.

For reference I'm on a 7020 SFF with two monitors both connected DisplayPort to DisplayPort (no adaptors). Primary monitor is 4k, secondary is 1080p. Staying with Catalina for now, so to me the thing that would make the most sense would be to removeenable-hdmi20, then test various flags/properties until 4k and dual monitor works.

Re. audio, I personally use a monitor that has no speakers so I wouldn't miss anything. My personal preference would be avoiding panics/crashes vs., convenience (i.e., prioritizing stability).

I haven't changed my serials yet, but I see my steps as:

• Update serials to match Monterey preferred system (i.e., new mac mini)
• Test flags/framebuffer changes with dual monitor/4k (if you can point me to an updated config with all the properties/flags you want me to test that'd be ideal)
• Since I'm on Catalina, when testing, I'd delete the enable-hdmi20 property to simulate Big Sur/Monterey
• Test hot plugging
• Can't test audio over DP since no monitor audio or audio jacks on either monitor!

Let me know if I'm wrong or missing anything! I'm happy to do whatever testing I can (without upgrading yet to Monterey, still using system for work).

I think earlier re. flags, I think all that I managed to figured out was that I could use a 'wrong' flag to disable an output. This did reveal that by disabling the secondary monitor via the framebuffer, 4k was re-enabled on the primary monitor without the need for enable-hdmi20. I wonder if disabling the VGA framebuffer would have the same effect!

I was never able to parse what the bits actually meant, and mostly just copy-pasted things to see what would happen :P I'll look into those further readings you pointed too, appreciate it and all your work! It's a busy time for me right now so I haven't been available to contribute too much at the moment but I have been trying to monitor and I sincerely appreciate your work here!

[zearp]

Not worries! I can make some test EFI's you can boot into. Should be rather painless if you're signed out, or copy serials over. I think for 4k testing you could stay on Catalina if it breaks as soon as hdmi20 is disabled, you can zero it out to disable like I have in the current config.

I noticed that setting the bus-id of the VGA port to 00 did remove the login lag someone reported (its a common issue with "active" unused framebuffers) but it didn't remove it from IOreg. Only setting up the DP ports and limiting the frame buffers to 2 did result in it being removed from IOreg. I figured that would be preferred. One a rainy Sunday Might try VGA but from what I gather it works only with the HD4400 for Haswell. Which is a glitchy thing in my experience.

I'm interested is just enabling enable-dpcd-max-link-rate-fix and see what it detects in the boot log and if 4k works with hdmi20 disabled. That should give some insights on what's going on and if needed we can manually set the speeds. I remember digging into hdmi20 and it does something different than the replacement does. And what happend to you with your flags indicates maybe a b/w allocation problem or something. The WEG docs mention this fix in relation to Dell laptops, things overlap in Dells universe so this may also help here.

I did run into something interesting when testing flags, I had only 1 screen connected but macOS had 2 screens, one at a low weird resolution. The resolution reminded me of the weird resolution some people get after wake when using a dGPU. These flags sure are the biggest mystery so far. I started with all zero's just to see what it does with nothing. And it was all fine. Except for hot plug. Then by only enabling that other flag it was fixed by broke audio.

Only 4k is really on my todo list for this build. I'd like to get rid of needing legacy roms but that is also a blackhole and I would only want to fix that so we can use real Secure Boot. But thats just a nice thing not a must have. I'm currently moving the mess that the readme has become to something easier to digest. After that I think this EFI is pretty much done. It would just need updates and such. Maybe once a week or every 2 weeks. Config changes and such aren't that tricky and the joy of OpenCore is that once it all works with the macOS version you need you can forget about it and treat your Dell like a Mac including using Bootcamp haha.

After Monterey there's a very slim chance we get another update on the Mac mini SMBIOS. So then getting any newer macOS to work will be matter of patching and messing about to a point that might introduce instability as we might to use SMBIOS with power management/etc for a different platform. While that may work I prefer not using it cuz SMBIOS is also a bit of blackhole, I don't know half of what that does. Maybe it will be ok but I don't expect much. Until Monterey loses security updates the EFI should be fine for years to come.

Thank you too for testing and helping out! I have a lot of random parts but can only test so much. The most important part is that I learned a lot and got myself and hopefully some others a nice stable macOS machine to play with for little money. Despite it being a Dell it is a business build with good parts albeit proprietary should last many years to come. No leaky caps on these boards.

I'll see when I can get some configs/settings up to test out. No rush, 4k works fine on the real desktop OS which is still Catalina with no wasted user interface space and runs rock solid on our machines. Though I admit Monterey is running really smooth, on par with my much newer NUCs but that interface still needs a lot of fixes. Lots of Big Sur issues got fixed though.

Oh here is the new readme/docs I'm working on: https://zearp.github.io/doctest/ -- still a big WIP.

Yes, I been having some extra free time haha.

[mgrimace]

Not worries! I can make some test EFI's you can boot into.

Even just a table of the DeviceProperties (e.g., VGA disabled, flags to test, enable-dpcd-max-link-rate-fix, etc).

I figured that would be preferred. One a rainy Sunday Might try VGA but from what I gather it works only with the HD4400 for Haswell. Which is a glitchy thing in my experience.

Yeah, I don't see any real need for VGA and would prefer to have it disabled

I'm interested is just enabling enable-dpcd-max-link-rate-fix and see what it detects in the boot log and if 4k works with hdmi20 disabled. That should give some insights on what's going on and if needed we can manually set the speeds.

This is curious, I'll try this out, how/where do I share the boot log (and anything I need to redact for privacy)?

After that I think this EFI is pretty much done. It would just need updates and such. Maybe once a week or every 2 weeks. Config changes and such aren't that tricky and the joy of OpenCore is that once it all works with the macOS version you need you can forget about it and treat your Dell like a Mac including using Bootcamp haha.

That's great! If we can solve the remaining iGPU (i.e., basically finalize the DeviceProperties/Framebuffers) then it'll be rock solid with as much functionality as we can squeeze out of the darn thing. I personally don't have any other gaps with my own usage!

After Monterey there's a very slim chance we get another update on the Mac mini SMBIOS.

I agree that this would be a logical place to stop, it seems like diminishing returns to sacrifice stability for newer OS. I'm amazed it'll get as far as Monterey to be honest. I'm relieved to hear that your experience with Monterey has been positive (vs., Big Sur).

Despite it being a Dell it is a business build with good parts albeit proprietary should last many years to come. No leaky caps on these boards.

^^^ this 100%. It's the right mix of cheap, reliable, and hackintosh-able (with full functionality with minimal hardware changes - e.g., SSD, wifi/BT) :)

Oh here is the new readme/docs I'm working on: https://zearp.github.io/doctest/ -- still a big WIP.

Looks great!!

[mgrimace]

@zearp OK extremely promising early test results!! Yes 4k, yes dual monitor, no enable-hdmi20!

Test conditions:

• iMac15,1
• Catalina
• 27" 4k/60 (freesync) DP>DP
• 24" 1080p/60 DP>DP
• iGPU only

Config:

• current published config (as of Jul 18/2021 which includes the flags to disable VGA), added enable-dpcd-max-link-rate-fix and set to enabled, and enable-hdmi20 completely removed (to simulate Big Sur/Monterey)

Working:

• 4k/60 with freesync - NOTE: needed to toggle the monitor off/on for it to detect 4k (initially appeared as not-4k).
• second 1080p monitor
• Toggled both monitors on/off via power buttons, no freeze or crash

Not working:

• screen rotation on second monitor (I use it in vertical/portrait)
• option + cmd + Displays does not reveal rotation (used to work to allow rotation on built-in screens)

Other notes;

• 4k appears as "Built-in iMac retina", second monitor appears as "iMac" (which is probably why I can't rotate it)

[mgrimace]

Quick update: 4k does not persist if I remove the port-limit, so I'm thinking the solution is more likely related to disabling VGA than anything else (e.g., perhaps a bandwidth issue as we theorized). As it is, I have to revert to my old config because I can't figure out how to rotate the second display yet. The app SwitchResX wasn't working to force it either.

[zearp]

Ohh yeah the rotation could be related to flags too maybe? You can try the ones we used before. I kind of assumed they didn't do anything other than the bits I tried. I just started at all zero's for the flags as a baseline. It is still very mysterious what the flags exactly do. But at least figured out which bit must be set to get audio over it.

If both ports have the same flags there shouldn't be a difference in how macOS detects the screen. Both should be internal with the same options (in theory). Maybe the setting to rotate the screen is not done via the flags. The bandwidth thing could be true yeah.

Maybe adding dpcd-max-link-rate and setting it to 14000000 can help. 0x14 should be enough for 4k If all is well you should get some probing entries in the kernel log after boot (taken from the WEG docs):

igfx: @ (DBG) MLR: Found CFL- platforms. Will setup the fix for the CFL- graphics driver.
igfx: @ (DBG) MLR: [CFL-] Functions have been routed successfully.
igfx: @ (DBG) MLR: [CFL-] wrapReadAUX() Called with controller at 0xffffff802ca6e000 and framebuffer at 0xffffff81aa5a3000.
igfx: @ (DBG) MLR: [COMM] orgReadAUX() Routed to CFL IMP with Address = 0x0; Length = 16.
igfx: @ (DBG) MLR: [COMM] GetFBIndex() Port at 0x0; Framebuffer at 0xffffff81aa5a3000.
igfx: @ (DBG) MLR: [COMM] wrapReadAUX() Will probe the maximum link rate from the table.
igfx: @ (DBG) MLR: [COMM] orgReadAUX() Routed to CFL IMP with Address = 0x700; Length = 1.
igfx: @ (DBG) MLR: [COMM] ProbeMaxLinkRate() Found eDP version 1.4+ (Value = 0x4).
igfx: @ (DBG) MLR: [COMM] orgReadAUX() Routed to CFL IMP with Address = 0x10; Length = 16.
igfx: @ (DBG) MLR: [COMM] ProbeMaxLinkRate() Table[0] =  8100; Link Rate = 1620000000; Decimal Value = 0x06.
igfx: @ (DBG) MLR: [COMM] ProbeMaxLinkRate() Table[1] = 10800; Link Rate = 2160000000; Decimal Value = 0x08.
igfx: @ (DBG) MLR: [COMM] ProbeMaxLinkRate() Table[2] = 12150; Link Rate = 2430000000; Decimal Value = 0x09.
igfx: @ (DBG) MLR: [COMM] ProbeMaxLinkRate() Table[3] = 13500; Link Rate = 2700000000; Decimal Value = 0x0a.
igfx: @ (DBG) MLR: [COMM] ProbeMaxLinkRate() Table[4] = 16200; Link Rate = 3240000000; Decimal Value = 0x0c.
igfx: @ (DBG) MLR: [COMM] ProbeMaxLinkRate() Table[5] = 21600; Link Rate = 4320000000; Decimal Value = 0x10.
igfx: @ (DBG) MLR: [COMM] ProbeMaxLinkRate() Table[6] = 27000; Link Rate = 5400000000; Decimal Value = 0x14.
igfx: @ (DBG) MLR: [COMM] ProbeMaxLinkRate() End of table.
igfx: @ (DBG) MLR: [COMM] wrapReadAUX() Maximum link rate 0x14 has been set in the DPCD buffer.
igfx: @ (DBG) MLR: [CFL-] wrapReadAUX() Called with controller at 0xffffff802ca6e000 and framebuffer at 0xffffff81aa5a3000.
igfx: @ (DBG) MLR: [COMM] orgReadAUX() Routed to CFL IMP with Address = 0x2200; Length = 16.
igfx: @ (DBG) MLR: [COMM] GetFBIndex() Port at 0x0; Framebuffer at 0xffffff81aa5a3000.
igfx: @ (DBG) MLR: [COMM] wrapReadAUX() Will use the maximum link rate specified by user or cached by the previous probe call.
igfx: @ (DBG) MLR: [COMM] wrapReadAUX() Maximum link rate 0x14 has been set in the DPCD buffer.

It's where it negotiates the speed, if it doesn't detect the right stuff we may have to tell it what speed to use. Shouldn't be too difficult to work that out. There are only a few settings to try; HBR, HBR2 and HBR3. Hopefully one of them does the trick. To get the logs all you need is to replace WEG with a debug version of it. The latest build from Dortania should be fine (plus -wegdbg boot flag) but I can also make a full debug EFI if needed where everything is compiled with debug flags.

I will also check my kernel log when using DP -> DP and those dpcd settings.

Circling back to rotation, have you tried it the flags all zero'd out? That should change both screens to external and maybe reveals al the options. Hot plug etc might break but just for testing out if setting the screen to external via flags does anything. Maybe the crashes and panics can be fixed another way. I had some troubles collecting the panic logs when I tried. Think I forgot some boot flag to store them on disk. I'm on the lookout for a mega cheap monitor with DP so I can test dual DP screens cuz with my current dual setup where one screen uses conversion is not very ideal for testing.

Everything should work without depending on 3rd party apps. My guess and hope is that we can sort things out out with flags and settings. I'm pretty sure the dpcd stuff is where the solution is at least for the b/w allocation and such. I forgot what exactly the difference was between hdmi20 and the max pixel setting but they did something in different areas yet resulting in the same making 4k work on some setups. It's somewhere in this thread lol.

There are some more WEG things to try but. Will check with a debug version if anything is needed. Like fixing dvmt if macOS doesn't calculate the right amount. The WEG FAQ is a bit messy but it does contain a lot of info. Lots of it hidden in spoilers like the above log example.

Will update once I done some tests here.

[zearp]

Hmm, for some reason I can't get WEG to output those things. I have both Lilu + WEG debug versions installed and added boot flags for both too. See a bunch of logs scroll by but can't find them in system logs? I must be missing something obvious here lol.

[zearp]

When I record the verbose boot I see the debug log entries pass by (igfx stuff) but I can't find them in the logs after booting. So weird. Maybe it's a Monterey thing. According to the WEG docs log show --predicate 'process == "kernel" AND (eventMessage CONTAINS "WhateverGreen" OR eventMessage CONTAINS "Lilu")' --style syslog --last boot --source should those messages but even with --info and --debug added I see nothing. I'll try with Big Sur too.

[zearp]

Ok, got it sorted. On Big sure and later it is no longer working and you need to add another boot flag liludump=30 that will create a file in /var/log/ called Lilu_1.5.5_21.0.txt which has all the juicy details. I noticed a lot of WEG errors though they might not be errors but the config it sees cuz later it sets those things up properly. Still interesting to see all the logs, also noticed something about force-online missing stuff. Which is funny cuz it does fix things on my old Philips screen, without it it stays off after waking up.

getOSData force-online-framebuffers was not found would imply we need to tell it where to enable but my guess is that it enable itself for all frame buffers when not set. Assuming is bad but I do it anyways haha. Not relevant for this anyways.

Oh, have you also tried without any of the fixes we use? Maybe all that was needed was to disable the unused framebuffer and none of the max pixel or dpcd fixes are actually needed. Either way, some stuff from the logs:

Lilu       api: @ (DBG) got load request from WhateverGreen (152)
WhateverGreen      init: @ (DBG) WhateverGreen bootstrap DBG-152-2021-07-19
WhateverGreen       rad: @ (DBG) not enabling CAIL_DisableDrmdmaPowerGating
WhateverGreen       rad: @ (DBG) not enabling CAIL_DisableGfxCGPowerGating
WhateverGreen       rad: @ (DBG) not enabling CAIL_DisableUVDPowerGating
WhateverGreen       rad: @ (DBG) not enabling CAIL_DisableVCEPowerGating
WhateverGreen       rad: @ (DBG) not enabling CAIL_DisableDynamicGfxMGPowerGating
WhateverGreen       rad: @ (DBG) not enabling CAIL_DisableGmcPowerGating
WhateverGreen       rad: @ (DBG) not enabling CAIL_DisableAcpPowerGating
WhateverGreen       rad: @ (DBG) not enabling CAIL_DisableSAMUPowerGating
WhateverGreen    unfair: @ (DBG) chosen shared cache path is /System/Library/dyld/dyld_shared_cache_x86_64h
WhateverGreen       weg: @ (DBG) non-apple-fw proceeding with devprops 1
WhateverGreen     iokit: @ (DBG) getOSData device-id has 412 value
WhateverGreen       weg: @ (DBG) IGPU has real 0412 acpi 0412 fake 0000 and model Intel HD Graphics 4600
WhateverGreen       weg: @ (DBG) adding missing model Intel HD Graphics 4600 from autotodetect
WhateverGreen       weg: @ (DBG) found existing built-in
WhateverGreen     iokit: @ (DBG) getOSData applbkl was not found
WhateverGreen       weg: @ (DBG) detecting policy
WhateverGreen       weg: @ (DBG) no external gpus
WhateverGreen     iokit: @ (DBG) getOSData framebuffer-patch-enable has 1 value
WhateverGreen      igfx: @ (DBG) framebuffer-patch-enable 1
WhateverGreen     iokit: @ (DBG) getOSData framebuffer-framebufferid was not found
WhateverGreen     iokit: @ (DBG) getOSData framebuffer-flags was not found
WhateverGreen     iokit: @ (DBG) getOSData framebuffer-camellia was not found
WhateverGreen     iokit: @ (DBG) getOSData framebuffer-mobile was not found
WhateverGreen     iokit: @ (DBG) getOSData framebuffer-pipecount was not found
WhateverGreen     iokit: @ (DBG) getOSData framebuffer-portcount has 2 value
WhateverGreen     iokit: @ (DBG) getOSData framebuffer-memorycount was not found
WhateverGreen     iokit: @ (DBG) getOSData framebuffer-stolenmem has 4000000 value
WhateverGreen     iokit: @ (DBG) getOSData framebuffer-fbmem has 3000000 value
WhateverGreen     iokit: @ (DBG) getOSData framebuffer-unifiedmem was not found
WhateverGreen     iokit: @ (DBG) getOSData framebuffer-cursormem was not found
WhateverGreen     iokit: @ (DBG) getOSData framebuffer-con0-enable has 1 value
WhateverGreen      igfx: @ (DBG) framebuffer-con0-enable 1
WhateverGreen     iokit: @ (DBG) getOSData framebuffer-con0-index was not found
WhateverGreen     iokit: @ (DBG) getOSData framebuffer-con0-busid was not found
WhateverGreen     iokit: @ (DBG) getOSData framebuffer-con0-pipe was not found
WhateverGreen     iokit: @ (DBG) getOSData framebuffer-con0-type was not found
WhateverGreen     iokit: @ (DBG) getOSData framebuffer-con0-flags was not found
WhateverGreen     iokit: @ (DBG) getOSData framebuffer-con1-enable has 1 value
WhateverGreen      igfx: @ (DBG) framebuffer-con1-enable 1
WhateverGreen     iokit: @ (DBG) getOSData framebuffer-con1-index was not found
WhateverGreen     iokit: @ (DBG) getOSData framebuffer-con1-busid was not found
WhateverGreen     iokit: @ (DBG) getOSData framebuffer-con1-pipe was not found
WhateverGreen     iokit: @ (DBG) getOSData framebuffer-con1-type was not found
WhateverGreen     iokit: @ (DBG) getOSData framebuffer-con1-flags was not found
WhateverGreen     iokit: @ (DBG) getOSData framebuffer-con2-enable was not found
WhateverGreen     iokit: @ (DBG) getOSData framebuffer-con3-enable was not found
WhateverGreen     iokit: @ (DBG) getOSData framebuffer-con4-enable was not found
WhateverGreen     iokit: @ (DBG) getOSData framebuffer-con5-enable was not found
WhateverGreen     iokit: @ (DBG) getOSData framebuffer-patch0-enable was not found
WhateverGreen     iokit: @ (DBG) getOSData dpcd-max-link-rate was not found
WhateverGreen      igfx: @ (DBG) MLR: No custom maximum link rate specified. Will probe the value automatically.
WhateverGreen     iokit: @ (DBG) getOSData rps-control was not found
WhateverGreen     iokit: @ (DBG) getOSData complete-modeset was not found
WhateverGreen     iokit: @ (DBG) getOSData force-online has 1 value
WhateverGreen       weg: @ (DBG) force online overriden by device property 1
WhateverGreen     iokit: @ (DBG) getOSData force-online-framebuffers was not found
WhateverGreen     iokit: @ (DBG) getOSData igfxpavp was not found
WhateverGreen     iokit: @ (DBG) getOSData max-pixel-clock-frequency was not found
WhateverGreen      igfx: @ (DBG) FCA: Enabled = 1.
WhateverGreen      igfx: @ (DBG) RRS: Enabled = 0.
WhateverGreen      igfx: @ (DBG) RWS: Enabled = 0.
WhateverGreen    unfair: @ (DBG) disabling unfair gva due to missing boot argument
WhateverGreen       weg: @ (DBG) vinfo 1: 1080:1920 32:7680:1
WhateverGreen       weg: @ (DBG) vinfo 2:  67:240 7680:1:0
WhateverGreen      igfx: @ (DBG) MLR: Found CFL- platforms. Will setup the fix for the CFL- graphics driver.
WhateverGreen      igfx: @ MLR: [CFL-] Failed to route functions.
WhateverGreen      igfx: @ FOD: Failed to route the function getDisplayStatus.
WhateverGreen      igfx: @ (DBG) platform is snb 0 and list 0xFFFFFF7FA5679070
WhateverGreen      igfx: @ (DBG) patching framebufferId 0x0D220003
WhateverGreen      igfx: @ (DBG) mobile: 0x00000000
WhateverGreen      igfx: @ (DBG) pipeCount: 3
WhateverGreen      igfx: @ (DBG) portCount: 2
WhateverGreen      igfx: @ (DBG) fbMemoryCount: 3
WhateverGreen      igfx: @ (DBG) stolenMemorySize: 0x04000000
WhateverGreen      igfx: @ (DBG) framebufferMemorySize: 0x03000000
WhateverGreen      igfx: @ (DBG) unifiedMemorySize: 0x60000000
WhateverGreen      igfx: @ (DBG) patching framebufferId 0x0D220003 connector [2] busId: 0x04, pipe: 10, type: 0x00000400, flags: 0x00000010
WhateverGreen      igfx: @ (DBG) patching framebufferId 0x0D220003 connector [3] busId: 0x06, pipe: 8, type: 0x00000400, flags: 0x00000010
WhateverGreen      igfx: @ (DBG) patching framebufferId 0x0D220003 successful
WhateverGreen      igfx: @ (DBG) MPC: Changing max pixel clock from 360000000 Hz to 675000000 Hz
WhateverGreen      igfx: @ (DBG) MPC: Changing max pixel clock from 270000000 Hz to 675000000 Hz

My take away form this log, I have max pixel clock enabled and at the end it does seem to change things from the defaults. Not sure if this is all thats needed to fix 4k. right before that we see it patches the connectors without errors.

It complains about a lot of "missing" entries but my guess is those are optional, else it would be mentioned in the docs. I know some require you to tell it which frame buffers to patch but we don't need those patches (lspcon).

But the DP stuff is very limited, I don't see nearly as much as the example output form the docs.

WhateverGreen     iokit: @ (DBG) getOSData dpcd-max-link-rate was not found
WhateverGreen      igfx: @ (DBG) MLR: No custom maximum link rate specified. Will probe the value automatically.

Thats all it shows, I see no results of the actual probing and maybe it doesn't matter. Will try with 0x14 set as thats needed for 4k and see if there's any more in the logs.

[zearp]

I can now see an extra entry but the probing itself is not visible for me. Not sure why.

WhateverGreen      igfx: @ (DBG) MLR: Found a valid custom maximum link rate value 0x14.

This may be due to Big Sur too. Not sure, Apple did lock down a lot of things so maybe certain debug things don't work anymore?

With the Framebuffer below I am able to select 4k resolution on my dummy. This is with the DP display connected to DP2 and the dummy to DP1. Surprisingly I can even set it to 120hz on lower resolutions.

I leave the bit that fixes the crashes on cuz I also don't need audio and I don't think they would influence this at all. I will see if I can get some panic logs later and maybe try to fix that, but 4k has priority haha.

I will try disabling the fixes and see when I can no longer set a 4k resolution. I am doing this on Monterey but it shouldn't matter, you might get better logs on Catalina.

[zearp]

Judging by the size difference it looks like 4k to me. Quite a lot of extra desktop space, too bad its only a dummy 😁

[zearp]

Interesting, with enable-dpcd-max-link-rate-fix disabled I can no longer set 4k resolutions. The max pixel clock override might still be needed, I will test that out now.

[zearp]

Both are needed. Without max pixel clock override I only get 1 working screen, which might be due to me using conversion. Hopefully this means that 4k now works on any macOS by using these new options and leaving hdmi20 disabled. I might remove it in the config and also add the new options the config on the repo.

[mgrimace]

Circling back to rotation, have you tried it the flags all zero'd out? That should change both screens to external and maybe reveals al the options.

Well this is odd. tl;dr changing flags to anything but 10000000 resulted in no video output whatsoever on either screen (using "working" 4k config as described in my post above).

What I did (and I haven't looked at flags in a while so I could be entirely wrong!)

Right now we have the following flags:

con1: 02040A00 00040000 10000000 con2: 03060800 00040000 10000000

My understanding is that the 10000000 are the flags, and that the "original" flags given our platformID should be 87000000 right? So I did two test flag changes:

Test 1 using proper/original flags (no other changes) con1: 02040A00 00040000 87000000 con2: 03060800 00040000 87000000

Result 1 - no video output (boots through verbose mode to apple logo load screen, apple logo is huge, then no output thereafter = black screens)

Test 2 changed flags to zeros (which is what I assumed you meant but zeroing out flags) con1: 02040A00 00040000 00000000 con2: 03060800 00040000 00000000

Result 2 - same; no video output (boots through verbose mode to apple logo load screen, apple logo is huge, then no output thereafter = black screens)

[zearp]

Thanks for those tests. Sounds pretty weird with the blown up Apple logo. Could it be a power down might be needed? I was just messing around with this to help someone who opened an issue here and had to power down after hot-plugging too much as it wasn't doing anything anymore (it also didn't crash, screen sharing works).

Either way, 87 with the bit set that sorts out the crashes would become 97. You can use Hackintool to see the flags and what changes with certain options enabled/disabled. Also makes it easy to compare them.

There are also flags on another page but they don't seem to produce any changes if you would to generate a patch. I just use it to see what kind of stuff each flag enables/disables on the connector page.

[zearp]

Lol, with 97 set my Philips screen is blinking on/off with that old school analog tv noise for about 5 times before it shows the login screen just fine. Never had that before.

These flags are the biggest mystery so far. Might have to call in Mulder and Scully.