[Bug 221583] Lenovo 82KU: keyboard backlight works via Fn+Space but no kbd_backlight LED device exposed

[bugzilla-daemon@kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=221583

--- Comment #14 from Rong Zhang (i@rong.moe) ---
Hi George,

I am afraid you have somewhat overtrusted AI hallucinations...

(In reply to George from comment #12)
> Hi Rong,
> I’ve attached my current dsdt.dsl. With this version, the GNOME Quick
> Settings panel correctly displays all three states (Off, Low, High), but
> clicking any of them has no effect on the physical backlight. Additionally,
> pressing Fn+Space no longer triggers the OSD popup at all.

Having all three states just means that the KBLC method correctly returns 0x5
when the first (and the only) argument is 0x1.

Except for that, everything goes wrong and has fundamental divergences from my
patch. The divergences make absolutely no sense to me. I don't believe your
device's keyboard backlight brightness has anything to do with KBLO and KLFS. I
will explain why later.

> For context, I previously had a version where Off and Low worked physically
> and the OSD appeared, but selecting High would instantly reset the state to
> Off.

What version? My patch or an AI-generated/modified one? Please attach it.

And please rollback to the version, it's probably a right step toward software
control. Then, set all three states via software, and dump 0xFE00D42A to see
what happens.

> Through EC memory dumping, I confirmed my laptop uses register 0x8A
> (not 0x2A as in the original patch), 

You confirmed, or AI confirmed?

Bit 0 of 0x8A is KBLO. AI must have seen the ASL code of other Lenovo laptops
during the pre-training stage, so it told you that "KBLO" is meant for keyboard
backlight brightness. Unfortunately, it makes no sense for your device. The
KBLO field and the SALS method exist on your device just because Lenovo
engineers produced a lot of dead code by copying and pasting ASL code across
different products and insanely "evolving" them. That's probably also the
reason why KLFS exists.

Meanwhile, these field names look like abbreviations and are very good at
causing AI hallucinations. AI will be easily stuck in its speculations for
absolutely no reason.

Your previous MMIO dumps have already proved that 0x2A is the offset we were
looking for. Your dumps are very similar to the ones on my device. Trust your
MMIO dumps, instead of AI.

> and that writing 0x02 to the 2-bit KLEN
> field inadvertently sets the UCHE (USB Charging) bit, which cuts power to
> the backlight or whatever qwant thinks I have no idea.

Completely AI hallucinations. In my patch, KLEN is located at bits 1-2 of 0x2A.
There is no chance that it overwrites UCHE at bit 1 of 0x8A. If something ever
inadvertently sets the UCHE bits, it must be an AI hallucination that puts KLEN
at bits 0-1 of 0x8A.

> I’m not confident enough in ASL to resolve this safely.

Your replies had too many divergences from my patch, which made me suspect
whether you've really tried my patch yourself instead of simply throwing it to
an AI. I'm not confident enough about the AI-generated answers or agentic
actions, either.

So, let's save each other's time. Ignore the instructions from AI, just answer
me:

What happened when you manually wrote the values you've found to 0xFE00D42A
through /dev/mem?

Have you ever tried my patch *without* any modifications? What was the exact
result when you applied it as is?

I've asked these questions before, and I am still waiting for your answers.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.