Bug 152545 - hiddev eats successive reports of the same value
Summary: hiddev eats successive reports of the same value
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel
Version: 4.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Pete Zaitcev
QA Contact: Brian Brock
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-03-30 07:03 UTC by Boris Shingarov
Modified: 2007-11-30 22:07 UTC (History)
3 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2006-07-25 20:34:37 UTC


Attachments (Terms of Use)
Proposed patch (497 bytes, patch)
2005-04-05 22:02 UTC, Boris Shingarov
no flags Details | Diff

Description Boris Shingarov 2005-03-30 07:03:19 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050221 Firefox/1.0 (Ubuntu) (Ubuntu package 1.0+dfsg.1-6ubuntu1)

Description of problem:
This has been described as Bug 1048 in the kernel bugzilla; however, there has been no activity on that bug since 2003 (although the bug is in the "New" state), therefore I am thinking maybe working to fix this in a RedHat specific kernel is a better idea.

The issue is, if a HID device sends a report with the same absolute value twice, the second report gets swallowed in hid_input_field().  Similarly, relative values of zero never make it through to the userland client.
The trouble with this is that there are several devices broken by this behavior (e.g., the CRYPTOCard hardtoken initializers).

Version-Release number of selected component (if applicable):
tested on 2.6.6, 2.6.9, 2.6.10, 2.6.11

How reproducible:
Always

Steps to Reproduce:
Test with any device sending host-bound reports with the same value several times in a row.  The code in hid-core.c flattens them into one report.

The code in question is in hid-core.c, function hid_input_field():

if (field->flags & HID_MAIN_ITEM_RELATIVE) {
	if (!value[n])
		continue;
} else {
	if (value[n] == field->value[n])
		continue;
}

I am not sure what negative consequences might follow if we remove this code.  We ship a patch which removes it, with our "hardtoken initializer" devices; it does not seem to break other devices.

Additional info:

Comment 1 Boris Shingarov 2005-04-05 22:02:59 UTC
Created attachment 112732 [details]
Proposed patch

This is the patch that we have been giving to the users of the KTI-1 and RBI-1
initializers for the last year or so.  It simply removes the code which eats
successive same-valued reports.

Comment 2 Pete Zaitcev 2006-07-25 20:34:37 UTC
This, unfortunately, has to be wontfix-ed. However, the good news is,
the upstream has this fix. Therefore, RHEL 5 is going to have it too.



Note You need to log in before you can comment on or make changes to this bug.