2006-12-09 00:40:44 +07:00
|
|
|
/*
|
|
|
|
* Copyright (c) 2000-2001 Vojtech Pavlik
|
2010-02-03 02:46:34 +07:00
|
|
|
* Copyright (c) 2006-2010 Jiri Kosina
|
2006-12-09 00:40:44 +07:00
|
|
|
*
|
|
|
|
* HID to Linux Input mapping
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
* the Free Software Foundation; either version 2 of the License, or
|
|
|
|
* (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
* along with this program; if not, write to the Free Software
|
|
|
|
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
|
|
|
|
*
|
|
|
|
* Should you need to contact me, the author, you can do so either by
|
|
|
|
* e-mail - mail your message to <vojtech@ucw.cz>, or by paper mail:
|
|
|
|
* Vojtech Pavlik, Simunkova 1594, Prague 8, 182 00 Czech Republic
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/slab.h>
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
|
|
|
|
#include <linux/hid.h>
|
2007-01-25 17:43:31 +07:00
|
|
|
#include <linux/hid-debug.h>
|
2006-12-09 00:40:44 +07:00
|
|
|
|
2011-12-03 02:12:36 +07:00
|
|
|
#include "hid-ids.h"
|
|
|
|
|
2006-12-09 00:40:44 +07:00
|
|
|
#define unk KEY_UNKNOWN
|
|
|
|
|
|
|
|
static const unsigned char hid_keyboard[256] = {
|
|
|
|
0, 0, 0, 0, 30, 48, 46, 32, 18, 33, 34, 35, 23, 36, 37, 38,
|
|
|
|
50, 49, 24, 25, 16, 19, 31, 20, 22, 47, 17, 45, 21, 44, 2, 3,
|
|
|
|
4, 5, 6, 7, 8, 9, 10, 11, 28, 1, 14, 15, 57, 12, 13, 26,
|
|
|
|
27, 43, 43, 39, 40, 41, 51, 52, 53, 58, 59, 60, 61, 62, 63, 64,
|
|
|
|
65, 66, 67, 68, 87, 88, 99, 70,119,110,102,104,111,107,109,106,
|
|
|
|
105,108,103, 69, 98, 55, 74, 78, 96, 79, 80, 81, 75, 76, 77, 71,
|
|
|
|
72, 73, 82, 83, 86,127,116,117,183,184,185,186,187,188,189,190,
|
|
|
|
191,192,193,194,134,138,130,132,128,129,131,137,133,135,136,113,
|
|
|
|
115,114,unk,unk,unk,121,unk, 89, 93,124, 92, 94, 95,unk,unk,unk,
|
2011-04-20 02:28:30 +07:00
|
|
|
122,123, 90, 91, 85,unk,unk,unk,unk,unk,unk,unk,111,unk,unk,unk,
|
2006-12-09 00:40:44 +07:00
|
|
|
unk,unk,unk,unk,unk,unk,unk,unk,unk,unk,unk,unk,unk,unk,unk,unk,
|
2007-08-09 18:24:11 +07:00
|
|
|
unk,unk,unk,unk,unk,unk,179,180,unk,unk,unk,unk,unk,unk,unk,unk,
|
2006-12-09 00:40:44 +07:00
|
|
|
unk,unk,unk,unk,unk,unk,unk,unk,unk,unk,unk,unk,unk,unk,unk,unk,
|
2011-04-20 02:28:30 +07:00
|
|
|
unk,unk,unk,unk,unk,unk,unk,unk,111,unk,unk,unk,unk,unk,unk,unk,
|
2006-12-09 00:40:44 +07:00
|
|
|
29, 42, 56,125, 97, 54,100,126,164,166,165,163,161,115,114,113,
|
|
|
|
150,158,159,128,136,177,178,176,142,152,173,140,unk,unk,unk,unk
|
|
|
|
};
|
|
|
|
|
|
|
|
static const struct {
|
|
|
|
__s32 x;
|
|
|
|
__s32 y;
|
|
|
|
} hid_hat_to_axis[] = {{ 0, 0}, { 0,-1}, { 1,-1}, { 1, 0}, { 1, 1}, { 0, 1}, {-1, 1}, {-1, 0}, {-1,-1}};
|
|
|
|
|
2008-05-16 16:49:18 +07:00
|
|
|
#define map_abs(c) hid_map_usage(hidinput, usage, &bit, &max, EV_ABS, (c))
|
|
|
|
#define map_rel(c) hid_map_usage(hidinput, usage, &bit, &max, EV_REL, (c))
|
|
|
|
#define map_key(c) hid_map_usage(hidinput, usage, &bit, &max, EV_KEY, (c))
|
|
|
|
#define map_led(c) hid_map_usage(hidinput, usage, &bit, &max, EV_LED, (c))
|
2006-12-09 00:40:44 +07:00
|
|
|
|
2008-05-16 16:49:18 +07:00
|
|
|
#define map_abs_clear(c) hid_map_usage_clear(hidinput, usage, &bit, \
|
|
|
|
&max, EV_ABS, (c))
|
|
|
|
#define map_key_clear(c) hid_map_usage_clear(hidinput, usage, &bit, \
|
|
|
|
&max, EV_KEY, (c))
|
2006-12-09 00:40:44 +07:00
|
|
|
|
2010-09-10 11:57:17 +07:00
|
|
|
static bool match_scancode(struct hid_usage *usage,
|
|
|
|
unsigned int cur_idx, unsigned int scancode)
|
2007-05-09 15:57:20 +07:00
|
|
|
{
|
2010-09-10 11:57:17 +07:00
|
|
|
return (usage->hid & (HID_USAGE_PAGE | HID_USAGE)) == scancode;
|
2007-05-09 15:57:20 +07:00
|
|
|
}
|
|
|
|
|
2010-09-10 11:57:17 +07:00
|
|
|
static bool match_keycode(struct hid_usage *usage,
|
|
|
|
unsigned int cur_idx, unsigned int keycode)
|
2007-05-09 15:57:20 +07:00
|
|
|
{
|
2010-09-16 09:36:56 +07:00
|
|
|
/*
|
|
|
|
* We should exclude unmapped usages when doing lookup by keycode.
|
|
|
|
*/
|
|
|
|
return (usage->type == EV_KEY && usage->code == keycode);
|
2010-09-10 11:57:17 +07:00
|
|
|
}
|
2010-03-09 13:37:10 +07:00
|
|
|
|
2010-09-10 11:57:17 +07:00
|
|
|
static bool match_index(struct hid_usage *usage,
|
|
|
|
unsigned int cur_idx, unsigned int idx)
|
|
|
|
{
|
|
|
|
return cur_idx == idx;
|
2007-05-09 15:57:20 +07:00
|
|
|
}
|
|
|
|
|
2010-09-10 11:57:17 +07:00
|
|
|
typedef bool (*hid_usage_cmp_t)(struct hid_usage *usage,
|
|
|
|
unsigned int cur_idx, unsigned int val);
|
|
|
|
|
2007-05-09 15:57:20 +07:00
|
|
|
static struct hid_usage *hidinput_find_key(struct hid_device *hid,
|
2010-09-10 11:57:17 +07:00
|
|
|
hid_usage_cmp_t match,
|
|
|
|
unsigned int value,
|
|
|
|
unsigned int *usage_idx)
|
2007-05-09 15:57:20 +07:00
|
|
|
{
|
2010-09-10 11:57:17 +07:00
|
|
|
unsigned int i, j, k, cur_idx = 0;
|
2007-05-09 15:57:20 +07:00
|
|
|
struct hid_report *report;
|
|
|
|
struct hid_usage *usage;
|
|
|
|
|
|
|
|
for (k = HID_INPUT_REPORT; k <= HID_OUTPUT_REPORT; k++) {
|
|
|
|
list_for_each_entry(report, &hid->report_enum[k].report_list, list) {
|
|
|
|
for (i = 0; i < report->maxfield; i++) {
|
2010-09-10 11:57:17 +07:00
|
|
|
for (j = 0; j < report->field[i]->maxusage; j++) {
|
2007-05-09 15:57:20 +07:00
|
|
|
usage = report->field[i]->usage + j;
|
2010-09-16 09:36:56 +07:00
|
|
|
if (usage->type == EV_KEY || usage->type == 0) {
|
2010-09-10 11:57:17 +07:00
|
|
|
if (match(usage, cur_idx, value)) {
|
|
|
|
if (usage_idx)
|
|
|
|
*usage_idx = cur_idx;
|
|
|
|
return usage;
|
|
|
|
}
|
|
|
|
cur_idx++;
|
|
|
|
}
|
2007-05-09 15:57:20 +07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2010-09-10 11:57:17 +07:00
|
|
|
static struct hid_usage *hidinput_locate_usage(struct hid_device *hid,
|
|
|
|
const struct input_keymap_entry *ke,
|
|
|
|
unsigned int *index)
|
|
|
|
{
|
|
|
|
struct hid_usage *usage;
|
|
|
|
unsigned int scancode;
|
|
|
|
|
|
|
|
if (ke->flags & INPUT_KEYMAP_BY_INDEX)
|
|
|
|
usage = hidinput_find_key(hid, match_index, ke->index, index);
|
|
|
|
else if (input_scancode_to_scalar(ke, &scancode) == 0)
|
|
|
|
usage = hidinput_find_key(hid, match_scancode, scancode, index);
|
|
|
|
else
|
|
|
|
usage = NULL;
|
|
|
|
|
|
|
|
return usage;
|
|
|
|
}
|
|
|
|
|
2010-03-09 13:37:10 +07:00
|
|
|
static int hidinput_getkeycode(struct input_dev *dev,
|
2010-09-10 11:57:17 +07:00
|
|
|
struct input_keymap_entry *ke)
|
2007-05-09 15:57:20 +07:00
|
|
|
{
|
2007-10-31 18:33:26 +07:00
|
|
|
struct hid_device *hid = input_get_drvdata(dev);
|
2007-05-09 15:57:20 +07:00
|
|
|
struct hid_usage *usage;
|
2010-09-10 11:57:17 +07:00
|
|
|
unsigned int scancode, index;
|
2007-08-09 19:04:56 +07:00
|
|
|
|
2010-09-10 11:57:17 +07:00
|
|
|
usage = hidinput_locate_usage(hid, ke, &index);
|
2007-05-09 15:57:20 +07:00
|
|
|
if (usage) {
|
2010-09-16 09:36:56 +07:00
|
|
|
ke->keycode = usage->type == EV_KEY ?
|
|
|
|
usage->code : KEY_RESERVED;
|
2010-09-10 11:57:17 +07:00
|
|
|
ke->index = index;
|
|
|
|
scancode = usage->hid & (HID_USAGE_PAGE | HID_USAGE);
|
|
|
|
ke->len = sizeof(scancode);
|
|
|
|
memcpy(ke->scancode, &scancode, sizeof(scancode));
|
2007-05-09 15:57:20 +07:00
|
|
|
return 0;
|
|
|
|
}
|
2010-09-10 11:57:17 +07:00
|
|
|
|
2007-05-09 15:57:20 +07:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2010-03-09 13:37:10 +07:00
|
|
|
static int hidinput_setkeycode(struct input_dev *dev,
|
2010-09-10 11:57:17 +07:00
|
|
|
const struct input_keymap_entry *ke,
|
|
|
|
unsigned int *old_keycode)
|
2007-05-09 15:57:20 +07:00
|
|
|
{
|
2007-10-31 18:33:26 +07:00
|
|
|
struct hid_device *hid = input_get_drvdata(dev);
|
2007-05-09 15:57:20 +07:00
|
|
|
struct hid_usage *usage;
|
2007-08-09 19:04:56 +07:00
|
|
|
|
2010-09-10 11:57:17 +07:00
|
|
|
usage = hidinput_locate_usage(hid, ke, NULL);
|
2007-05-09 15:57:20 +07:00
|
|
|
if (usage) {
|
2010-09-16 09:36:56 +07:00
|
|
|
*old_keycode = usage->type == EV_KEY ?
|
|
|
|
usage->code : KEY_RESERVED;
|
2010-09-10 11:57:17 +07:00
|
|
|
usage->code = ke->keycode;
|
2007-08-09 19:04:56 +07:00
|
|
|
|
2010-09-10 11:57:17 +07:00
|
|
|
clear_bit(*old_keycode, dev->keybit);
|
2007-05-09 15:57:20 +07:00
|
|
|
set_bit(usage->code, dev->keybit);
|
2010-10-26 09:44:21 +07:00
|
|
|
dbg_hid("Assigned keycode %d to HID usage code %x\n",
|
2010-09-10 11:57:17 +07:00
|
|
|
usage->code, usage->hid);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Set the keybit for the old keycode if the old keycode is used
|
|
|
|
* by another key
|
|
|
|
*/
|
|
|
|
if (hidinput_find_key(hid, match_keycode, *old_keycode, NULL))
|
|
|
|
set_bit(*old_keycode, dev->keybit);
|
2007-08-09 19:04:56 +07:00
|
|
|
|
2007-05-09 15:57:20 +07:00
|
|
|
return 0;
|
|
|
|
}
|
2007-08-09 19:04:56 +07:00
|
|
|
|
2007-05-09 15:57:20 +07:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
HID: Fix unit exponent parsing again
Revert some changes done in 774638386826621c984ab6994439f474709cac5e.
Revert all changes done in hidinput_calc_abs_res as it mistakingly used
"Unit" item exponent nibbles to affect resolution value. This wasn't
breaking resolution calculation of relevant axes of any existing
devices, though, as they have only one dimension to their units and thus
1 in the corresponding nible.
Revert to reading "Unit Exponent" item value as a signed integer in
hid_parser_global to fix reading specification-complying values. This
fixes resolution calculation of devices complying to the HID standard,
including Huion, KYE, Waltop and UC-Logic graphics tablets which have
their report descriptors fixed by the drivers.
Explanations follow.
There are two "unit exponents" in HID specification and it is important
not to mix them. One is the global "Unit Exponent" item and another is
nibble values in the global "Unit" item. See 6.2.2.7 Global Items.
The "Unit Exponent" value is just a signed integer and is used to scale
the integer resolution unit values, so fractions can be expressed.
The nibbles of "Unit" value are used to select the unit system (nibble
0), and presence of a particular basic unit type in the unit formula and
its *exponent* (or power, nibbles 1-6). And yes, the latter is in two
complement and zero means absence of the unit type.
Taking the representation example of (integer) joules from the
specification:
[mass(grams)][length(centimeters)^2][time(seconds)^-2] * 10^-7
the "Unit Exponent" would be -7 (or 0xF9, if stored as a byte) and the
"Unit" value would be 0xE121, signifying:
Nibble Part Value Meaning
----- ---- ----- -------
0 System 1 SI Linear
1 Length 2 Centimeters^2
2 Mass 1 Grams
3 Time -2 Seconds^-2
To give the resolution in e.g. hundredth of joules the "Unit Exponent"
item value should have been -9.
See also the examples of "Unit" values for some common units in the same
chapter.
However, there is a common misunderstanding about the "Unit Exponent"
value encoding, where it is assumed to be stored the same as nibbles in
"Unit" item. This is most likely due to the specification being a bit
vague and overloading the term "unit exponent". This also was and still
is proliferated by the official "HID Descriptor Tool", which makes this
mistake and stores "Unit Exponent" as such. This format is also
mentioned in books such as "USB Complete" and in Microsoft's hardware
design guides.
As a result many devices currently on the market use this encoding and
so the driver should support them.
Signed-off-by: Nikolai Kondrashov <spbnick@gmail.com>
Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-10-13 19:09:52 +07:00
|
|
|
|
2010-09-15 17:51:14 +07:00
|
|
|
/**
|
|
|
|
* hidinput_calc_abs_res - calculate an absolute axis resolution
|
|
|
|
* @field: the HID report field to calculate resolution for
|
|
|
|
* @code: axis code
|
|
|
|
*
|
|
|
|
* The formula is:
|
|
|
|
* (logical_maximum - logical_minimum)
|
|
|
|
* resolution = ----------------------------------------------------------
|
|
|
|
* (physical_maximum - physical_minimum) * 10 ^ unit_exponent
|
|
|
|
*
|
|
|
|
* as seen in the HID specification v1.11 6.2.2.7 Global Items.
|
|
|
|
*
|
2010-12-02 17:49:06 +07:00
|
|
|
* Only exponent 1 length units are processed. Centimeters and inches are
|
|
|
|
* converted to millimeters. Degrees are converted to radians.
|
2010-09-15 17:51:14 +07:00
|
|
|
*/
|
2012-11-14 22:59:13 +07:00
|
|
|
__s32 hidinput_calc_abs_res(const struct hid_field *field, __u16 code)
|
2010-09-15 17:51:14 +07:00
|
|
|
{
|
|
|
|
__s32 unit_exponent = field->unit_exponent;
|
|
|
|
__s32 logical_extents = field->logical_maximum -
|
|
|
|
field->logical_minimum;
|
|
|
|
__s32 physical_extents = field->physical_maximum -
|
|
|
|
field->physical_minimum;
|
|
|
|
__s32 prev;
|
|
|
|
|
|
|
|
/* Check if the extents are sane */
|
|
|
|
if (logical_extents <= 0 || physical_extents <= 0)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Verify and convert units.
|
|
|
|
* See HID specification v1.11 6.2.2.7 Global Items for unit decoding
|
|
|
|
*/
|
2012-03-20 21:01:32 +07:00
|
|
|
switch (code) {
|
|
|
|
case ABS_X:
|
|
|
|
case ABS_Y:
|
|
|
|
case ABS_Z:
|
2012-11-14 22:59:13 +07:00
|
|
|
case ABS_MT_POSITION_X:
|
|
|
|
case ABS_MT_POSITION_Y:
|
|
|
|
case ABS_MT_TOOL_X:
|
|
|
|
case ABS_MT_TOOL_Y:
|
|
|
|
case ABS_MT_TOUCH_MAJOR:
|
|
|
|
case ABS_MT_TOUCH_MINOR:
|
HID: Fix unit exponent parsing again
Revert some changes done in 774638386826621c984ab6994439f474709cac5e.
Revert all changes done in hidinput_calc_abs_res as it mistakingly used
"Unit" item exponent nibbles to affect resolution value. This wasn't
breaking resolution calculation of relevant axes of any existing
devices, though, as they have only one dimension to their units and thus
1 in the corresponding nible.
Revert to reading "Unit Exponent" item value as a signed integer in
hid_parser_global to fix reading specification-complying values. This
fixes resolution calculation of devices complying to the HID standard,
including Huion, KYE, Waltop and UC-Logic graphics tablets which have
their report descriptors fixed by the drivers.
Explanations follow.
There are two "unit exponents" in HID specification and it is important
not to mix them. One is the global "Unit Exponent" item and another is
nibble values in the global "Unit" item. See 6.2.2.7 Global Items.
The "Unit Exponent" value is just a signed integer and is used to scale
the integer resolution unit values, so fractions can be expressed.
The nibbles of "Unit" value are used to select the unit system (nibble
0), and presence of a particular basic unit type in the unit formula and
its *exponent* (or power, nibbles 1-6). And yes, the latter is in two
complement and zero means absence of the unit type.
Taking the representation example of (integer) joules from the
specification:
[mass(grams)][length(centimeters)^2][time(seconds)^-2] * 10^-7
the "Unit Exponent" would be -7 (or 0xF9, if stored as a byte) and the
"Unit" value would be 0xE121, signifying:
Nibble Part Value Meaning
----- ---- ----- -------
0 System 1 SI Linear
1 Length 2 Centimeters^2
2 Mass 1 Grams
3 Time -2 Seconds^-2
To give the resolution in e.g. hundredth of joules the "Unit Exponent"
item value should have been -9.
See also the examples of "Unit" values for some common units in the same
chapter.
However, there is a common misunderstanding about the "Unit Exponent"
value encoding, where it is assumed to be stored the same as nibbles in
"Unit" item. This is most likely due to the specification being a bit
vague and overloading the term "unit exponent". This also was and still
is proliferated by the official "HID Descriptor Tool", which makes this
mistake and stores "Unit Exponent" as such. This format is also
mentioned in books such as "USB Complete" and in Microsoft's hardware
design guides.
As a result many devices currently on the market use this encoding and
so the driver should support them.
Signed-off-by: Nikolai Kondrashov <spbnick@gmail.com>
Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-10-13 19:09:52 +07:00
|
|
|
if (field->unit == 0x11) { /* If centimeters */
|
2010-12-02 17:49:06 +07:00
|
|
|
/* Convert to millimeters */
|
|
|
|
unit_exponent += 1;
|
HID: Fix unit exponent parsing again
Revert some changes done in 774638386826621c984ab6994439f474709cac5e.
Revert all changes done in hidinput_calc_abs_res as it mistakingly used
"Unit" item exponent nibbles to affect resolution value. This wasn't
breaking resolution calculation of relevant axes of any existing
devices, though, as they have only one dimension to their units and thus
1 in the corresponding nible.
Revert to reading "Unit Exponent" item value as a signed integer in
hid_parser_global to fix reading specification-complying values. This
fixes resolution calculation of devices complying to the HID standard,
including Huion, KYE, Waltop and UC-Logic graphics tablets which have
their report descriptors fixed by the drivers.
Explanations follow.
There are two "unit exponents" in HID specification and it is important
not to mix them. One is the global "Unit Exponent" item and another is
nibble values in the global "Unit" item. See 6.2.2.7 Global Items.
The "Unit Exponent" value is just a signed integer and is used to scale
the integer resolution unit values, so fractions can be expressed.
The nibbles of "Unit" value are used to select the unit system (nibble
0), and presence of a particular basic unit type in the unit formula and
its *exponent* (or power, nibbles 1-6). And yes, the latter is in two
complement and zero means absence of the unit type.
Taking the representation example of (integer) joules from the
specification:
[mass(grams)][length(centimeters)^2][time(seconds)^-2] * 10^-7
the "Unit Exponent" would be -7 (or 0xF9, if stored as a byte) and the
"Unit" value would be 0xE121, signifying:
Nibble Part Value Meaning
----- ---- ----- -------
0 System 1 SI Linear
1 Length 2 Centimeters^2
2 Mass 1 Grams
3 Time -2 Seconds^-2
To give the resolution in e.g. hundredth of joules the "Unit Exponent"
item value should have been -9.
See also the examples of "Unit" values for some common units in the same
chapter.
However, there is a common misunderstanding about the "Unit Exponent"
value encoding, where it is assumed to be stored the same as nibbles in
"Unit" item. This is most likely due to the specification being a bit
vague and overloading the term "unit exponent". This also was and still
is proliferated by the official "HID Descriptor Tool", which makes this
mistake and stores "Unit Exponent" as such. This format is also
mentioned in books such as "USB Complete" and in Microsoft's hardware
design guides.
As a result many devices currently on the market use this encoding and
so the driver should support them.
Signed-off-by: Nikolai Kondrashov <spbnick@gmail.com>
Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-10-13 19:09:52 +07:00
|
|
|
} else if (field->unit == 0x13) { /* If inches */
|
2010-12-02 17:49:06 +07:00
|
|
|
/* Convert to millimeters */
|
|
|
|
prev = physical_extents;
|
|
|
|
physical_extents *= 254;
|
|
|
|
if (physical_extents < prev)
|
2010-09-15 17:51:14 +07:00
|
|
|
return 0;
|
2010-12-02 17:49:06 +07:00
|
|
|
unit_exponent -= 1;
|
HID: Fix unit exponent parsing again
Revert some changes done in 774638386826621c984ab6994439f474709cac5e.
Revert all changes done in hidinput_calc_abs_res as it mistakingly used
"Unit" item exponent nibbles to affect resolution value. This wasn't
breaking resolution calculation of relevant axes of any existing
devices, though, as they have only one dimension to their units and thus
1 in the corresponding nible.
Revert to reading "Unit Exponent" item value as a signed integer in
hid_parser_global to fix reading specification-complying values. This
fixes resolution calculation of devices complying to the HID standard,
including Huion, KYE, Waltop and UC-Logic graphics tablets which have
their report descriptors fixed by the drivers.
Explanations follow.
There are two "unit exponents" in HID specification and it is important
not to mix them. One is the global "Unit Exponent" item and another is
nibble values in the global "Unit" item. See 6.2.2.7 Global Items.
The "Unit Exponent" value is just a signed integer and is used to scale
the integer resolution unit values, so fractions can be expressed.
The nibbles of "Unit" value are used to select the unit system (nibble
0), and presence of a particular basic unit type in the unit formula and
its *exponent* (or power, nibbles 1-6). And yes, the latter is in two
complement and zero means absence of the unit type.
Taking the representation example of (integer) joules from the
specification:
[mass(grams)][length(centimeters)^2][time(seconds)^-2] * 10^-7
the "Unit Exponent" would be -7 (or 0xF9, if stored as a byte) and the
"Unit" value would be 0xE121, signifying:
Nibble Part Value Meaning
----- ---- ----- -------
0 System 1 SI Linear
1 Length 2 Centimeters^2
2 Mass 1 Grams
3 Time -2 Seconds^-2
To give the resolution in e.g. hundredth of joules the "Unit Exponent"
item value should have been -9.
See also the examples of "Unit" values for some common units in the same
chapter.
However, there is a common misunderstanding about the "Unit Exponent"
value encoding, where it is assumed to be stored the same as nibbles in
"Unit" item. This is most likely due to the specification being a bit
vague and overloading the term "unit exponent". This also was and still
is proliferated by the official "HID Descriptor Tool", which makes this
mistake and stores "Unit Exponent" as such. This format is also
mentioned in books such as "USB Complete" and in Microsoft's hardware
design guides.
As a result many devices currently on the market use this encoding and
so the driver should support them.
Signed-off-by: Nikolai Kondrashov <spbnick@gmail.com>
Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-10-13 19:09:52 +07:00
|
|
|
} else {
|
2010-09-15 17:51:14 +07:00
|
|
|
return 0;
|
|
|
|
}
|
2012-03-20 21:01:32 +07:00
|
|
|
break;
|
|
|
|
|
|
|
|
case ABS_RX:
|
|
|
|
case ABS_RY:
|
|
|
|
case ABS_RZ:
|
|
|
|
case ABS_TILT_X:
|
|
|
|
case ABS_TILT_Y:
|
2010-09-15 17:51:14 +07:00
|
|
|
if (field->unit == 0x14) { /* If degrees */
|
|
|
|
/* Convert to radians */
|
|
|
|
prev = logical_extents;
|
|
|
|
logical_extents *= 573;
|
|
|
|
if (logical_extents < prev)
|
|
|
|
return 0;
|
|
|
|
unit_exponent += 1;
|
|
|
|
} else if (field->unit != 0x12) { /* If not radians */
|
|
|
|
return 0;
|
|
|
|
}
|
2012-03-20 21:01:32 +07:00
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
2010-09-15 17:51:14 +07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Apply negative unit exponent */
|
|
|
|
for (; unit_exponent < 0; unit_exponent++) {
|
|
|
|
prev = logical_extents;
|
|
|
|
logical_extents *= 10;
|
|
|
|
if (logical_extents < prev)
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
/* Apply positive unit exponent */
|
|
|
|
for (; unit_exponent > 0; unit_exponent--) {
|
|
|
|
prev = physical_extents;
|
|
|
|
physical_extents *= 10;
|
|
|
|
if (physical_extents < prev)
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Calculate resolution */
|
2012-11-14 22:59:14 +07:00
|
|
|
return DIV_ROUND_CLOSEST(logical_extents, physical_extents);
|
2010-09-15 17:51:14 +07:00
|
|
|
}
|
2012-11-14 22:59:13 +07:00
|
|
|
EXPORT_SYMBOL_GPL(hidinput_calc_abs_res);
|
2010-09-15 17:51:14 +07:00
|
|
|
|
HID: hid-input: add support for HID devices reporting Battery Strength
Some HID devices, such as my Bluetooth mouse, report their battery
strength as an event. Rather than passing it through as a strange
absolute input event, this patch registers it with the power_supply
subsystem as a battery, so that the device's Battery Strength can be
reported to usermode.
The battery appears in sysfs names
/sys/class/power_supply/hid-<UNIQ>-battery, and it is a child of the
battery-containing device, so it should be clear what it's the battery of.
Unfortunately on my current Fedora 16 system, while the battery does
appear in the UI, it is listed as a Laptop Battery with 0% charge (since
it ignores the "capacity" property of the battery and instead computes
it from the "energy*" fields, which we can't supply given the limited
information contained within the HID Report).
Still, this patch is the first step.
Signed-off-by: Jeremy Fitzhardinge <jeremy@goop.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-23 15:49:14 +07:00
|
|
|
#ifdef CONFIG_HID_BATTERY_STRENGTH
|
|
|
|
static enum power_supply_property hidinput_battery_props[] = {
|
|
|
|
POWER_SUPPLY_PROP_PRESENT,
|
|
|
|
POWER_SUPPLY_PROP_ONLINE,
|
|
|
|
POWER_SUPPLY_PROP_CAPACITY,
|
|
|
|
POWER_SUPPLY_PROP_MODEL_NAME,
|
2011-12-08 08:31:43 +07:00
|
|
|
POWER_SUPPLY_PROP_STATUS,
|
|
|
|
POWER_SUPPLY_PROP_SCOPE,
|
HID: hid-input: add support for HID devices reporting Battery Strength
Some HID devices, such as my Bluetooth mouse, report their battery
strength as an event. Rather than passing it through as a strange
absolute input event, this patch registers it with the power_supply
subsystem as a battery, so that the device's Battery Strength can be
reported to usermode.
The battery appears in sysfs names
/sys/class/power_supply/hid-<UNIQ>-battery, and it is a child of the
battery-containing device, so it should be clear what it's the battery of.
Unfortunately on my current Fedora 16 system, while the battery does
appear in the UI, it is listed as a Laptop Battery with 0% charge (since
it ignores the "capacity" property of the battery and instead computes
it from the "energy*" fields, which we can't supply given the limited
information contained within the HID Report).
Still, this patch is the first step.
Signed-off-by: Jeremy Fitzhardinge <jeremy@goop.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-23 15:49:14 +07:00
|
|
|
};
|
|
|
|
|
2011-12-03 02:12:36 +07:00
|
|
|
#define HID_BATTERY_QUIRK_PERCENT (1 << 0) /* always reports percent */
|
2011-12-09 15:10:28 +07:00
|
|
|
#define HID_BATTERY_QUIRK_FEATURE (1 << 1) /* ask for feature report */
|
2015-12-14 19:42:26 +07:00
|
|
|
#define HID_BATTERY_QUIRK_IGNORE (1 << 2) /* completely ignore the battery */
|
2011-12-03 02:12:36 +07:00
|
|
|
|
|
|
|
static const struct hid_device_id hid_battery_quirks[] = {
|
2012-11-25 21:08:34 +07:00
|
|
|
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE,
|
2014-12-21 07:01:35 +07:00
|
|
|
USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_ISO),
|
|
|
|
HID_BATTERY_QUIRK_PERCENT | HID_BATTERY_QUIRK_FEATURE },
|
|
|
|
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE,
|
|
|
|
USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_ANSI),
|
|
|
|
HID_BATTERY_QUIRK_PERCENT | HID_BATTERY_QUIRK_FEATURE },
|
2011-12-09 15:10:28 +07:00
|
|
|
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE,
|
2014-12-21 07:01:35 +07:00
|
|
|
USB_DEVICE_ID_APPLE_ALU_WIRELESS_2011_ANSI),
|
2011-12-09 15:10:28 +07:00
|
|
|
HID_BATTERY_QUIRK_PERCENT | HID_BATTERY_QUIRK_FEATURE },
|
2014-12-16 22:37:22 +07:00
|
|
|
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE,
|
|
|
|
USB_DEVICE_ID_APPLE_ALU_WIRELESS_2011_ISO),
|
|
|
|
HID_BATTERY_QUIRK_PERCENT | HID_BATTERY_QUIRK_FEATURE },
|
2012-07-04 20:20:31 +07:00
|
|
|
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE,
|
|
|
|
USB_DEVICE_ID_APPLE_ALU_WIRELESS_ANSI),
|
|
|
|
HID_BATTERY_QUIRK_PERCENT | HID_BATTERY_QUIRK_FEATURE },
|
2015-12-14 19:42:26 +07:00
|
|
|
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_ELECOM,
|
|
|
|
USB_DEVICE_ID_ELECOM_BM084),
|
|
|
|
HID_BATTERY_QUIRK_IGNORE },
|
2011-12-03 02:12:36 +07:00
|
|
|
{}
|
|
|
|
};
|
|
|
|
|
|
|
|
static unsigned find_battery_quirk(struct hid_device *hdev)
|
|
|
|
{
|
|
|
|
unsigned quirks = 0;
|
|
|
|
const struct hid_device_id *match;
|
|
|
|
|
|
|
|
match = hid_match_id(hdev, hid_battery_quirks);
|
|
|
|
if (match != NULL)
|
|
|
|
quirks = match->driver_data;
|
|
|
|
|
|
|
|
return quirks;
|
|
|
|
}
|
|
|
|
|
HID: hid-input: add support for HID devices reporting Battery Strength
Some HID devices, such as my Bluetooth mouse, report their battery
strength as an event. Rather than passing it through as a strange
absolute input event, this patch registers it with the power_supply
subsystem as a battery, so that the device's Battery Strength can be
reported to usermode.
The battery appears in sysfs names
/sys/class/power_supply/hid-<UNIQ>-battery, and it is a child of the
battery-containing device, so it should be clear what it's the battery of.
Unfortunately on my current Fedora 16 system, while the battery does
appear in the UI, it is listed as a Laptop Battery with 0% charge (since
it ignores the "capacity" property of the battery and instead computes
it from the "energy*" fields, which we can't supply given the limited
information contained within the HID Report).
Still, this patch is the first step.
Signed-off-by: Jeremy Fitzhardinge <jeremy@goop.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-23 15:49:14 +07:00
|
|
|
static int hidinput_get_battery_property(struct power_supply *psy,
|
|
|
|
enum power_supply_property prop,
|
|
|
|
union power_supply_propval *val)
|
|
|
|
{
|
2015-03-12 14:44:11 +07:00
|
|
|
struct hid_device *dev = power_supply_get_drvdata(psy);
|
HID: hid-input: add support for HID devices reporting Battery Strength
Some HID devices, such as my Bluetooth mouse, report their battery
strength as an event. Rather than passing it through as a strange
absolute input event, this patch registers it with the power_supply
subsystem as a battery, so that the device's Battery Strength can be
reported to usermode.
The battery appears in sysfs names
/sys/class/power_supply/hid-<UNIQ>-battery, and it is a child of the
battery-containing device, so it should be clear what it's the battery of.
Unfortunately on my current Fedora 16 system, while the battery does
appear in the UI, it is listed as a Laptop Battery with 0% charge (since
it ignores the "capacity" property of the battery and instead computes
it from the "energy*" fields, which we can't supply given the limited
information contained within the HID Report).
Still, this patch is the first step.
Signed-off-by: Jeremy Fitzhardinge <jeremy@goop.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-23 15:49:14 +07:00
|
|
|
int ret = 0;
|
2013-09-02 18:43:00 +07:00
|
|
|
__u8 *buf;
|
HID: hid-input: add support for HID devices reporting Battery Strength
Some HID devices, such as my Bluetooth mouse, report their battery
strength as an event. Rather than passing it through as a strange
absolute input event, this patch registers it with the power_supply
subsystem as a battery, so that the device's Battery Strength can be
reported to usermode.
The battery appears in sysfs names
/sys/class/power_supply/hid-<UNIQ>-battery, and it is a child of the
battery-containing device, so it should be clear what it's the battery of.
Unfortunately on my current Fedora 16 system, while the battery does
appear in the UI, it is listed as a Laptop Battery with 0% charge (since
it ignores the "capacity" property of the battery and instead computes
it from the "energy*" fields, which we can't supply given the limited
information contained within the HID Report).
Still, this patch is the first step.
Signed-off-by: Jeremy Fitzhardinge <jeremy@goop.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-23 15:49:14 +07:00
|
|
|
|
|
|
|
switch (prop) {
|
|
|
|
case POWER_SUPPLY_PROP_PRESENT:
|
|
|
|
case POWER_SUPPLY_PROP_ONLINE:
|
|
|
|
val->intval = 1;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case POWER_SUPPLY_PROP_CAPACITY:
|
2013-09-02 18:43:00 +07:00
|
|
|
|
|
|
|
buf = kmalloc(2 * sizeof(__u8), GFP_KERNEL);
|
|
|
|
if (!buf) {
|
|
|
|
ret = -ENOMEM;
|
|
|
|
break;
|
|
|
|
}
|
2014-02-06 04:33:22 +07:00
|
|
|
ret = hid_hw_raw_request(dev, dev->battery_report_id, buf, 2,
|
|
|
|
dev->battery_report_type,
|
|
|
|
HID_REQ_GET_REPORT);
|
2011-12-09 15:10:28 +07:00
|
|
|
|
|
|
|
if (ret != 2) {
|
2013-05-13 22:01:30 +07:00
|
|
|
ret = -ENODATA;
|
2013-09-02 18:43:00 +07:00
|
|
|
kfree(buf);
|
2011-12-02 12:52:22 +07:00
|
|
|
break;
|
|
|
|
}
|
2013-05-13 22:01:30 +07:00
|
|
|
ret = 0;
|
2011-12-02 12:52:22 +07:00
|
|
|
|
HID: hid-input: add support for HID devices reporting Battery Strength
Some HID devices, such as my Bluetooth mouse, report their battery
strength as an event. Rather than passing it through as a strange
absolute input event, this patch registers it with the power_supply
subsystem as a battery, so that the device's Battery Strength can be
reported to usermode.
The battery appears in sysfs names
/sys/class/power_supply/hid-<UNIQ>-battery, and it is a child of the
battery-containing device, so it should be clear what it's the battery of.
Unfortunately on my current Fedora 16 system, while the battery does
appear in the UI, it is listed as a Laptop Battery with 0% charge (since
it ignores the "capacity" property of the battery and instead computes
it from the "energy*" fields, which we can't supply given the limited
information contained within the HID Report).
Still, this patch is the first step.
Signed-off-by: Jeremy Fitzhardinge <jeremy@goop.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-23 15:49:14 +07:00
|
|
|
if (dev->battery_min < dev->battery_max &&
|
2011-12-03 02:12:36 +07:00
|
|
|
buf[1] >= dev->battery_min &&
|
|
|
|
buf[1] <= dev->battery_max)
|
|
|
|
val->intval = (100 * (buf[1] - dev->battery_min)) /
|
HID: hid-input: add support for HID devices reporting Battery Strength
Some HID devices, such as my Bluetooth mouse, report their battery
strength as an event. Rather than passing it through as a strange
absolute input event, this patch registers it with the power_supply
subsystem as a battery, so that the device's Battery Strength can be
reported to usermode.
The battery appears in sysfs names
/sys/class/power_supply/hid-<UNIQ>-battery, and it is a child of the
battery-containing device, so it should be clear what it's the battery of.
Unfortunately on my current Fedora 16 system, while the battery does
appear in the UI, it is listed as a Laptop Battery with 0% charge (since
it ignores the "capacity" property of the battery and instead computes
it from the "energy*" fields, which we can't supply given the limited
information contained within the HID Report).
Still, this patch is the first step.
Signed-off-by: Jeremy Fitzhardinge <jeremy@goop.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-23 15:49:14 +07:00
|
|
|
(dev->battery_max - dev->battery_min);
|
2013-09-02 18:43:00 +07:00
|
|
|
kfree(buf);
|
HID: hid-input: add support for HID devices reporting Battery Strength
Some HID devices, such as my Bluetooth mouse, report their battery
strength as an event. Rather than passing it through as a strange
absolute input event, this patch registers it with the power_supply
subsystem as a battery, so that the device's Battery Strength can be
reported to usermode.
The battery appears in sysfs names
/sys/class/power_supply/hid-<UNIQ>-battery, and it is a child of the
battery-containing device, so it should be clear what it's the battery of.
Unfortunately on my current Fedora 16 system, while the battery does
appear in the UI, it is listed as a Laptop Battery with 0% charge (since
it ignores the "capacity" property of the battery and instead computes
it from the "energy*" fields, which we can't supply given the limited
information contained within the HID Report).
Still, this patch is the first step.
Signed-off-by: Jeremy Fitzhardinge <jeremy@goop.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-23 15:49:14 +07:00
|
|
|
break;
|
|
|
|
|
|
|
|
case POWER_SUPPLY_PROP_MODEL_NAME:
|
|
|
|
val->strval = dev->name;
|
|
|
|
break;
|
|
|
|
|
2011-12-02 12:52:22 +07:00
|
|
|
case POWER_SUPPLY_PROP_STATUS:
|
|
|
|
val->intval = POWER_SUPPLY_STATUS_DISCHARGING;
|
|
|
|
break;
|
|
|
|
|
2011-12-08 08:31:43 +07:00
|
|
|
case POWER_SUPPLY_PROP_SCOPE:
|
|
|
|
val->intval = POWER_SUPPLY_SCOPE_DEVICE;
|
|
|
|
break;
|
|
|
|
|
HID: hid-input: add support for HID devices reporting Battery Strength
Some HID devices, such as my Bluetooth mouse, report their battery
strength as an event. Rather than passing it through as a strange
absolute input event, this patch registers it with the power_supply
subsystem as a battery, so that the device's Battery Strength can be
reported to usermode.
The battery appears in sysfs names
/sys/class/power_supply/hid-<UNIQ>-battery, and it is a child of the
battery-containing device, so it should be clear what it's the battery of.
Unfortunately on my current Fedora 16 system, while the battery does
appear in the UI, it is listed as a Laptop Battery with 0% charge (since
it ignores the "capacity" property of the battery and instead computes
it from the "energy*" fields, which we can't supply given the limited
information contained within the HID Report).
Still, this patch is the first step.
Signed-off-by: Jeremy Fitzhardinge <jeremy@goop.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-23 15:49:14 +07:00
|
|
|
default:
|
|
|
|
ret = -EINVAL;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2011-12-03 10:05:07 +07:00
|
|
|
static bool hidinput_setup_battery(struct hid_device *dev, unsigned report_type, struct hid_field *field)
|
HID: hid-input: add support for HID devices reporting Battery Strength
Some HID devices, such as my Bluetooth mouse, report their battery
strength as an event. Rather than passing it through as a strange
absolute input event, this patch registers it with the power_supply
subsystem as a battery, so that the device's Battery Strength can be
reported to usermode.
The battery appears in sysfs names
/sys/class/power_supply/hid-<UNIQ>-battery, and it is a child of the
battery-containing device, so it should be clear what it's the battery of.
Unfortunately on my current Fedora 16 system, while the battery does
appear in the UI, it is listed as a Laptop Battery with 0% charge (since
it ignores the "capacity" property of the battery and instead computes
it from the "energy*" fields, which we can't supply given the limited
information contained within the HID Report).
Still, this patch is the first step.
Signed-off-by: Jeremy Fitzhardinge <jeremy@goop.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-23 15:49:14 +07:00
|
|
|
{
|
2015-03-12 14:44:11 +07:00
|
|
|
struct power_supply_desc *psy_desc = NULL;
|
|
|
|
struct power_supply_config psy_cfg = { .drv_data = dev, };
|
2011-12-03 02:12:36 +07:00
|
|
|
unsigned quirks;
|
2011-12-03 10:05:07 +07:00
|
|
|
s32 min, max;
|
|
|
|
|
|
|
|
if (field->usage->hid != HID_DC_BATTERYSTRENGTH)
|
|
|
|
return false; /* no match */
|
HID: hid-input: add support for HID devices reporting Battery Strength
Some HID devices, such as my Bluetooth mouse, report their battery
strength as an event. Rather than passing it through as a strange
absolute input event, this patch registers it with the power_supply
subsystem as a battery, so that the device's Battery Strength can be
reported to usermode.
The battery appears in sysfs names
/sys/class/power_supply/hid-<UNIQ>-battery, and it is a child of the
battery-containing device, so it should be clear what it's the battery of.
Unfortunately on my current Fedora 16 system, while the battery does
appear in the UI, it is listed as a Laptop Battery with 0% charge (since
it ignores the "capacity" property of the battery and instead computes
it from the "energy*" fields, which we can't supply given the limited
information contained within the HID Report).
Still, this patch is the first step.
Signed-off-by: Jeremy Fitzhardinge <jeremy@goop.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-23 15:49:14 +07:00
|
|
|
|
2015-03-12 14:44:11 +07:00
|
|
|
if (dev->battery != NULL)
|
2011-12-03 10:05:07 +07:00
|
|
|
goto out; /* already initialized? */
|
HID: hid-input: add support for HID devices reporting Battery Strength
Some HID devices, such as my Bluetooth mouse, report their battery
strength as an event. Rather than passing it through as a strange
absolute input event, this patch registers it with the power_supply
subsystem as a battery, so that the device's Battery Strength can be
reported to usermode.
The battery appears in sysfs names
/sys/class/power_supply/hid-<UNIQ>-battery, and it is a child of the
battery-containing device, so it should be clear what it's the battery of.
Unfortunately on my current Fedora 16 system, while the battery does
appear in the UI, it is listed as a Laptop Battery with 0% charge (since
it ignores the "capacity" property of the battery and instead computes
it from the "energy*" fields, which we can't supply given the limited
information contained within the HID Report).
Still, this patch is the first step.
Signed-off-by: Jeremy Fitzhardinge <jeremy@goop.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-23 15:49:14 +07:00
|
|
|
|
2015-12-14 19:42:26 +07:00
|
|
|
quirks = find_battery_quirk(dev);
|
|
|
|
|
|
|
|
hid_dbg(dev, "device %x:%x:%x %d quirks %d\n",
|
|
|
|
dev->bus, dev->vendor, dev->product, dev->version, quirks);
|
|
|
|
|
|
|
|
if (quirks & HID_BATTERY_QUIRK_IGNORE)
|
|
|
|
goto out;
|
|
|
|
|
2015-03-12 14:44:11 +07:00
|
|
|
psy_desc = kzalloc(sizeof(*psy_desc), GFP_KERNEL);
|
|
|
|
if (psy_desc == NULL)
|
2011-12-03 10:05:07 +07:00
|
|
|
goto out;
|
HID: hid-input: add support for HID devices reporting Battery Strength
Some HID devices, such as my Bluetooth mouse, report their battery
strength as an event. Rather than passing it through as a strange
absolute input event, this patch registers it with the power_supply
subsystem as a battery, so that the device's Battery Strength can be
reported to usermode.
The battery appears in sysfs names
/sys/class/power_supply/hid-<UNIQ>-battery, and it is a child of the
battery-containing device, so it should be clear what it's the battery of.
Unfortunately on my current Fedora 16 system, while the battery does
appear in the UI, it is listed as a Laptop Battery with 0% charge (since
it ignores the "capacity" property of the battery and instead computes
it from the "energy*" fields, which we can't supply given the limited
information contained within the HID Report).
Still, this patch is the first step.
Signed-off-by: Jeremy Fitzhardinge <jeremy@goop.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-23 15:49:14 +07:00
|
|
|
|
2015-03-12 14:44:11 +07:00
|
|
|
psy_desc->name = kasprintf(GFP_KERNEL, "hid-%s-battery", dev->uniq);
|
|
|
|
if (psy_desc->name == NULL) {
|
|
|
|
kfree(psy_desc);
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
psy_desc->type = POWER_SUPPLY_TYPE_BATTERY;
|
|
|
|
psy_desc->properties = hidinput_battery_props;
|
|
|
|
psy_desc->num_properties = ARRAY_SIZE(hidinput_battery_props);
|
|
|
|
psy_desc->use_for_apm = 0;
|
|
|
|
psy_desc->get_property = hidinput_get_battery_property;
|
HID: hid-input: add support for HID devices reporting Battery Strength
Some HID devices, such as my Bluetooth mouse, report their battery
strength as an event. Rather than passing it through as a strange
absolute input event, this patch registers it with the power_supply
subsystem as a battery, so that the device's Battery Strength can be
reported to usermode.
The battery appears in sysfs names
/sys/class/power_supply/hid-<UNIQ>-battery, and it is a child of the
battery-containing device, so it should be clear what it's the battery of.
Unfortunately on my current Fedora 16 system, while the battery does
appear in the UI, it is listed as a Laptop Battery with 0% charge (since
it ignores the "capacity" property of the battery and instead computes
it from the "energy*" fields, which we can't supply given the limited
information contained within the HID Report).
Still, this patch is the first step.
Signed-off-by: Jeremy Fitzhardinge <jeremy@goop.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-23 15:49:14 +07:00
|
|
|
|
2011-12-03 10:05:07 +07:00
|
|
|
min = field->logical_minimum;
|
|
|
|
max = field->logical_maximum;
|
|
|
|
|
2011-12-03 02:12:36 +07:00
|
|
|
if (quirks & HID_BATTERY_QUIRK_PERCENT) {
|
|
|
|
min = 0;
|
|
|
|
max = 100;
|
|
|
|
}
|
|
|
|
|
2011-12-09 15:10:28 +07:00
|
|
|
if (quirks & HID_BATTERY_QUIRK_FEATURE)
|
|
|
|
report_type = HID_FEATURE_REPORT;
|
|
|
|
|
HID: hid-input: add support for HID devices reporting Battery Strength
Some HID devices, such as my Bluetooth mouse, report their battery
strength as an event. Rather than passing it through as a strange
absolute input event, this patch registers it with the power_supply
subsystem as a battery, so that the device's Battery Strength can be
reported to usermode.
The battery appears in sysfs names
/sys/class/power_supply/hid-<UNIQ>-battery, and it is a child of the
battery-containing device, so it should be clear what it's the battery of.
Unfortunately on my current Fedora 16 system, while the battery does
appear in the UI, it is listed as a Laptop Battery with 0% charge (since
it ignores the "capacity" property of the battery and instead computes
it from the "energy*" fields, which we can't supply given the limited
information contained within the HID Report).
Still, this patch is the first step.
Signed-off-by: Jeremy Fitzhardinge <jeremy@goop.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-23 15:49:14 +07:00
|
|
|
dev->battery_min = min;
|
|
|
|
dev->battery_max = max;
|
2011-12-03 02:18:45 +07:00
|
|
|
dev->battery_report_type = report_type;
|
2011-12-03 10:05:07 +07:00
|
|
|
dev->battery_report_id = field->report->id;
|
HID: hid-input: add support for HID devices reporting Battery Strength
Some HID devices, such as my Bluetooth mouse, report their battery
strength as an event. Rather than passing it through as a strange
absolute input event, this patch registers it with the power_supply
subsystem as a battery, so that the device's Battery Strength can be
reported to usermode.
The battery appears in sysfs names
/sys/class/power_supply/hid-<UNIQ>-battery, and it is a child of the
battery-containing device, so it should be clear what it's the battery of.
Unfortunately on my current Fedora 16 system, while the battery does
appear in the UI, it is listed as a Laptop Battery with 0% charge (since
it ignores the "capacity" property of the battery and instead computes
it from the "energy*" fields, which we can't supply given the limited
information contained within the HID Report).
Still, this patch is the first step.
Signed-off-by: Jeremy Fitzhardinge <jeremy@goop.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-23 15:49:14 +07:00
|
|
|
|
2015-03-12 14:44:11 +07:00
|
|
|
dev->battery = power_supply_register(&dev->dev, psy_desc, &psy_cfg);
|
|
|
|
if (IS_ERR(dev->battery)) {
|
|
|
|
hid_warn(dev, "can't register power supply: %ld\n",
|
|
|
|
PTR_ERR(dev->battery));
|
|
|
|
kfree(psy_desc->name);
|
|
|
|
kfree(psy_desc);
|
|
|
|
dev->battery = NULL;
|
2015-03-23 22:34:51 +07:00
|
|
|
} else {
|
|
|
|
power_supply_powers(dev->battery, &dev->dev);
|
HID: hid-input: add support for HID devices reporting Battery Strength
Some HID devices, such as my Bluetooth mouse, report their battery
strength as an event. Rather than passing it through as a strange
absolute input event, this patch registers it with the power_supply
subsystem as a battery, so that the device's Battery Strength can be
reported to usermode.
The battery appears in sysfs names
/sys/class/power_supply/hid-<UNIQ>-battery, and it is a child of the
battery-containing device, so it should be clear what it's the battery of.
Unfortunately on my current Fedora 16 system, while the battery does
appear in the UI, it is listed as a Laptop Battery with 0% charge (since
it ignores the "capacity" property of the battery and instead computes
it from the "energy*" fields, which we can't supply given the limited
information contained within the HID Report).
Still, this patch is the first step.
Signed-off-by: Jeremy Fitzhardinge <jeremy@goop.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-23 15:49:14 +07:00
|
|
|
}
|
2011-12-03 10:05:07 +07:00
|
|
|
|
|
|
|
out:
|
|
|
|
return true;
|
HID: hid-input: add support for HID devices reporting Battery Strength
Some HID devices, such as my Bluetooth mouse, report their battery
strength as an event. Rather than passing it through as a strange
absolute input event, this patch registers it with the power_supply
subsystem as a battery, so that the device's Battery Strength can be
reported to usermode.
The battery appears in sysfs names
/sys/class/power_supply/hid-<UNIQ>-battery, and it is a child of the
battery-containing device, so it should be clear what it's the battery of.
Unfortunately on my current Fedora 16 system, while the battery does
appear in the UI, it is listed as a Laptop Battery with 0% charge (since
it ignores the "capacity" property of the battery and instead computes
it from the "energy*" fields, which we can't supply given the limited
information contained within the HID Report).
Still, this patch is the first step.
Signed-off-by: Jeremy Fitzhardinge <jeremy@goop.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-23 15:49:14 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
static void hidinput_cleanup_battery(struct hid_device *dev)
|
|
|
|
{
|
2015-08-03 12:57:30 +07:00
|
|
|
const struct power_supply_desc *psy_desc;
|
|
|
|
|
2015-03-12 14:44:11 +07:00
|
|
|
if (!dev->battery)
|
HID: hid-input: add support for HID devices reporting Battery Strength
Some HID devices, such as my Bluetooth mouse, report their battery
strength as an event. Rather than passing it through as a strange
absolute input event, this patch registers it with the power_supply
subsystem as a battery, so that the device's Battery Strength can be
reported to usermode.
The battery appears in sysfs names
/sys/class/power_supply/hid-<UNIQ>-battery, and it is a child of the
battery-containing device, so it should be clear what it's the battery of.
Unfortunately on my current Fedora 16 system, while the battery does
appear in the UI, it is listed as a Laptop Battery with 0% charge (since
it ignores the "capacity" property of the battery and instead computes
it from the "energy*" fields, which we can't supply given the limited
information contained within the HID Report).
Still, this patch is the first step.
Signed-off-by: Jeremy Fitzhardinge <jeremy@goop.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-23 15:49:14 +07:00
|
|
|
return;
|
|
|
|
|
2015-08-03 12:57:30 +07:00
|
|
|
psy_desc = dev->battery->desc;
|
2015-03-12 14:44:11 +07:00
|
|
|
power_supply_unregister(dev->battery);
|
2015-08-03 12:57:30 +07:00
|
|
|
kfree(psy_desc->name);
|
|
|
|
kfree(psy_desc);
|
2015-03-12 14:44:11 +07:00
|
|
|
dev->battery = NULL;
|
HID: hid-input: add support for HID devices reporting Battery Strength
Some HID devices, such as my Bluetooth mouse, report their battery
strength as an event. Rather than passing it through as a strange
absolute input event, this patch registers it with the power_supply
subsystem as a battery, so that the device's Battery Strength can be
reported to usermode.
The battery appears in sysfs names
/sys/class/power_supply/hid-<UNIQ>-battery, and it is a child of the
battery-containing device, so it should be clear what it's the battery of.
Unfortunately on my current Fedora 16 system, while the battery does
appear in the UI, it is listed as a Laptop Battery with 0% charge (since
it ignores the "capacity" property of the battery and instead computes
it from the "energy*" fields, which we can't supply given the limited
information contained within the HID Report).
Still, this patch is the first step.
Signed-off-by: Jeremy Fitzhardinge <jeremy@goop.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-23 15:49:14 +07:00
|
|
|
}
|
|
|
|
#else /* !CONFIG_HID_BATTERY_STRENGTH */
|
2011-12-03 10:05:07 +07:00
|
|
|
static bool hidinput_setup_battery(struct hid_device *dev, unsigned report_type,
|
|
|
|
struct hid_field *field)
|
HID: hid-input: add support for HID devices reporting Battery Strength
Some HID devices, such as my Bluetooth mouse, report their battery
strength as an event. Rather than passing it through as a strange
absolute input event, this patch registers it with the power_supply
subsystem as a battery, so that the device's Battery Strength can be
reported to usermode.
The battery appears in sysfs names
/sys/class/power_supply/hid-<UNIQ>-battery, and it is a child of the
battery-containing device, so it should be clear what it's the battery of.
Unfortunately on my current Fedora 16 system, while the battery does
appear in the UI, it is listed as a Laptop Battery with 0% charge (since
it ignores the "capacity" property of the battery and instead computes
it from the "energy*" fields, which we can't supply given the limited
information contained within the HID Report).
Still, this patch is the first step.
Signed-off-by: Jeremy Fitzhardinge <jeremy@goop.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-23 15:49:14 +07:00
|
|
|
{
|
2011-12-03 10:05:07 +07:00
|
|
|
return false;
|
HID: hid-input: add support for HID devices reporting Battery Strength
Some HID devices, such as my Bluetooth mouse, report their battery
strength as an event. Rather than passing it through as a strange
absolute input event, this patch registers it with the power_supply
subsystem as a battery, so that the device's Battery Strength can be
reported to usermode.
The battery appears in sysfs names
/sys/class/power_supply/hid-<UNIQ>-battery, and it is a child of the
battery-containing device, so it should be clear what it's the battery of.
Unfortunately on my current Fedora 16 system, while the battery does
appear in the UI, it is listed as a Laptop Battery with 0% charge (since
it ignores the "capacity" property of the battery and instead computes
it from the "energy*" fields, which we can't supply given the limited
information contained within the HID Report).
Still, this patch is the first step.
Signed-off-by: Jeremy Fitzhardinge <jeremy@goop.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-23 15:49:14 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
static void hidinput_cleanup_battery(struct hid_device *dev)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
#endif /* CONFIG_HID_BATTERY_STRENGTH */
|
|
|
|
|
2006-12-09 00:40:44 +07:00
|
|
|
static void hidinput_configure_usage(struct hid_input *hidinput, struct hid_field *field,
|
|
|
|
struct hid_usage *usage)
|
|
|
|
{
|
|
|
|
struct input_dev *input = hidinput->input;
|
2007-05-09 15:17:31 +07:00
|
|
|
struct hid_device *device = input_get_drvdata(input);
|
2008-07-31 16:09:37 +07:00
|
|
|
int max = 0, code;
|
2006-12-09 00:40:44 +07:00
|
|
|
unsigned long *bit = NULL;
|
|
|
|
|
|
|
|
field->hidinput = hidinput;
|
|
|
|
|
|
|
|
if (field->flags & HID_MAIN_ITEM_CONSTANT)
|
|
|
|
goto ignore;
|
|
|
|
|
2013-09-12 02:56:57 +07:00
|
|
|
/* Ignore if report count is out of bounds. */
|
|
|
|
if (field->report_count < 1)
|
|
|
|
goto ignore;
|
|
|
|
|
2007-08-12 04:39:42 +07:00
|
|
|
/* only LED usages are supported in output fields */
|
|
|
|
if (field->report_type == HID_OUTPUT_REPORT &&
|
|
|
|
(usage->hid & HID_USAGE_PAGE) != HID_UP_LED) {
|
|
|
|
goto ignore;
|
|
|
|
}
|
|
|
|
|
2008-05-16 16:49:16 +07:00
|
|
|
if (device->driver->input_mapping) {
|
|
|
|
int ret = device->driver->input_mapping(device, hidinput, field,
|
|
|
|
usage, &bit, &max);
|
|
|
|
if (ret > 0)
|
|
|
|
goto mapped;
|
|
|
|
if (ret < 0)
|
|
|
|
goto ignore;
|
|
|
|
}
|
|
|
|
|
2006-12-09 00:40:44 +07:00
|
|
|
switch (usage->hid & HID_USAGE_PAGE) {
|
2008-06-19 04:55:41 +07:00
|
|
|
case HID_UP_UNDEFINED:
|
|
|
|
goto ignore;
|
2006-12-09 00:40:44 +07:00
|
|
|
|
2008-06-19 04:55:41 +07:00
|
|
|
case HID_UP_KEYBOARD:
|
|
|
|
set_bit(EV_REP, input->evbit);
|
2006-12-09 00:40:44 +07:00
|
|
|
|
2008-06-19 04:55:41 +07:00
|
|
|
if ((usage->hid & HID_USAGE) < 256) {
|
|
|
|
if (!hid_keyboard[usage->hid & HID_USAGE]) goto ignore;
|
|
|
|
map_key_clear(hid_keyboard[usage->hid & HID_USAGE]);
|
|
|
|
} else
|
|
|
|
map_key(KEY_UNKNOWN);
|
2006-12-09 00:40:44 +07:00
|
|
|
|
2008-06-19 04:55:41 +07:00
|
|
|
break;
|
2006-12-09 00:40:44 +07:00
|
|
|
|
2008-06-19 04:55:41 +07:00
|
|
|
case HID_UP_BUTTON:
|
2010-02-17 15:36:35 +07:00
|
|
|
code = ((usage->hid - 1) & HID_USAGE);
|
2006-12-09 00:40:44 +07:00
|
|
|
|
2008-06-19 04:55:41 +07:00
|
|
|
switch (field->application) {
|
|
|
|
case HID_GD_MOUSE:
|
2010-12-14 17:56:56 +07:00
|
|
|
case HID_GD_POINTER: code += BTN_MOUSE; break;
|
2010-01-04 18:20:56 +07:00
|
|
|
case HID_GD_JOYSTICK:
|
2010-07-13 00:28:26 +07:00
|
|
|
if (code <= 0xf)
|
|
|
|
code += BTN_JOYSTICK;
|
|
|
|
else
|
2012-10-29 20:29:30 +07:00
|
|
|
code += BTN_TRIGGER_HAPPY - 0x10;
|
|
|
|
break;
|
|
|
|
case HID_GD_GAMEPAD:
|
|
|
|
if (code <= 0xf)
|
|
|
|
code += BTN_GAMEPAD;
|
|
|
|
else
|
|
|
|
code += BTN_TRIGGER_HAPPY - 0x10;
|
2010-07-13 00:28:26 +07:00
|
|
|
break;
|
2008-06-19 04:55:41 +07:00
|
|
|
default:
|
|
|
|
switch (field->physical) {
|
|
|
|
case HID_GD_MOUSE:
|
2010-12-14 17:56:56 +07:00
|
|
|
case HID_GD_POINTER: code += BTN_MOUSE; break;
|
|
|
|
case HID_GD_JOYSTICK: code += BTN_JOYSTICK; break;
|
|
|
|
case HID_GD_GAMEPAD: code += BTN_GAMEPAD; break;
|
|
|
|
default: code += BTN_MISC;
|
2006-12-09 00:40:44 +07:00
|
|
|
}
|
2008-06-19 04:55:41 +07:00
|
|
|
}
|
2006-12-09 00:40:44 +07:00
|
|
|
|
2008-06-19 04:55:41 +07:00
|
|
|
map_key(code);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case HID_UP_SIMULATION:
|
|
|
|
switch (usage->hid & 0xffff) {
|
|
|
|
case 0xba: map_abs(ABS_RUDDER); break;
|
|
|
|
case 0xbb: map_abs(ABS_THROTTLE); break;
|
|
|
|
case 0xc4: map_abs(ABS_GAS); break;
|
|
|
|
case 0xc5: map_abs(ABS_BRAKE); break;
|
|
|
|
case 0xc8: map_abs(ABS_WHEEL); break;
|
|
|
|
default: goto ignore;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case HID_UP_GENDESK:
|
|
|
|
if ((usage->hid & 0xf0) == 0x80) { /* SystemControl */
|
|
|
|
switch (usage->hid & 0xf) {
|
|
|
|
case 0x1: map_key_clear(KEY_POWER); break;
|
|
|
|
case 0x2: map_key_clear(KEY_SLEEP); break;
|
|
|
|
case 0x3: map_key_clear(KEY_WAKEUP); break;
|
2011-04-20 02:28:30 +07:00
|
|
|
case 0x4: map_key_clear(KEY_CONTEXT_MENU); break;
|
|
|
|
case 0x5: map_key_clear(KEY_MENU); break;
|
|
|
|
case 0x6: map_key_clear(KEY_PROG1); break;
|
|
|
|
case 0x7: map_key_clear(KEY_HELP); break;
|
|
|
|
case 0x8: map_key_clear(KEY_EXIT); break;
|
|
|
|
case 0x9: map_key_clear(KEY_SELECT); break;
|
|
|
|
case 0xa: map_key_clear(KEY_RIGHT); break;
|
|
|
|
case 0xb: map_key_clear(KEY_LEFT); break;
|
|
|
|
case 0xc: map_key_clear(KEY_UP); break;
|
|
|
|
case 0xd: map_key_clear(KEY_DOWN); break;
|
|
|
|
case 0xe: map_key_clear(KEY_POWER2); break;
|
|
|
|
case 0xf: map_key_clear(KEY_RESTART); break;
|
2008-06-19 04:55:41 +07:00
|
|
|
default: goto unknown;
|
2006-12-09 00:40:44 +07:00
|
|
|
}
|
|
|
|
break;
|
2008-06-19 04:55:41 +07:00
|
|
|
}
|
2006-12-09 00:40:44 +07:00
|
|
|
|
HID: input: ignore System Control application usages if not System Controls
Microsoft is reusing its report descriptor again and again, and part of it
looks like this:
0x05, 0x01, // Usage Page (Generic Desktop) 299
0x09, 0x80, // Usage (System Control) 301
0xa1, 0x01, // Collection (Application) 303
0x85, 0x03, // Report ID (3) 305
0x19, 0x00, // Usage Minimum (0) 307
0x29, 0xff, // Usage Maximum (255) 309
0x15, 0x00, // Logical Minimum (0) 311
0x26, 0xff, 0x00, // Logical Maximum (255) 313
0x81, 0x00, // Input (Data,Arr,Abs) 316
0xc0, // End Collection 318
While there is nothing wrong in term of processing, we do however blindly
map the full usage range (it's an array) from 0x00 to 0xff, which creates
some interesting axis, like ABS_X|Y, and a bunch of ABS_MISC + n.
While libinput and other stacks don't care that much (we can detect them),
joydev is very happy and attaches itself to the mouse or keyboard.
The problem is that joydev now handles the device as a joystick, but given
that we have a HID array, it sets all the ABS_* values to 0. And in its
world, 0 means -32767 (minimum value), which sends spurious events to games
(think Steam).
It looks like hid-microsoft tries to tackle the very same problem with its
.report_fixup callback. But fixing the report descriptor is an endless task
and is quite obfuscated.
So take the hammer, and decide that if the application is meant to be
System Control, any other usage not in the System Control range should
be ignored.
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1325354
Link: https://bugzilla.kernel.org/show_bug.cgi?id=28912
Link: https://github.com/ValveSoftware/steam-for-linux/issues/3384
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1325354
Link: https://bugzilla.kernel.org/show_bug.cgi?id=37982
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2016-09-13 16:52:37 +07:00
|
|
|
/*
|
|
|
|
* Some lazy vendors declare 255 usages for System Control,
|
|
|
|
* leading to the creation of ABS_X|Y axis and too many others.
|
|
|
|
* It wouldn't be a problem if joydev doesn't consider the
|
|
|
|
* device as a joystick then.
|
|
|
|
*/
|
|
|
|
if (field->application == HID_GD_SYSTEM_CONTROL)
|
|
|
|
goto ignore;
|
|
|
|
|
2008-06-19 04:55:41 +07:00
|
|
|
if ((usage->hid & 0xf0) == 0x90) { /* D-pad */
|
2006-12-09 00:40:44 +07:00
|
|
|
switch (usage->hid) {
|
2008-06-19 04:55:41 +07:00
|
|
|
case HID_GD_UP: usage->hat_dir = 1; break;
|
|
|
|
case HID_GD_DOWN: usage->hat_dir = 5; break;
|
|
|
|
case HID_GD_RIGHT: usage->hat_dir = 3; break;
|
|
|
|
case HID_GD_LEFT: usage->hat_dir = 7; break;
|
|
|
|
default: goto unknown;
|
2006-12-09 00:40:44 +07:00
|
|
|
}
|
2008-06-19 04:55:41 +07:00
|
|
|
if (field->dpad) {
|
|
|
|
map_abs(field->dpad);
|
|
|
|
goto ignore;
|
2007-01-15 23:28:47 +07:00
|
|
|
}
|
2008-06-19 04:55:41 +07:00
|
|
|
map_abs(ABS_HAT0X);
|
2006-12-09 00:40:44 +07:00
|
|
|
break;
|
2008-06-19 04:55:41 +07:00
|
|
|
}
|
2006-12-09 00:40:44 +07:00
|
|
|
|
2008-06-19 04:55:41 +07:00
|
|
|
switch (usage->hid) {
|
|
|
|
/* These usage IDs map directly to the usage codes. */
|
|
|
|
case HID_GD_X: case HID_GD_Y: case HID_GD_Z:
|
|
|
|
case HID_GD_RX: case HID_GD_RY: case HID_GD_RZ:
|
HID: input: force generic axis to be mapped to their user space axis
Atmel 840B digitizer presents a stylus interface which reports twice
the X coordinate and then twice the Y coordinate. In its current
implementation, hid-input assign the first X to X, then the second to Y,
then the first Y to Z, then the second one to RX.
This is wrong, and X should always be mapped to X, no matter what.
A solution consists in forcing X, Y, Z, RX, RY, RZ to be mapped to their
correct user space counter part.
Reported-by: Éric Brunet <Eric.Brunet@lps.ens.fr>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2014-08-26 00:07:10 +07:00
|
|
|
if (field->flags & HID_MAIN_ITEM_RELATIVE)
|
|
|
|
map_rel(usage->hid & 0xf);
|
|
|
|
else
|
|
|
|
map_abs_clear(usage->hid & 0xf);
|
|
|
|
break;
|
|
|
|
|
2008-06-19 04:55:41 +07:00
|
|
|
case HID_GD_SLIDER: case HID_GD_DIAL: case HID_GD_WHEEL:
|
|
|
|
if (field->flags & HID_MAIN_ITEM_RELATIVE)
|
|
|
|
map_rel(usage->hid & 0xf);
|
|
|
|
else
|
|
|
|
map_abs(usage->hid & 0xf);
|
|
|
|
break;
|
2006-12-09 00:40:44 +07:00
|
|
|
|
2008-06-19 04:55:41 +07:00
|
|
|
case HID_GD_HATSWITCH:
|
|
|
|
usage->hat_min = field->logical_minimum;
|
|
|
|
usage->hat_max = field->logical_maximum;
|
|
|
|
map_abs(ABS_HAT0X);
|
|
|
|
break;
|
2006-12-09 00:40:44 +07:00
|
|
|
|
2008-06-19 04:55:41 +07:00
|
|
|
case HID_GD_START: map_key_clear(BTN_START); break;
|
|
|
|
case HID_GD_SELECT: map_key_clear(BTN_SELECT); break;
|
2006-12-09 00:40:44 +07:00
|
|
|
|
2008-06-19 04:55:41 +07:00
|
|
|
default: goto unknown;
|
|
|
|
}
|
2006-12-09 00:40:44 +07:00
|
|
|
|
2008-06-19 04:55:41 +07:00
|
|
|
break;
|
|
|
|
|
|
|
|
case HID_UP_LED:
|
|
|
|
switch (usage->hid & 0xffff) { /* HID-Value: */
|
|
|
|
case 0x01: map_led (LED_NUML); break; /* "Num Lock" */
|
|
|
|
case 0x02: map_led (LED_CAPSL); break; /* "Caps Lock" */
|
|
|
|
case 0x03: map_led (LED_SCROLLL); break; /* "Scroll Lock" */
|
|
|
|
case 0x04: map_led (LED_COMPOSE); break; /* "Compose" */
|
|
|
|
case 0x05: map_led (LED_KANA); break; /* "Kana" */
|
|
|
|
case 0x27: map_led (LED_SLEEP); break; /* "Stand-By" */
|
|
|
|
case 0x4c: map_led (LED_SUSPEND); break; /* "System Suspend" */
|
|
|
|
case 0x09: map_led (LED_MUTE); break; /* "Mute" */
|
|
|
|
case 0x4b: map_led (LED_MISC); break; /* "Generic Indicator" */
|
|
|
|
case 0x19: map_led (LED_MAIL); break; /* "Message Waiting" */
|
|
|
|
case 0x4d: map_led (LED_CHARGING); break; /* "External Power Connected" */
|
|
|
|
|
|
|
|
default: goto ignore;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case HID_UP_DIGITIZER:
|
|
|
|
switch (usage->hid & 0xff) {
|
2010-07-14 04:50:57 +07:00
|
|
|
case 0x00: /* Undefined */
|
|
|
|
goto ignore;
|
|
|
|
|
2008-06-19 04:55:41 +07:00
|
|
|
case 0x30: /* TipPressure */
|
|
|
|
if (!test_bit(BTN_TOUCH, input->keybit)) {
|
|
|
|
device->quirks |= HID_QUIRK_NOTOUCH;
|
|
|
|
set_bit(EV_KEY, input->evbit);
|
|
|
|
set_bit(BTN_TOUCH, input->keybit);
|
2006-12-09 00:40:44 +07:00
|
|
|
}
|
2008-06-19 04:55:41 +07:00
|
|
|
map_abs_clear(ABS_PRESSURE);
|
2006-12-09 00:40:44 +07:00
|
|
|
break;
|
|
|
|
|
2008-06-19 04:55:41 +07:00
|
|
|
case 0x32: /* InRange */
|
|
|
|
switch (field->physical & 0xff) {
|
|
|
|
case 0x21: map_key(BTN_TOOL_MOUSE); break;
|
|
|
|
case 0x22: map_key(BTN_TOOL_FINGER); break;
|
|
|
|
default: map_key(BTN_TOOL_PEN); break;
|
2006-12-09 00:40:44 +07:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
2008-06-19 04:55:41 +07:00
|
|
|
case 0x3c: /* Invert */
|
|
|
|
map_key_clear(BTN_TOOL_RUBBER);
|
2006-12-09 00:40:44 +07:00
|
|
|
break;
|
|
|
|
|
2012-03-20 21:01:32 +07:00
|
|
|
case 0x3d: /* X Tilt */
|
|
|
|
map_abs_clear(ABS_TILT_X);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case 0x3e: /* Y Tilt */
|
|
|
|
map_abs_clear(ABS_TILT_Y);
|
|
|
|
break;
|
|
|
|
|
2008-06-19 04:55:41 +07:00
|
|
|
case 0x33: /* Touch */
|
|
|
|
case 0x42: /* TipSwitch */
|
|
|
|
case 0x43: /* TipSwitch2 */
|
|
|
|
device->quirks &= ~HID_QUIRK_NOTOUCH;
|
|
|
|
map_key_clear(BTN_TOUCH);
|
|
|
|
break;
|
2006-12-09 00:40:44 +07:00
|
|
|
|
2008-06-19 04:55:41 +07:00
|
|
|
case 0x44: /* BarrelSwitch */
|
|
|
|
map_key_clear(BTN_STYLUS);
|
|
|
|
break;
|
2006-12-09 00:40:44 +07:00
|
|
|
|
2010-08-07 02:03:07 +07:00
|
|
|
case 0x46: /* TabletPick */
|
2014-06-03 07:19:52 +07:00
|
|
|
case 0x5a: /* SecondaryBarrelSwitch */
|
2010-08-07 02:03:07 +07:00
|
|
|
map_key_clear(BTN_STYLUS2);
|
|
|
|
break;
|
|
|
|
|
2014-06-03 07:19:52 +07:00
|
|
|
case 0x5b: /* TransducerSerialNumber */
|
2014-09-24 01:09:28 +07:00
|
|
|
usage->type = EV_MSC;
|
|
|
|
usage->code = MSC_SERIAL;
|
|
|
|
bit = input->mscbit;
|
|
|
|
max = MSC_MAX;
|
2014-06-03 07:19:52 +07:00
|
|
|
break;
|
|
|
|
|
2008-06-19 04:55:41 +07:00
|
|
|
default: goto unknown;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
2015-03-05 05:10:26 +07:00
|
|
|
case HID_UP_TELEPHONY:
|
|
|
|
switch (usage->hid & HID_USAGE) {
|
|
|
|
case 0x2f: map_key_clear(KEY_MICMUTE); break;
|
|
|
|
case 0xb0: map_key_clear(KEY_NUMERIC_0); break;
|
|
|
|
case 0xb1: map_key_clear(KEY_NUMERIC_1); break;
|
|
|
|
case 0xb2: map_key_clear(KEY_NUMERIC_2); break;
|
|
|
|
case 0xb3: map_key_clear(KEY_NUMERIC_3); break;
|
|
|
|
case 0xb4: map_key_clear(KEY_NUMERIC_4); break;
|
|
|
|
case 0xb5: map_key_clear(KEY_NUMERIC_5); break;
|
|
|
|
case 0xb6: map_key_clear(KEY_NUMERIC_6); break;
|
|
|
|
case 0xb7: map_key_clear(KEY_NUMERIC_7); break;
|
|
|
|
case 0xb8: map_key_clear(KEY_NUMERIC_8); break;
|
|
|
|
case 0xb9: map_key_clear(KEY_NUMERIC_9); break;
|
|
|
|
case 0xba: map_key_clear(KEY_NUMERIC_STAR); break;
|
|
|
|
case 0xbb: map_key_clear(KEY_NUMERIC_POUND); break;
|
|
|
|
case 0xbc: map_key_clear(KEY_NUMERIC_A); break;
|
|
|
|
case 0xbd: map_key_clear(KEY_NUMERIC_B); break;
|
|
|
|
case 0xbe: map_key_clear(KEY_NUMERIC_C); break;
|
|
|
|
case 0xbf: map_key_clear(KEY_NUMERIC_D); break;
|
|
|
|
default: goto ignore;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
2011-04-20 02:28:30 +07:00
|
|
|
case HID_UP_CONSUMER: /* USB HUT v1.12, pages 75-84 */
|
2008-06-19 04:55:41 +07:00
|
|
|
switch (usage->hid & HID_USAGE) {
|
|
|
|
case 0x000: goto ignore;
|
2011-04-20 02:28:30 +07:00
|
|
|
case 0x030: map_key_clear(KEY_POWER); break;
|
|
|
|
case 0x031: map_key_clear(KEY_RESTART); break;
|
|
|
|
case 0x032: map_key_clear(KEY_SLEEP); break;
|
2008-06-19 04:55:41 +07:00
|
|
|
case 0x034: map_key_clear(KEY_SLEEP); break;
|
2011-04-20 02:28:30 +07:00
|
|
|
case 0x035: map_key_clear(KEY_KBDILLUMTOGGLE); break;
|
2008-06-19 04:55:41 +07:00
|
|
|
case 0x036: map_key_clear(BTN_MISC); break;
|
|
|
|
|
2011-04-20 02:28:30 +07:00
|
|
|
case 0x040: map_key_clear(KEY_MENU); break; /* Menu */
|
|
|
|
case 0x041: map_key_clear(KEY_SELECT); break; /* Menu Pick */
|
|
|
|
case 0x042: map_key_clear(KEY_UP); break; /* Menu Up */
|
|
|
|
case 0x043: map_key_clear(KEY_DOWN); break; /* Menu Down */
|
|
|
|
case 0x044: map_key_clear(KEY_LEFT); break; /* Menu Left */
|
|
|
|
case 0x045: map_key_clear(KEY_RIGHT); break; /* Menu Right */
|
|
|
|
case 0x046: map_key_clear(KEY_ESC); break; /* Menu Escape */
|
|
|
|
case 0x047: map_key_clear(KEY_KPPLUS); break; /* Menu Value Increase */
|
|
|
|
case 0x048: map_key_clear(KEY_KPMINUS); break; /* Menu Value Decrease */
|
|
|
|
|
|
|
|
case 0x060: map_key_clear(KEY_INFO); break; /* Data On Screen */
|
|
|
|
case 0x061: map_key_clear(KEY_SUBTITLE); break; /* Closed Caption */
|
|
|
|
case 0x063: map_key_clear(KEY_VCR); break; /* VCR/TV */
|
|
|
|
case 0x065: map_key_clear(KEY_CAMERA); break; /* Snapshot */
|
|
|
|
case 0x069: map_key_clear(KEY_RED); break;
|
|
|
|
case 0x06a: map_key_clear(KEY_GREEN); break;
|
|
|
|
case 0x06b: map_key_clear(KEY_BLUE); break;
|
|
|
|
case 0x06c: map_key_clear(KEY_YELLOW); break;
|
|
|
|
case 0x06d: map_key_clear(KEY_ZOOM); break;
|
|
|
|
|
2014-04-26 01:26:44 +07:00
|
|
|
case 0x06f: map_key_clear(KEY_BRIGHTNESSUP); break;
|
|
|
|
case 0x070: map_key_clear(KEY_BRIGHTNESSDOWN); break;
|
|
|
|
case 0x072: map_key_clear(KEY_BRIGHTNESS_TOGGLE); break;
|
|
|
|
case 0x073: map_key_clear(KEY_BRIGHTNESS_MIN); break;
|
|
|
|
case 0x074: map_key_clear(KEY_BRIGHTNESS_MAX); break;
|
|
|
|
case 0x075: map_key_clear(KEY_BRIGHTNESS_AUTO); break;
|
|
|
|
|
2011-04-20 02:28:30 +07:00
|
|
|
case 0x082: map_key_clear(KEY_VIDEO_NEXT); break;
|
2008-06-19 04:55:41 +07:00
|
|
|
case 0x083: map_key_clear(KEY_LAST); break;
|
2011-04-20 02:28:30 +07:00
|
|
|
case 0x084: map_key_clear(KEY_ENTER); break;
|
2008-06-19 04:55:41 +07:00
|
|
|
case 0x088: map_key_clear(KEY_PC); break;
|
|
|
|
case 0x089: map_key_clear(KEY_TV); break;
|
|
|
|
case 0x08a: map_key_clear(KEY_WWW); break;
|
|
|
|
case 0x08b: map_key_clear(KEY_DVD); break;
|
|
|
|
case 0x08c: map_key_clear(KEY_PHONE); break;
|
|
|
|
case 0x08d: map_key_clear(KEY_PROGRAM); break;
|
|
|
|
case 0x08e: map_key_clear(KEY_VIDEOPHONE); break;
|
|
|
|
case 0x08f: map_key_clear(KEY_GAMES); break;
|
|
|
|
case 0x090: map_key_clear(KEY_MEMO); break;
|
|
|
|
case 0x091: map_key_clear(KEY_CD); break;
|
|
|
|
case 0x092: map_key_clear(KEY_VCR); break;
|
|
|
|
case 0x093: map_key_clear(KEY_TUNER); break;
|
|
|
|
case 0x094: map_key_clear(KEY_EXIT); break;
|
|
|
|
case 0x095: map_key_clear(KEY_HELP); break;
|
|
|
|
case 0x096: map_key_clear(KEY_TAPE); break;
|
|
|
|
case 0x097: map_key_clear(KEY_TV2); break;
|
|
|
|
case 0x098: map_key_clear(KEY_SAT); break;
|
|
|
|
case 0x09a: map_key_clear(KEY_PVR); break;
|
|
|
|
|
|
|
|
case 0x09c: map_key_clear(KEY_CHANNELUP); break;
|
|
|
|
case 0x09d: map_key_clear(KEY_CHANNELDOWN); break;
|
|
|
|
case 0x0a0: map_key_clear(KEY_VCR2); break;
|
|
|
|
|
|
|
|
case 0x0b0: map_key_clear(KEY_PLAY); break;
|
|
|
|
case 0x0b1: map_key_clear(KEY_PAUSE); break;
|
|
|
|
case 0x0b2: map_key_clear(KEY_RECORD); break;
|
|
|
|
case 0x0b3: map_key_clear(KEY_FASTFORWARD); break;
|
|
|
|
case 0x0b4: map_key_clear(KEY_REWIND); break;
|
|
|
|
case 0x0b5: map_key_clear(KEY_NEXTSONG); break;
|
|
|
|
case 0x0b6: map_key_clear(KEY_PREVIOUSSONG); break;
|
|
|
|
case 0x0b7: map_key_clear(KEY_STOPCD); break;
|
|
|
|
case 0x0b8: map_key_clear(KEY_EJECTCD); break;
|
|
|
|
case 0x0bc: map_key_clear(KEY_MEDIA_REPEAT); break;
|
2011-04-20 02:28:30 +07:00
|
|
|
case 0x0b9: map_key_clear(KEY_SHUFFLE); break;
|
|
|
|
case 0x0bf: map_key_clear(KEY_SLOW); break;
|
2008-06-19 04:55:41 +07:00
|
|
|
|
|
|
|
case 0x0cd: map_key_clear(KEY_PLAYPAUSE); break;
|
2014-04-26 01:26:44 +07:00
|
|
|
case 0x0cf: map_key_clear(KEY_VOICECOMMAND); break;
|
2008-06-19 04:55:41 +07:00
|
|
|
case 0x0e0: map_abs_clear(ABS_VOLUME); break;
|
|
|
|
case 0x0e2: map_key_clear(KEY_MUTE); break;
|
|
|
|
case 0x0e5: map_key_clear(KEY_BASSBOOST); break;
|
|
|
|
case 0x0e9: map_key_clear(KEY_VOLUMEUP); break;
|
|
|
|
case 0x0ea: map_key_clear(KEY_VOLUMEDOWN); break;
|
2011-04-20 02:28:30 +07:00
|
|
|
case 0x0f5: map_key_clear(KEY_SLOW); break;
|
2008-06-19 04:55:41 +07:00
|
|
|
|
2014-04-26 01:26:44 +07:00
|
|
|
case 0x181: map_key_clear(KEY_BUTTONCONFIG); break;
|
2008-06-19 04:55:41 +07:00
|
|
|
case 0x182: map_key_clear(KEY_BOOKMARKS); break;
|
|
|
|
case 0x183: map_key_clear(KEY_CONFIG); break;
|
|
|
|
case 0x184: map_key_clear(KEY_WORDPROCESSOR); break;
|
|
|
|
case 0x185: map_key_clear(KEY_EDITOR); break;
|
|
|
|
case 0x186: map_key_clear(KEY_SPREADSHEET); break;
|
|
|
|
case 0x187: map_key_clear(KEY_GRAPHICSEDITOR); break;
|
|
|
|
case 0x188: map_key_clear(KEY_PRESENTATION); break;
|
|
|
|
case 0x189: map_key_clear(KEY_DATABASE); break;
|
|
|
|
case 0x18a: map_key_clear(KEY_MAIL); break;
|
|
|
|
case 0x18b: map_key_clear(KEY_NEWS); break;
|
|
|
|
case 0x18c: map_key_clear(KEY_VOICEMAIL); break;
|
|
|
|
case 0x18d: map_key_clear(KEY_ADDRESSBOOK); break;
|
|
|
|
case 0x18e: map_key_clear(KEY_CALENDAR); break;
|
2014-04-26 01:26:44 +07:00
|
|
|
case 0x18f: map_key_clear(KEY_TASKMANAGER); break;
|
|
|
|
case 0x190: map_key_clear(KEY_JOURNAL); break;
|
2008-06-19 04:55:41 +07:00
|
|
|
case 0x191: map_key_clear(KEY_FINANCE); break;
|
|
|
|
case 0x192: map_key_clear(KEY_CALC); break;
|
2011-04-20 02:28:30 +07:00
|
|
|
case 0x193: map_key_clear(KEY_PLAYER); break;
|
2008-06-19 04:55:41 +07:00
|
|
|
case 0x194: map_key_clear(KEY_FILE); break;
|
|
|
|
case 0x196: map_key_clear(KEY_WWW); break;
|
2010-02-08 20:02:05 +07:00
|
|
|
case 0x199: map_key_clear(KEY_CHAT); break;
|
2008-06-19 04:55:41 +07:00
|
|
|
case 0x19c: map_key_clear(KEY_LOGOFF); break;
|
|
|
|
case 0x19e: map_key_clear(KEY_COFFEE); break;
|
2014-04-26 01:26:44 +07:00
|
|
|
case 0x19f: map_key_clear(KEY_CONTROLPANEL); break;
|
|
|
|
case 0x1a2: map_key_clear(KEY_APPSELECT); break;
|
2014-01-29 23:57:41 +07:00
|
|
|
case 0x1a3: map_key_clear(KEY_NEXT); break;
|
|
|
|
case 0x1a4: map_key_clear(KEY_PREVIOUS); break;
|
2008-06-19 04:55:41 +07:00
|
|
|
case 0x1a6: map_key_clear(KEY_HELP); break;
|
|
|
|
case 0x1a7: map_key_clear(KEY_DOCUMENTS); break;
|
|
|
|
case 0x1ab: map_key_clear(KEY_SPELLCHECK); break;
|
2011-04-20 02:28:30 +07:00
|
|
|
case 0x1ae: map_key_clear(KEY_KEYBOARD); break;
|
2014-04-26 01:26:44 +07:00
|
|
|
case 0x1b1: map_key_clear(KEY_SCREENSAVER); break;
|
2014-01-29 23:57:41 +07:00
|
|
|
case 0x1b4: map_key_clear(KEY_FILE); break;
|
2011-04-20 02:28:30 +07:00
|
|
|
case 0x1b6: map_key_clear(KEY_IMAGES); break;
|
|
|
|
case 0x1b7: map_key_clear(KEY_AUDIO); break;
|
|
|
|
case 0x1b8: map_key_clear(KEY_VIDEO); break;
|
2008-06-19 04:55:41 +07:00
|
|
|
case 0x1bc: map_key_clear(KEY_MESSENGER); break;
|
|
|
|
case 0x1bd: map_key_clear(KEY_INFO); break;
|
|
|
|
case 0x201: map_key_clear(KEY_NEW); break;
|
|
|
|
case 0x202: map_key_clear(KEY_OPEN); break;
|
|
|
|
case 0x203: map_key_clear(KEY_CLOSE); break;
|
|
|
|
case 0x204: map_key_clear(KEY_EXIT); break;
|
|
|
|
case 0x207: map_key_clear(KEY_SAVE); break;
|
|
|
|
case 0x208: map_key_clear(KEY_PRINT); break;
|
|
|
|
case 0x209: map_key_clear(KEY_PROPS); break;
|
|
|
|
case 0x21a: map_key_clear(KEY_UNDO); break;
|
|
|
|
case 0x21b: map_key_clear(KEY_COPY); break;
|
|
|
|
case 0x21c: map_key_clear(KEY_CUT); break;
|
|
|
|
case 0x21d: map_key_clear(KEY_PASTE); break;
|
|
|
|
case 0x21f: map_key_clear(KEY_FIND); break;
|
|
|
|
case 0x221: map_key_clear(KEY_SEARCH); break;
|
|
|
|
case 0x222: map_key_clear(KEY_GOTO); break;
|
|
|
|
case 0x223: map_key_clear(KEY_HOMEPAGE); break;
|
|
|
|
case 0x224: map_key_clear(KEY_BACK); break;
|
|
|
|
case 0x225: map_key_clear(KEY_FORWARD); break;
|
|
|
|
case 0x226: map_key_clear(KEY_STOP); break;
|
|
|
|
case 0x227: map_key_clear(KEY_REFRESH); break;
|
|
|
|
case 0x22a: map_key_clear(KEY_BOOKMARKS); break;
|
|
|
|
case 0x22d: map_key_clear(KEY_ZOOMIN); break;
|
|
|
|
case 0x22e: map_key_clear(KEY_ZOOMOUT); break;
|
|
|
|
case 0x22f: map_key_clear(KEY_ZOOMRESET); break;
|
|
|
|
case 0x233: map_key_clear(KEY_SCROLLUP); break;
|
|
|
|
case 0x234: map_key_clear(KEY_SCROLLDOWN); break;
|
|
|
|
case 0x238: map_rel(REL_HWHEEL); break;
|
2011-04-20 02:28:30 +07:00
|
|
|
case 0x23d: map_key_clear(KEY_EDIT); break;
|
2008-06-19 04:55:41 +07:00
|
|
|
case 0x25f: map_key_clear(KEY_CANCEL); break;
|
2011-04-20 02:28:30 +07:00
|
|
|
case 0x269: map_key_clear(KEY_INSERT); break;
|
|
|
|
case 0x26a: map_key_clear(KEY_DELETE); break;
|
2008-06-19 04:55:41 +07:00
|
|
|
case 0x279: map_key_clear(KEY_REDO); break;
|
|
|
|
|
|
|
|
case 0x289: map_key_clear(KEY_REPLY); break;
|
|
|
|
case 0x28b: map_key_clear(KEY_FORWARDMAIL); break;
|
|
|
|
case 0x28c: map_key_clear(KEY_SEND); break;
|
|
|
|
|
2014-10-18 06:53:39 +07:00
|
|
|
case 0x2c7: map_key_clear(KEY_KBDINPUTASSIST_PREV); break;
|
|
|
|
case 0x2c8: map_key_clear(KEY_KBDINPUTASSIST_NEXT); break;
|
|
|
|
case 0x2c9: map_key_clear(KEY_KBDINPUTASSIST_PREVGROUP); break;
|
|
|
|
case 0x2ca: map_key_clear(KEY_KBDINPUTASSIST_NEXTGROUP); break;
|
|
|
|
case 0x2cb: map_key_clear(KEY_KBDINPUTASSIST_ACCEPT); break;
|
|
|
|
case 0x2cc: map_key_clear(KEY_KBDINPUTASSIST_CANCEL); break;
|
|
|
|
|
2014-10-22 04:11:00 +07:00
|
|
|
default: map_key_clear(KEY_UNKNOWN);
|
2008-06-19 04:55:41 +07:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
HID: hid-input: add support for HID devices reporting Battery Strength
Some HID devices, such as my Bluetooth mouse, report their battery
strength as an event. Rather than passing it through as a strange
absolute input event, this patch registers it with the power_supply
subsystem as a battery, so that the device's Battery Strength can be
reported to usermode.
The battery appears in sysfs names
/sys/class/power_supply/hid-<UNIQ>-battery, and it is a child of the
battery-containing device, so it should be clear what it's the battery of.
Unfortunately on my current Fedora 16 system, while the battery does
appear in the UI, it is listed as a Laptop Battery with 0% charge (since
it ignores the "capacity" property of the battery and instead computes
it from the "energy*" fields, which we can't supply given the limited
information contained within the HID Report).
Still, this patch is the first step.
Signed-off-by: Jeremy Fitzhardinge <jeremy@goop.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-23 15:49:14 +07:00
|
|
|
case HID_UP_GENDEVCTRLS:
|
2011-12-03 10:05:07 +07:00
|
|
|
if (hidinput_setup_battery(device, HID_INPUT_REPORT, field))
|
HID: hid-input: add support for HID devices reporting Battery Strength
Some HID devices, such as my Bluetooth mouse, report their battery
strength as an event. Rather than passing it through as a strange
absolute input event, this patch registers it with the power_supply
subsystem as a battery, so that the device's Battery Strength can be
reported to usermode.
The battery appears in sysfs names
/sys/class/power_supply/hid-<UNIQ>-battery, and it is a child of the
battery-containing device, so it should be clear what it's the battery of.
Unfortunately on my current Fedora 16 system, while the battery does
appear in the UI, it is listed as a Laptop Battery with 0% charge (since
it ignores the "capacity" property of the battery and instead computes
it from the "energy*" fields, which we can't supply given the limited
information contained within the HID Report).
Still, this patch is the first step.
Signed-off-by: Jeremy Fitzhardinge <jeremy@goop.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-23 15:49:14 +07:00
|
|
|
goto ignore;
|
2011-12-03 10:05:07 +07:00
|
|
|
else
|
HID: hid-input: add support for HID devices reporting Battery Strength
Some HID devices, such as my Bluetooth mouse, report their battery
strength as an event. Rather than passing it through as a strange
absolute input event, this patch registers it with the power_supply
subsystem as a battery, so that the device's Battery Strength can be
reported to usermode.
The battery appears in sysfs names
/sys/class/power_supply/hid-<UNIQ>-battery, and it is a child of the
battery-containing device, so it should be clear what it's the battery of.
Unfortunately on my current Fedora 16 system, while the battery does
appear in the UI, it is listed as a Laptop Battery with 0% charge (since
it ignores the "capacity" property of the battery and instead computes
it from the "energy*" fields, which we can't supply given the limited
information contained within the HID Report).
Still, this patch is the first step.
Signed-off-by: Jeremy Fitzhardinge <jeremy@goop.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-23 15:49:14 +07:00
|
|
|
goto unknown;
|
|
|
|
break;
|
|
|
|
|
2008-06-19 04:55:41 +07:00
|
|
|
case HID_UP_HPVENDOR: /* Reported on a Dutch layout HP5308 */
|
|
|
|
set_bit(EV_REP, input->evbit);
|
|
|
|
switch (usage->hid & HID_USAGE) {
|
|
|
|
case 0x021: map_key_clear(KEY_PRINT); break;
|
|
|
|
case 0x070: map_key_clear(KEY_HP); break;
|
|
|
|
case 0x071: map_key_clear(KEY_CAMERA); break;
|
|
|
|
case 0x072: map_key_clear(KEY_SOUND); break;
|
|
|
|
case 0x073: map_key_clear(KEY_QUESTION); break;
|
|
|
|
case 0x080: map_key_clear(KEY_EMAIL); break;
|
|
|
|
case 0x081: map_key_clear(KEY_CHAT); break;
|
|
|
|
case 0x082: map_key_clear(KEY_SEARCH); break;
|
|
|
|
case 0x083: map_key_clear(KEY_CONNECT); break;
|
|
|
|
case 0x084: map_key_clear(KEY_FINANCE); break;
|
|
|
|
case 0x085: map_key_clear(KEY_SPORT); break;
|
|
|
|
case 0x086: map_key_clear(KEY_SHOP); break;
|
2012-07-06 17:06:11 +07:00
|
|
|
default: goto ignore;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case HID_UP_HPVENDOR2:
|
|
|
|
set_bit(EV_REP, input->evbit);
|
|
|
|
switch (usage->hid & HID_USAGE) {
|
2016-08-04 09:26:20 +07:00
|
|
|
case 0x001: map_key_clear(KEY_MICMUTE); break;
|
2012-07-06 17:06:11 +07:00
|
|
|
case 0x003: map_key_clear(KEY_BRIGHTNESSDOWN); break;
|
|
|
|
case 0x004: map_key_clear(KEY_BRIGHTNESSUP); break;
|
2008-06-19 04:55:41 +07:00
|
|
|
default: goto ignore;
|
|
|
|
}
|
|
|
|
break;
|
2006-12-09 00:40:44 +07:00
|
|
|
|
2008-06-19 04:55:41 +07:00
|
|
|
case HID_UP_MSVENDOR:
|
|
|
|
goto ignore;
|
2006-12-09 00:40:44 +07:00
|
|
|
|
2008-06-19 04:55:41 +07:00
|
|
|
case HID_UP_CUSTOM: /* Reported on Logitech and Apple USB keyboards */
|
|
|
|
set_bit(EV_REP, input->evbit);
|
|
|
|
goto ignore;
|
2006-12-09 00:40:44 +07:00
|
|
|
|
2008-06-19 04:55:41 +07:00
|
|
|
case HID_UP_LOGIVENDOR:
|
2015-11-20 06:42:14 +07:00
|
|
|
/* intentional fallback */
|
|
|
|
case HID_UP_LOGIVENDOR2:
|
|
|
|
/* intentional fallback */
|
|
|
|
case HID_UP_LOGIVENDOR3:
|
2008-06-19 04:55:41 +07:00
|
|
|
goto ignore;
|
2010-07-13 00:28:26 +07:00
|
|
|
|
2008-06-19 04:55:41 +07:00
|
|
|
case HID_UP_PID:
|
|
|
|
switch (usage->hid & HID_USAGE) {
|
|
|
|
case 0xa4: map_key_clear(BTN_DEAD); break;
|
|
|
|
default: goto ignore;
|
|
|
|
}
|
|
|
|
break;
|
2006-12-09 00:40:44 +07:00
|
|
|
|
2008-06-19 04:55:41 +07:00
|
|
|
default:
|
|
|
|
unknown:
|
|
|
|
if (field->report_size == 1) {
|
|
|
|
if (field->report->type == HID_OUTPUT_REPORT) {
|
|
|
|
map_led(LED_MISC);
|
2006-12-09 00:40:44 +07:00
|
|
|
break;
|
|
|
|
}
|
2008-06-19 04:55:41 +07:00
|
|
|
map_key(BTN_MISC);
|
2006-12-09 00:40:44 +07:00
|
|
|
break;
|
2008-06-19 04:55:41 +07:00
|
|
|
}
|
|
|
|
if (field->flags & HID_MAIN_ITEM_RELATIVE) {
|
|
|
|
map_rel(REL_MISC);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
map_abs(ABS_MISC);
|
|
|
|
break;
|
2006-12-09 00:40:44 +07:00
|
|
|
}
|
|
|
|
|
2007-11-22 21:18:18 +07:00
|
|
|
mapped:
|
2008-05-16 16:49:16 +07:00
|
|
|
if (device->driver->input_mapped && device->driver->input_mapped(device,
|
|
|
|
hidinput, field, usage, &bit, &max) < 0)
|
|
|
|
goto ignore;
|
|
|
|
|
2006-12-09 00:40:44 +07:00
|
|
|
set_bit(usage->type, input->evbit);
|
|
|
|
|
|
|
|
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)
|
|
|
|
goto ignore;
|
|
|
|
|
|
|
|
|
|
|
|
if (usage->type == EV_ABS) {
|
|
|
|
|
|
|
|
int a = field->logical_minimum;
|
|
|
|
int b = field->logical_maximum;
|
|
|
|
|
|
|
|
if ((device->quirks & HID_QUIRK_BADPAD) && (usage->code == ABS_X || usage->code == ABS_Y)) {
|
|
|
|
a = field->logical_minimum = 0;
|
|
|
|
b = field->logical_maximum = 255;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (field->application == HID_GD_GAMEPAD || field->application == HID_GD_JOYSTICK)
|
|
|
|
input_set_abs_params(input, usage->code, a, b, (b - a) >> 8, (b - a) >> 4);
|
|
|
|
else input_set_abs_params(input, usage->code, a, b, 0, 0);
|
|
|
|
|
2010-09-15 17:51:14 +07:00
|
|
|
input_abs_set_res(input, usage->code,
|
|
|
|
hidinput_calc_abs_res(field, usage->code));
|
|
|
|
|
2010-06-23 23:31:37 +07:00
|
|
|
/* use a larger default input buffer for MT devices */
|
|
|
|
if (usage->code == ABS_MT_POSITION_X && input->hint_events_per_packet == 0)
|
|
|
|
input_set_events_per_packet(input, 60);
|
2006-12-09 00:40:44 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
if (usage->type == EV_ABS &&
|
|
|
|
(usage->hat_min < usage->hat_max || usage->hat_dir)) {
|
|
|
|
int i;
|
|
|
|
for (i = usage->code; i < usage->code + 2 && i <= max; i++) {
|
|
|
|
input_set_abs_params(input, i, -1, 1, 0, 0);
|
|
|
|
set_bit(i, input->absbit);
|
|
|
|
}
|
|
|
|
if (usage->hat_dir && !field->dpad)
|
|
|
|
field->dpad = usage->code;
|
|
|
|
}
|
|
|
|
|
2007-07-04 21:45:59 +07:00
|
|
|
/* for those devices which produce Consumer volume usage as relative,
|
|
|
|
* we emulate pressing volumeup/volumedown appropriate number of times
|
|
|
|
* in hidinput_hid_event()
|
|
|
|
*/
|
|
|
|
if ((usage->type == EV_ABS) && (field->flags & HID_MAIN_ITEM_RELATIVE) &&
|
|
|
|
(usage->code == ABS_VOLUME)) {
|
|
|
|
set_bit(KEY_VOLUMEUP, input->keybit);
|
|
|
|
set_bit(KEY_VOLUMEDOWN, input->keybit);
|
|
|
|
}
|
|
|
|
|
2007-08-20 17:13:34 +07:00
|
|
|
if (usage->type == EV_KEY) {
|
|
|
|
set_bit(EV_MSC, input->evbit);
|
|
|
|
set_bit(MSC_SCAN, input->mscbit);
|
|
|
|
}
|
|
|
|
|
2006-12-09 00:40:44 +07:00
|
|
|
ignore:
|
|
|
|
return;
|
2009-06-12 20:20:55 +07:00
|
|
|
|
2006-12-09 00:40:44 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
void hidinput_hid_event(struct hid_device *hid, struct hid_field *field, struct hid_usage *usage, __s32 value)
|
|
|
|
{
|
|
|
|
struct input_dev *input;
|
2007-10-15 01:35:40 +07:00
|
|
|
unsigned *quirks = &hid->quirks;
|
2006-12-09 00:40:44 +07:00
|
|
|
|
|
|
|
if (!field->hidinput)
|
|
|
|
return;
|
|
|
|
|
|
|
|
input = field->hidinput->input;
|
|
|
|
|
|
|
|
if (!usage->type)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (usage->hat_min < usage->hat_max || usage->hat_dir) {
|
|
|
|
int hat_dir = usage->hat_dir;
|
|
|
|
if (!hat_dir)
|
|
|
|
hat_dir = (value - usage->hat_min) * 8 / (usage->hat_max - usage->hat_min + 1) + 1;
|
|
|
|
if (hat_dir < 0 || hat_dir > 8) hat_dir = 0;
|
|
|
|
input_event(input, usage->type, usage->code , hid_hat_to_axis[hat_dir].x);
|
2010-07-13 00:28:26 +07:00
|
|
|
input_event(input, usage->type, usage->code + 1, hid_hat_to_axis[hat_dir].y);
|
|
|
|
return;
|
|
|
|
}
|
2006-12-09 00:40:44 +07:00
|
|
|
|
|
|
|
if (usage->hid == (HID_UP_DIGITIZER | 0x003c)) { /* Invert */
|
|
|
|
*quirks = value ? (*quirks | HID_QUIRK_INVERT) : (*quirks & ~HID_QUIRK_INVERT);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (usage->hid == (HID_UP_DIGITIZER | 0x0032)) { /* InRange */
|
|
|
|
if (value) {
|
|
|
|
input_event(input, usage->type, (*quirks & HID_QUIRK_INVERT) ? BTN_TOOL_RUBBER : usage->code, 1);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
input_event(input, usage->type, usage->code, 0);
|
|
|
|
input_event(input, usage->type, BTN_TOOL_RUBBER, 0);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (usage->hid == (HID_UP_DIGITIZER | 0x0030) && (*quirks & HID_QUIRK_NOTOUCH)) { /* Pressure */
|
|
|
|
int a = field->logical_minimum;
|
|
|
|
int b = field->logical_maximum;
|
|
|
|
input_event(input, EV_KEY, BTN_TOUCH, value > a + ((b - a) >> 3));
|
|
|
|
}
|
|
|
|
|
|
|
|
if (usage->hid == (HID_UP_PID | 0x83UL)) { /* Simultaneous Effects Max */
|
2007-05-30 20:07:13 +07:00
|
|
|
dbg_hid("Maximum Effects - %d\n",value);
|
2006-12-09 00:40:44 +07:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (usage->hid == (HID_UP_PID | 0x7fUL)) {
|
2007-05-30 20:07:13 +07:00
|
|
|
dbg_hid("PID Pool Report\n");
|
2006-12-09 00:40:44 +07:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if ((usage->type == EV_KEY) && (usage->code == 0)) /* Key 0 is "unassigned", not KEY_UNKNOWN */
|
|
|
|
return;
|
|
|
|
|
2007-07-04 21:45:59 +07:00
|
|
|
if ((usage->type == EV_ABS) && (field->flags & HID_MAIN_ITEM_RELATIVE) &&
|
|
|
|
(usage->code == ABS_VOLUME)) {
|
|
|
|
int count = abs(value);
|
|
|
|
int direction = value > 0 ? KEY_VOLUMEUP : KEY_VOLUMEDOWN;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < count; i++) {
|
|
|
|
input_event(input, EV_KEY, direction, 1);
|
|
|
|
input_sync(input);
|
|
|
|
input_event(input, EV_KEY, direction, 0);
|
|
|
|
input_sync(input);
|
|
|
|
}
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
HID: hid-input: allow array fields out of range
Allow array field values out of range as per HID 1.11 specification,
section 6.2.25:
Rather than returning a single bit for each button in the group, an
array returns an index in each field that corresponds to the pressed
button (like keyboard scan codes). An out-of range value in and array
field is considered no controls asserted.
Apparently, "and" above is a typo and should be "an".
This fixes at least Waltop tablet pen clicks - otherwise BTN_TOUCH is never
released.
The relevant part of Waltop tablet report descriptors is this:
0x09, 0x42, /* Usage (Tip Switch), */
0x09, 0x44, /* Usage (Barrel Switch), */
0x09, 0x46, /* Usage (Tablet Pick), */
0x15, 0x01, /* Logical Minimum (1), */
0x25, 0x03, /* Logical Maximum (3), */
0x75, 0x04, /* Report Size (4), */
0x95, 0x01, /* Report Count (1), */
0x80, /* Input, */
This is a regression fix for commit b4b583d ("HID: be more strict when
ignoring out-of-range fields").
Signed-off-by: Nikolai Kondrashov <spbnick@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2012-03-03 03:13:58 +07:00
|
|
|
/*
|
|
|
|
* Ignore out-of-range values as per HID specification,
|
2013-06-20 04:52:11 +07:00
|
|
|
* section 5.10 and 6.2.25.
|
|
|
|
*
|
|
|
|
* The logical_minimum < logical_maximum check is done so that we
|
|
|
|
* don't unintentionally discard values sent by devices which
|
|
|
|
* don't specify logical min and max.
|
HID: hid-input: allow array fields out of range
Allow array field values out of range as per HID 1.11 specification,
section 6.2.25:
Rather than returning a single bit for each button in the group, an
array returns an index in each field that corresponds to the pressed
button (like keyboard scan codes). An out-of range value in and array
field is considered no controls asserted.
Apparently, "and" above is a typo and should be "an".
This fixes at least Waltop tablet pen clicks - otherwise BTN_TOUCH is never
released.
The relevant part of Waltop tablet report descriptors is this:
0x09, 0x42, /* Usage (Tip Switch), */
0x09, 0x44, /* Usage (Barrel Switch), */
0x09, 0x46, /* Usage (Tablet Pick), */
0x15, 0x01, /* Logical Minimum (1), */
0x25, 0x03, /* Logical Maximum (3), */
0x75, 0x04, /* Report Size (4), */
0x95, 0x01, /* Report Count (1), */
0x80, /* Input, */
This is a regression fix for commit b4b583d ("HID: be more strict when
ignoring out-of-range fields").
Signed-off-by: Nikolai Kondrashov <spbnick@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2012-03-03 03:13:58 +07:00
|
|
|
*/
|
|
|
|
if ((field->flags & HID_MAIN_ITEM_VARIABLE) &&
|
2013-06-19 22:49:05 +07:00
|
|
|
(field->logical_minimum < field->logical_maximum) &&
|
HID: hid-input: allow array fields out of range
Allow array field values out of range as per HID 1.11 specification,
section 6.2.25:
Rather than returning a single bit for each button in the group, an
array returns an index in each field that corresponds to the pressed
button (like keyboard scan codes). An out-of range value in and array
field is considered no controls asserted.
Apparently, "and" above is a typo and should be "an".
This fixes at least Waltop tablet pen clicks - otherwise BTN_TOUCH is never
released.
The relevant part of Waltop tablet report descriptors is this:
0x09, 0x42, /* Usage (Tip Switch), */
0x09, 0x44, /* Usage (Barrel Switch), */
0x09, 0x46, /* Usage (Tablet Pick), */
0x15, 0x01, /* Logical Minimum (1), */
0x25, 0x03, /* Logical Maximum (3), */
0x75, 0x04, /* Report Size (4), */
0x95, 0x01, /* Report Count (1), */
0x80, /* Input, */
This is a regression fix for commit b4b583d ("HID: be more strict when
ignoring out-of-range fields").
Signed-off-by: Nikolai Kondrashov <spbnick@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2012-03-03 03:13:58 +07:00
|
|
|
(value < field->logical_minimum ||
|
|
|
|
value > field->logical_maximum)) {
|
2011-10-28 23:15:02 +07:00
|
|
|
dbg_hid("Ignoring out-of-range value %x\n", value);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
HID: input: fix confusion on conflicting mappings
On an PC-101/103/104 keyboard (American layout) the 'Enter' key and its
neighbours look like this:
+---+ +---+ +-------+
| 1 | | 2 | | 5 |
+---+ +---+ +-------+
+---+ +-----------+
| 3 | | 4 |
+---+ +-----------+
On a PC-102/105 keyboard (European layout) it looks like this:
+---+ +---+ +-------+
| 1 | | 2 | | |
+---+ +---+ +-+ 4 |
+---+ +---+ | |
| 3 | | 5 | | |
+---+ +---+ +-----+
(Note that the number of keys is the same, but key '5' is moved down and
the shape of key '4' is changed. Keys '1' to '3' are exactly the same.)
The keys 1-4 report the same scan-code in HID in both layouts, even though
the keysym they produce is usually different depending on the XKB-keymap
used by user-space.
However, key '5' (US 'backslash'/'pipe') reports 0x31 for the upper layout
and 0x32 for the lower layout, as defined by the HID spec. This is highly
confusing as the linux-input API uses a single keycode for both.
So far, this was never a problem as there never has been a keyboard with
both of those keys present at the same time. It would have to look
something like this:
+---+ +---+ +-------+
| 1 | | 2 | | x31 |
+---+ +---+ +-------+
+---+ +---+ +-----+
| 3 | |x32| | 4 |
+---+ +---+ +-----+
HID can represent such a keyboard, but the linux-input API cannot.
Furthermore, any user-space mapping would be confused by this and,
luckily, no-one ever produced such hardware.
Now, the HID input layer fixed this mess by mapping both 0x31 and 0x32 to
the same keycode (KEY_BACKSLASH==0x2b). As only one of both physical keys
is present on a hardware, this works just fine.
Lets introduce hardware-vendors into this:
------------------------------------------
Unfortunately, it seems way to expensive to produce a different device for
American and European layouts. Therefore, hardware-vendors put both keys,
(0x31 and 0x32) on the same keyboard, but only one of them is hooked up
to the physical button, the other one is 'dead'.
This means, they can use the same hardware, with a different button-layout
and automatically produce the correct HID events for American *and*
European layouts. This is unproblematic for normal keyboards, as the
'dead' key will never report any KEY-DOWN events. But RollOver keyboards
send the whole matrix on each key-event, allowing n-key roll-over mode.
This means, we get a 0x31 and 0x32 event on each key-press. One of them
will always be 0, the other reports the real state. As we map both to the
same keycode, we will get spurious key-events, even though the real
key-state never changed.
The easiest way would be to blacklist 'dead' keys and never handle those.
We could simply read the 'country' tag of USB devices and blacklist either
key according to the layout. But... hardware vendors... want the same
device for all countries and thus many of them set 'country' to 0 for all
devices. Meh..
So we have to deal with this properly. As we cannot know which of the keys
is 'dead', we either need a heuristic and track those keys, or we simply
make use of our value-tracking for HID fields. We simply ignore HID events
for absolute data if the data didn't change. As HID tracks events on the
HID level, we haven't done the keycode translation, yet. Therefore, the
'dead' key is tracked independently of the real key, therefore, any events
on it will be ignored.
This patch simply discards any HID events for absolute data if it didn't
change compared to the last report. We need to ignore relative and
buffered-byte reports for obvious reasons. But those cannot be affected by
this bug, so we're fine.
Preferably, we'd do this filtering on the HID-core level. But this might
break a lot of custom drivers, if they do not follow the HID specs.
Therefore, we do this late in hid-input just before we inject it into the
input layer (which does the exact same filtering, but on the keycode
level).
If this turns out to break some devices, we might have to limit filtering
to EV_KEY events. But lets try to do the Right Thing first, and properly
filter any absolute data that didn't change.
This patch is tagged for 'stable' as it fixes a lot of n-key RollOver
hardware. We might wanna wait with backporting for a while, before we know
it doesn't break anything else, though.
Cc: <stable@vger.kernel.org>
Reported-by: Adam Goode <adam@spicenitz.org>
Reported-by: Fredrik Hallenberg <megahallon@gmail.com>
Tested-by: Fredrik Hallenberg <megahallon@gmail.com>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2014-12-29 21:21:26 +07:00
|
|
|
/*
|
|
|
|
* Ignore reports for absolute data if the data didn't change. This is
|
|
|
|
* not only an optimization but also fixes 'dead' key reports. Some
|
|
|
|
* RollOver implementations for localized keys (like BACKSLASH/PIPE; HID
|
|
|
|
* 0x31 and 0x32) report multiple keys, even though a localized keyboard
|
|
|
|
* can only have one of them physically available. The 'dead' keys
|
|
|
|
* report constant 0. As all map to the same keycode, they'd confuse
|
|
|
|
* the input layer. If we filter the 'dead' keys on the HID level, we
|
|
|
|
* skip the keycode translation and only forward real events.
|
|
|
|
*/
|
|
|
|
if (!(field->flags & (HID_MAIN_ITEM_RELATIVE |
|
|
|
|
HID_MAIN_ITEM_BUFFERED_BYTE)) &&
|
2015-01-07 04:34:19 +07:00
|
|
|
(field->flags & HID_MAIN_ITEM_VARIABLE) &&
|
HID: input: fix confusion on conflicting mappings
On an PC-101/103/104 keyboard (American layout) the 'Enter' key and its
neighbours look like this:
+---+ +---+ +-------+
| 1 | | 2 | | 5 |
+---+ +---+ +-------+
+---+ +-----------+
| 3 | | 4 |
+---+ +-----------+
On a PC-102/105 keyboard (European layout) it looks like this:
+---+ +---+ +-------+
| 1 | | 2 | | |
+---+ +---+ +-+ 4 |
+---+ +---+ | |
| 3 | | 5 | | |
+---+ +---+ +-----+
(Note that the number of keys is the same, but key '5' is moved down and
the shape of key '4' is changed. Keys '1' to '3' are exactly the same.)
The keys 1-4 report the same scan-code in HID in both layouts, even though
the keysym they produce is usually different depending on the XKB-keymap
used by user-space.
However, key '5' (US 'backslash'/'pipe') reports 0x31 for the upper layout
and 0x32 for the lower layout, as defined by the HID spec. This is highly
confusing as the linux-input API uses a single keycode for both.
So far, this was never a problem as there never has been a keyboard with
both of those keys present at the same time. It would have to look
something like this:
+---+ +---+ +-------+
| 1 | | 2 | | x31 |
+---+ +---+ +-------+
+---+ +---+ +-----+
| 3 | |x32| | 4 |
+---+ +---+ +-----+
HID can represent such a keyboard, but the linux-input API cannot.
Furthermore, any user-space mapping would be confused by this and,
luckily, no-one ever produced such hardware.
Now, the HID input layer fixed this mess by mapping both 0x31 and 0x32 to
the same keycode (KEY_BACKSLASH==0x2b). As only one of both physical keys
is present on a hardware, this works just fine.
Lets introduce hardware-vendors into this:
------------------------------------------
Unfortunately, it seems way to expensive to produce a different device for
American and European layouts. Therefore, hardware-vendors put both keys,
(0x31 and 0x32) on the same keyboard, but only one of them is hooked up
to the physical button, the other one is 'dead'.
This means, they can use the same hardware, with a different button-layout
and automatically produce the correct HID events for American *and*
European layouts. This is unproblematic for normal keyboards, as the
'dead' key will never report any KEY-DOWN events. But RollOver keyboards
send the whole matrix on each key-event, allowing n-key roll-over mode.
This means, we get a 0x31 and 0x32 event on each key-press. One of them
will always be 0, the other reports the real state. As we map both to the
same keycode, we will get spurious key-events, even though the real
key-state never changed.
The easiest way would be to blacklist 'dead' keys and never handle those.
We could simply read the 'country' tag of USB devices and blacklist either
key according to the layout. But... hardware vendors... want the same
device for all countries and thus many of them set 'country' to 0 for all
devices. Meh..
So we have to deal with this properly. As we cannot know which of the keys
is 'dead', we either need a heuristic and track those keys, or we simply
make use of our value-tracking for HID fields. We simply ignore HID events
for absolute data if the data didn't change. As HID tracks events on the
HID level, we haven't done the keycode translation, yet. Therefore, the
'dead' key is tracked independently of the real key, therefore, any events
on it will be ignored.
This patch simply discards any HID events for absolute data if it didn't
change compared to the last report. We need to ignore relative and
buffered-byte reports for obvious reasons. But those cannot be affected by
this bug, so we're fine.
Preferably, we'd do this filtering on the HID-core level. But this might
break a lot of custom drivers, if they do not follow the HID specs.
Therefore, we do this late in hid-input just before we inject it into the
input layer (which does the exact same filtering, but on the keycode
level).
If this turns out to break some devices, we might have to limit filtering
to EV_KEY events. But lets try to do the Right Thing first, and properly
filter any absolute data that didn't change.
This patch is tagged for 'stable' as it fixes a lot of n-key RollOver
hardware. We might wanna wait with backporting for a while, before we know
it doesn't break anything else, though.
Cc: <stable@vger.kernel.org>
Reported-by: Adam Goode <adam@spicenitz.org>
Reported-by: Fredrik Hallenberg <megahallon@gmail.com>
Tested-by: Fredrik Hallenberg <megahallon@gmail.com>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2014-12-29 21:21:26 +07:00
|
|
|
usage->usage_index < field->maxusage &&
|
|
|
|
value == field->value[usage->usage_index])
|
|
|
|
return;
|
|
|
|
|
2007-08-20 17:13:34 +07:00
|
|
|
/* report the usage code as scancode if the key status has changed */
|
2015-05-28 05:09:08 +07:00
|
|
|
if (usage->type == EV_KEY &&
|
|
|
|
(!test_bit(usage->code, input->key)) == value)
|
2007-08-20 17:13:34 +07:00
|
|
|
input_event(input, EV_MSC, MSC_SCAN, usage->hid);
|
2007-08-09 18:24:11 +07:00
|
|
|
|
2006-12-09 00:40:44 +07:00
|
|
|
input_event(input, usage->type, usage->code, value);
|
|
|
|
|
2015-07-10 04:33:21 +07:00
|
|
|
if ((field->flags & HID_MAIN_ITEM_RELATIVE) &&
|
|
|
|
usage->type == EV_KEY && value) {
|
|
|
|
input_sync(input);
|
2006-12-09 00:40:44 +07:00
|
|
|
input_event(input, usage->type, usage->code, 0);
|
2015-07-10 04:33:21 +07:00
|
|
|
}
|
2006-12-09 00:40:44 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
void hidinput_report_event(struct hid_device *hid, struct hid_report *report)
|
|
|
|
{
|
|
|
|
struct hid_input *hidinput;
|
|
|
|
|
2010-08-24 15:54:44 +07:00
|
|
|
if (hid->quirks & HID_QUIRK_NO_INPUT_SYNC)
|
|
|
|
return;
|
|
|
|
|
2006-12-09 00:40:44 +07:00
|
|
|
list_for_each_entry(hidinput, &hid->inputs, list)
|
|
|
|
input_sync(hidinput->input);
|
|
|
|
}
|
2006-12-09 00:40:53 +07:00
|
|
|
EXPORT_SYMBOL_GPL(hidinput_report_event);
|
2006-12-09 00:40:44 +07:00
|
|
|
|
2006-12-09 00:40:53 +07:00
|
|
|
int hidinput_find_field(struct hid_device *hid, unsigned int type, unsigned int code, struct hid_field **field)
|
2006-12-09 00:40:44 +07:00
|
|
|
{
|
|
|
|
struct hid_report *report;
|
|
|
|
int i, j;
|
|
|
|
|
|
|
|
list_for_each_entry(report, &hid->report_enum[HID_OUTPUT_REPORT].report_list, list) {
|
|
|
|
for (i = 0; i < report->maxfield; i++) {
|
|
|
|
*field = report->field[i];
|
|
|
|
for (j = 0; j < (*field)->maxusage; j++)
|
|
|
|
if ((*field)->usage[j].type == type && (*field)->usage[j].code == code)
|
|
|
|
return j;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return -1;
|
|
|
|
}
|
2006-12-09 00:40:53 +07:00
|
|
|
EXPORT_SYMBOL_GPL(hidinput_find_field);
|
2006-12-09 00:40:44 +07:00
|
|
|
|
2011-11-17 18:23:50 +07:00
|
|
|
struct hid_field *hidinput_get_led_field(struct hid_device *hid)
|
|
|
|
{
|
|
|
|
struct hid_report *report;
|
|
|
|
struct hid_field *field;
|
|
|
|
int i, j;
|
|
|
|
|
|
|
|
list_for_each_entry(report,
|
|
|
|
&hid->report_enum[HID_OUTPUT_REPORT].report_list,
|
|
|
|
list) {
|
|
|
|
for (i = 0; i < report->maxfield; i++) {
|
|
|
|
field = report->field[i];
|
|
|
|
for (j = 0; j < field->maxusage; j++)
|
|
|
|
if (field->usage[j].type == EV_LED)
|
|
|
|
return field;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(hidinput_get_led_field);
|
|
|
|
|
|
|
|
unsigned int hidinput_count_leds(struct hid_device *hid)
|
|
|
|
{
|
|
|
|
struct hid_report *report;
|
|
|
|
struct hid_field *field;
|
|
|
|
int i, j;
|
|
|
|
unsigned int count = 0;
|
|
|
|
|
|
|
|
list_for_each_entry(report,
|
|
|
|
&hid->report_enum[HID_OUTPUT_REPORT].report_list,
|
|
|
|
list) {
|
|
|
|
for (i = 0; i < report->maxfield; i++) {
|
|
|
|
field = report->field[i];
|
|
|
|
for (j = 0; j < field->maxusage; j++)
|
|
|
|
if (field->usage[j].type == EV_LED &&
|
|
|
|
field->value[j])
|
|
|
|
count += 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return count;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(hidinput_count_leds);
|
|
|
|
|
2013-07-16 00:10:12 +07:00
|
|
|
static void hidinput_led_worker(struct work_struct *work)
|
|
|
|
{
|
|
|
|
struct hid_device *hid = container_of(work, struct hid_device,
|
|
|
|
led_work);
|
|
|
|
struct hid_field *field;
|
|
|
|
struct hid_report *report;
|
2014-02-21 03:24:48 +07:00
|
|
|
int len, ret;
|
2013-07-16 00:10:12 +07:00
|
|
|
__u8 *buf;
|
|
|
|
|
|
|
|
field = hidinput_get_led_field(hid);
|
|
|
|
if (!field)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* field->report is accessed unlocked regarding HID core. So there might
|
|
|
|
* be another incoming SET-LED request from user-space, which changes
|
|
|
|
* the LED state while we assemble our outgoing buffer. However, this
|
|
|
|
* doesn't matter as hid_output_report() correctly converts it into a
|
|
|
|
* boolean value no matter what information is currently set on the LED
|
|
|
|
* field (even garbage). So the remote device will always get a valid
|
|
|
|
* request.
|
|
|
|
* And in case we send a wrong value, a next led worker is spawned
|
|
|
|
* for every SET-LED request so the following worker will send the
|
|
|
|
* correct value, guaranteed!
|
|
|
|
*/
|
|
|
|
|
|
|
|
report = field->report;
|
|
|
|
|
|
|
|
/* use custom SET_REPORT request if possible (asynchronous) */
|
|
|
|
if (hid->ll_driver->request)
|
|
|
|
return hid->ll_driver->request(hid, report, HID_REQ_SET_REPORT);
|
|
|
|
|
|
|
|
/* fall back to generic raw-output-report */
|
2014-11-27 22:02:36 +07:00
|
|
|
len = hid_report_len(report);
|
2014-02-02 11:23:10 +07:00
|
|
|
buf = hid_alloc_report_buf(report, GFP_KERNEL);
|
2013-07-16 00:10:12 +07:00
|
|
|
if (!buf)
|
|
|
|
return;
|
|
|
|
|
|
|
|
hid_output_report(report, buf);
|
|
|
|
/* synchronous output report */
|
2014-02-21 03:24:48 +07:00
|
|
|
ret = hid_hw_output_report(hid, buf, len);
|
|
|
|
if (ret == -ENOSYS)
|
|
|
|
hid_hw_raw_request(hid, report->id, buf, len, HID_OUTPUT_REPORT,
|
|
|
|
HID_REQ_SET_REPORT);
|
2013-07-16 00:10:12 +07:00
|
|
|
kfree(buf);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int hidinput_input_event(struct input_dev *dev, unsigned int type,
|
|
|
|
unsigned int code, int value)
|
|
|
|
{
|
|
|
|
struct hid_device *hid = input_get_drvdata(dev);
|
|
|
|
struct hid_field *field;
|
|
|
|
int offset;
|
|
|
|
|
|
|
|
if (type == EV_FF)
|
|
|
|
return input_ff_event(dev, type, code, value);
|
|
|
|
|
|
|
|
if (type != EV_LED)
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
if ((offset = hidinput_find_field(hid, type, code, &field)) == -1) {
|
|
|
|
hid_warn(dev, "event field not found\n");
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
hid_set_field(field, offset, value);
|
|
|
|
|
|
|
|
schedule_work(&hid->led_work);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2007-01-24 17:54:19 +07:00
|
|
|
static int hidinput_open(struct input_dev *dev)
|
|
|
|
{
|
2007-05-09 15:17:31 +07:00
|
|
|
struct hid_device *hid = input_get_drvdata(dev);
|
|
|
|
|
2010-12-08 14:02:48 +07:00
|
|
|
return hid_hw_open(hid);
|
2007-01-24 17:54:19 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
static void hidinput_close(struct input_dev *dev)
|
|
|
|
{
|
2007-05-09 15:17:31 +07:00
|
|
|
struct hid_device *hid = input_get_drvdata(dev);
|
|
|
|
|
2010-12-08 14:02:48 +07:00
|
|
|
hid_hw_close(hid);
|
2007-01-24 17:54:19 +07:00
|
|
|
}
|
|
|
|
|
2011-02-25 01:30:59 +07:00
|
|
|
static void report_features(struct hid_device *hid)
|
|
|
|
{
|
|
|
|
struct hid_driver *drv = hid->driver;
|
|
|
|
struct hid_report_enum *rep_enum;
|
|
|
|
struct hid_report *rep;
|
|
|
|
int i, j;
|
|
|
|
|
|
|
|
rep_enum = &hid->report_enum[HID_FEATURE_REPORT];
|
|
|
|
list_for_each_entry(rep, &rep_enum->report_list, list)
|
2013-09-12 02:56:57 +07:00
|
|
|
for (i = 0; i < rep->maxfield; i++) {
|
|
|
|
/* Ignore if report count is out of bounds. */
|
|
|
|
if (rep->field[i]->report_count < 1)
|
|
|
|
continue;
|
|
|
|
|
2011-12-02 12:52:22 +07:00
|
|
|
for (j = 0; j < rep->field[i]->maxusage; j++) {
|
|
|
|
/* Verify if Battery Strength feature is available */
|
2011-12-03 10:05:07 +07:00
|
|
|
hidinput_setup_battery(hid, HID_FEATURE_REPORT, rep->field[i]);
|
2011-12-02 12:52:22 +07:00
|
|
|
|
|
|
|
if (drv->feature_mapping)
|
|
|
|
drv->feature_mapping(hid, rep->field[i],
|
|
|
|
rep->field[i]->usage + j);
|
|
|
|
}
|
2013-09-12 02:56:57 +07:00
|
|
|
}
|
2011-02-25 01:30:59 +07:00
|
|
|
}
|
|
|
|
|
2012-11-23 22:31:24 +07:00
|
|
|
static struct hid_input *hidinput_allocate(struct hid_device *hid)
|
|
|
|
{
|
|
|
|
struct hid_input *hidinput = kzalloc(sizeof(*hidinput), GFP_KERNEL);
|
|
|
|
struct input_dev *input_dev = input_allocate_device();
|
|
|
|
if (!hidinput || !input_dev) {
|
|
|
|
kfree(hidinput);
|
|
|
|
input_free_device(input_dev);
|
|
|
|
hid_err(hid, "Out of memory during hid input probe\n");
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
input_set_drvdata(input_dev, hid);
|
2014-02-21 03:24:49 +07:00
|
|
|
input_dev->event = hidinput_input_event;
|
2012-11-23 22:31:24 +07:00
|
|
|
input_dev->open = hidinput_open;
|
|
|
|
input_dev->close = hidinput_close;
|
|
|
|
input_dev->setkeycode = hidinput_setkeycode;
|
|
|
|
input_dev->getkeycode = hidinput_getkeycode;
|
|
|
|
|
|
|
|
input_dev->name = hid->name;
|
|
|
|
input_dev->phys = hid->phys;
|
|
|
|
input_dev->uniq = hid->uniq;
|
|
|
|
input_dev->id.bustype = hid->bus;
|
|
|
|
input_dev->id.vendor = hid->vendor;
|
|
|
|
input_dev->id.product = hid->product;
|
|
|
|
input_dev->id.version = hid->version;
|
2013-12-19 23:05:13 +07:00
|
|
|
input_dev->dev.parent = &hid->dev;
|
2012-11-23 22:31:24 +07:00
|
|
|
hidinput->input = input_dev;
|
|
|
|
list_add_tail(&hidinput->list, &hid->inputs);
|
|
|
|
|
|
|
|
return hidinput;
|
|
|
|
}
|
|
|
|
|
2013-03-23 00:38:28 +07:00
|
|
|
static bool hidinput_has_been_populated(struct hid_input *hidinput)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
unsigned long r = 0;
|
|
|
|
|
|
|
|
for (i = 0; i < BITS_TO_LONGS(EV_CNT); i++)
|
|
|
|
r |= hidinput->input->evbit[i];
|
|
|
|
|
|
|
|
for (i = 0; i < BITS_TO_LONGS(KEY_CNT); i++)
|
|
|
|
r |= hidinput->input->keybit[i];
|
|
|
|
|
|
|
|
for (i = 0; i < BITS_TO_LONGS(REL_CNT); i++)
|
|
|
|
r |= hidinput->input->relbit[i];
|
|
|
|
|
|
|
|
for (i = 0; i < BITS_TO_LONGS(ABS_CNT); i++)
|
|
|
|
r |= hidinput->input->absbit[i];
|
|
|
|
|
|
|
|
for (i = 0; i < BITS_TO_LONGS(MSC_CNT); i++)
|
|
|
|
r |= hidinput->input->mscbit[i];
|
|
|
|
|
|
|
|
for (i = 0; i < BITS_TO_LONGS(LED_CNT); i++)
|
|
|
|
r |= hidinput->input->ledbit[i];
|
|
|
|
|
|
|
|
for (i = 0; i < BITS_TO_LONGS(SND_CNT); i++)
|
|
|
|
r |= hidinput->input->sndbit[i];
|
|
|
|
|
|
|
|
for (i = 0; i < BITS_TO_LONGS(FF_CNT); i++)
|
|
|
|
r |= hidinput->input->ffbit[i];
|
|
|
|
|
|
|
|
for (i = 0; i < BITS_TO_LONGS(SW_CNT); i++)
|
|
|
|
r |= hidinput->input->swbit[i];
|
|
|
|
|
|
|
|
return !!r;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void hidinput_cleanup_hidinput(struct hid_device *hid,
|
|
|
|
struct hid_input *hidinput)
|
|
|
|
{
|
|
|
|
struct hid_report *report;
|
|
|
|
int i, k;
|
|
|
|
|
|
|
|
list_del(&hidinput->list);
|
|
|
|
input_free_device(hidinput->input);
|
|
|
|
|
|
|
|
for (k = HID_INPUT_REPORT; k <= HID_OUTPUT_REPORT; k++) {
|
|
|
|
if (k == HID_OUTPUT_REPORT &&
|
|
|
|
hid->quirks & HID_QUIRK_SKIP_OUTPUT_REPORTS)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
list_for_each_entry(report, &hid->report_enum[k].report_list,
|
|
|
|
list) {
|
|
|
|
|
|
|
|
for (i = 0; i < report->maxfield; i++)
|
|
|
|
if (report->field[i]->hidinput == hidinput)
|
|
|
|
report->field[i]->hidinput = NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
kfree(hidinput);
|
|
|
|
}
|
|
|
|
|
2006-12-09 00:40:44 +07:00
|
|
|
/*
|
|
|
|
* Register the input device; print a message.
|
|
|
|
* Configure the input layer interface
|
|
|
|
* Read all reports and initialize the absolute field values.
|
|
|
|
*/
|
|
|
|
|
2008-06-27 05:04:24 +07:00
|
|
|
int hidinput_connect(struct hid_device *hid, unsigned int force)
|
2006-12-09 00:40:44 +07:00
|
|
|
{
|
2012-07-30 18:28:18 +07:00
|
|
|
struct hid_driver *drv = hid->driver;
|
2006-12-09 00:40:44 +07:00
|
|
|
struct hid_report *report;
|
|
|
|
struct hid_input *hidinput = NULL;
|
|
|
|
int i, j, k;
|
|
|
|
|
|
|
|
INIT_LIST_HEAD(&hid->inputs);
|
2013-07-16 00:10:12 +07:00
|
|
|
INIT_WORK(&hid->led_work, hidinput_led_worker);
|
2006-12-09 00:40:44 +07:00
|
|
|
|
2008-06-27 05:04:24 +07:00
|
|
|
if (!force) {
|
|
|
|
for (i = 0; i < hid->maxcollection; i++) {
|
|
|
|
struct hid_collection *col = &hid->collection[i];
|
|
|
|
if (col->type == HID_COLLECTION_APPLICATION ||
|
|
|
|
col->type == HID_COLLECTION_PHYSICAL)
|
|
|
|
if (IS_INPUT_APPLICATION(col->usage))
|
|
|
|
break;
|
|
|
|
}
|
2006-12-09 00:40:44 +07:00
|
|
|
|
2008-06-27 05:04:24 +07:00
|
|
|
if (i == hid->maxcollection)
|
|
|
|
return -1;
|
|
|
|
}
|
2006-12-09 00:40:44 +07:00
|
|
|
|
2011-02-25 01:30:59 +07:00
|
|
|
report_features(hid);
|
|
|
|
|
|
|
|
for (k = HID_INPUT_REPORT; k <= HID_OUTPUT_REPORT; k++) {
|
2011-01-08 05:44:32 +07:00
|
|
|
if (k == HID_OUTPUT_REPORT &&
|
|
|
|
hid->quirks & HID_QUIRK_SKIP_OUTPUT_REPORTS)
|
|
|
|
continue;
|
2007-01-11 21:51:17 +07:00
|
|
|
|
2006-12-09 00:40:44 +07:00
|
|
|
list_for_each_entry(report, &hid->report_enum[k].report_list, list) {
|
|
|
|
|
|
|
|
if (!report->maxfield)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (!hidinput) {
|
2012-11-23 22:31:24 +07:00
|
|
|
hidinput = hidinput_allocate(hid);
|
|
|
|
if (!hidinput)
|
2007-10-30 19:02:44 +07:00
|
|
|
goto out_unwind;
|
2006-12-09 00:40:44 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 0; i < report->maxfield; i++)
|
|
|
|
for (j = 0; j < report->field[i]->maxusage; j++)
|
|
|
|
hidinput_configure_usage(hidinput, report->field[i],
|
|
|
|
report->field[i]->usage + j);
|
|
|
|
|
2013-03-23 00:38:28 +07:00
|
|
|
if ((hid->quirks & HID_QUIRK_NO_EMPTY_INPUT) &&
|
|
|
|
!hidinput_has_been_populated(hidinput))
|
|
|
|
continue;
|
|
|
|
|
2006-12-09 00:40:44 +07:00
|
|
|
if (hid->quirks & HID_QUIRK_MULTI_INPUT) {
|
|
|
|
/* This will leave hidinput NULL, so that it
|
|
|
|
* allocates another one if we have more inputs on
|
|
|
|
* the same interface. Some devices (e.g. Happ's
|
|
|
|
* UGCI) cram a lot of unrelated inputs into the
|
|
|
|
* same interface. */
|
|
|
|
hidinput->report = report;
|
2015-09-30 05:52:59 +07:00
|
|
|
if (drv->input_configured &&
|
|
|
|
drv->input_configured(hid, hidinput))
|
|
|
|
goto out_cleanup;
|
2007-10-30 19:02:44 +07:00
|
|
|
if (input_register_device(hidinput->input))
|
|
|
|
goto out_cleanup;
|
2006-12-09 00:40:44 +07:00
|
|
|
hidinput = NULL;
|
|
|
|
}
|
|
|
|
}
|
2011-01-08 05:44:32 +07:00
|
|
|
}
|
2006-12-09 00:40:44 +07:00
|
|
|
|
2013-03-23 00:38:28 +07:00
|
|
|
if (hidinput && (hid->quirks & HID_QUIRK_NO_EMPTY_INPUT) &&
|
|
|
|
!hidinput_has_been_populated(hidinput)) {
|
|
|
|
/* no need to register an input device not populated */
|
|
|
|
hidinput_cleanup_hidinput(hid, hidinput);
|
|
|
|
hidinput = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (list_empty(&hid->inputs)) {
|
|
|
|
hid_err(hid, "No inputs registered, leaving\n");
|
|
|
|
goto out_unwind;
|
|
|
|
}
|
|
|
|
|
2012-07-30 18:28:18 +07:00
|
|
|
if (hidinput) {
|
2015-09-30 05:52:59 +07:00
|
|
|
if (drv->input_configured &&
|
|
|
|
drv->input_configured(hid, hidinput))
|
|
|
|
goto out_cleanup;
|
2012-07-30 18:28:18 +07:00
|
|
|
if (input_register_device(hidinput->input))
|
|
|
|
goto out_cleanup;
|
|
|
|
}
|
2006-12-09 00:40:44 +07:00
|
|
|
|
|
|
|
return 0;
|
2007-10-30 19:02:44 +07:00
|
|
|
|
|
|
|
out_cleanup:
|
2011-02-15 21:41:10 +07:00
|
|
|
list_del(&hidinput->list);
|
2007-10-30 19:02:44 +07:00
|
|
|
input_free_device(hidinput->input);
|
|
|
|
kfree(hidinput);
|
|
|
|
out_unwind:
|
|
|
|
/* unwind the ones we already registered */
|
|
|
|
hidinput_disconnect(hid);
|
|
|
|
|
|
|
|
return -1;
|
2006-12-09 00:40:44 +07:00
|
|
|
}
|
2006-12-09 00:40:53 +07:00
|
|
|
EXPORT_SYMBOL_GPL(hidinput_connect);
|
2006-12-09 00:40:44 +07:00
|
|
|
|
|
|
|
void hidinput_disconnect(struct hid_device *hid)
|
|
|
|
{
|
|
|
|
struct hid_input *hidinput, *next;
|
|
|
|
|
HID: hid-input: add support for HID devices reporting Battery Strength
Some HID devices, such as my Bluetooth mouse, report their battery
strength as an event. Rather than passing it through as a strange
absolute input event, this patch registers it with the power_supply
subsystem as a battery, so that the device's Battery Strength can be
reported to usermode.
The battery appears in sysfs names
/sys/class/power_supply/hid-<UNIQ>-battery, and it is a child of the
battery-containing device, so it should be clear what it's the battery of.
Unfortunately on my current Fedora 16 system, while the battery does
appear in the UI, it is listed as a Laptop Battery with 0% charge (since
it ignores the "capacity" property of the battery and instead computes
it from the "energy*" fields, which we can't supply given the limited
information contained within the HID Report).
Still, this patch is the first step.
Signed-off-by: Jeremy Fitzhardinge <jeremy@goop.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-23 15:49:14 +07:00
|
|
|
hidinput_cleanup_battery(hid);
|
|
|
|
|
2006-12-09 00:40:44 +07:00
|
|
|
list_for_each_entry_safe(hidinput, next, &hid->inputs, list) {
|
|
|
|
list_del(&hidinput->list);
|
|
|
|
input_unregister_device(hidinput->input);
|
|
|
|
kfree(hidinput);
|
|
|
|
}
|
2013-07-16 00:10:12 +07:00
|
|
|
|
|
|
|
/* led_work is spawned by input_dev callbacks, but doesn't access the
|
|
|
|
* parent input_dev at all. Once all input devices are removed, we
|
|
|
|
* know that led_work will never get restarted, so we can cancel it
|
|
|
|
* synchronously and are safe. */
|
|
|
|
cancel_work_sync(&hid->led_work);
|
2006-12-09 00:40:44 +07:00
|
|
|
}
|
2006-12-09 00:40:53 +07:00
|
|
|
EXPORT_SYMBOL_GPL(hidinput_disconnect);
|
|
|
|
|