Re: [PATCH 0/4] platform/x86: intel-vbtn: Add support for several more switches/buttons

[Bastien Nocera <hadess@hadess.net>]

On Sun, 2017-11-05 at 14:31 +0200, Andy Shevchenko wrote:
> On Fri, Nov 3, 2017 at 9:03 PM, Stefan Brüns
> <stefan.bruens@rwth-aachen.de> wrote:
> > Currently, intel-vbtn only supports the most relevant buttons,
> > although
> > there are several more events, mostly in use by convertibles.
> > 
> > This series adds support for three more events. One of these events
> > is a switch (SW_*) event, which is currently not working when using
> > sparse keymaps. The first patch fixes this combination.
> > 
> > The second patch adds support for the SW_TABLET_MODE switch, which
> > is used by current convertibles.
> > 
> > The third patch adds support for the KEY_ROTATE_DISPLAY. On the
> > Dell
> > XPS 12 (9Q33), rotation lock is implemented as a button to toggle
> > between locked and unlocked state. In locked state, the
> > accelerometer
> > should be ignored, while in unlocked the screen contents should
> > autorotate based on the tablet orientation. The same functionality
> > is likely implemented as a switch (SW_ROTATE_LOCK event) on
> > different
> > hardware.

KEY_ROTATE_DISPLAY will resolve to XF86RotateWindows. This is a button
for devices without accelerometers (such as old Thinkpad tablet models
with Wacom builtin), to request the display to be rotated. It's not a
request to the OS to toggle the acceleration lock.

The acceleration lock is currently handled in user-space if "Win+O" is
pressed, as some BIOSes will generate this key combination directly,
which Windows will handle.

Please revert this patch, it should send out Win+O instead (or it needs
another keycode added).

(Also, even if the code ultimately lands in the platform tree, it would
be nice to send the linux-input list a copy of those types of patches,
where this problem would have been caught earlier).

Cheers