[ltp] tpacpi bug in tpacpi::thinklight/brightness for X1 Carbon

[Chris Schumann]

On 12/31/2013 07:29 AM, Henrique de Moraes Holschuh wrote:
> On Mon, 30 Dec 2013, Chris Schumann wrote:
>>> I am reading this, but I can't do much without access to a X1.  The
>>> thinklight control uses a specific ACPI method, so your X1 has it or it
>>> would not have turned anything off.
> Meh.  The "off" command uses the generic "update-cmos" handler (UCMS), which
> often just stores info in come nvram instead of doing something.  In the
> keyboard backlight case, the OFF command for the lights (thinklight and
> apparently backlight) actually turns them off, but if there is an ON
> command, it is command 0x0e (which is supposed to just toggle the
> thinklight).
>
> Please test it, see if thinkpad-acpi will give you the /proc/acpi/ibm/cmos
> file.
I'm not sure what to test here, but I have this:
$ cat /proc/acpi/ibm/cmos
status:        supported
commands:    <cmd> (<cmd> is 0-21)

> If it still does in your kernel, echo "0x0e" > /proc/acpi/ibm/cmos
> might be useful.  Other interesting cmos commands might be 0x0b to 0x0d.
Not so useful:
$ sudo echo "0x0e" > /proc/acpi/ibm/cmos
bash: /proc/acpi/ibm/cmos: Permission denied

> The DSDT has KBLT to get the status, KBLS to get/set the status (generic SMI
> trap), as well as several loosely related EC events reported to userspace.
>
> There are two higher-level ACPI methods: MLCG (get) and MLCS (set), the
> later issues EC events 0x6001 (unknown) and 0x1012.  0x1012 is known: it is
> the hotkey event for FN+PGUP (thinklight key on older thinkpads).
>
> What's in the FN+PGUP key of a X1 carbon?  This is weird, I'd expect it to
> be mapped to FN+SPACE (event 0x1014)...
>
> Anyway, looks like FN+SPACE is supposed to mess with a light, the EC handle
> for that one (_Q63) does issue event 0x1014, and calls CMOS command 0x0B,
> which used to be related to screen expansion.
>
> Are any of you X1 carbon owners confortable with kernel hacking?
>
Fn+SPACE works the keyboard backlight through 3 states: low, high, off. 
The intensity does not jump, but ramps, so there's some spiffy hardware 
in there.

I used to write embedded firmware (for printers and communication 
devices), so I'm pretty comfy with that aspect. Just haven't done much 
of that in Linux. I'm happy to help if I can.

Chris