Hi
(+CC Dmitry, Jiri, Peter, Benjamin)
On Tue, Jul 31, 2018 at 1:48 AM <Roderick.Colenbrander@xxxxxxxx> wrote:
> Hi all,
>
> I would like to share a proposal to extend evdev with support for
> pressure sensitive "analog" buttons. It is a feature common on gaming
> peripherals (arcade sticks, gamepads, wii guitar) as well now on analog
> keyboards such as Wooting One / Two keyboards on which every button is
> both analog and digital (so ~100 analog keys).
>
> These devices are difficult to support using the existing evdev API. The
> problem is the EV_KEY event type was meant for digital keys, whereas the
> EV_ABS could be used for this purpose except that it has reached its
> axes limit due to the EVIOCGABS/SABS limitation of 0x40.
>
> The proposal is to add a new event type "EV_PSR" to evdev to describe
> pressure sensitive keys. Keys reported to this mechanism can report
> analog values. Often devices also report a digital value for the same
> button, so EV_PSR analog keys can have a matching digital EV_KEY. For
> this reason, we suggest to share key codes. (This is up for debate of
> course to tie both together like this.)
>
> Pressure sensitive keys, have similarities with regular absolute axes as
> they have min/max values and probably fuzz makes sense as well. It could
> be said we should extend ABS like David Herrmann proposed in his ABS2
> proposal a while ago and remove the EVIOCGABS/SABS limitations.
>
> This is an initial proposal to address limitations in evdev to improve
> device support in existing drivers such as hid-sony, hid-betopff,
> psxpad-spi, hid-wii and probably others as well as new devices such as
> Wooting keyboards
>
> Thanks,
> Roderick Colenbrander
I like it. Reporting pressure information of keys is currently a huge
hassle and this would simplify it a lot.
The question I see is whether to extend evdev with EV_PSR (or EV_ABS2
for that matter), or to switch to multitouch'ish reports, which simply
combine multiple input-events. Furthermore, the current
'input_device->absinfo' array is already quite big. Adding another one
with an entry for *every* possible key will probably not work out. So
the implementation will probably not be straightforward.
Thanks
David
>
> ---
> Documentation/input/event-codes.rst | 21 +++++++++++++++++++++
> include/uapi/linux/input-event-codes.h | 1 +
> include/uapi/linux/input.h | 14 ++++++++++++++
> 3 files changed, 36 insertions(+)
>
> diff --git a/Documentation/input/event-codes.rst
> b/Documentation/input/event-codes.rst
> index a8c0873beb95..846562d4db4b 100644
> --- a/Documentation/input/event-codes.rst
> +++ b/Documentation/input/event-codes.rst
> @@ -41,6 +41,11 @@ Codes section for details on valid codes for each type.
> - Used to describe state changes of keyboards, buttons, or other
> key-like
> devices.
>
> +* EV_PSR:
> +
> + - Used to describe pressure sensitive 'analog' buttons, e.g. analog
> buttons
> + on arcade sticks, gamepads or keyboards.
> +
> * EV_REL:
>
> - Used to describe relative axis value changes, e.g. moving the
> mouse 5 units
> @@ -177,6 +182,22 @@ a value of 1 in the same synchronization frame.
> This usage is deprecated.
> Note: In multitouch drivers, the input_mt_report_finger_count()
> function should
> be used to emit these codes. Please see multi-touch-protocol.txt for
> details.
>
> +EV_PSR
> +------
> +
> +EV_PSR events describe absolute changes in a key press-like event. It
> is used
> +for devices reporting pressure senstive / analog key presses. These events
> +can't be described through EV_KEY as it is a digital only interface.
> +
> +Pressure senstive keys can be found on gaming devices, keyboards and
> other devices.
> +These devices often report both digital and pressure sensitive events
> for a given
> +key. For this reason, the KEY_<name> and BTN_<name> codes as defined
> for EV_KEY
> +are reused. A device supporting digital and pressure sensitive events
> for the same
> +key, should use the same key code across EV_KEY and EV_PSR.
> +
> +The value range and resolution for a pressure sensitive button can be
> obtained
> +through EVIOCGPRS.
> +
> EV_REL
> ------
>
> diff --git a/include/uapi/linux/input-event-codes.h
> b/include/uapi/linux/input-event-codes.h
> index 53fbae27b280..d142498fc64c 100644
> --- a/include/uapi/linux/input-event-codes.h
> +++ b/include/uapi/linux/input-event-codes.h
> @@ -41,6 +41,7 @@
> #define EV_ABS 0x03
> #define EV_MSC 0x04
> #define EV_SW 0x05
> +#define EV_PSR 0x06
> #define EV_LED 0x11
> #define EV_SND 0x12
> #define EV_REP 0x14
> diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h
> index 7288a7c573cc..f5ce2abde800 100644
> --- a/include/uapi/linux/input.h
> +++ b/include/uapi/linux/input.h
> @@ -121,6 +121,17 @@ struct input_mask {
> __u64 codes_ptr;
> };
>
> +
> +/**
> + * struct input_psrinfo - used by EVIOCGPRS/EVIOSPRS ioctls.
> + * @code: pressure sensitive key to query.
> + * @info: value/limits for this key.
> + */
> +struct input_psrinfo {
> + __u16 code;
> + struct input_absinfo info; //should this be its own psr specfic struct??
> +};
> +
> #define EVIOCGVERSION _IOR('E', 0x01, int) /* get driver version */
> #define EVIOCGID _IOR('E', 0x02, struct input_id) /* get device ID */
> #define EVIOCGREP _IOR('E', 0x03, unsigned int[2]) /* get repeat
> settings */
> @@ -232,6 +243,9 @@ struct input_mask {
> */
> #define EVIOCSMASK _IOW('E', 0x93, struct input_mask) /* Set
> event-masks */
>
> +#define EVIOCGPSR _IOR('E', 0x94, struct input_psrinfo) /* get psr
> value/limits */
> +#define EVIOCSPSR _IOW('E', 0x95, struct input_psrinfo) /* set psr
> value/limits */
> +
> #define EVIOCSCLOCKID _IOW('E', 0xa0, int) /* Set clockid to be
> used for timestamps */
>
> /*
> --
> 2.14.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
