Please explain why deleting the code is legit here.

Please explain why deleting the code is legit here.

that code I deleted on cfl+ is not essential, keeping that code works on cfl, cml and icl but on whiskey lake creates problems since it makes it load uid 10 and not 13

but I repeat it is a problem only with whiskey lake generation, the others work well with current pnlf release.
this new version continues to work well even with the aforementioned ones.

Reported by my mates that some CML machines can not change brightness in 3 minutes. After 3 minutes, everything works well. No log for now. Occured since updated SSDT-PNLF in cbea3f1

Reported by my mates that some CML machines can not change brightness in 3 minutes. After 3 minutes, everything works well. No log for now. Occured since updated SSDT-PNLF in cbea3f1

I have a i7 10510u cml and it works perfectly. Also with the first version.. Never had this problem so maybe it comes from other stuff in their efi?

Reported by my mates that some CML machines can not change brightness in 3 minutes. After 3 minutes, everything works well. No log for now. Occured since updated SSDT-PNLF in cbea3f1

Probably is this:
-igfxblr boot argument (and enable-backlight-registers-fix property) to fix backlight registers on CFL + platforms.

Just add to their efi this Bootarg in nvram "-igfxblr" or in the Dev prop patch "enable-backlight-registers-fix" with 01000000 DATA
And don't forget to reset nvram!

And please, study and read before apply something...

@Vorshim92 Thanks for the reply. I am still confused about CFL part in SSDT-PNLF. Why we need to assign COFFEELAKE_PWMMAX to CFL pwm in SSDT-PNLF while in SSDT-PNLFCFL, we only need to change UID to 13? To me, SSDT-PNLFCFL is a much cleaner and native way to inject UID without modifying PWM max value.

@Vorshim92 Thanks for the reply. I am still confused about CFL part in SSDT-PNLF. Why we need to assign COFFEELAKE_PWMMAX to CFL pwm in SSDT-PNLF while in SSDT-PNLFCFL, we only need to change UID to 13? To me, SSDT-PNLFCFL is a much cleaner and native way to inject UID without modifying PWM max value.

sorry meddling, but you did not understand how it works you just have to fill in aml, and then he alone according to your device id of the igpu, inject in automatic correct uid, in your case sect 13 in automatic since you have cfl.
you don't have to change any value in ssdt, you just have to save it in aml.
and you have to use -igfxblr as bootarg from cfl and later
Kind regards.

@Lorys89 Thanks for the reply. SSDT-PNLF has detailed notations so it's not difficult to understand how it works on assigning PWM value. The auto device-id detection is indeed good for newcomers. What I doubted is the necessity for CFL users transition from SSDT-PNLFCFL to SSDT-PNLF since PNLFCFL seems to be a much decent UID injection targeted for CFL+ users.

-igfxblr is not needed on my friend's machine when he uses SSDT-PNLFCFL. I will ask him to try this with PNLF. BTW, still hoping that AppleBacklightSmoother could be updated as it was also a great solution for brightness adjustion.

What I suggest and I believe the behind reason for Rehabman having a separated PNLFCFL is letting CFL machine's LMAX and PWM untouched. In the new version of PNLF, CFL machine's UID is set to 19 and triggers F19Txxxx backlight data. While UID 13 in SSDT-PNLFCFL will call native AppleBacklight.kext. (For some reason, machine within PNLFCFL's UID is still set to 19?)
I haven't dived too deep on this since I don't have a CFL machine until a week later. But thanks to everyone who worked on the PNLF improvement.

What I suggest and I believe the behind reason for Rehabman having a separated PNLFCFL is letting CFL machine's LMAX and PWM untouched. In the new version of PNLF, CFL machine's UID is set to 19 and triggers F19Txxxx backlight data. While UID 13 in SSDT-PNLFCFL will call native AppleBacklight.kext. (For some reason, machine within PNLFCFL's UID is still set to 19?)
I haven't dived too deep on this since I don't have a CFL machine until a week later. But thanks to everyone who worked on the PNLF improvement.

then you know that uid 19 (decimal) converted is uid 0x13 (hex)
I hope you have clarified your doubts, and remember that from cfl and later, you have to use the backlight correction -igfxblr

@1alessandro1 , thank you for the follow-up. @Lorys89 did not delete my comment. I deleted my comment (which originally asked if SSDT-PNLF might cause the kernel panic) because the kernel panic still happens with the the non-CFL version of SSDT-PNLF. I have now reverted to OC 0.7.1 and corresponding kexts released with OC 0.7.1 (WEG, Lilu, etc) in an attempt to isolate the kernel panic.

I apologize for the false alarm - I deleted my comment, because I don't think my kernel panic is caused by SSDT-PNLF.

@1alessandro1 , thank you for the follow-up. @Lorys89 did not delete my comment. I deleted my comment (which originally asked if SSDT-PNLF might cause the kernel panic) because the kernel panic still happens with the the non-CFL version of SSDT-PNLF. I have now reverted to OC 0.7.1 and corresponding kexts released with OC 0.7.1 (WEG, Lilu, etc) in an attempt to isolate the kernel panic.

I apologize for the false alarm - I deleted my comment, because I don't think my kernel panic is caused by SSDT-PNLF.

ssdt pnlf cannot cause kp, or starts or does not start (does not load) investigates ssdt pnlf cannot cause kp, it's next time write about acidanthera bugtracker.
Have a nice day.

My hack (HP Envy Kabylake R i5-8250U/UHD620) BIOS does not permit configuration of video RAM, so I configured framebuffer-fbmem and framebuffer-stolenmem as I understood from here. I used the 9MB and 19MB values respectively from the Dortania post-install guide. After increasing these values (to 21MB and 39MB respectively), I am no longer observing the Kabylake kernel panic. I will continue to monitor and report back if anything changes.

UPDATE: I have removed framebuffer-fbmem and framebuffer-stolenmem from my OC 0.7.3 config.plist and am not experiencing any kernel panics. I re-read this and now understand that I misinterpretted the Dortania instruction. I incorrectly thought that an inability to configure VRAM in BIOS meant an automatic need to configure framebuffer-fbmem and framebuffer-stolenmem in OC's config.plist DeviceProperties. I now realize that configuring these is only necessary if VRAM is not sufficient to support fbmem and stolenmem required by the chosen framebuffer (AAPL,ig-platform-id). I suspect that if I booted Windows on my rig (I don't have Windows installed and only run Big Sur 11.6), I would see that available video memory is more than adequate for my chosen framebuffer.