quoted
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.
On Mon, Dec 12, 2011 at 01:49:59PM -0500, simon@mungewell.org 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
I'm finally coming back to this after quite some time.
Tried to find more info regarding the issue with the constant bit on those
input reports, but I wasn't able to come up with anything useful.
Windows just seems to ignore it.
Well, it's probably not worth it to spend anymore time on this, so I
prepared a patch that fixes the report descriptor accordingly.
I tried to follow the kernel patch policy, but since this is my first
patch I might have screwed something up. Just let me know.
Andreas