On Fri, 30 Mar 2007, Pete Zaitcev wrote:
> @@ -1328,9 +1340,18 @@ static int hid_probe(struct usb_interface *intf, const
> struct usb_device_id *id)
> return -ENODEV;
> }
>
> - if ((hid->claimed & HID_CLAIMED_INPUT))
> + if ((hid->claimed & HID_CLAIMED_INPUT)) {
> hid_ff_init(hid);
>
> + /*
> + * We do this only if input has claimed the device because
> + * we can only find fields after they were configured in
> + * hidinput_connect.
> + */
> + /* if (hid->quirks & HID_QUIRK_RESET_LEDS) */
> + usbhid_set_leds(hid, LED_NUML, 0);
> + }
> +
> if (hid->quirks & HID_QUIRK_SONY_PS3_CONTROLLER)
> hid_fixup_sony_ps3_controller(interface_to_usbdev(intf),
> intf->cur_altsetting->desc.bInterfaceNumber);
Hi Pete,
I think I see an issue here. Imagine that you boot a system initially with
one keyboard connected (usb, ps/2, doesn't matter), and after some time
you connect second USB keyboard (the NumLock is 'on' on the first keyboard
when you connect the second one).
Without your patch, the NumLock led will be OK on the second keyboard
immediately. With your patch, the NumLock will be forced to 'off' and it
will be out of sync with the first keyboard. The leds will get in sync
later when any change occurs.
> diff --git a/include/linux/hid.h b/include/linux/hid.h
> index d26b08f..f592f01 100644
> --- a/include/linux/hid.h
> +++ b/include/linux/hid.h
> @@ -267,6 +267,7 @@ struct hid_item {
> #define HID_QUIRK_SKIP_OUTPUT_REPORTS 0x00020000
> #define HID_QUIRK_IGNORE_MOUSE 0x00040000
> #define HID_QUIRK_SONY_PS3_CONTROLLER 0x00080000
> +#define HID_QUIRK_RESET_LEDS 0x00100000
I think this is not worth a quirk - when we get it working properly, why
not do it unconditionally for all keyboards?
> URL with details, discussion, rejected patch to read BIOS byte at 0x417:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228674
"You are not authorized to access bug #228674. To see this bug, you must
first log in to an account with the appropriate permissions."
:)
Thanks,
--
Jiri Kosina
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
