Jump to content
1504 posts in this topic

Recommended Posts

Quick update, I have tried with more parameters :

 

plist-try-more-values.png

 

But without success. I'm getting artifacts at the end of the boot process (in the verbose command), then a timeout in IGPU. The GUI doesn't start.

 

This is how my BIOS looks like :

 

biosTrigkeyIGPU.jpg

Edited by frankynov

Hi everyone,

 

I have made a new attempt, using new values and more complete in the DeviceProperties based on some recommendations :

 

newattempt-igfx-values.png

 

But unfortunately this didn't help a lot, but changed some things.
Now, instead of being stuck at the verbose screen, the external HDMI monitor turns black.

I can connect to the machine via RDP and here is what I can see now via the remote connection :

 

--> No more red line in the connectors tab in Hackintools (but no screen seems to be detected at all in the hardware report)

 

trigkey-patch-wip.png

 

trigkey-vram.png

 

We can see also that the VRAM is no longer 7Mb. But in the remote session, I can't detect any video acceleration (dock still opaque and Maps not displaying anything). And of course, HDMI port doesn't broadcast a signal.

 

Any idea ? :)

 

Thanks !

@frankynov Please post your config.plist when asking for help.  A couple of things I noticed:

 

  1. You don't need to define device-id in your DeviceProperties.  It is detected (and supported) automatically)
  2. The trigkey S1 mini that I looked at (there may be multiple versions) has HDMI ports, but the framebuffer you are using (3EA50009) defines the following connector types:
    1. LVDS
    2. DP
    3. DP

      Have you tried setting the type of con0 to HDMI?  What are your video connectors on your PC?
  3. Assuming that you don't have an LVDS connector on con0, you will need to change con0's connector type and possibly its index and busID.  Take a look at my framebuffer patching lessons learned here and here.
  4. You don't need to define hda-gfx = onboard1 in your DeviceProperties.  AppleALC.kext does this for you.
  5. You may need to revise the connector flags.   Try the flags that I include in my EFI attached here.
  6. I would recommend that you don't add igfxfw to your DeviceProperties until after you have working graphics.
  7. You may need to add boot-arg -disablegfxfirmware until your graphics patches are working
  8. You may need to try other framebuffers (AAPL,ig-platform-id). See my test results for my rig here.  3EA50009 didn't work for me.
Edited by deeveedee
18 minutes ago, deeveedee said:

@frankynov Please post your config.plist when asking for help.  A couple of things I noticed:

 

  1. You don't need to define device-id in your DeviceProperties.  It is detected (and supported) automatically)
  2. The trigkey S1 mini that I looked at (there may be multiple versions) has HDMI ports, but the framebuffer you are using (3EA50009) defines the following connector types:
    1. LVDS
    2. DP
    3. DP

      Have you tried setting the type of con0 to HDMI?  What are your video connectors on your PC?
  3. Assuming that you don't have an LVDS connector on con0, you will need to change con0's connector type and possibly its index and busID.  Take a look at my framebuffer patching lessons learned here and here.
  4. You don't need to define hda-gfx = onboard1 in your DeviceProperties.  AppleALC.kext does this for you.
  5. You may need to revise the connector flags.   Try the flags that I include in my EFI attached here.
  6. I would recommend that you don't add igfxfw to your DeviceProperties until after you have working graphics.
  7. You may need to add boot-arg -disablegfxfirmware until your graphics patches are working

 

Hi Deeveedee,

 

Thanks for your answer, that's a lot to process :)

I have performed a couple of changes to the config plist file, now using the Macmini8,1. Please see the file attached. I now only have the AAPL,ig-platform-id & device-id.

Regarding your point 1), actually if I do not define device-id, I'm stuck in verbose mode and the GUI doesn't start. Putting it to 3EA50000 allows to see the GUI but without the acceleration. I can now boot without the -igfxvesa option.

 

Quote

Have you tried setting the type of con0 to HDMI?  What are your video connectors on your PC?

 

I'm not actually sure how to set type to con0. There are two HDMI ports on the machine, the one next to the power supply is the one giving signal (other doesn't seem to give any in macos).

Point 3) --> Ok I'll read it multiple times and try to understand, that's kinda very low level patching we are doing here :)

4) Ok, removed

5) Will try later today !

6) Ok, removed

7) Added in the boot-arg.

 

Thanks already for your time, really appreciate !

 

config.plist

@frankynov I tried viewing your config.plist, but it seems to be corrupted.  If you are using SMBIOS model MacMini8,1 (good choice), then you may want to experiment with other framebuffers.  See the last bullet that I added in my previous post.

 

EDIT: @frankynov If you can't boot without device-id, something else is wrong with your config.plist.  The device-id your are specifying (0x3ea5) is your CPUs native device-id.   It is detected automatically and is a supported device-id as noted here.  Always use OpenCore's ocvalidate in the Utilities folder (in the version of OpenCore you download) to check your config.plist for errors before testing.

Edited by deeveedee
2 minutes ago, deeveedee said:

