>> You have to check the rsize, otherwise you might have problems writing >> outside the size of the original descriptor. > > That's exactly what I've been doing, or did I miss something? > In fact, I wanted to be absolutely sure and only mess with the descriptor > when the sizes match. (*rsize == 137) 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. > Should already be on the list. And I was able to identify the culprit so > no need to bother you. > > The problem is the following code in hidinput_configure_usage > (drivers/hid/hid-input.c): > > if (field->flags & HID_MAIN_ITEM_CONSTANT) > goto ignore; > > The buttons and the hat are defined with the constant flag enabled. > Now I might be reading the spec wrong, but I'm not so sure that we can > simply skip constant values. 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'. > Well, I need to patch the descriptor nevertheless because it defines a > non-existing sixth axis. Might as well remove the constant flag on the > buttons and hat. However, other devices might be affected as well, so > I'd like to get some input on how to deal with the situation. 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. Some drivers provide a complete/new descriptor where patching is complicated, although you gain extra hacker-points if you can achieve the same with a minimal patch :-) Simon. -- 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
