Bug 5233
| Summary: | usb hid 'relative' input events incorrectly treated as 'absolute' events | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Jochen Eisinger (jochen) |
| Component: | USB | Assignee: | Jiri Kosina (jikos) |
| Status: | CLOSED CODE_FIX | ||
| Severity: | normal | CC: | dmitry.torokhov, jikos, paul, protasnb, vojtech |
| Priority: | P2 | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.13 | Subsystem: | |
| Regression: | --- | Bisected commit-id: | |
| Attachments: |
send a (new) REL_VOLUME event on relative volume input events
patch - emulate relative volume usage by successive KEY_VOLUME{UP,DOWN} |
||
|
Description
Jochen Eisinger
2005-09-12 12:36:28 UTC
Created attachment 5981 [details]
send a (new) REL_VOLUME event on relative volume input events
tested against vanilla 2.6.13 (incl. output from /dev/input/event)
Hmm, this seems fishy. I'll need to check the HID HUT spec. In the HUT this control isn't restricted to absolute values. While the example in the appendix A is absolute, the control itself isn't restricted (if i'm not mistaken) The patch still applies against 2.6.13.4 and 2.6.14-rc4 btw I looked into HUT specification and it said that LC control in form of spring-loaded jog dial can generate relative events. However I am not sure if adding REL_VOLUME is a good idea, nothing knows how to handle it. Would it be possible to convert such events into KEY_VOLUMEUP/KEY_VOLUMEDOWN instead? In order to convert the relative into absolute events, the driver would have to store one counter per relative volume control and modify it according to the current volume change. What 'knows' ABS_VOLUME events, I haven't really found much information about that on the web. There is actually a daemon that already understands the REL_VOLUME events (surprise, surprise) on my homepage http://penguin-breeder.org/patches/download/volumed.c It'd require adding yet another exception to hid-input.c, but it's certainly possible. I don't think translating to KEY_VOLUMEUP and KEY_VOLUMEDOWN is a solution to this problem, as a single REL_VOLUME would have to be translated into several KEY_ events. REL_VOLUME carries an information in the value field how much the volume should be changed. When translating the REL_VOLUME event into a single KEY_ event, this information would be lost. Translating to many events isn't a problem. could you point me at some example where this is done? I'm not sure how to do this. It would go something like this:
for (i = 0; i < n; i++) {
input_event(dev, EV_KEY, KEY_VOLUMEUP, 1);
input_sync(dev);
input_event(dev, EV_KEY, KEY_VOLUMEUP, 0);
input_sync(dev);
}
What's the verdict on the patch? Should it be revised, revisited? Or the problem was resolved some other way? Thanks. it's still a problem, but I lack the knowledge about the input subsystem to come up with a patch that maps REL_VOLUME to KEY_VOLUMEUP/DOWN events. Let's see if Jiri has a spare minute to imlement that quirk ;) Created attachment 11875 [details]
patch - emulate relative volume usage by successive KEY_VOLUME{UP,DOWN}
Jochen, does the attached patch work for you as expected? (it's against current HID tree, i.e. should apply cleanly to anything newer than 2.6.22-rc1).
The patch works for me, thanks a lot! Queued in my tree for upstream merge, thanks for testing. |