Hervé

Are you using Heliport client too? Alternatively, try AirportItlwm https://openintelwireless.github.io

I meant whatever driver you may have added wherever to get your BT dongle working, what else?

Monterey normally boots with the exact same settings and config as Big Sur. Only Lilu & plugins are recommended for updates, failing what the -lilubetaall boot-arg & associates are required. If you believe your issue is Bluetooth related -and it could be of course-, unplug your dongle and remove all associated kexts you may have installed.

1st off all, you need to provide your system's specs (computer model, BIOS version, chipset, CPU, GPU, audio, LAN, wireless, etc.). Then you need to specify the boot loader you're using and its version Finally, post a zipped copy of your boot loader EFI No assistance can be provided without this minimum requirements. The only thing I can confirm is that Bluetooth is often problematic under Monterey beta1 so don't hesitate to disable it to begin with.

I'm tempted to say you're looking at brightness and brightness control the wrong way. Look up existing guides & threads related to the Latitude Exx70 models. Keep things simple and focused on the Latitude families. NB: As per our stated rules, which I invite to read if you've not done it yet, no links to forbidden sites and easy on the quoting!

Those values are the expected ones but you could always tried the other values that have been posted/mentioned for other various Dell models. Note that you would need to engage in complex technical analysis if you wanted to verify the ACPI codes returned by the Fn-Fxx key combinations for brightness control. Former Hackintosh expert Rehabman detailed the process on one of his GitHub repos. Alternatively: revert to the original SSDT-BRT6 table (with IGPU device for iGPU) rename GFX0 to IGPU in SSDT-PNLF-CFL table add renaming of GFX0 to IGPU in your OC config and test again. I would also suggest you test switching from SSDT-PNLF-CFL to SSDT-PNLF table, the one applicable to models of previous generations.

Monterey usually works with the exact same settings as with Big Sur. On the various laptops I installed it on (Latitude E6230/E7270, Satellite Pro R50-B): Screen brightness works the same in Monterey as it does in Big Sur (brightness level should be retained if you have a fully working NVRAM) Brightness control works the same in Monterey as it does in Big Sur Sleep & wake work the same in Monterey as they does in Big Sur DW1820A works the same in Monterey as it does in Big Sur (Tosh R50B & Lat E7270) Touchscren stopped working in Big Sur on my Skylake E7270 whilst it worked OOB in Mojave and Catalina; such Toushcreens are USB-based and fully detected/reported in SysInfo->USB As for TouchPad, it really depends on the model fitted to your laptop but I2C models are limited

I see a likely issue with regards to brightness keys: the SSDT-BRT6 patched table refers to IGPU device for the iGPU the SSDT-PNLF-CFL patched table refers to GFX0 device for the iGPU there is no renaming of GFX0 to IGPU in your OC config Lilu probably renames GFX0 to IGPU after that all tables have loaded and SSDT-BRT6 may not be properly applicable as a result Given that you have brightness control overall (although not through the expected keys), it's fair to say that SSDT-PNLF-CFL is fully operational. As such, do try and rename IGPU to GFX0 in SSDT-BRT6 table, recompile it and save it. That should hopefully fix the brightness keys.

You may experiment with other layouts specified for that ALC295 codec in the AppleALC wiki. I would also recommend you 1st add CodecCommander kext to your kexts set during your experimentation.

