* Re: HID: input: support for misbehaving mice having logical_minimum != 0
[not found] <1496529275.7616.7.camel@intelfx.name>
@ 2017-06-07 0:30 ` Ivan Shapovalov
2018-01-21 6:01 ` Ivan Shapovalov
1 sibling, 0 replies; 2+ messages in thread
From: Ivan Shapovalov @ 2017-06-07 0:30 UTC (permalink / raw)
To: linux-input
[-- Attachment #1: Type: text/plain, Size: 2395 bytes --]
On 2017-06-04 at 01:34 +0300, Ivan Shapovalov wrote:
> Hello folks,
>
> (this is not an actual patch submission; also, this is my first
> submission to mainline kernel, so bear with me...)
>
> This is an attempt to fix touchpad handling on Sony Vaio Tap 11.
> On that hardware, touchpad is visible as a generic hid-input mouse.
> The problem is that kernel does not register mouse button release
> events because the hardware reports bogus logical minimum (1) in the
> respective field of the HID descriptor. (Sorry for probably wrong
> terminology.)
>
> Moreover, the reported logical maximum (5) also disagrees with what
> I've seen in other generic USB mice (it's 1 everywhere else), but I
> do
> not see the logic by which it is determined -- blindly forcing it to
> 1
> system-wide locks me out of the keyboard.
>
> A PoC patch is below that makes touchpad work on that system.
> However,
> the keyboard/mouse on that system are connected via a WUSB dongle
> with
> a generic USB VID/PID, so matching via these (as in the rest of
> usbhid
> quirks) seems inappropriate.
>
> So, I'd appreciate a hint on how to match that hardware for a proper
> quirk and what to do with the odd reported logical maximum.
>
> I'm also attaching the output of various debug tools ran before and
> after patching.
>
> ---
> drivers/hid/hid-input.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
> index d05f903c7614..f8e780185c8a 100644
> --- a/drivers/hid/hid-input.c
> +++ b/drivers/hid/hid-input.c
> @@ -1069,6 +1069,16 @@ static void hidinput_configure_usage(struct
> hid_input *hidinput, struct hid_fiel
> if (usage->type == EV_KEY) {
> set_bit(EV_MSC, input->evbit);
> set_bit(MSC_SCAN, input->mscbit);
> +
> + if (field->logical_minimum > 0) {
> + hid_err(device, "XXX: EV_KEY logical_minimum
> = %d != 0 - updating\n", field->logical_minimum);
> + field->logical_minimum = 0;
> + if (field->logical_maximum != 1) {
> + hid_err(device, "XXX: EV_KEY
> logical_maximum = %d != 1 - updating\n", field->logical_maximum);
> + field->logical_maximum = 1;
> + }
> + }
> +
> }
>
> ignore:
> --
> 2.13.0
>
> Thanks,
Anyone? Or should I resend this with [PATCH] in Subject: to make this
noticed?
--
Ivan Shapovalov / intelfx /
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread* Re: HID: input: support for misbehaving mice having logical_minimum != 0
[not found] <1496529275.7616.7.camel@intelfx.name>
2017-06-07 0:30 ` HID: input: support for misbehaving mice having logical_minimum != 0 Ivan Shapovalov
@ 2018-01-21 6:01 ` Ivan Shapovalov
1 sibling, 0 replies; 2+ messages in thread
From: Ivan Shapovalov @ 2018-01-21 6:01 UTC (permalink / raw)
To: linux-input; +Cc: Benjamin Tissoires, Jiri Kosina
[-- Attachment #1: Type: text/plain, Size: 2399 bytes --]
On 2017-06-04 at 01:34 +0300, Ivan Shapovalov wrote:
> Hello folks,
>
> (this is not an actual patch submission; also, this is my first
> submission to mainline kernel, so bear with me...)
>
> This is an attempt to fix touchpad handling on Sony Vaio Tap 11.
> On that hardware, touchpad is visible as a generic hid-input mouse.
> The problem is that kernel does not register mouse button release
> events because the hardware reports bogus logical minimum (1) in the
> respective field of the HID descriptor. (Sorry for probably wrong
> terminology.)
>
> Moreover, the reported logical maximum (5) also disagrees with what
> I've seen in other generic USB mice (it's 1 everywhere else), but I
> do
> not see the logic by which it is determined -- blindly forcing it to
> 1
> system-wide locks me out of the keyboard.
>
> A PoC patch is below that makes touchpad work on that system.
> However,
> the keyboard/mouse on that system are connected via a WUSB dongle
> with
> a generic USB VID/PID, so matching via these (as in the rest of
> usbhid
> quirks) seems inappropriate.
>
> So, I'd appreciate a hint on how to match that hardware for a proper
> quirk and what to do with the odd reported logical maximum.
>
> I'm also attaching the output of various debug tools ran before and
> after patching.
>
> ---
> drivers/hid/hid-input.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
> index d05f903c7614..f8e780185c8a 100644
> --- a/drivers/hid/hid-input.c
> +++ b/drivers/hid/hid-input.c
> @@ -1069,6 +1069,16 @@ static void hidinput_configure_usage(struct
> hid_input *hidinput, struct hid_fiel
> if (usage->type == EV_KEY) {
> set_bit(EV_MSC, input->evbit);
> set_bit(MSC_SCAN, input->mscbit);
> +
> + if (field->logical_minimum > 0) {
> + hid_err(device, "XXX: EV_KEY logical_minimum
> = %d != 0 - updating\n", field->logical_minimum);
> + field->logical_minimum = 0;
> + if (field->logical_maximum != 1) {
> + hid_err(device, "XXX: EV_KEY
> logical_maximum = %d != 1 - updating\n", field->logical_maximum);
> + field->logical_maximum = 1;
> + }
> + }
> +
> }
>
> ignore:
> --
> 2.13.0
>
> Thanks,
Ping?
Anyone?
Cc'ing maintainers of HID core layer as per MAINTAINERS.
Cheers,
--
Ivan Shapovalov / intelfx /
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread