Re: HID: input: support for misbehaving mice having logical_minimum != 0

Re: HID: input: support for misbehaving mice having logical_minimum != 0

[Ivan Shapovalov]

[-- 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 --]

Re: HID: input: support for misbehaving mice having logical_minimum != 0

[Ivan Shapovalov]

[-- 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 --]