Hervé

DW1550 is based on BCM4352. Just follow the usual patching process. It's not supported OOB.

@Jorge1964, you need to use a supported wireless card. Please refer to our FAQ and R&D->Wireless section where you'll see references of supported models. Yours is not, as long been indicated in our published inventories and needs to be replaced.

Start afresh bu following Dortania's guide for Comet Lake laptops: https://dortania.github.io/OpenCore-Install-Guide/config-laptop.plist/coffee-lake-plus.html

Try the darwake boot arg, with its various values: darkwake=no/0/1/2/3/4/8/10

It'd be nice to consult the guides posted here to begin with.

Look up my E7250 guide and grab the PS2 controller kext from there. It's good old DrHurt's R6 for Alps hardware and it works perfectly on the E7x50 without the issue you mentioned. Can't see why you'd encounter such issue with wake. Make sure you've got the right CPU power management settings in place and hibernation disable (see our FAQ section if necessary). Of course, no kext or anything specific for Sleep & Wake apart from disabling hibernation. Lastly, configure your BIOS parameters as per the posted recommended settings. That about all we can say in the absence of any troubleshooting/debugging material from your part.

E5430 is Ivy Bridge, quite similar to E6x30 laptops. SMBIOS MacBookPro9,2 or MacBookPro10,2 required. I’d be surprised if we did not have existing boot packs somewhere on the forum.

Basic macOS functionalities... Use your Keyboard PrefPane to swap keys (like Option & Command).

What have you tried and achieved so far?

I don't recall ever creating a patched DSDT for an E6430; if you're using my E6230's patched DSDT on an E6430, don't be surprised to encounter issues. We've never recommended nor advocated using any given patched DSDT on a different computer model...

Try an post an IOReg when you boot your PixelBook with an inappropriate framebuffer value.

You're only seeing 8MB VRAM because you still do not have full graphics acceleration. Once you've sussed out the correct settings, VRAM will be automatically set to something like 1536MB. Post a zipped copy of your EFI folder.

iGPU device-id and framebuffer platform-id are 2 x seperate things and you do not derive latter from former. See WEG's manual.

Unless I'm mistaken, I saw iMac18,1 SMBIOS in your config file. That would obviously be quite wrong given that this was a Kaby Lake desktop Mac (granted it was fitted with i5-7360U mobile CPU) with Intel Iris Plus 640 graphics. What you really ought to use is MacBook10,1 SMBIOS, i.e. the profile of those mid-2017 last little MacBooks fitted with similar CPUs (i5-7Y54 & i7-7Y75) and Intel HD615 graphics. Regarding graphics, I believe you should use KBL framebuffer id 0x591e0000 or 0x591e0001, specified in reverse byte order. In your OC (or Clover) config, you'd therefore inject these as follows: AAPL,ig-platform-id 00001E59 DATA or AAPL,ig-platform-id 01001E59 DATA This is what is recommended as per Clover's and WEG's own documentation: https://github.com/acidanthera/WhateverGreen/blob/master/Manual/FAQ.IntelHD.en.md ID: 591E0000, 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 ID: 591E0001, STOLEN: 38 MB, FBMEM: 0 bytes, VRAM: 1536 MB, Flags: 0x002B0702 TOTAL STOLEN: 39 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 115 MB, MAX OVERALL: 116 MB (122171392 bytes) Model name: Intel HD Graphics 615 Camellia: CamelliaV2 (2), 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: 0x00000181 - ConnectorDP [2] busId: 0x04, pipe: 10, type: 0x00000400, flags: 0x00000181 - ConnectorDP 00000800 02000000 98000000 01050900 00040000 81010000 02040A00 00040000 81010000 If not, well, you'd have to experiment with other KBL framebuffer ids.

Congratulations. Now read what's written on the label (concentrate your attention on the top right corner) and head over to our Technical Info->Wifi forum section. Thank you.

RTC-related CMOS reset maybe. There is an OC NVRAM parameter that was developed to that effect after Catalina 10.15.4 was released. You may want to give it a try... Or check any RTC-related parameter you may have in your current config.

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- /!\ Big Sur, Monterey and Ventura /!\ -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Big Sur dropped support for Broadcom BCM4331 and BCM43324 which results in the disappearance of AirPortBrcm4360 kext! This basically extended death to DW1820A when using the solution detailed above. A 1st workaround is to call on a patched version of Catalina's IO80211Family kext where only AirPortBrcm4360 has been retained as PlugIn. See here for details. With OpenCore, the patched kext can be placed in the OC kexts folder and added to the list of add-on kexts in the OC config. Add minimum kernel set to 20 if the config is also used for previous macOS version(s). IO80211Catalina.kext.zip A 2nd workaround is to call on Acidanthera's AirportBrcmFixup kext (its injectors are not required/used) + injecting compatibility with pci14e4,43ba (BCM43602) or pci14e4,43a0 (BCM4360). This was tested and verified under OpenCore by enabling only the parent kext of the fixup kext v2.1.2 and leaving both of its injector PlugIns disabled. The adjusted IOProbeScore value of the Fixup kext seems to be the key here. Others (it was my case) will find that, in Big Sur and later, injecting compatibility with pci14e4,43a0 (Broadcom BCM4360) + disabling ASPM does suffice.

Be happy: no dGPU listed so it'd be fair to say it's properly disabled.

In IORegistryExplorer, do File->SaveAs and save the IOREg output to a file. Zip it and post it; we'll look at it. In a laptop, the dGPU is normally located at IO address 0x00010000 on the PCIe bus, so you'd have a device looking like <XXXX@1> in the tree (eg: GFX0@1).

Check dGPU status in IOReg with IORegistryExplorer app; maybe it's still enabled, in which case, it'll eat up battery.

In theory, yes. In my own experience, the bootpack remains the same for both macOS versions. Just make sure to use the latest versions of the add-on kexts (eg: Lilu, WEG, etc.).

Re: brightness control, you should have it as long as you inject the SSDT-PNLF ACPI table. By default, the expected keyboard shortcuts won't work (but other key combinations will) until you add the SSDT-BRT6 ACPI table that was developed by Jake Lo as an alternative to DSDT patching (as described in my E6230 or 7490 guide for instance). You can look it up through a forum Search. Re: wireless, it all depends on the card fitted to your laptop. We've no crystall ball... Consult our R&D->Wireless section and its inventories for guidance.

Pentium G4560 is fitted with unsupported HD 610 iGPU; as such, you can forget about it and you should remove your properties injection trying to get the iGPU supported as HD 630. It's useless. It looks like you're mixing Clover drivers with OC drivers (eg: SMCHelper, used for FakeSMC). Why? This is most likely incorrect and I can only suggest you refrain from doing this. You're injecting NullCPUPowerManagement; not sure you need this. No Booter quirks at all, that's definitely wrong. I suggest you start at the beginning and read Dortania's OpenCore documentation! https://dortania.github.io/OpenCore-Install-Guide/

No. Yes.

Quite a challenge to understand what you're trying to say or provide a suitable answer with such vagueness but I can tell you this: Location Services utility needs wireless to be working because, in the absence of a built-in GPS in a Mac, the IP@ of the wireless interface is used to locate the host. It does not use the IP@ assigned to the LAN interface. Afaik, there is no workaround.