Much has been written for years and is known about Apple wireless cards based on the Broadcom BCM4360 chipset. Having been using BCM94360CD cards for years with mini-PCIe adapters in my old Latitude E6220 and E6230 laptops, I looked at the best possible Apple alternative for my Latitude E7270 fitted with 1 x Key A/E M.2 WLAN slot. Until now, I had been using 1st a BCM4350-based Dell DW1820A, then a Fenvi BCM94360NG card in this Skylake laptop. But I recently had the opportunity to buy an Apple BCM94360CS2 card for a handful of € and M.2 adapters for Apple BCM94360xxx cards cost pennies so I went ahead with it. Having received my Key A/E M.2-to-Apple adapter from China after a very very long wait, I proceeded to install the Apple Card in my E7270. It's easily achieved at the cost of a couple of minor and less minor limitations. 1) WLAN slot size and card size: the E7270 offers a classic M.2 WLAN slot that supports a Key A/E 2230 card (22x30mm). the BCM94360CS2 card is a little narrower than 22mm (about 17/18mm) but longer than 30mm (about 37/38mm). the M.2 adapter is 22mm wide but much longer than 30mm (about 46mm). as such, the adapter+BCM94360CS2 card package's length extends beyond the 30mm limit of the E7270 WLAN slot. 2) rubber piece: there is a piece of rubber lightly glued to the motherboard between the WLAN slot and its neighbouring WWAN slot. this rubber piece supports the top end of any M.2 2230 WLAN card, right under the securing metal bracket. this rubber piece gets in the way of the M.2 adapter and BMC94360CS2 card and needs to be removed; thankfully, it can simply be easily unglued and moved aside rather than cut out. 3) WWAN slot: the length of the M.2 adapter and BCM94360CS2 card mean that, once fitted in, they end up occupying part of the WWAN slot. impact is that no WWAN card or other M.2 card (eg: 2240 NVME SSD) can be fitted into the slot. Benefits with the recent and sustained price increase of M.2 DW1820A, Fenvi BCM94360NG or DW1560 cards, Apple BCM94360CS2 has become quite attractive because, at the time of writing, it can be obtained 2 to 3 times cheaper on the 2nd hand market (15 to 20 $/€). being dual-antenna, BCM94360CS2 makes a perfect alternative to the aforementioned M.2 cards and Apple's own BCM94360CS/BCM943602CS cards which are 3 x antennas and therefore often unsuitable in laptops. the card is fitted with same MHF4 antenna connectors as most M.2 wireless cards. it's an Apple card so 802.11ac wireless + bluetooth 4.0 work OOB and perfectly. Drawbacks the card's length: whilst using an M.2 adapter is not usually an issue (most offer a removable section), the length of the card may not allow to fit it into all laptops. There are of course M.2 extenders with ribbon cables + antenna extenders but these still require to find free space within the laptop. This has the merit to exist but will not be suitable in many if not most cases.

Re: USB mouse, assuming the device is fully working/not defective, you need to ensure you've mapped all your USB ports, internal and external. You may use tools such as Hackintool to that effect or follow the USB mapping guidance available in the Dortania documentation. You should also consult the extensive literature posted by @tanya about her own Latitude 3400. She certainly achieved great success.

Try and experiment with the various CFL mobile device ids and mobile layout ids specified in the WEG user manual. You may find a combination that works. Failing that, you may also try the settings that applied to 8th gen Kaby Lake R platforms like the Latitude 7490. This being said, there are several people who posted about their Latitude 7400 laptop also fitted with Whiskey Lake i7-8665u CPU. If you run a search for 7400-related threads/posts on the forum, you'll find a few. Afaik, they all had graphics acceleration fully running with CFL layout 0x3E9B, CFL fake iGPU id 0x3E9B and MBP15,2 SMBIOS. You've got to properly configure the properties you inject of course, it clearly was not the case in the last screenshot posted by @tommyluco ("deviceID" instead of "device-id"). This particular post is pretty limpid on the matter to me.

If Firewolf's kext results in KP, try the previous kext developed by Cholonam's. Both normally support Realtek RTS525A readers. Re: brightness keys, your DSDT shows: 1) usual BRT6 brightness control method for Dell laptops Method (BRT6, 2, NotSerialized) { If (LEqual (Arg0, One)) { Notify (LCD, 0x86) } If (And (Arg0, 0x02)) { Notify (LCD, 0x87) } } 2) BRT6 called from EV5 method as usual Method (EV5, 2, NotSerialized) { \_SB.PCI0.GFX0.BRT6 (Arg0, Arg1) } 3) EV5 called from SMEE if OSID returns a value greater of equal to 0x20 as usual Method (SMEE, 1, NotSerialized) { Store (Arg0, Local0) Store (GENS (0x11, Zero, Zero), Local0) If (LGreaterEqual (\_SB.OSID (), 0x20)) { If (And (Local0, 0x04)) { EV5 (One, Zero) } If (And (Local0, 0x02)) { EV5 (0x02, Zero) } } If (And (Local0, 0x08)) { Store (GENS (0x1D, Zero, Zero), Local0) EV15 (Local0, Zero) } } 4) SMEE called from SMIE method as usual Method (SMIE, 0, NotSerialized) { Store (GENS (0x10, Zero, Zero), Local0) If (And (Local0, 0x04)) { SMEE (Local0) } If (And (Local0, 0x02)) { EV7 (Zero, Zero) } If (And (Local0, 0x08)) { EV9 (Zero, Zero) } If (And (Local0, 0x40)) { EV8 (Zero, Zero) } If (And (Local0, 0x80)){} If (And (Local0, 0x10)){} } 5) SMIE called from NEVT method as usual Method (NEVT, 0, NotSerialized) { Store (ECG1 (), Local0) Store (ECGD (), Local1) Store (Add (ShiftLeft (Local1, 0x10), Local0), Local2) [...] If (And (Local0, 0x80)) { SMIE () } } So, given that all is exactly as per other previous generations of Latitude (E6x30, E6x40, E7x50, E7x70, etc.), you can apply the same patches as we've detailed in our various guides: 1) in your bootloader ACPI config rename OSID to XSID -> to avoid bug after _OSI renaming rename _OSI to XOSI -> to bypass _OSI rename "BRT6,2" to "BRTX,2" -> to bypass vanilla BRT6 method 2) inject the following SSDT tables: SSDT-BRT6.aml -> injects new BRT6 method with correct key values for brightness control SSDT-XOSI.aml -> ensures OSID returns the required value You'll find those in, say, my E7270 guide. You should then have working brightness keys