@frankynov I tried viewing your config.plist, but it seems to be corrupted.  If you are using SMBIOS model MacMini8,1 (good choice), then you may want to experiment with other framebuffers.  See the last bullet that I added in my previous post.

 

Sorry for the file, I had edited out the serial numbers, it should be good now in the one below (I'll anyway use different serials once all is good) :)

config.plist

@frankynov The device-id in your config.plist is invalid.  <3EA50000> should be <A53E0000> (Little Endian / Reverse Byte Order).  When you specify an invalid device-id, your "voiding" your graphics patches.  Remove the device-id and review my other suggestions.

@deeveedee Ok thanks.
I'll start preparing the stuff.

So as a starting point I have taken this info from the WEG manual for my platform :

 

ID: 3EA50009, STOLEN: 57 MB, FBMEM: 0 bytes, VRAM: 1536 MB, Flags: 0x00830B0A
TOTAL STOLEN: 58 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 172 MB, MAX OVERALL: 173 MB (181940224 bytes)
Model name: Intel HD Graphics CFL CRB
Camellia: CamelliaV3 (3), Freq: 0 Hz, FreqMax: 0 Hz
Mobile: 1, PipeCount: 3, PortCount: 3, FBMemoryCount: 3

 

And built a table here. Now I have to try and discover what to patch with what :)

 

