[ltp] tpacpi bug in tpacpi::thinklight/brightness for X1 Carbon
Wed, 01 Jan 2014 08:22:05 -0600
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
> Please test it, see if thinkpad-acpi will give you the /proc/acpi/ibm/cmos
I'm not sure what to test here, but I have this:
$ cat /proc/acpi/ibm/cmos
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
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.