2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
2010-02-02 20:46:34 +01:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-01-25 11:43:31 +01:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2011-12-02 11:12:36 -08:00
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-04-19 15:28:30 -04:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2007-08-09 13:24:11 +02:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2011-04-19 15:28:30 -04:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-05-16 11:49:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2008-05-16 11:49:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2010-09-09 21:57:17 -07:00
|
|
|
|
|
|
|
|
|
2007-05-09 10:57:20 +02:00
|
|
|
|
2010-09-09 21:57:17 -07:00
|
|
|
|
2007-05-09 10:57:20 +02:00
|
|
|
|
|
|
|
|
|
2010-09-09 21:57:17 -07:00
|
|
|
|
|
|
|
|
|
2007-05-09 10:57:20 +02:00
|
|
|
|
2010-09-15 19:36:56 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-09 21:57:17 -07:00
|
|
|
|
2010-03-08 22:37:10 -08:00
|
|
|
|
2010-09-09 21:57:17 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-09 10:57:20 +02:00
|
|
|
|
|
|
|
|
|
2010-09-09 21:57:17 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-09 10:57:20 +02:00
|
|
|
|
2010-09-09 21:57:17 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-09 10:57:20 +02:00
|
|
|
|
2010-09-09 21:57:17 -07:00
|
|
|
|
2007-05-09 10:57:20 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-09 21:57:17 -07:00
|
|
|
|
2007-05-09 10:57:20 +02:00
|
|
|
|
2010-09-15 19:36:56 -07:00
|
|
|
|
2010-09-09 21:57:17 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-09 10:57:20 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-09 21:57:17 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-03-08 22:37:10 -08:00
|
|
|
|
2010-09-09 21:57:17 -07:00
|
|
|
|
2007-05-09 10:57:20 +02:00
|
|
|
|
2007-10-31 12:33:26 +01:00
|
|
|
|
2007-05-09 10:57:20 +02:00
|
|
|
|
2010-09-09 21:57:17 -07:00
|
|
|
|
2007-08-09 14:04:56 +02:00
|
|
|
|
2010-09-09 21:57:17 -07:00
|
|
|
|
2007-05-09 10:57:20 +02:00
|
|
|
|
2010-09-15 19:36:56 -07:00
|
|
|
|
|
|
|
|
|
2010-09-09 21:57:17 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-09 10:57:20 +02:00
|
|
|
|
|
|
|
|
|
2010-09-09 21:57:17 -07:00
|
|
|
|
2007-05-09 10:57:20 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-03-08 22:37:10 -08:00
|
|
|
|
2010-09-09 21:57:17 -07:00
|
|
|
|
|
|
|
|
|
2007-05-09 10:57:20 +02:00
|
|
|
|
2007-10-31 12:33:26 +01:00
|
|
|
|
2007-05-09 10:57:20 +02:00
|
|
|
|
2007-08-09 14:04:56 +02:00
|
|
|
|
2010-09-09 21:57:17 -07:00
|
|
|
|
2007-05-09 10:57:20 +02:00
|
|
|
|
2010-09-15 19:36:56 -07:00
|
|
|
|
|
|
|
|
|
2010-09-09 21:57:17 -07:00
|
|
|
|
2007-08-09 14:04:56 +02:00
|
|
|
|
2010-09-09 21:57:17 -07:00
|
|
|
|
2007-05-09 10:57:20 +02:00
|
|
|
|
2010-10-25 19:44:21 -07:00
|
|
|
|
2010-09-09 21:57:17 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-08-09 14:04:56 +02:00
|
|
|
|
2007-05-09 10:57:20 +02:00
|
|
|
|
|
|
|
|
|
2007-08-09 14:04:56 +02:00
|
|
|
|
2007-05-09 10:57:20 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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 15:09:52 +03:00
|
|
|
|
2010-09-15 14:51:14 +04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-12-02 11:49:06 +01:00
|
|
|
|
|
|
|
|
|
2010-09-15 14:51:14 +04:00
|
|
|
|
2012-11-14 16:59:13 +01:00
|
|
|
|
2010-09-15 14:51:14 +04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-03-20 16:01:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-14 16:59:13 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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 15:09:52 +03:00
|
|
|
|
2010-12-02 11:49:06 +01:00
|
|
|
|
|
|
|
|
|
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 15:09:52 +03:00
|
|
|
|
2010-12-02 11:49:06 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-15 14:51:14 +04:00
|
|
|
|
2010-12-02 11:49:06 +01:00
|
|
|
|
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 15:09:52 +03:00
|
|
|
|
2010-09-15 14:51:14 +04:00
|
|
|
|
|
|
|
|
|
2012-03-20 16:01:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-10-19 18:03:54 -07:00
|
|
|
|
2012-03-20 16:01:32 +02:00
|
|
|
|
|
|
|
|
|
2010-09-15 14:51:14 +04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-03-20 16:01:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-15 14:51:14 +04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-14 16:59:14 +01:00
|
|
|
|
2010-09-15 14:51:14 +04:00
|
|
|
|
2012-11-14 16:59:13 +01:00
|
|
|
|
2010-09-15 14:51:14 +04: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 00:49:14 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-07 17:31:43 -08: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 00:49:14 -08:00
|
|
|
|
|
|
|
|
|
2011-12-02 11:12:36 -08:00
|
|
|
|
2011-12-09 00:10:28 -08:00
|
|
|
|
2015-12-14 17:42:26 +05:00
|
|
|
|
2011-12-02 11:12:36 -08:00
|
|
|
|
|
|
|
|
|
2012-11-25 15:08:34 +01:00
|
|
|
|
2014-12-20 19:01:35 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-09 00:10:28 -08:00
|
|
|
|
2014-12-20 19:01:35 -05:00
|
|
|
|
2011-12-09 00:10:28 -08:00
|
|
|
|
2014-12-16 15:37:22 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-04 10:20:31 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-12-14 17:42:26 +05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-02 11:12:36 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-01 15:38:01 -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 00:49:14 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-12 08:44:11 +01:00
|
|
|
|
2017-08-01 15:38:01 -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 00:49:14 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-01 15:38:01 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-02 03:52:22 -02:00
|
|
|
|
|
|
|
|
|
2017-08-01 15:38:01 -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 00:49:14 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-02 03:52:22 -02:00
|
|
|
|
2017-08-01 15:38:01 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-02 03:52:22 -02:00
|
|
|
|
|
|
|
|
|
2011-12-07 17:31:43 -08: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 00:49:14 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-01 15:38:01 -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 00:49:14 -08:00
|
|
|
|
2017-08-01 15:38:01 -07:00
|
|
|
|
2015-03-12 08:44:11 +01:00
|
|
|
|
2011-12-02 11:12:36 -08:00
|
|
|
|
2011-12-02 19:05:07 -08:00
|
|
|
|
2017-08-01 15:38:01 -07:00
|
|
|
|
2011-12-02 19:05:07 -08:00
|
|
|
|
2017-08-01 15:38:01 -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 00:49:14 -08:00
|
|
|
|
2015-12-14 17:42:26 +05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-01 15:38:01 -07:00
|
|
|
|
2015-12-14 17:42:26 +05:00
|
|
|
|
2015-03-12 08:44:11 +01:00
|
|
|
|
2017-08-01 15:38:01 -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 00:49:14 -08:00
|
|
|
|
2017-08-01 15:38:02 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-01 15:38:01 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-12 08:44:11 +01: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 00:49:14 -08:00
|
|
|
|
2011-12-02 19:05:07 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-02 11:12:36 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-09 00:10:28 -08: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 00:49:14 -08:00
|
|
|
|
|
|
|
|
|
2011-12-02 11:18:45 -08:00
|
|
|
|
2011-12-02 19:05:07 -08: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 00:49:14 -08:00
|
|
|
|
2015-03-12 08:44:11 +01:00
|
|
|
|
|
|
|
|
|
2017-08-01 15:38:01 -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 00:49:14 -08:00
|
|
|
|
2011-12-02 19:05:07 -08:00
|
|
|
|
2017-08-01 15:38:01 -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 00:49:14 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-08-03 14:57:30 +09:00
|
|
|
|
|
|
|
|
|
2015-03-12 08:44:11 +01: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 00:49:14 -08:00
|
|
|
|
|
|
|
|
|
2015-08-03 14:57:30 +09:00
|
|
|
|
2015-03-12 08:44:11 +01:00
|
|
|
|
2015-08-03 14:57:30 +09:00
|
|
|
|
|
|
|
|
|
2015-03-12 08:44:11 +01: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 00:49:14 -08:00
|
|
|
|
2017-08-01 15:38:01 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-10 12:47:56 -07:00
|
|
|
|
|
|
|
|
|
2017-08-01 15:38:01 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-10 12:47:56 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-01 15:38:01 -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 00:49:14 -08:00
|
|
|
|
2017-08-01 15:38:01 -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 00:49:14 -08:00
|
|
|
|
2017-08-01 15:38:01 -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 00:49:14 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-01 15:38:01 -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 00:49:14 -08:00
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-09 10:17:31 +02:00
|
|
|
|
2008-07-31 11:09:37 +02:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-09-11 21:56:57 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-08-11 23:39:42 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-05-16 11:49:16 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
2010-02-17 09:36:35 +01:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
2010-12-14 11:56:56 +01:00
|
|
|
|
2010-01-04 12:20:56 +01:00
|
|
|
|
2010-07-12 19:28:26 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-10-29 14:29:30 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-07-12 19:28:26 +02:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-12-14 11:56:56 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-04-19 15:28:30 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
2006-12-08 18:40:44 +01: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 11:52:37 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-01-15 17:28:47 +01:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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-25 13:07:10 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2017-05-10 17:12:52 +02:00
|
|
|
|
|
|
|
|
|
2017-05-11 19:11:11 +02:00
|
|
|
|
2017-05-10 17:12:52 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-07-13 23:50:57 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-01 15:38:01 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
2012-03-20 16:01:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2017-10-03 15:05:41 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-08-06 23:03:07 +04:00
|
|
|
|
2014-06-02 17:19:52 -07:00
|
|
|
|
2010-08-06 23:03:07 +04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-06-02 17:19:52 -07:00
|
|
|
|
2014-09-23 11:09:28 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-06-02 17:19:52 -07:00
|
|
|
|
|
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-04 14:10:26 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-04-19 15:28:30 -04:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
2011-04-19 15:28:30 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
2011-04-19 15:28:30 -04:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
2011-04-19 15:28:30 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-04-25 20:26:44 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-04-19 15:28:30 -04:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
2011-04-19 15:28:30 -04:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-04-19 15:28:30 -04:00
|
|
|
|
|
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
2014-04-25 20:26:44 +02:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-04-19 15:28:30 -04:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
2014-04-25 20:26:44 +02:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-04-25 20:26:44 +02:00
|
|
|
|
|
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
2011-04-19 15:28:30 -04:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
2010-02-08 13:02:05 +00:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
2014-04-25 20:26:44 +02:00
|
|
|
|
|
|
|
|
|
2014-01-29 17:57:41 +01:00
|
|
|
|
|
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-04-19 15:28:30 -04:00
|
|
|
|
2014-04-25 20:26:44 +02:00
|
|
|
|
2014-01-29 17:57:41 +01:00
|
|
|
|
2011-04-19 15:28:30 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-04-19 15:28:30 -04:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
2011-04-19 15:28:30 -04:00
|
|
|
|
|
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-10-18 01:53:39 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-10-21 23:11:00 +02:00
|
|
|
|
2008-06-18 23:55:41 +02: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 00:49:14 -08:00
|
|
|
|
2017-08-01 15:38:01 -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 00:49:14 -08:00
|
|
|
|
2017-08-01 15:38:01 -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 00:49:14 -08:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-06 18:06:11 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-08-04 10:26:20 +08:00
|
|
|
|
2012-07-06 18:06:11 +08:00
|
|
|
|
|
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
2015-11-19 16:42:14 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
2010-07-12 19:28:26 +02:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
2007-11-22 15:18:18 +01:00
|
|
|
|
2008-05-16 11:49:16 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-15 14:51:14 +04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-06-23 09:31:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-07-04 16:45:59 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-08-20 12:13:34 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
2009-06-12 15:20:55 +02:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-10-14 19:35:40 +01:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2017-08-01 15:38:01 -07:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
2017-08-01 15:38:01 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2017-08-01 15:38:01 -07:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
2017-08-01 15:38:01 -07:00
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-07-12 19:28:26 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-30 15:07:13 +02:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-30 15:07:13 +02:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-07-04 16:45:59 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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-02 22:13:58 +02:00
|
|
|
|
|
|
|
|
|
2017-03-14 13:29:13 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-06-19 23:52:11 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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-02 22:13:58 +02:00
|
|
|
|
|
|
|
|
|
2017-03-14 13:29:13 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-28 18:15:02 +02:00
|
|
|
|
|
|
|
|
|
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 15:21:26 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-06 22:34:19 +01:00
|
|
|
|
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 15:21:26 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-08-20 12:13:34 +02:00
|
|
|
|
2015-05-27 17:09:08 -05:00
|
|
|
|
|
|
|
|
|
2007-08-20 12:13:34 +02:00
|
|
|
|
2007-08-09 13:24:11 +02:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
2015-07-09 14:33:21 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2015-07-09 14:33:21 -07:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-08-24 10:54:44 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:53 +01:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2006-12-08 18:40:53 +01:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:53 +01:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2011-11-17 19:23:50 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-07-15 19:10:12 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-20 15:24:48 -05:00
|
|
|
|
2013-07-15 19:10:12 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-27 16:02:36 +01:00
|
|
|
|
2014-02-01 23:23:10 -05:00
|
|
|
|
2013-07-15 19:10:12 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-20 15:24:48 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-07-15 19:10:12 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-01-24 11:54:19 +01:00
|
|
|
|
|
|
|
|
|
2007-05-09 10:17:31 +02:00
|
|
|
|
|
|
|
|
|
2010-12-07 23:02:48 -08:00
|
|
|
|
2007-01-24 11:54:19 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-09 10:17:31 +02:00
|
|
|
|
|
|
|
|
|
2010-12-07 23:02:48 -08:00
|
|
|
|
2007-01-24 11:54:19 +01:00
|
|
|
|
|
|
|
|
|
2011-02-24 19:30:59 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-01 15:38:01 -07:00
|
|
|
|
2011-02-24 19:30:59 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-09-11 21:56:57 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-02 03:52:22 -02:00
|
|
|
|
2017-08-01 15:38:01 -07:00
|
|
|
|
|
|
|
|
|
2011-12-02 03:52:22 -02:00
|
|
|
|
2017-08-01 15:38:01 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-02 03:52:22 -02:00
|
|
|
|
|
|
|
|
|
2017-08-01 15:38:01 -07:00
|
|
|
|
2011-12-02 03:52:22 -02:00
|
|
|
|
2013-09-11 21:56:57 +02:00
|
|
|
|
2011-02-24 19:30:59 +01:00
|
|
|
|
|
|
|
|
|
2012-11-23 16:31:24 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-20 15:24:49 -05:00
|
|
|
|
2012-11-23 16:31:24 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-12-19 11:05:13 -05:00
|
|
|
|
2012-11-23 16:31:24 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-22 18:38:28 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-25 14:27:21 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-27 00:04:24 +02:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2012-07-30 13:28:18 +02:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2016-11-25 14:27:21 +01:00
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
2013-07-15 19:10:12 +02:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2008-06-27 00:04:24 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2008-06-27 00:04:24 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2011-02-24 19:30:59 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-01-07 23:44:32 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-01-11 16:51:17 +02:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-25 14:27:21 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2012-11-23 16:31:24 +01:00
|
|
|
|
|
|
|
|
|
2007-10-30 13:02:44 +01:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
2016-11-25 14:27:21 +01:00
|
|
|
|
2013-03-22 18:38:28 +01:00
|
|
|
|
2016-11-25 14:27:21 +01:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
2011-01-07 23:44:32 +01:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2016-11-25 14:27:21 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-22 18:38:28 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2007-10-30 13:02:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2006-12-08 18:40:53 +01:00
|
|
|
|
2006-12-08 18:40:44 +01: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 00:49:14 -08:00
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
2016-11-25 14:27:21 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
2013-07-15 19:10:12 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2006-12-08 18:40:53 +01:00
|
|
|
|
|
|
|
|
|
