On Mon, Dec 12, 2011 at 01:49:59PM -0500, simon@xxxxxxxxxxxxx wrote: > Err.. must have been sleepy when I looked over your code. Don't know > whether '>=' is better than '==', all other modules do this and I wonder > whether the kernel can get a larger descriptor block by some mechanism. Well, this would be kind of strange, wouldn't it? But I can change it to '>=' if it makes you happy. :) > Quite obviously if the buttons change value in the HID stream then they > are not 'CONSTANT', personally I would patch this part of the HID > descriptor so they are just defined as 'input variable'. While I personally agree with that interpretation, the spec only states that constant fields can not be written by the host. (I know, this doesn't make any sense for an input report.) Somewhere I read that a constant field with no usage assigned to it should be treated as padding. But in this case, there is a usage assigned to. And this is what I'd actually do in hidinput_configure_usage: only goto ignore if there is no usage associated with the field. On the other hand, the gamepad example in the HID Usage Tables doesn't use the constant flag for buttons. > Not sure why you would think other devices might be affected. Patching the > HID descriptor should be limited to this USBID pair, and even only active > if the device provided matches the template you use to trigger patching. I was worrying that other devices might declare some non-padding input fields as constants. So if you fix this problem in the generic part (i. e. hid-input.c) those devices will also start working correctly. Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
