[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 #28 from Rong Zhang (i@rong.moe) ---
(In reply to George from comment #26)
> Hi Rong,
> 
> I did the lid test exactly as you asked. I set the keyboard brightness to
> High using Fn+Space.

What I said was "try writing to 0x2A, and ...". What value did you write?
Nothing? Or the High one? You would need to write a desired brightness value
other than the current physical one to 0x2A right before closing the lid.

> When I closed the lid, the keyboard light turned off
> after about 5 seconds. 

Hmm, after 5s? Most devices I met turn off the keyboard backlight immediately.

Please check if GNOME puts your laptop into suspend (sleep) after receiving a
lid event. If this is the case, please disable the feature in GNOME before
experimenting again.

> When I opened the lid again, the light turned back on
> at High. (Closing the lid when the keyboard light is off does not turn it
> open when i open the lid)
> 
> I also ran the diff command on the MMIO dumps before closing and after
> opening the lid.

Unfortunately, you dumped the MMIO region twice with the lid open: before
closing == lid is open; after opening == lid is open.

I need it once with the lid open and once with it closed (and *keep the lid
closed* while dumping). Basically, you would have to connect to an external
monitor to use the laptop with the lid closed, or use SSH.

> The output is:
> 2c2
> < 0x00000000FE00D401: 00010000
> ---
> > 0x00000000FE00D401: 00000001
> 
> 7c7
> < 0x00000000FE00D406: 00011100
> ---
> > 0x00000000FE00D406: 00011010
> 
> 177,178c177,178
> < 0x00000000FE00D4B0: 00110010
> < 0x00000000FE00D4B1: 00101100
> ---
> > 0x00000000FE00D4B0: 00100110
> > 0x00000000FE00D4B1: 00101010
> 
> 184c184
> < 0x00000000FE00D4B7: 00101000
> ---
> > 0x00000000FE00D4B7: 00100111
> 
> 199c199
> < 0x00000000FE00D4C6: 00010010
> ---
> > 0x00000000FE00D4C6: 00010011

Nothing looks special. They are just some volatile values related to thermal
states.

> 
> I also did the manual test of register 0x8A as yoy asked
> 
> Step 3 (KBLO = 0, KLFS = 0): the light turned OFF
> Step 4 (KBLO = 0, KLFS = 1): the light did not turn ON
> Step 5 (KBLO = 1, KLFS = 0): the light turns ON at LOW brightness
> Step 6 (KBLO = 1, KLFS = 1): the light stays at LOW brightness

During the test, what's the 0x2A value? In other words, where was the first
step?

Could you try the procedure below to see if it synchronizes the brightness:

1. Write a desired brightness level to 0x2A. It must be different from the
current physical one
2. Read 0x8A
3. Manipulate the read value to make KBLO (bit 0) = 0, and write the modified
value back to 0x8A
3. Same as 2, but KBLO=1

And repeat the procedure with different brightness levels written to 0x2A.

> Hopefully i got everything correct.

You've done quite well, other than missing some pieces. Please address them in
your next reply.

> I am also attaching the stock dsdt.

It's not the one I asked. I asked for a full DSDT corresponding to the snippet
in comment 24, which returns 0x3 when the ICMD is 0x1. Your attachment returns
0x5.

Anyway, it's not important anymore, and you don't need to reupload it. Test
results for smashing KBLO are enough for me.

> 
> Oh  yeah also Bios info:
> Version: GLCN68WW
> Release Date: 03/19/2025

Fine, it's up to date. So an up-to-date BIOS can't fix this. Classic Lenovo
conduct, sigh.

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

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