-
Posts
10013 -
Joined
-
Last visited
-
Days Won
560
Content Type
Profiles
Articles, News and Tips
Forums
Everything posted by Hervé
-
Conditional ACPI patching for OS X?
Hervé replied to Lost-Entrepreneur439's topic in DSDT/SSDT patching
Simply apply your patch under the condition of booting/running Mac OS X/OS X/macOS, i.e.: If (_OSI ("Darwin")) { // your patch here } or If (_OSI ("Darwin")) { // your patch here } Else { // original ACPI code } -
Released May 13th, 2024. Build 23F79 Enhancements, bug fixes ans security updates. Safe to install on our Hackintosh platforms. No changes compared to Sonoma 14.4 (see dedicated update article), i.e. no kexts update for wireless services required this time. Also released at the same time: macOS Ventura Security Update 13.6.7 (Build 22G720) macOS Monterey Security Update 12.7.5 (Build 21H1222) View full article
-
[Solved] DW1560: Bluetooth support in Monterey?
Hervé replied to Akv's topic in Wireless & Bluetooth
Sorry, I've no idea what you did. You're gonna have to be a lot more specific. You've not even specified what you use in terms of bootloaders. -
[Solved] DW1560: Bluetooth support in Monterey?
Hervé replied to Akv's topic in Wireless & Bluetooth
See here and use the latest versions of the kexts mentioned in the thread: https://osxlatitude.com/forums/topic/13140-solved-dw1560-bluetooth-stopped-working -
The GPU...
-
Latitude E6400: Unable to boot with OpenCore and SSDTs only
Hervé replied to CattaRappa's topic in E6xxx
If you want to consider a suitable build with SSDTs only, I suggest you post the raw/vanilla DSDT extracted from BIOS and the patched one. We'll then be able to examine the differences between them and suggest SSDT alternatives to the patched DSDT. -
Latitude E6400: Unable to boot with OpenCore and SSDTs only
Hervé replied to CattaRappa's topic in E6xxx
I wouldn't bother to try and use OpenCore or follow the Dortania guidance for an old C2D laptop. OpenCore has no proper support for CPU power management on these platforms. Stick to Clover, knowing that using SSDTs only is not restricted to OpenCore at all and can of course be used with other bootloaders such as Clover. -
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.
-
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.
-
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.
-
Try with SecureBootModel set to disabled.
-
[Solved] Intel wifi does not work in Sonoma
Hervé replied to ZainAnjum's topic in Wireless & Bluetooth
https://github.com/OpenIntelWireless/itlwm/releases Grab the alpha version labeled Sonoma14.4 if that's the macOS version you're running. -
Latitude 5490: No sleep when laptop runs on mains (Monterey)
Hervé replied to bezik46's topic in 5000 Series
Ok, you meant Sleep when on mains/AC. What are your sleep settings? Did you disable hibernation? -
Latitude 5490: No sleep when laptop runs on mains (Monterey)
Hervé replied to bezik46's topic in 5000 Series
Sleep on power ? -
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.
-
If you're using OpenCore that's normal. Only Clover or Chameleon apply ACPI patches at macOS level only by default.
-
Dell Inspiron N5040: Several issues with High Sierra
Hervé replied to Lost-Entrepreneur439's topic in Other Dell laptops
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/ -
Feel free to make one up if you cannot find any existing one.
-
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)
-
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.
-
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