Thread (3 messages) flat view 3 messages, 2 authors, 2012-02-22

Re: Saitek PS1000 gamepad - HID descriptor wonky

From: Andreas Hübner <hidden>
Date: 2011-12-13 19:09:42

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help