linux-kernel - Re: thinkpad_acpi: Lenovo ThinkPad Yoga 12 side lock button (0x6020)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 11 Oct 2015 09:12:54 -0300
From:	Henrique de Moraes Holschuh <hmh@....eng.br>
To:	Darren Hart <dvhart@...radead.org>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	ibm-acpi-devel@...ts.sourceforge.net,
	platform-driver-x86@...r.kernel.org
Subject: Re: thinkpad_acpi: Lenovo ThinkPad Yoga 12 side lock button (0x6020)

On Sat, 10 Oct 2015, Darren Hart wrote:
> The Lenovo ThinkPad Yogo 12 has a button on the side by the power and volume
> keys with a padlock icon on it, I presume intended to be used as Screenlock.
> 
> It emits 0x6020 which means it falls into the hotkey_notify_6xxx() block. It
> seems this should be handled similarly to the 0x1xxx events instead (as a
> hotkey).
> 
> Is this a keymap change candidate? If so, How do I map 0x6020 to a scancode?

We'd have to extend thinkpad-acpi to have sparse keymaps.  It is not a good
idea to intrude on the 0x1xxx range, as Lenovo can, and did, extend it at
least once already (adaptive keyboard).

We could, as a first step, map 0x6020 to a static keycode, as the padlock
symbol is pretty specific.

Extending thinkpad-acpi for sparse keymaps needs two steps:

1. Design the keymap, it will need a "vendor range", and a "driver range".
We should reserve 0x0000 to 0xffff as vendor range, and something higher for
driver and future use.

I think we could reserve bits 28-31 of the keymap "address" to select
"bank", and have 00 = vendor, 01 = driver, and the others as reserved.

Also, thinkpad-acpi may need to issue events that are not EV_KBD.  Do we
have a map that can do that sort of mapping?  Should we leave those out, as
special cases?

2. Implement the keymap, and decide what we do when someone maps an event
that is currently special-cased in thinkpad-acpi, or not something that
should be mapped to an external event in the first place.

Reject the attempt?  Override driver behavior?  Keep driver behavior _and_
issue the event?

E.g. allowing 0x6020 is a no-brainer: we should.  But what about 0x6030
(thermal table changed), or the battery alarms?  I'd say they should never
become keypresses: if anyone is doing that, they're abusing the input layer
for sure, and this _always_ comes back to bite us later.

I've had some bad experiences with this.  People creating feedback loops
into the driver, etc.  Some of this braindamage, introduced in userspace a
decade ago, is still limiting or discouraging feature implementation today.

-- 
  "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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/