Signed-off-by: Bastien Nocera <[email protected]>
---
include/uapi/linux/input.h | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h
index b0a8130..affe40e 100644
--- a/include/uapi/linux/input.h
+++ b/include/uapi/linux/input.h
@@ -740,6 +740,16 @@ struct input_keymap_entry {
#define KEY_BRIGHTNESS_MIN 0x250 /* Set Brightness to Minimum */
#define KEY_BRIGHTNESS_MAX 0x251 /* Set Brightness to Maximum */
+#define KEY_CLIPPING_TOOL 0x252 /* Screenshot clipping tool */
+#define KEY_CLOUD 0x253 /* Cloud Settings */
+#define KEY_CAMERA_GESTURES 0x254 /* Toggle Camera gestures */
+#define KEY_NEW_TAB 0x255 /* Open a new tab */
+#define KEY_MICUP 0x256 /* Microphone Up */
+#define KEY_MICDOWN 0x257 /* Microphone Down */
+#define KEY_MICCANCEL_MODE 0x258 /* Toggle Microphone cancellation mode */
+#define KEY_CAMERA_ZOOM_MODE 0x259 /* Toggle camera zoom mode */
+#define KEY_ROTATE_DISPLAY 0x25a /* Rotate screen by 90 degrees */
+
#define KEY_KBDINPUTASSIST_PREV 0x260
#define KEY_KBDINPUTASSIST_NEXT 0x261
#define KEY_KBDINPUTASSIST_PREVGROUP 0x262
--
2.1.0
On Wed, 18 Feb 2015, Bastien Nocera wrote:
> Signed-off-by: Bastien Nocera <[email protected]>
This one requires an ACK from the input maintainers, or no go...
> diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h
> index b0a8130..affe40e 100644
> --- a/include/uapi/linux/input.h
> +++ b/include/uapi/linux/input.h
> @@ -740,6 +740,16 @@ struct input_keymap_entry {
> #define KEY_BRIGHTNESS_MIN 0x250 /* Set Brightness to Minimum */
> #define KEY_BRIGHTNESS_MAX 0x251 /* Set Brightness to Maximum */
>
> +#define KEY_CLIPPING_TOOL 0x252 /* Screenshot clipping tool */
> +#define KEY_CLOUD 0x253 /* Cloud Settings */
> +#define KEY_CAMERA_GESTURES 0x254 /* Toggle Camera gestures */
> +#define KEY_NEW_TAB 0x255 /* Open a new tab */
> +#define KEY_MICUP 0x256 /* Microphone Up */
> +#define KEY_MICDOWN 0x257 /* Microphone Down */
> +#define KEY_MICCANCEL_MODE 0x258 /* Toggle Microphone cancellation mode */
> +#define KEY_CAMERA_ZOOM_MODE 0x259 /* Toggle camera zoom mode */
> +#define KEY_ROTATE_DISPLAY 0x25a /* Rotate screen by 90 degrees */
> +
> #define KEY_KBDINPUTASSIST_PREV 0x260
> #define KEY_KBDINPUTASSIST_NEXT 0x261
> #define KEY_KBDINPUTASSIST_PREVGROUP 0x262
--
"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
On Wed, 2015-02-18 at 21:34 -0200, Henrique de Moraes Holschuh wrote:
> On Wed, 18 Feb 2015, Bastien Nocera wrote:
> > Signed-off-by: Bastien Nocera <[email protected]>
>
> This one requires an ACK from the input maintainers, or no go...
Any comments about the other patches?
On Mon, Feb 23, 2015, at 07:15, Bastien Nocera wrote:
> On Wed, 2015-02-18 at 21:34 -0200, Henrique de Moraes Holschuh wrote:
> > On Wed, 18 Feb 2015, Bastien Nocera wrote:
> > > Signed-off-by: Bastien Nocera <[email protected]>
> >
> > This one requires an ACK from the input maintainers, or no go...
>
> Any comments about the other patches?
The series looks mostly good, but the new keymap and attributes need to
go
in the driver documentation (Documentation/laptops/thinkpad-acpi.txt),
and some
of the commit decriptions could use an update.
You could opt to change some of those keypresses dinamically into
driver-specific
ACPI events, by setting the keymap entry to KEY_RESERVED. The driver
will
issue HKEY events in that case. That will be an viable alternative for
some of the new
keys.
The beauty of it is that keymaps are configurable in run-time, so
userspace can
just set any key entries it wants to change to something else, and ACPI
events will be
suppressed if the entry is not set to KEY_RESERVED anymore.
We need to be careful with tpacpi_input_send_key_masked(). If any of the
codepaths
could call it from the adaptative keyboard handling code, it needs to be
updated (just
assume anything above 32 is enabled, as the firmware does not have an
event mask
for the new keycodes).
--
"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
On Mon, 2015-02-23 at 07:49 -0300, Henrique de Moraes Holschuh wrote:
> On Mon, Feb 23, 2015, at 07:15, Bastien Nocera wrote:
> > On Wed, 2015-02-18 at 21:34 -0200, Henrique de Moraes Holschuh wrote:
> > > On Wed, 18 Feb 2015, Bastien Nocera wrote:
> > > > Signed-off-by: Bastien Nocera <[email protected]>
> > >
> > > This one requires an ACK from the input maintainers, or no go...
> >
> > Any comments about the other patches?
>
> The series looks mostly good, but the new keymap and attributes need to
> go
> in the driver documentation (Documentation/laptops/thinkpad-acpi.txt),
> and some
> of the commit decriptions could use an update.
>
> You could opt to change some of those keypresses dinamically into
> driver-specific
> ACPI events, by setting the keymap entry to KEY_RESERVED. The driver
> will
> issue HKEY events in that case. That will be an viable alternative for
> some of the new
> keys.
I don't understand what you mean here.
> The beauty of it is that keymaps are configurable in run-time, so
> userspace can
> just set any key entries it wants to change to something else, and ACPI
> events will be
> suppressed if the entry is not set to KEY_RESERVED anymore.
Keymaps are already configurable at run-time, that's how udev changes
keymaps. Or did you mean something else?
> We need to be careful with tpacpi_input_send_key_masked(). If any of the
> codepaths
> could call it from the adaptative keyboard handling code,
But we're not calling it from there, are we?
> it needs to be
> updated (just
> assume anything above 32 is enabled, as the firmware does not have an
> event mask
> for the new keycodes).
On Mon, Feb 23, 2015, at 08:41, Bastien Nocera wrote:
> > You could opt to change some of those keypresses dinamically into
> > driver-specific
> > ACPI events, by setting the keymap entry to KEY_RESERVED. The driver
> > will
> > issue HKEY events in that case. That will be an viable alternative for
> > some of the new
> > keys.
>
> I don't understand what you mean here.
I mean please set anything that you don't have a keycode for in the new
keymaps to either KEY_RESERVED (will issue an HKEY ACPI event) or
KEY_UNKNOWN (will issue an input EV_KEY event for KEY_UNKNOWN grouped
with an EV_MSC EV MSC_SCAN event that allows userspace to know which key
was pressed/released even if it has no specific keycode).
> > The beauty of it is that keymaps are configurable in run-time, so
> > userspace can
> > just set any key entries it wants to change to something else, and ACPI
> > events will be
> > suppressed if the entry is not set to KEY_RESERVED anymore.
>
> Keymaps are already configurable at run-time, that's how udev changes
> keymaps. Or did you mean something else?
I mean if anyone wants to change something that is KEY_RESERVED or
KEY_UNKNOWN they can configure the driver to do so at runtime through
the input device interface, i.e. get udev to do it.
Nothing new, there.
> > We need to be careful with tpacpi_input_send_key_masked(). If any of the
> > codepaths
> > could call it from the adaptative keyboard handling code,
>
> But we're not calling it from there, are we?
Probably not, but it would be a good idea to double-check.
--
"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