Hi Vojtech,
I CC'ed the linux-usb list, I hope you don't mind.
Well, changing the usage code assignment to whatever the next available is
still seems very strange to me...I agree for a default assignment where
the code is set to the "MISC" code, then it makes sense to just use the
next code if multiple identical ones are set. But for other sections
outside of the default, the code should be set specifically to what the
device (usage) says it is. So it doesn't make sense to me to change it
for non-default cases. Do you think there is a case outside of the
default case where it does make sense to shift the usage code?
Anyway, you are right, there root cause for my device was the GENDESK
section having a rather broad fall-thru, i.e. the assignment of the usage
code to "usage->hid & 0xf" is too generic. The device has a usage of
0x00010000, which is GENDESK Usage Page and "undefined" Usage Id. The
(hid & 0xf) assignment (and no MAIN_ITEM_RELATIVE flag) assigns this usage
code to ABS_X. When the real ABS_X comes in later, with a usage of
0x00010030, GENDESK Usage Page and "X" Usage Id, the ABS_X usage code is
taken and so the "X" Usage Id is set to ABS_Y.
Fixing the GENDESK section would fix the problem also, however it is more
complex and all the Usage Ids don't correspond exactly to Input codes, so
I was reluctant to mess with it. But if you agree that would be better to
fix, I can send a patch in for that. Do you think the GENDESK Usage Id
matching should be increased significantly for most/all Usage Ids or would
you rather just adding a catch for the 0x0000 "undefined" Usage Id?
Thanks.
On Wed, 11 Aug 2004, Vojtech Pavlik wrote:
>On Tue, Aug 10, 2004 at 11:59:47PM -0400, Dan Streetman wrote:
>>
>> Should have CCed both of you.
>>
>> --
>> Dan Streetman
>> [EMAIL PROTECTED]
>> ---------------------
>> 186,272 miles per second:
>> It isn't just a good idea, it's the law!
>>
>> ---------- Forwarded message ----------
>> Date: Tue, 10 Aug 2004 13:46:13 -0400 (EDT)
>> From: Dan Streetman <[EMAIL PROTECTED]>
>> To: Linux USB devel <[EMAIL PROTECTED]>
>> Subject: [linux-usb-devel] [patch] remove find_next_zero_bit in hid-input
>>
>>
>> There is code in the hidinput_configure_usage() function that, after
>> parsing the usage info, test_and_sets the usage->code bit in the
>> appropriate bitfield. However, if the bit is already set, it searches for
>> the next available bit, and sets the usage->code to it. This doesn't make
>> sense to me, as the usage->code was set, and arbitrarily changing it to
>> the next available bit will change its meaning to an incorrect setting.
>>
>> For example I have a touchscreen that, because of this, is reporting ABS_Y
>> and ABS_Z coordinates instead of ABS_X and ABS_Y coordinates (i.e. their
>> usage->code was shifted because of this).
>>
>> This patch changes the code to only set the bit. I left the test for
>> code > max in, but that probably is not needed except as a sanity check
>> for the set_bit().
>
>The intention of that bit of code is that we often have devices where we
>are not able to assign a specific event code to a usage, so we try our
>best and assign something that looks appropriate. (see the 'default:'
>cases in the switch() tables above the lines you're changing).
>
>Without the find_next_zero_bit(), all the event codes would be the same,
>and what might be ten buttons on a joystick would only be reported as one.
>
>Yes, the event codes for them might not be completely logical, but at
>least they'll be buttons in the joystick example.
>
>Now in your touchscreen case, there must be a reason why ABS_Y is not
>available at the time the event code is being assigned to the real Y
>axis, some other valuator must've already taken it's position. Maybe
>pressure, maybe something else.
>
>In that case, adding a correct 'case:' statement for the other valuator
>will both get rid of the problem of Y being reported as ABS_Z, and the
>other valuator as ABS_Y.
>
>> Signed-off-by: Dan Streetman <[EMAIL PROTECTED]>
>>
>> --- linux-2.6.8-rc4/drivers/usb/input/hid-input.c 2004-06-16 01:19:17.000000000
>> -0400
>> +++ linux-2.6.8-rc4-input/drivers/usb/input/hid-input.c 2004-08-10
>> 13:30:38.000000000 -0400
>> @@ -383,13 +383,11 @@
>> set_bit(REL_HWHEEL, bit);
>> }
>>
>> - while (usage->code <= max && test_and_set_bit(usage->code, bit)) {
>> - usage->code = find_next_zero_bit(bit, max + 1, usage->code);
>> - }
>> -
>> if (usage->code > max)
>> return;
>>
>> + set_bit(usage->code, bit);
>> +
>> if (usage->type == EV_ABS) {
>> int a = field->logical_minimum;
>> int b = field->logical_maximum;
>
>
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
