Jump to content

lulujyc

Members
  • Posts

    17
  • Joined

  • Last visited

  • Days Won

    1

lulujyc last won the day on July 27

lulujyc had the most liked content!

Recent Profile Visitors

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

lulujyc's Achievements

Private First Class

Private First Class (3/17)

2

Reputation

  1. iirc the M6800 has a MUX which is causing this problem on 11.3+ but the MUX also works to disable the iGPU which is why these laptops are especially good for hackintoshes due to how badly macos handles most dual gpu laptops hehe. still suggest OP to check the dGPU addresses as different chip vendors might cause differences in addresses -- at least being the case for me.
  2. Use SSDT-XOSI (refer from dortania) to test polling mode and if that works manually configure your GPIO, use VoodooI2C official docs
  3. You need to find your dGPU PCI address and add the dGPU patch to disable the dGPU brightness control that 11.3+ defaults to. From what I understand, the iGPU patch is meant to force enable backlight via iGPU, and you also need to disable the default-enabled dGPU backlight.
  4. Hello. I have found a solution to your mentioned issue. My Precision 7530, which also has a compatible dGPU, has non-working brightness after the 11.3+ upgrade. And yes, you are right -- the cause of the problem is because 11.3+ Apple decided to change its driver stack somehow to default the brightness control to the dGPU, which does not have internal screens. So either we use solely iGPU, or we route the internal display to the dGPU and turn off the iGPU which is power consuming. Someone on reddit, however, was smart enough to find a solution right here. In this solution, the dGPU brightness control were given back to the iGPU via a smart patch. Hope that helps! https://www.reddit.com/r/hackintosh/comments/nzsyqo/inspiron_15_r_se_7520_big_sur_115_beta_2_success/?ref=share&ref_source=embed&utm_content=title&utm_medium=post_embed&utm_name=d2f878a2486d45fa91e92a051f573f6b&utm_source=embedly&utm_term=nzsyqo
  5. Hi, Thank you for your reply! I have tried adding Windows patches to the DSDT with no hope, I2C stucks at VoodooI2CPCIController::pci8086,a369 Could not get ACPI device for PCI provider. SSDT XOSI will not work in my setup, given I need to inject the DSDT. The current DSDT in my ACPI folder is extracted and patched and should be useful to look at. Thanks again!
  6. The Boot Log says: VoodooI2CPCIController::pci8086,a369 Could not get ACPI device for PCI provider
  7. Hi, First of all, I would like to thank to those who helped me previously fixing all the weird bugs of the machine. However, I have very unfortunately encountered new issues regarding the I2C trackpad, after installing a spare M.2 2242 PCIe NVMe drive to the machine. Specifically, the I2C trackpad stopped working and is no longer recognized after I installed the drive in. If I try to touch the trackpad, it will not respond and also render my keyboard not to function. However, if I try to not touch the trackpad, the keyboard will keep working well. The same issue happened when I was dealing with the graphics autoswitching bug. When the Graphics was switched to the Discrete mode by the ACPI bug, the same I2C misfunction happens. I was thinking that being a bug of the VESA graphics at that time, but now I think I am wrong. Removing the 2242 drive, and leaving only the 2280 drive that I had when I made a successful I2C attempt, nevertheless, didn't help solving this problem. Now I am thinking that this could be very possibly some kind of IRQ conflicts, but I have no idea how to solve this. I wonder if you experience similar issues, or have ideas to fix it. I have posted my whole configuration to a github repo, which can be found here: https://github.com/lulujyc/Dell-Precision-7530-OpenCore Many thanks in advance! Update: I felt like enough dealing with all the hassle brought by this prototype board. Ordered a new 7530 MLB from Dell and decided to do a board swap also for upgraded performance
  8. Sure, thank you very much. I just forgot to enable the Automatic quirk, making all OpenCore SMBIOS changes useless. Now I have CustomSMBIOSGUID plus Custom, which is fully working. By the way, I wonder if you have insights regarding the I2C TrackPoint issue? https://github.com/VoodooI2C/VoodooI2C/issues/460 As confirmed by the VoodooI2C team, it is VoodooI2C that haven't supported the I2C stuff in 7530 yet. Marking this as solved. Huge thanks to everyone!
  9. Could this be a problem with the firmware? Here is my current config.plistconfig.renametoplist.zip Oh sorry, never mind, I forgot to enable Automatic. It is a typo indeed. Thank you!
  10. Absolutely. The 7x30 pointing device runs entirely on I2C, so it could be more or less a VoodooI2C issue (I've seen others having ALPS I2C reporting the same issue as well). Even the TrackPoint runs on I2C, so VoodooPS2 didn't help. Thanks. mbp.ioreg
  11. Okay, using his repo and the same DSDT integrating route, I made the I2C working. However, the TrackPoint doesn't work, and in the 3-button Trackpad, only the Left button is recognized. I wonder if you can give some further insights. Now the only problem is SMBIOS, and then -- a working MBP16 replacement
  12. Thank you for your suggestion! I've integrated the SSDT into my DSDT, which looks like perfectly worked now. Just to make sure -- there is now no need to rename EV3 to XEV3 since it is already in the else condition now? Sorry I'm very new to DSDT. By the way, I wonder if you have some ideas regarding the I2C and SMBIOS problems. Thanks!
  13. It is not Optimus. this laptop utilize hardware MUX (which can be controlled in bios to enable only dgpu) instead of generic Optimus. thanks It is a problem related to EV3 in SSDT. I've seen a 7540 owner having similar problem, that is macOS makes MUX to be Discrete upon a reboot when it's set to Hybrid before. However his SSDT and Hotpatch can't fit mine 7530... This is the 7540 repo https://github.com/nnkn/hackintosh-dell-precision-7540-oc
  14. Hi, first of all thank you very much for your work! I know injecting DSDT is not the suggested route, but it is the only way for me to boot, otherwise the problematic prototype DSDT will make the kernel stuck at loading ACPI tables error. So I tried manually adding the SSDT-GPRW, SSDT-XOSI and the ACPI Patch (i did enable it) to my original configuarition, but unfortunately this didn't work. I tried adding other ACPI patches to see if I can get the trackpad to work or the MUX and SMBIOS can be fixed but had no luck. Here is the ioreg. Thanks again!mbp.ioreg
×
×
  • Create New...