[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1509972104.2869.110.camel@hadess.net>
Date: Mon, 06 Nov 2017 13:41:44 +0100
From: Bastien Nocera <hadess@...ess.net>
To: Andy Shevchenko <andy.shevchenko@...il.com>,
Stefan Brüns <stefan.bruens@...h-aachen.de>
Cc: Platform Driver <platform-driver-x86@...r.kernel.org>,
Andy Shevchenko <andy@...radead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
AceLan Kao <acelan.kao@...onical.com>,
Dmitry Torokhov <dmitry.torokhov@...il.com>,
linux-input <linux-input@...r.kernel.org>,
Darren Hart <dvhart@...radead.org>
Subject: Re: [PATCH 0/4] platform/x86: intel-vbtn: Add support for several
more switches/buttons
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@...h-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
Powered by blists - more mailing lists