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

[Henrique de Moraes Holschuh]

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.  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.

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?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh