| Message ID | 1424292832.32581.49.camel@hadess.net (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, 18 Feb 2015, Bastien Nocera wrote: > Signed-off-by: Bastien Nocera <hadess@hadess.net> 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
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 <hadess@hadess.net> > > This one requires an ACK from the input maintainers, or no go... Any comments about the other patches? -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 <hadess@hadess.net> > > > > 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).
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 <hadess@hadess.net> > > > > > > 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). -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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
Signed-off-by: Bastien Nocera <hadess@hadess.net> --- include/uapi/linux/input.h | 10 ++++++++++ 1 file changed, 10 insertions(+)