Spoiler
[0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000098 - ConnectorLVDS
00000800 02000000 98000000
Bit 	Name 	Value
Bit 1	Port	00
Bit 2	Bus ID	00
Bit 3-4	Pipe Number	0800
Bit 5-8	Connector Type	02000000
Bit 9-12	Flags	98000000

[1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x000001C7 - ConnectorDP
01050900 00040000 C7010000
Bit 	Name 	Value
Bit 1	Port	01
Bit 2	Bus ID	05
Bit 3-4	Pipe Number	0900
Bit 5-8	Connector Type	00040000
Bit 9-12	Flags	C7010000

[2] busId: 0x04, pipe: 10, type: 0x00000400, flags: 0x000001C7 - ConnectorDP
02040A00 00040000 C7010000
Bit 	Name 	Value
Bit 1	Port	02
Bit 2	Bus ID	04
Bit 3-4	Pipe Number	0A00
Bit 5-8	Connector Type	00040000
Bit 9-12	Flags	C7010000

 

1246836046_Capturedecran2023-04-17a15_25_12.png.815de992461e215e80c94cd2a6d6159c.png

 

@frankynov  As you can see here, framebuffer 3ea50009 didn't work for me (and I am using SMBIOS model MacMini8,1).  I needed to use a mobile framebuffer that ended in 0.  I chose 3e920000.

5 hours ago, deeveedee said:

@frankynov  As you can see here, framebuffer 3ea50009 didn't work for me (and I am using SMBIOS model MacMini8,1).  I needed to use a mobile framebuffer that ended in 0.  I chose 3e920000.

Got it, thanks, I have two candidates I can use I think : 3EA50000 and 3EA50004 - which is the one that seems to be used in the Intel NUC using the same CPU.

So this is what I extracted from the doc with 3EA50000

 

 3EA50000.thumb.png.0eb705e4fd09a9575b8497c7301ec11f.png

 

As I understand, the connectors are defined as LVDS/EDP, Display Port, Display Port.

How do you suggest to proceed with the tests ? 

I was thinking to "force" all the ports to be set to HDMI output (0008 0000).

But the first port bus ID is set to 00, does it mean it is never activated ?

If so, I need to increment the bus ID until I find a signal ?

In my example for the first con0 : 

 

00000800 00080000 98000000

01000800 00080000 98000000

02000800 00080000 98000000

03000800 00080000 98000000

04000800 00080000 98000000

05000800 00080000 98000000

06000800 00080000 98000000

 

And I reboot at each try, then try to do the same on the 2 remaining ports ?

I just need to do the patch on the actual HDMI connector but I have no idea which one it is ! 😄

 

Again, thanks a lot for your time and explanations, I think I'm starting to get the point of all of it.

 

@frankynov You don't need to feel constrained by the 3ea5 device-id.  The 3e920000 framebuffer that I suggested is an equally good candidate.  I didn't have success with any framebuffers that didn't end in 0.  You need to patiently test with each framebuffer value like I indicate in the links posted in my previous posts.  If you are able to map your physical video ports to the logical con0, con1, con2 in DeviceProperties, that will make your job much easier (since you know what ports are affected by your changes).  That's going to require potentially tedious trial and error that I can't spare you.

 

With my previous posts and using my MacMini8,1 thread as a reference, you now have enough info to conduct your experiments.  Just be patient.  Good luck!

13 minutes ago, deeveedee said:

@frankynov You don't need to feel constrained by the 3ea5 device-id.  The 3e920000 framebuffer that I suggested is an equally good candidate.  I didn't have success with any framebuffers that didn't end in 0.  You need to patiently test with each framebuffer value like I indicate in the links posted in my previous posts.  If you are able to map your physical video ports to the logical con0, con1, con2 in DeviceProperties, that will make your job much easier (since you know what ports are affected by your changes).  That's going to require potentially tedious trial and error that I can't spare you.

 

With my previous posts and using my MacMini8,1 thread as a reference, you now have enough info to conduct your experiments.  Just be patient.  Good luck!

 

Perfect, thanks a lot. I'll report back once I have it working - gonna be in a few days as I will be AFK for a while. Again, thank you for your patience !

  • 2 weeks later...
Is the backlight-registers-fix broken on 13.4 beta 2? Both my laptops now have like a 2 minute delay before showing anything on internal monitors.


Sent from my iPhone using Tapatalk

Now Beta 3 same issue. Any resolution?


Sent from my iPhone using Tapatalk
  • 4 weeks later...

I have the same issue with my Dell (Intel 8th), my laptops have like a 2/3 minutes delay before showing anything on internal monitors.

 

To solve the problem more quickly, close the cover in the login screen... wait for sleep mode, then reopen it.

Despite my research I haven't found a solution yet. 

 

 

 

 

  • 8 months later...

Hi,

 

I am trying to understand the use of Whatevergreen when using a system with headless iGPU and dGPU.

 

My setup: Ventura on Z170X UD5, i7-6700K spoofed as KabyLake, Radeon RX 480.  Installed via Open Core using symbios 18.3.

 

For a while Hackintool was showing hardware decode disabled.  Then I used Hackintool to apply patch to spoof iGPU id and to set framebuffer. The result was

 

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>PciRoot(0x0)/Pci(0x2,0x0)</key>
    <dict>
        <key>AAPL,ig-platform-id</key>
        <data>AwASWQ==</data>
        <key>AAPL,slot-name</key>
        <string>Internal@0,2,0</string>
        <key>device-id</key>
        <data>ElkAAA==</data>
        <key>device_type</key>
        <string>Display controller</string>
        <key>framebuffer-patch-enable</key>
        <data>AQAAAA==</data>
        <key>hda-gfx</key>
        <string>onboard-2</string>
        <key>model</key>
        <string>Intel HD Graphics 530</string>
    </dict>
</dict>
</plist>

 

Now Hackintool shows as seen in attached:

 

I am not sure if I was really supposed to do this, as I read that headless iGPU doesn't require framebuffer patch.

 

Have I really achieved what best fits my use case? In my case, here is what is important:

 

4K editing in FCP.  I want dGPU to be used maximally and if it can't handle some task then I would like the iGPU.  I edit in ProRes or ProRes proxies then export to H264, H265.  So I need my setup optimized for that.


I went down a DRM rabbit hole after seeing that Hackintool was showing disabled VDA decoder. Now that I got it enabled I am just wondering if it wasn't important in the first place. Editing in FCP is 10000 times more important to me than DRM.

 

Any tips appreciated!

 

thanks

Screenshot 2024-02-08 at 18.19.26.png

16 hours ago, pkdesign said:

I wish I could understand how not to use WEG. Every time I disable it my system will not work.

1. You have to use SMBIOS with the same Graphics card. For example 

iMacPro1,1 -> Vega 56

iMac18.2 -> RX560

iMac18,3, iMac19,1 ->RX570/RX580

iMac20,2 -> RX5700

or use BoardID not same as ProductName.

2. Sometimes  Clover setting RadeonDeInit do the work.

3. Choose a port. I got a card flashed for mining. Only DP1 was working. I reflashed modern VBIOS and got all 4 ports are working DVI, HDMI, DP1, DP2.

4. Since Ventura you may disable iGPU.

 

WhateverGreen may disable pink lines on startup screen but it is not a good patch. These lines is just video memory test. Not more.

  • Like 2
  • 1 month later...

I thought Ventura and Sonoma can work without WEG only when using iMacPro or MacPro SMBIOS and that iMac always needed WEG. But @Slice said in a previous post that he has iMac without WEG.


On my system, graphics only work fine without WEG with iMacPro or MacPro SMBIOS. If I put iMac SMBIOS and remove WEG, graphics don't work well.

 

Answering @AslashA if you use only the AMD (iGPU doesn't exist or is disabled in BIOS) WEG has none or few advantages. Every user having AMD as main card and iGPU as headless mode card needs WEG.

 

Edited by miliuco
  • Like 2
  • 1 month later...

I believe I have an example of a Radeon Graphics card that will not work in Sonoma without WEG.  See here. This particular RX560x needs a connector patch and unless I'm mistaken, this requires WEG (unless you create your own kext to perform the framebuffer patching).

 

EDIT: I did test my hack with SMBIOS iMac18,2 and without WhateverGreen.kext (using boot-arg -no_compat_check to boot Sonoma).  The result is no display.  The only way that I have been able to have working RX560x graphics on my hack is with WhateverGreen.kext to implement a connector patch.

 

EDIT2: I learned that iMac19,2 offers an option with RX560x.  I tested SMBIOS iMac19,2 on my hack without WEG, but still no display.  Even with SMBIOS iMac19,2, I must use WEG to modify the Radeon connector definition.

Edited by deeveedee
  • Like 1
×
×
  • Create New...