Skip to contentSkip to conversation

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

DISCUSSION Roel Kluin 2 participants 3 messages Jan 9, 2010 HID

lore
Share & tools
lore

Roel Kluin

author
#0 lore raw

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

#1 lore raw
Quoted 9 lines · 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?

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,

Signature · 2 lines
Jiri Kosina
SUSE Labs, Novell Inc.
author
#2 lore raw
Quoted 17 lines · Jiri Kosina
Quoted 9 lines · 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?

Hi Roel,

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

Quoted 7 lines

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html