Yes, though it's always better to obtain the IOReg extract from an app like IORegistryExplorer than provide a text-based one that is most difficult to analyse. Did you use this? https://osxlatitude.com/forums/topic/10209-how-do-i-generate-debugging-files/?tab=comments#comment-97908

-> moved to Monterey beta section where this thread belongs; please make sure to post in the forum's relevant sections. Thank you. With regards to your observations and experiments: 1) Monterey is at initial 1st Developper Preview stage at this point of time 2) Monterey carries no native support for HD4000 graphics that have now been officially dropped from macOS 3) HD4000 can only be supported after patching Monterey beta1 with tools such as OCLP v0.1.7 and later 4) Automatic login must be enabled after 1st boot and until you patch Monterey, failing what you end up with the graphics initialisation failure loop you currently experience I had already mentioned this in my Monterey beta1 thread posted in this very section. Please note that you're highly likely to experience reduced performance, very high temperatures and regular crashes with Monterey; it's very early stages and it does not run too great on dropped Ivy Bridge/HD4000 platforms for the moment. Best is to wait for subsequent beta versions and further development on the patching side.

Looking at your posted IOReg, I see that your SD card reader is a PCIe Realtek RTS525A (10ec:525a). As such, I expect the new beta driver recently offered by Firewolf to bring life to yours. Just try and inject it. On the brightness keys front, I would not expect much out of that kext mentioned at Dortania. To me, the existing solution of combined ACPI + SSDT patches is spread wide enough to pretty much vouch for it across the Latitude generations. I would therefore also expect that applying the documented method should work on your 7310 laptop too. But post your extracted BIOS tables so that we have a look, especially at your original DSDT.

There's renewed interest on the development of drivers for Realtek PCIe card readers and it's fantastics news! Last year, we reported here on Cholonam's work that, building on the original work of developper Sinetek, gave a new life to some of our Realtek card readers. It was pretty good stuff and allowed many of us with, say RTS525a card readers, to finally be able to use SD cards under macOS. Performance was however pretty limited. This year, Austere.J (aka Firewolf) has embarked on writing a brand new driver and, my God, is it good! The driver is under active development as we write but Austere.J has started on the RTS525a with super results and he's adding support for other Realtek RTS models too. 2 x major improvements compared to Cholonam's driver: the card reader is now reported as built-in in SysInfo the card's full performance is being achieved You can follow the on-going R&D here at Insanelymac and drivers are posted here on FireWolf's GitHub repo. Please join me in helping Austere.J in the testing and give him the support and thanks he deserves. View full article

I understand that ALC3236 codec is ALC233; look that up in the AppleALC wiki and experiment with the various layout ids listed. https://github.com/acidanthera/applealc/wiki/supported-codecs Re: AR9565 wireless, those were never natively supported and required a specifically re-written Atheros40 kext. Then, performance was not great. Knowing that you'll probably have trouble getting this card to work under Big Sur, it'd be far better to replace it with a fully supported M.2 model. You can check these out in our wireless cards inventories and our M.2 wireless cards inventory, all available in our R&D->Wireless section.

You're using an EFI made for a different model that may not have the exact same hardware specs as your own particular laptop. You need to identify your audio codec and specify the make & model of your wireless card. Don't hesitate to open up your laptop to look at the label of the wireless card. Failing that, post an IOReg extract saved from IORegistryExplorer app.

OCC app gets aligned with versions of OpenCore. So, you must have a mismatch between the version of OCC you used and the OpenCore version you've installed. In most case, these warnings can be ignored but OpenCore can be subject to updates that completely modify the way parameters are defined. In rare cases, you could find yourself in a situation where a config file updated through OCC would no longer allow you to boot OpenCore due to changes in the config that aren't supported by an older version of OpenCore. For instance a config updated by OCC for OC 0.7.0 when installed OpenCore version is, say, 0.6.3 or 0.6.5. If you don't update OpenCore, don't update OCC either. Keep them aligned. Right now, you should probably update OpenCore to 0.7.0/0.7.1 and OCC to the latest available version, v2.44.0 at time of writing. Then stop there.

Usually, I turn TPM & USB Wake Support off.

Glad to see that you got graphics acceleration after entering the suggested properties in the correct reverse byte order.

It's 1st beta and Bluetooth is buggy, even for real Macs. So guys, just be patient.

Remember to post your system's specs in signature.