Jump to content

Hervé

Administrators
 View Profile  See their activity

  • Posts

    9899

  • Joined

  • Last visited

  • Days Won

    548

Hervé last won the day on April 9

Hervé had the most liked content!

67 Followers

See all followers

About Hervé

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Hervé's Achievements

Brigadier General

Brigadier General (17/17)

1.2k

Reputation

27

Community Answers

  1. Hervé
    It's just a matter of framebuffer and matching of connectors with physical outputs. On rare occasions, certain outputs may not work at all. Patching the HDMI port to type 00080000 is only required to gain HDMI output, it's not required for video output. All I can suggest is that you experiment with the various CFL/CML framebuffers and check them all out for HDMI output.
  2. Hervé
    That's entirely cosmetic and bears no influence on your Hackintosh. Furthermore, it probably only appears in an add-on application such as About this Hack. If you want the proper CPU model to be reported, inject its CPUID in your OC config.
  3. Hervé
    Seems your HP 400 G6 is fitted with a Comet Lake CPU given that the reported iGPU id is 0x9BC8. It's a desktop platform, yet you use mobile framebuffer 0x3E9B0000 which natively defines the following 3 ports: [0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000098 - ConnectorLVDS [1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x00000187 - ConnectorDP [2] busId: 0x04, pipe: 10, type: 0x00000400, flags: 0x00000187 - ConnectorDP 00000800 02000000 98000000 01050900 00040000 87010000 02040A00 00040000 87010000 This is not suitable given that 1st output port (i.e. connector con0) is defines as an LVDS port. DP output appears to attach to 2nd connector con1 in your IOReg. I would suggest you opt for the desktop framebuffer recommended in the WEG user Manuel, i.e. 0x3E9B0007 which defines the following 3 ports: [1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x000003C7 - ConnectorDP [2] busId: 0x04, pipe: 10, type: 0x00000400, flags: 0x000003C7 - ConnectorDP [3] busId: 0x06, pipe: 8, type: 0x00000400, flags: 0x000003C7 - ConnectorDP 01050900 00040000 C7030000 02040A00 00040000 C7030000 03060800 00040000 C7030000 This should give you a better chance to obtain DP + HDMI output. If you do, identify which connector is DP and which connector is HDMI so that you may patch the HDMI one accordingly (i.e. set its type to 00080000) should you wish to enjoy HDMI audio. You may also want to switch SMBIOS from iMac20,1 to MacMini8,1.
  4. Hervé
    Try with SecureBootModel set to disabled.
  5. Hervé
    https://github.com/OpenIntelWireless/itlwm/releases Grab the alpha version labeled Sonoma14.4 if that's the macOS version you're running.
  6. Hervé
    You're probably using an unsuitable kext for your TouchPad. Identify your model. Check what's available in existing bootpacks for your laptop model, similar ones or models with similar TouchPads.
  7. Hervé
    Ok, you meant Sleep when on mains/AC. What are your sleep settings? Did you disable hibernation?
  8. Hervé
    Sleep on power ?
  9. Hervé
    Ok, so dGPU remains disabled on warm reboots from macOS into Windows. There are only a few ways to address this: you opt for the boor arg option rather than the patched ACPI code. you call on your EGPU ACPI code on macOS shutdown to re-enable the dGPU; that should be handled by an event that you need to identify. Maybe one of those EV methods. you power off your laptop when you want to boot Windows.
  10. Hervé
    If you're using OpenCore that's normal. Only Clover or Chameleon apply ACPI patches at macOS level only by default.
  11. Hervé
    You may want to consider switching to Clover on your Arrandale laptop. OpenCore does not provide adequate CPU power management for pre-Sandy Bridge CPUs whereas Chameleon/Clover do (Generation of C States/P States). This being said, if what you experience is instant wake on sleep, it usually is USB-ports related. As for lack of brightness control and black screen on wake, your SSDT-PNLF is probably unsuitable. You also need to have full graphics acceleration to be able to wake your laptop properly. Do you obtain it on this 1st gen HD model? If your model is not compatible, just forget it as a Hackintosh. https://www.insanelymac.com/forum/topic/286092-guide-1st-generation-intel-hd-graphics-qeci/
  12. Hervé
    Feel free to make one up if you cannot find any existing one.
  13. Hervé
    Released Mar 7th, 2024. Build 23E214 Enhancements, bug fixes ans security updates. Safe to install on our Hackintosh platforms. Note that it's important to update wireless kexts IO80211FamilyLegacy + IOSkywalkFamily to new versions tuned for Sonoma 14.4 (kexts used up to 14.3 no longer work). No wifi without those revised kexts. All details are available here in our dedicated thread on the matter. Also released at the same time: macOS Ventura Security Update 13.6.5 (build 22G621) macOS Monterey Security Update 12.7.4 (build 21H1123)
  14. Hervé

    macOS Sonoma is out

    Hervé posted an article in News

    Released Sep 26th, 2023 as announced. Version 14.0, build 23A344 (same as RC2 published Sep 21st). Sonoma drops official support for Kaby Lake platforms that remained supported in Ventura, Apple raising minimal requirements to Amber Lake and Coffee Lake platforms (with the exception of iMacPro1,1 as in Ventura). However, support for Kaby Lake graphics remain provided with all KBL kexts still present, this in order to ensure support for Amber Lake MacBookAir8,1. By extension, this means that graphics support for Skylake iGPUs can also be retained using those same KBL settings as used in Ventura. For other iGPUs, patches are available through OCLP tool to regain graphics acceleration. Officially supported Intel platforms are now limited to : iMac19,x (8th gen. Coffee Lake) iMacPro1,1 (Skylake Xeon) MacBookAir8,1 (8th gen. Amber Lake) MacBookPro15,x (8th gen. Coffee Lake) Macmini8,1 (8th gen Coffee Lake) MacPro7,1 (Cacade Lake) With Sonoma, Apple also dropped official support for what they call "legacy" Broadcom cards that remained supported up to Ventura. These include cards based on Broadcom BCM4350, BCM4360 or BCM43602 chipsets. If Bluetooth remains natively supported on such legacy cards, native Wifi support is now limited to those Apple proprietary Broadcom SOCs that have been fitted to the above Mac models. Support for "legacy" Broadcom cards can however be recovered with specific patching using OpenCore bootloader, kexts blocking and OCLP patches. Officially supported Broadcom SOCs include: BCM4355 (802.11ac): pci14e4,43dc (iMacPro1,1 + MacBookAir8,x) BCM4364 (802.11ac): pci14e4,4464 (Mac mini8,1 + MacBookPro15,x + MacBookPro16,x + iMac19,x + iMac20,x + MacPro7,1) BCM4377b (802.11ac): pci14e4,4488 (MacBookAir9,1) BCM4378 (802.11ax): Apple Silicon Mac models BCM4387 (802.11ax): Apple Silicon Mac models BCM4388 (802.11ax): Apple Silicon Mac models NB: macOS Big Sur is now officially unsupported.
  15. Hervé
    You now call upon KBL/ABL framebuffer 0x87C00000: ID: 87C00000, STOLEN: 34 MB, FBMEM: 0 bytes, VRAM: 1536 MB, Flags: 0x0000078B TOTAL STOLEN: 35 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 103 MB, MAX OVERALL: 104 MB (109588480 bytes) Model name: Intel HD Graphics KBL CRB 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: 0x00000098 - ConnectorLVDS [1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x00000187 - ConnectorDP [2] busId: 0x04, pipe: 10, type: 0x00000400, flags: 0x00000187 - ConnectorDP 00000800 02000000 98000000 01050900 00040000 87010000 02040A00 00040000 87010000 Your patches, as found in your posted Opencore config file: i.e. [0], busId: 0x00, pipe: 8, type: 0x00000200, flags: 0x00000098 - Connector Analog DVI [1], busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x00000187 - ConnectorDP [2], busId: 0x04, pipe: 10, type: 0x00000400, flags: 0x00000187 - ConnectorDP 00000800 00020000 98000000 --> analog DVI connector type 01050900 00040000 87010000 02040A00 00040000 87010000 Other than the strange patch of connector type 00020000 for con0 (which does not matter because con0 is not used, IOReg showing screen attached to con2), I fail to see the relevance of your other patches given that the values you inject are exactly the same as those natively defined in the framebuffer. As such, you most definitely do not patch any connector's pipe and you most definitely do not patch any property of the connector used for your LG TV. Since that you've now opted for a KBL/ABL framebuffer which attaches your screen to con2, why don't you just adjust con2's pipe to 0x12? framebuffer-patch-enable 1 NUMBER framebuffer-con2-enable 1 NUMBER framebuffer-con2-pipe 12000000 DATA
×
×
  • Create New...