HID: is scancode correctly reported after key status change in hidinput_hid_event()?

HID: is scancode correctly reported after key status change in hidinput_hid_event()?

[Roel Kluin]

vi drivers/hid/hid-input.c +634 and not in hidinput_hid_event()

 	/* report the usage code as scancode if the key status has changed */
	if (usage->type == EV_KEY && !!test_bit(usage->code, input->key) != value)
 		input_event(input, EV_MSC, MSC_SCAN, usage->hid);

Only if value is 1 or 0 the input_event() can occur, but value doesn't
seem to be intended to be used as a boolean. are we really doing the
correct test here?

Roel

Re: HID: is scancode correctly reported after key status change in hidinput_hid_event()?

[Jiri Kosina]

On Sat, 9 Jan 2010, Roel Kluin wrote:

> vi drivers/hid/hid-input.c +634 and not in hidinput_hid_event()
> 
>  	/* report the usage code as scancode if the key status has changed */
> 	if (usage->type == EV_KEY && !!test_bit(usage->code, input->key) != value)
>  		input_event(input, EV_MSC, MSC_SCAN, usage->hid);
> 
> Only if value is 1 or 0 the input_event() can occur, but value doesn't
> seem to be intended to be used as a boolean. are we really doing the
> correct test here?

Hi Roel,

well, value 2 means 'repeated' key, and there is no other possibility for 
EV_KEY value than 0,1,2.

For EV_KEY events generated by HID devices, the autorepeat is done by 
input core (as the device sends the report only when status is changed), 
so there is no easy way how to inject EV_MSC into the 'autorepeat reports' 
anyway.

Are you hitting some bug because of this, or have you found this out 
solely by code reading?

Thanks,

-- 
Jiri Kosina
SUSE Labs, Novell Inc.

Re: HID: is scancode correctly reported after key status change in hidinput_hid_event()?

[roel kluin]

On Sat, Jan 9, 2010 at 4:15 PM, Jiri Kosina <jkosina@suse.cz> wrote:
> On Sat, 9 Jan 2010, Roel Kluin wrote:
>
>> vi drivers/hid/hid-input.c +634 and not in hidinput_hid_event()
>>
>>       /* report the usage code as scancode if the key status has changed */
>>       if (usage->type == EV_KEY && !!test_bit(usage->code, input->key) != value)
>>               input_event(input, EV_MSC, MSC_SCAN, usage->hid);
>>
>> Only if value is 1 or 0 the input_event() can occur, but value doesn't
>> seem to be intended to be used as a boolean. are we really doing the
>> correct test here?
>
> Hi Roel,
>
> well, value 2 means 'repeated' key, and there is no other possibility for
> EV_KEY value than 0,1,2.
>
> For EV_KEY events generated by HID devices, the autorepeat is done by
> input core (as the device sends the report only when status is changed),
> so there is no easy way how to inject EV_MSC into the 'autorepeat reports'
> anyway.
>
> Are you hitting some bug because of this, or have you found this out
> solely by code reading?

only code reading.

Thanks
--
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