Hervé

I'm not familiar with several of those patched SSDT tables you use. All I can suggest is that you compare with setups of other similar 5490 or 7490 posted on the forum.

Modernising this fairly old thread to update it for property injection with our beloved Clover/OpenCore bootloaders. As stated in the posts above, the alternative to DSDT patching (deprecated today), patched SSDT and/or kext patching (totally deprecated today and most difficult since Big Sur) is to simply inject the properties detailed above in the bootloader's config: identify card reader's location (with say IORegistryExplorer or bootloader's device detection) inject the compatible property as bare minimum, the rest being entirely optional and cosmetic Device: PciRoot(0x0,0x0)/Pci(0x--,0x--)[/Pci(0x--,0x--)] -> 3rd location may not be applicable Property: compatible pci14e4,16bc STRING -> mandatory AAPL,slot-name <specify your PCI slot here> STRING -> optional/cosmetic device_type <specify the device type here> STRING -> optional/cosmetic name <specify a device name here> STRING -> optional/cosmtic model <specify the model ref. here> STRING -> optional/cosmetic Clover example; under Devices section:

Yes, details of the necessary patch are posted in the thread dedicated to that matter; you'll find it in the Technical info/R&D -> Card readers section. It applies to all versions of OS X/macOS that the Sandy Bridge E6x30 laptops may run. Process could not be simpler: identify your card reader location in IOReg inject the necessary property in the Device Properties section of your bootloader's config For instance, if your card reader is under RP0x@1C,5->PXSX@0, your property patch would be: Device location: PciRoot(0x0)/Pci(0x1C,0x5)/Pci(0x0,0x0) Property key: compatible Property value: pci14e4,16bc Property type: STRING Do browse the forum and call on the forum Search facility for future inquiries.

It's supposed to... if you can get it out of AirPlane mode under macOS. See previous EM7455 thread in this particular section.

Could be result from all those power-related ACPI patches and patched SSDTs you' re using. Can't say I've seen or used them before on my Kaby Lake R/UHD620 Latitude 7490 when I had it. Why don't you try experimenting without those (SSDT-MethodS3-disable, SSDT-PTSWAKTTS and associated ACPI patches on the OC config)? I'm also surprised you run with MBP14,1 SMBIOS for that laptop, rather than MBP15,x.

Look at our WWAN section here for possible assistance re: WWAN module. But given the availability of data connection sharing on SmartPhones, I see very little use for WWAN modules these days; and these require a SIM card to be inserted in the laptop too.

No, VGA may somehow work (and only OOB) but feel free to knock yourself out at it!

macOS has had no official support for VGA since Ivy Bridge. Beyond Sandy Bridge (the last platforms for which Intel framebuffers connectors could be patched for VGA), the only platforms for which VGA is known to work properly (and OOB) for certain under macOS are Haswell laptops with HD4400 (not HD4600) graphics. For newer platforms (eg: Kaby Lake R laptops), VGA either works OOB -and sometimes only in mirroring/clone mode of another external screen- or not at all. There are no settings you can deploy to obtain VGA output per sé. Afaik, if VGA output does not work OOB, you'll never obtain it on your Skylake laptop. Here, you'll find details of the experiments I conducted several years ago with VGA output on a Kaby Lake R Latitude 7490, the analog port being available on a USB-c Dock, not as a built-in port of the laptop. Re: Bluetooth off your Intel AC 8260, you need to follow the guidance posted at ITLWM repo/web site. NB: I don't know where Dortania folks got the idea that, on Skylake platforms, VGA was treated as DP but that's news to me (and I've been hackintoshing and working on graphics settings for quite some time)! Probably resulted from the observation that a working VGA output registered in IO against a framebuffer connector of DP type but that's quite a shortcut to subsequently state that "VGA is treated as DP"... They occasionally write and affirm incorrect things or contradictory information. For instance, in the installation guide for Skylake laptops, they post settings for HD510 graphics, thereby wrongly indicating that HD510 is supported whilst, in their GPU buyers guide, they correctly state that HD510 is unsupported; macOS has indeed no support whatsoever for GT1 Intel iGPUs ! In the same respect, they state that VGA connector type 10000000 is unsupported in 10.8 and newer, yet I had no issue with such VGA patching of the SNB framebuffer up to High Sierra (and later) on the Sandy Bridge/HD3000 Latitude E6220 I previously owned.

You gotta do your homework. I see that you have Clover Configurator app so look out for its cousin OpenCore Configurator. Failing that, if you read the Dortania documentation, something you really should do, you'll find references to tools such as ProperTree or other plist editor (eg: Xcode, Plist Edit Pro, etc.). I also invite you to learn how to take screenshots in macOS, something detailed in the keyboard Preference Panel. Screenshots are a million times better than poor/unreadable shots from smartphones.

No need for the following iGPU properties on Haswell graphics: framebuffer-fbmem 00009000 DATA framebuffer-stolenmem 00003001 DATA Make sure to remove them, reboot and reset NVRAM at OC Picker before booting Big Sur. Re: wifi, no idea about the hardware you got in place so, you'll have to post full specifications of your (E5x40 ?) laptop, whatever that may happen to be. Now need to look into your patched DSDT and SSDT in case those add conflicting stuff for your graphics. Checking up your OC config, I see that you do not inject the patched DSDT; wise decision given that it probably contains erroneous stuff. I already noticed this patcher the iGPU: Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method { If (LEqual (Arg2, Zero)) { Return (Buffer (One) { 0x03 }) } Return (Package (0x06) { "AAPL,ig-platform-id", Buffer (0x04) { 0x06, 0x00, 0x26, 0x0A }, "hda-gfx", Buffer (0x0A) { "onboard-1" }, "AAPL00,DualLink", Buffer (0x04) { 0x01, 0x00, 0x00, 0x00 } }) } which is incorrect (missing fake id 0x0412 and DualLink property invalid on Haswell iGPU).

You post in the Latitude E5xxx Series; pease specify your laptop model. Haswell-based E5x40 I presume. Please post a zipped copy of your bootloader's config and, if possible, an IOReg extract + SysProfiler extract. Very little we can do without minium information and, in all likelihood, you have some incorrect settings.

Audio should work with the exact same settings you previously had for Monterey. There should be no issue at all on that matter. Same applies to brightness control. For Wifi and Bluetooth, you need to consult the information available on the ITLWM site. Development for Ventura remained at early alpha stage until very recently (I've not checked status for several weeks) so make sure to check the latest information published by the devs.

Re: sleep, follow the steps detailed in our FAQ topic on the matter. Basically cancel hibernation and revert to plain old sleep with deletion of the sleepimage file. I'm reviewing your setup and I can already see some stuff needing to be changed. For instance: 1) you patch fbmem which is wrong; no need for such patch on Ivy Bridge HD4000 so make sure to remove that property: framebuffer-stolenmem 00000004 DATA 2) never seen the need for SSDT-EC-USBX on an Ivy Bridge laptop; afaik, this is for Skylake and later platforms. 3) not sure you need the SSDT-GPRW either. 4) renaming device EC to ECDV normally suffices, I don't thing you need the SSDT-EC-LAPTOP table. 5) don't think you need those PICI and TIMR ACPI patches that I see in your config; need to check the HPET and RTC ones as they look a little unusual to me for the platform.

Quad core i7-3740QM CPU, DW1510 Wireless card, HD4000 with LoRes LCD screen (no nVidia dGPU), right?

Post a copy of your latest EFI folder. We've had plenty of threads and guides for these ageing E6x30 models for years so I'm surprised you have such issues with your Catalina build. You may also want to switch to Clover; it's a lot less daunting than OpenCore and works perfectly on those old Ivy Bridge laptops.

You probably missed something re: ACPI patches for brightness because the solution has been fully proven across the board for Ivy Bridge models of the E6xxx series.

https://osxlatitude.com/forums/topic/15661-acpi-patch-for-brightness-keys-on-dell-laptops

TX/RX rates depend entirely on antennas and physical environments, not the OS. Your screenshots clearly show that both systems hook on your wireless network with identical specs: channel 40 (5GHz, 80MHz). Whilst you may not obtain 100% identical results between the 2 computers, you should nevertheless expect to obtain very similar results if both machines are sitting at roughly the same place. Afterwards, it depends on the antenna's characteristics and quality. 5GHz wireless networks are heavily sensitive to distance and signal reduction due to walls and other environmental elements. Hence why you should only compare TX/RX rates if computers stand at the same physical place. One other thing to note -as observed and detailed here- is that using AirportBrcmFixup can affect TX/RX rates. Make sure you use identical configurations on your 2 computers when you make your comparisons.

IOReg is unlikely to be of any use for that shutdown problem; a zipped copy of the bootloader's EFI you're using would be much more useful... As far as running Ventura on those unsupported platforms is concerned, you should: re-use what you had under Big Sur/Monterey (assuming everything worked Ok under macOS 11/12, including shutdown) update all your add-on kexts to latest versions (especially Lilu & PlugIns) use the SMBIOS of a MBP model supported under Ventura (eg: MBP14,1) for initial installation (and OTA updates) revert to Haswell SMBIOS and boot with -no_compat_check boot arg post-install apply OCLP root patching (use OCLP v0.6.1 minimum) after booting with Haswell settings for the 1st time and that's it. Has worked perfectly for my Ivy Bridge E6230, so it should too on your Haswell E5440. I'd say your shutdown issues are related to some patched ACPI tables or ACPI patches you use.

Probably far too many inappropriate kexts present. I'd start with a basic set and remove all of the following kexts, adding stuff gradually as/if required: CPUFriend + CPUFriendDataProvider (did you actually tune these for your specific CPU/SMBIOS model? If you didn't, there not suitable) FakePCIID_XXXX (can't seen why you'd need such deprecated kexts on a Whiskey Lake laptop) USBInjectAll (clashes with USBPorts assuming latter is the result of an adequate USB port mapping on the computer) HibernationFixup RTCMemoryFixup IOElectrify (if you need to tune TB ports, I'd do it once everything else works perfectly Ok) Thunderbolt3Unblocker (same, keep that to post-install if it's at all required) UVC2FaceTimeHD (can't see why you'd need that but, here too, keep that for post-install if it's at all required) Airportitlwm (keep that to post-install and make sure to follow the specific guidance posted for Monterey at the ITLWM site) For the other kexts you keep, make sure to update them to latest version, especially Lilu & associated PlugIns because you're running on older versions right now... As for the ACPI patched tables, I can only recommend you follow the guidance posted at Dortania, that's quite an extensive set of SSDT tables you got there. Finally, you only posted CPU+iGPU and SSD specs; I'd strongly recommend you identify the rest of your hardware in order to asses what you need (LAN, Wifi, Bluetooth, audio codec, card reader, etc., etc.).

The ACPI solution has been documented here for some years. It began with Sandy Bridge/Ivy Bridge Latitude E models. Glad to see it remains applicable to more recent models such as Comet Lake Latitude 3xxx/5xxx/7xxx series.

Possibly, Redo your mapping and verify your SSDT tables are adequate/appropriate.

-> Thread moved to relevant hardware support section; this is not a thread about hardware information. Please make every effort to post in the appropriate forum sections and to use punctuation, not just post in a single extended sequence of words! This is totally unreadable and such posts/threads be deleted without prior notice in the event of re-occurence. Assuming you've followed all the necessary recommendations posted at ITLWM, you can always try and re-apply the Windows driver for the card in the hope that it'll reload the firmware onto the card if that's what's gone sideways. But you may have to consider that the card is either suffering from a bad connection (try and clean the cards connector and the slot) or simply got defective (it happens). Check if the Bluetooth module is seen or not in SysInfo->Hardware->USB. If it's not, as per in Windows, you have a hardware-related issue. it's probably not the case but do check that Bluetooth did not get somehow disabled in BIOS settings.

No such thing as a Latitude "E7480", there are only Latitude 7x80. Renaming thread and adjusting contents + moving thread to the Latitude 7000 Series section. Grab the PS2/I2C kexts from EFI folders posted in existing Latitude 7280/7480 threads and adjust your bootloader's config accordingly.

I don't recall needing to set or select Legacy Boot option to boot the GrubShell USB key on my Latitude E7270 but if @BillDH2k managed to do it on his Latitude 7400, I can't see why you couldn't...