2019-05-19 13:07:45 +01:00
|
|
|
|
2006-12-08 18:41:30 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-11-03 16:57:43 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:41:30 +01:00
|
|
|
|
|
|
|
|
|
2022-11-03 16:57:43 +01:00
|
|
|
|
2006-12-08 18:41:30 +01:00
|
|
|
|
HID: force HID depending on INPUT
In most configurations, INPUT is actually a boolean: either y or disabled,
but when it's disabled, you can't do much on your average laptop.
But it turns out that there is a possibility to have INPUT as a module:
you have to disable VT and TTY (of course), but also enable EXPERT.
I'll leave how to disable VT and TTY as an exercise for the bravest.
Anyway, if INPUT is m, we can still configure HID as y, which is not
correct because hid-input.c depends on the input API, meaning that
vmlinuz can not link.
So: add depends on INPUT too at the HID level, to ensure that if INPUT=m,
HID can only be m or disabled.
Fixes: 25621bcc8976 ("HID: Kconfig: split HID support and hid-core compilation")
Reported-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/r/202211181742.QYJY6Gug-lkp@intel.com
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2022-11-18 11:54:48 +01:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2007-01-03 23:03:14 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-06-25 16:55:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-01-03 23:03:14 +01:00
|
|
|
|
2020-07-18 13:47:49 +02:00
|
|
|
|
2007-01-03 23:03:14 +01:00
|
|
|
|
2009-01-06 10:15:27 +01:00
|
|
|
|
2006-12-08 18:41:30 +01:00
|
|
|
|
2012-06-25 16: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
|
|
|
|
2012-04-24 10:51:30 +02:00
|
|
|
|
2014-12-17 11:53:54 -02:00
|
|
|
|
2012-04-18 10:05:17 -04:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2012-04-24 10:51:30 +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
|
|
|
|
2007-05-14 09:57:40 +02:00
|
|
|
|
|
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2007-05-14 09:57:40 +02:00
|
|
|
|
|
|
|
|
|
2020-04-12 11:07:43 +02:00
|
|
|
|
2007-05-14 09:57:40 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-06-10 15:16:13 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2012-06-10 15:16:13 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-23 12:07:07 +02:00
|
|
|
|
|
|
|
|
|
2012-06-25 16:55:41 +02:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2012-06-25 16:55:41 +02:00
|
|
|
|
|
|
|
|
|
2012-04-23 12:07:07 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-08-18 23:08:45 +00:00
|
|
|
|
2025-10-13 20:54:57 +00:00
|
|
|
|
2025-08-18 23:08:45 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-06-25 16:55:41 +02:00
|
|
|
|
|
|
|
|
|
2008-06-23 23:31:09 +02:00
|
|
|
|
2021-04-06 20:25:38 +02:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2021-04-06 20:25:38 +02:00
|
|
|
|
2008-06-23 23:31:09 +02:00
|
|
|
|
2017-02-14 14:17:56 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2017-02-14 14:17:56 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-11 00:27:34 -08:00
|
|
|
|
|
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2011-03-11 00:27:34 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-08-04 00:25:56 -07:00
|
|
|
|
2011-03-11 00:27:34 -08:00
|
|
|
|
2010-07-19 12:13:23 +02:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2010-07-19 12:13:23 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-18 23:36:49 +02:00
|
|
|
|
HID: Stop hiding options with !EXPERT
Many HID driver options are hidden unless EXPERT is set. While I
understand the idea of simplifying the kernel configuration for most
users, in practice I believe it adds more confusion than it helps.
One thing that worries me is that, in non-EXPERT mode, these drivers
will be either built-in or modular based on apparent magic. For
example, switching INPUT and HID from m to y will cause all these
drivers to be built into the kernel when they were previously built
as modules. Short of enabling EXPERT mode altogether, the user has no
control over that.
Generally I do not think tristate options should depend on !EXPERT.
Of these, 11 of 15 are currently in the hid subsystem.
The HID_LOGITECH option is even worse than the others. Sub-options
depend on it, and this causes menuconfig and friends to display the
option even though the user can't change its value. The help page for
HID_LOGITECH will not explain why the value can't be changed. It only
says, for example:
Depends on: INPUT [=y] && HID [=y]
and that leaves the user puzzled about why the option is forced to y.
You might argue that this is a Kconfig bug, but that doesn't make it
less annoying for the user.
Even worse is that some of the sub-options of HID_LOGITECH select
INPUT_FF_MEMLESS, which in turn gets out of control for the user. So,
if you set INPUT=y and HID=y (something most general purpose
distributions would do these days, as both modules would get loaded on
a vast majority of systems otherwise), and you want support for
force-feedback game controllers, you can't have that as a module, it
has to be built-in, regardless of how rare these devices are.
Of course, all this madness goes away once EXPERT is enabled, but then
the rest of the kernel configuration becomes more complex, which
totally voids the original point.
For this reason, I would like all HID device tristate options to be
displayed regardless of EXPERT being set or not. We can let the
default settings still depend on EXPERT, that's not intrusive.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2015-02-20 17:33:33 +01:00
|
|
|
|
2022-02-17 08:17:02 +01:00
|
|
|
|
|
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2008-06-18 23:36:49 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-10-16 01:25:15 +02:00
|
|
|
|
|
|
|
|
|
2008-06-18 23:36:49 +02:00
|
|
|
|
2013-04-17 18:15:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2013-04-17 18:15:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-12-31 17:34:11 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-04-10 10:30:57 +02:00
|
|
|
|
2024-12-31 17:34:11 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-12-31 17:35:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-12-31 17:37:17 +00:00
|
|
|
|
2024-12-31 17:35:04 +00:00
|
|
|
|
2025-04-10 10:30:56 +02:00
|
|
|
|
2024-12-31 17:35:04 +00:00
|
|
|
|
2024-12-31 17:37:17 +00:00
|
|
|
|
2024-12-31 17:35:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
HID: Asus X205TA keyboard driver
Asus X205TA built-in keyboard contains wrong
logical maximum value in report descriptor.
0x05, 0x01, // Usage Page (Generic Desktop)
0x09, 0x06, // Usage (Keyboard)
0xa1, 0x01, // Collection (Application)
0x85, 0x01, // Report ID (1)
0x05, 0x07, // Usage Page (Keyboard/Keypad)
0x19, 0xe0, // Usage Minimum (224)
0x29, 0xe7, // Usage Maximum (231)
0x15, 0x00, // Logical Minimum (0)
0x25, 0x01, // Logical Maximum (1)
0x75, 0x01, // Report Size (1)
0x95, 0x08, // Report Count (8)
0x81, 0x02, // Input (Data,Array,Abs)
0x95, 0x01, // Report Count (1)
0x75, 0x08, // Report Size (8)
0x81, 0x03, // Input (Const,Var,Abs)
0x95, 0x05, // Report Count (5)
0x75, 0x01, // Report Size (1)
0x05, 0x08, // Usage (LED)
0x19, 0x01, // Usage Minimum (1)
0x29, 0x05, // Usage Maximum (5)
0x91, 0x02, // Output (Data,Var,Abs)
0x95, 0x01, // Report Count (1)
0x75, 0x03, // Report Size (3)
0x91, 0x03, // Output (Const,Var,Abs)
0x95, 0x06, // Report Count (6)
0x75, 0x08, // Report Size (8)
0x15, 0x00, // Logical Minimum (0)
0x25, 0x65, // Logical Maximum (101) * too small *
0x05, 0x07, // Usage Page (Keyboard/Keypad)
0x19, 0x00, // Usage Minimum (0)
0x29, 0xdd, // Usage Maximum (221)
0x81, 0x00, // Input(Data,Array,Abs)
In Asus X205TA japanese keyboard model,there are language
specific keys over usage id 101.
This patch correct wrong logical maximum in report
descriptor.
Signed-off-by: Yusuke Fujimaki <usk.fujimaki@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2016-03-21 16:18:42 +09:00
|
|
|
|
|
|
|
|
|
2020-05-07 11:53:34 +02:00
|
|
|
|
2017-04-06 12:18:17 +02:00
|
|
|
|
2018-10-09 14:40:56 +08:00
|
|
|
|
2019-03-04 20:54:43 +01:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2017-03-01 15:48:51 -06:00
|
|
|
|
|
|
|
|
|
2016-04-03 23:15:16 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-03-01 15:48:51 -06:00
|
|
|
|
|
|
|
|
|
HID: Asus X205TA keyboard driver
Asus X205TA built-in keyboard contains wrong
logical maximum value in report descriptor.
0x05, 0x01, // Usage Page (Generic Desktop)
0x09, 0x06, // Usage (Keyboard)
0xa1, 0x01, // Collection (Application)
0x85, 0x01, // Report ID (1)
0x05, 0x07, // Usage Page (Keyboard/Keypad)
0x19, 0xe0, // Usage Minimum (224)
0x29, 0xe7, // Usage Maximum (231)
0x15, 0x00, // Logical Minimum (0)
0x25, 0x01, // Logical Maximum (1)
0x75, 0x01, // Report Size (1)
0x95, 0x08, // Report Count (8)
0x81, 0x02, // Input (Data,Array,Abs)
0x95, 0x01, // Report Count (1)
0x75, 0x08, // Report Size (8)
0x81, 0x03, // Input (Const,Var,Abs)
0x95, 0x05, // Report Count (5)
0x75, 0x01, // Report Size (1)
0x05, 0x08, // Usage (LED)
0x19, 0x01, // Usage Minimum (1)
0x29, 0x05, // Usage Maximum (5)
0x91, 0x02, // Output (Data,Var,Abs)
0x95, 0x01, // Report Count (1)
0x75, 0x03, // Report Size (3)
0x91, 0x03, // Output (Const,Var,Abs)
0x95, 0x06, // Report Count (6)
0x75, 0x08, // Report Size (8)
0x15, 0x00, // Logical Minimum (0)
0x25, 0x65, // Logical Maximum (101) * too small *
0x05, 0x07, // Usage Page (Keyboard/Keypad)
0x19, 0x00, // Usage Minimum (0)
0x29, 0xdd, // Usage Maximum (221)
0x81, 0x00, // Input(Data,Array,Abs)
In Asus X205TA japanese keyboard model,there are language
specific keys over usage id 101.
This patch correct wrong logical maximum in report
descriptor.
Signed-off-by: Yusuke Fujimaki <usk.fujimaki@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2016-03-21 16:18:42 +09:00
|
|
|
|
2012-04-10 19:29:04 -03:00
|
|
|
|
|
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2012-04-10 19:29:04 -03:00
|
|
|
|
|
|
|
|
|
2008-06-24 23:24:57 +02:00
|
|
|
|
HID: Stop hiding options with !EXPERT
Many HID driver options are hidden unless EXPERT is set. While I
understand the idea of simplifying the kernel configuration for most
users, in practice I believe it adds more confusion than it helps.
One thing that worries me is that, in non-EXPERT mode, these drivers
will be either built-in or modular based on apparent magic. For
example, switching INPUT and HID from m to y will cause all these
drivers to be built into the kernel when they were previously built
as modules. Short of enabling EXPERT mode altogether, the user has no
control over that.
Generally I do not think tristate options should depend on !EXPERT.
Of these, 11 of 15 are currently in the hid subsystem.
The HID_LOGITECH option is even worse than the others. Sub-options
depend on it, and this causes menuconfig and friends to display the
option even though the user can't change its value. The help page for
HID_LOGITECH will not explain why the value can't be changed. It only
says, for example:
Depends on: INPUT [=y] && HID [=y]
and that leaves the user puzzled about why the option is forced to y.
You might argue that this is a Kconfig bug, but that doesn't make it
less annoying for the user.
Even worse is that some of the sub-options of HID_LOGITECH select
INPUT_FF_MEMLESS, which in turn gets out of control for the user. So,
if you set INPUT=y and HID=y (something most general purpose
distributions would do these days, as both modules would get loaded on
a vast majority of systems otherwise), and you want support for
force-feedback game controllers, you can't have that as a module, it
has to be built-in, regardless of how rare these devices are.
Of course, all this madness goes away once EXPERT is enabled, but then
the rest of the kernel configuration becomes more complex, which
totally voids the original point.
For this reason, I would like all HID device tristate options to be
displayed regardless of EXPERT being set or not. We can let the
default settings still depend on EXPERT, that's not intrusive.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2015-02-20 17:33:33 +01:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2008-06-24 23:24:57 +02:00
|
|
|
|
|
|
|
|
|
2014-11-26 18:21:03 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2014-11-26 18:21:03 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-23 17:03:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-24 20:42:25 +02:00
|
|
|
|
HID: Stop hiding options with !EXPERT
Many HID driver options are hidden unless EXPERT is set. While I
understand the idea of simplifying the kernel configuration for most
users, in practice I believe it adds more confusion than it helps.
One thing that worries me is that, in non-EXPERT mode, these drivers
will be either built-in or modular based on apparent magic. For
example, switching INPUT and HID from m to y will cause all these
drivers to be built into the kernel when they were previously built
as modules. Short of enabling EXPERT mode altogether, the user has no
control over that.
Generally I do not think tristate options should depend on !EXPERT.
Of these, 11 of 15 are currently in the hid subsystem.
The HID_LOGITECH option is even worse than the others. Sub-options
depend on it, and this causes menuconfig and friends to display the
option even though the user can't change its value. The help page for
HID_LOGITECH will not explain why the value can't be changed. It only
says, for example:
Depends on: INPUT [=y] && HID [=y]
and that leaves the user puzzled about why the option is forced to y.
You might argue that this is a Kconfig bug, but that doesn't make it
less annoying for the user.
Even worse is that some of the sub-options of HID_LOGITECH select
INPUT_FF_MEMLESS, which in turn gets out of control for the user. So,
if you set INPUT=y and HID=y (something most general purpose
distributions would do these days, as both modules would get loaded on
a vast majority of systems otherwise), and you want support for
force-feedback game controllers, you can't have that as a module, it
has to be built-in, regardless of how rare these devices are.
Of course, all this madness goes away once EXPERT is enabled, but then
the rest of the kernel configuration becomes more complex, which
totally voids the original point.
For this reason, I would like all HID device tristate options to be
displayed regardless of EXPERT being set or not. We can let the
default settings still depend on EXPERT, that's not intrusive.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2015-02-20 17:33:33 +01:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2008-10-16 01:25:15 +02:00
|
|
|
|
2008-06-24 20:42:25 +02:00
|
|
|
|
2008-06-24 22:48:52 +02:00
|
|
|
|
2017-02-17 07:40:52 -06:00
|
|
|
|
2021-12-03 08:59:27 +01:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2017-02-17 07:40:52 -06:00
|
|
|
|
2008-06-24 22:48:52 +02:00
|
|
|
|
2015-09-30 15:14:20 +02:00
|
|
|
|
|
|
|
|
|
2021-12-02 12:48:19 +01:00
|
|
|
|
2024-10-09 00:30:29 +01:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2015-09-30 15:14:20 +02:00
|
|
|
|
|
|
|
|
|
2024-10-09 00:30:29 +01:00
|
|
|
|
2015-09-30 15:14:20 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-03-06 21:02:39 +00:00
|
|
|
|
2024-10-09 00:30:29 +01:00
|
|
|
|
2015-09-30 15:14:20 +02:00
|
|
|
|
2018-07-17 22:35:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-04-02 21:18:17 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-05-12 15:18:59 +02:00
|
|
|
|
2010-05-12 15:27:00 +02:00
|
|
|
|
2021-12-03 09:12:31 +01:00
|
|
|
|
2010-05-12 15:18:59 +02:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2010-05-12 15:18:59 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-01-22 11:59:43 +08:00
|
|
|
|
2021-07-20 22:27:08 +02:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2021-07-20 22:27:08 +02:00
|
|
|
|
|
|
|
|
|
2016-01-22 11:59:43 +08:00
|
|
|
|
2014-02-04 12:42:48 -06:00
|
|
|
|
|
|
|
|
|
2017-11-02 12:12:43 +01:00
|
|
|
|
2017-03-12 19:56:08 +01:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2014-02-04 12:42:48 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-07-02 10:39:31 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-23 22:54:08 +02:00
|
|
|
|
HID: Stop hiding options with !EXPERT
Many HID driver options are hidden unless EXPERT is set. While I
understand the idea of simplifying the kernel configuration for most
users, in practice I believe it adds more confusion than it helps.
One thing that worries me is that, in non-EXPERT mode, these drivers
will be either built-in or modular based on apparent magic. For
example, switching INPUT and HID from m to y will cause all these
drivers to be built into the kernel when they were previously built
as modules. Short of enabling EXPERT mode altogether, the user has no
control over that.
Generally I do not think tristate options should depend on !EXPERT.
Of these, 11 of 15 are currently in the hid subsystem.
The HID_LOGITECH option is even worse than the others. Sub-options
depend on it, and this causes menuconfig and friends to display the
option even though the user can't change its value. The help page for
HID_LOGITECH will not explain why the value can't be changed. It only
says, for example:
Depends on: INPUT [=y] && HID [=y]
and that leaves the user puzzled about why the option is forced to y.
You might argue that this is a Kconfig bug, but that doesn't make it
less annoying for the user.
Even worse is that some of the sub-options of HID_LOGITECH select
INPUT_FF_MEMLESS, which in turn gets out of control for the user. So,
if you set INPUT=y and HID=y (something most general purpose
distributions would do these days, as both modules would get loaded on
a vast majority of systems otherwise), and you want support for
force-feedback game controllers, you can't have that as a module, it
has to be built-in, regardless of how rare these devices are.
Of course, all this madness goes away once EXPERT is enabled, but then
the rest of the kernel configuration becomes more complex, which
totally voids the original point.
For this reason, I would like all HID device tristate options to be
displayed regardless of EXPERT being set or not. We can let the
default settings still depend on EXPERT, that's not intrusive.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2015-02-20 17:33:33 +01:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2008-10-16 01:25:15 +02:00
|
|
|
|
2008-06-23 22:54:08 +02:00
|
|
|
|
2009-05-15 15:46:44 +02:00
|
|
|
|
2010-08-16 16:26:08 +02:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2011-01-28 14:50:53 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-15 15:46:44 +02:00
|
|
|
|
|
|
|
|
|
2010-08-16 16:26:08 +02:00
|
|
|
|
2009-05-15 15:46:44 +02:00
|
|
|
|
2009-03-04 22:12:04 +13:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2009-03-04 22:12:04 +13:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-11-01 15:13:37 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2010-11-01 15:13:37 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-01-14 02:33:49 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2018-01-14 02:33:49 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-06-28 18:54:25 +02:00
|
|
|
|
2017-04-26 17:37:04 +01:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2017-04-26 17:37:04 +01:00
|
|
|
|
|
|
|
|
|
2018-03-01 17:22:23 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-01-23 12:56:09 +09:00
|
|
|
|
2010-06-28 18:54:25 +02:00
|
|
|
|
2013-05-07 11:40:58 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2013-05-07 11:40:58 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-25 22:15:10 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-11-19 17:49:27 -08:00
|
|
|
|
2023-01-25 22:15:10 +01:00
|
|
|
|
2008-06-24 21:11:21 +02:00
|
|
|
|
HID: Stop hiding options with !EXPERT
Many HID driver options are hidden unless EXPERT is set. While I
understand the idea of simplifying the kernel configuration for most
users, in practice I believe it adds more confusion than it helps.
One thing that worries me is that, in non-EXPERT mode, these drivers
will be either built-in or modular based on apparent magic. For
example, switching INPUT and HID from m to y will cause all these
drivers to be built into the kernel when they were previously built
as modules. Short of enabling EXPERT mode altogether, the user has no
control over that.
Generally I do not think tristate options should depend on !EXPERT.
Of these, 11 of 15 are currently in the hid subsystem.
The HID_LOGITECH option is even worse than the others. Sub-options
depend on it, and this causes menuconfig and friends to display the
option even though the user can't change its value. The help page for
HID_LOGITECH will not explain why the value can't be changed. It only
says, for example:
Depends on: INPUT [=y] && HID [=y]
and that leaves the user puzzled about why the option is forced to y.
You might argue that this is a Kconfig bug, but that doesn't make it
less annoying for the user.
Even worse is that some of the sub-options of HID_LOGITECH select
INPUT_FF_MEMLESS, which in turn gets out of control for the user. So,
if you set INPUT=y and HID=y (something most general purpose
distributions would do these days, as both modules would get loaded on
a vast majority of systems otherwise), and you want support for
force-feedback game controllers, you can't have that as a module, it
has to be built-in, regardless of how rare these devices are.
Of course, all this madness goes away once EXPERT is enabled, but then
the rest of the kernel configuration becomes more complex, which
totally voids the original point.
For this reason, I would like all HID device tristate options to be
displayed regardless of EXPERT being set or not. We can let the
default settings still depend on EXPERT, that's not intrusive.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2015-02-20 17:33:33 +01:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2008-10-16 01:25:15 +02:00
|
|
|
|
2008-06-24 21:11:21 +02:00
|
|
|
|
2021-02-19 18:36:44 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-08-13 11:11:27 -04:00
|
|
|
|
|
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2015-08-13 11:11:27 -04:00
|
|
|
|
|
|
|
|
|
2015-10-26 01:15:58 -07:00
|
|
|
|
|
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2015-10-26 01:15:58 -07:00
|
|
|
|
|
|
|
|
|
2020-03-13 03:12:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-06-27 00:07:31 +03:00
|
|
|
|
2012-07-06 08:05:04 -07:00
|
|
|
|
2011-06-27 00:07:31 +03:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2012-07-06 08:05:04 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-21 01:31:08 +02:00
|
|
|
|
2013-05-21 01:31:09 +02:00
|
|
|
|
|
|
|
|
|
2013-10-01 19:22:05 +02:00
|
|
|
|
2013-10-21 23:42:22 +02:00
|
|
|
|
2011-06-27 00:07:31 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2011-06-27 00:07:31 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
HID: hyperx: add driver for the HyperX QuadCast 2 mute button
The tap-to-mute button of the HyperX QuadCast 2 (03f0:07b4) is handled
entirely in the device firmware. The firmware gates the audio internally
but never sends the Telephony "Phone Mute" usage (0x2f) that its own report
descriptor advertises, and it does not touch the UAC feature unit either.
Consequently neither an evdev key event nor an ALSA mixer change is ever
generated, and userspace has no way to learn that the microphone was muted:
desktops keep showing the microphone as live, and conferencing applications
keep displaying an unmuted microphone while transmitting silence.
The mute state is reported through a vendor-defined collection instead:
06 c0 ff Usage Page (Vendor-Defined 0xFFC0)
a1 01 Collection (Application)
06 c1 ff Usage Page (Vendor-Defined 0xFFC1)
85 77 Report ID (0x77)
09 f0 Usage (0xF0)
75 08 95 3f Report Size (8), Report Count (63)
81 02 Input (Data,Var,Abs)
Pressing the button emits a 64-byte report on that collection:
77 06 00 00 ... microphone unmuted
77 06 01 00 ... microphone muted
where byte 1 identifies the mute event and byte 2 carries the resulting
state. As the payload is an opaque vendor blob carrying no HID usages,
hid-input cannot map it and a hwdb entry cannot express it either.
Add a driver that decodes the report and emits KEY_MICMUTE, which makes the
button behave like any other microphone mute key.
Note that the device reports the resulting absolute state, whereas
KEY_MICMUTE is a momentary key that userspace acts on as a toggle, so the
driver emits one keypress per state change.
Tested on a HyperX QuadCast 2 (03f0:07b4).
Signed-off-by: Benjamin Blume <benjaminblume@posteo.de>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-07-13 12:42:13 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-03-14 21:04:39 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-08-14 10:45:12 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-03-15 09:28:25 +08:00
|
|
|
|
|
|
|
|
|
2022-03-14 21:08:44 -07:00
|
|
|
|
|
|
|
|
|
2019-09-02 11:53:01 +02:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2018-03-15 09:28:25 +08:00
|
|
|
|
|
|
|
|
|
2023-07-16 20:48:34 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-09 15:03:04 -07:00
|
|
|
|
|
|
|
|
|
2022-03-14 21:04:39 -07:00
|
|
|
|
2022-03-14 19:45:37 -07:00
|
|
|
|
2020-09-09 15:03:04 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-06-18 19:05:02 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2014-06-18 19:05:02 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-07-20 03:15:46 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-02-17 15:12:45 +01:00
|
|
|
|
2011-03-22 02:29:17 -07:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2011-02-17 15:12:45 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-03-11 11:43:27 +01:00
|
|
|
|
2012-02-28 13:01:46 +02:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2012-02-28 13:01:46 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-03-11 11:43:27 +01:00
|
|
|
|
2024-10-05 13:57:04 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-08-09 20:44:17 +04:00
|
|
|
|
2010-08-09 19:56:01 +02:00
|
|
|
|
2015-03-04 11:24:55 -05:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2015-03-03 12:44:01 -05:00
|
|
|
|
2010-08-09 20:44:17 +04:00
|
|
|
|
2010-08-20 19:21:11 +04:00
|
|
|
|
|
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2010-08-20 19:21:11 +04:00
|
|
|
|
|
|
|
|
|
2019-02-10 12:13:48 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-09-02 10:25:52 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-09-19 14:12:36 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-07-24 23:35:13 +02:00
|
|
|
|
2010-08-16 16:26:08 +02:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2008-10-16 01:25:15 +02:00
|
|
|
|
2008-07-24 23:35:13 +02:00
|
|
|
|
2012-10-31 12:10:10 +01:00
|
|
|
|
|
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2012-10-31 12:10:10 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-05-10 17:12:53 +02:00
|
|
|
|
|
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2017-05-10 17:12:53 +02:00
|
|
|
|
|
|
|
|
|
2017-10-04 12:31:22 +02:00
|
|
|
|
|
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2017-10-04 12:31:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-07-13 14:19:58 +02:00
|
|
|
|
2010-08-16 16:26:08 +02:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2009-07-13 14:19:58 +02:00
|
|
|
|
|
|
|
|
|
2009-03-04 16:09:40 +01:00
|
|
|
|
HID: Stop hiding options with !EXPERT
Many HID driver options are hidden unless EXPERT is set. While I
understand the idea of simplifying the kernel configuration for most
users, in practice I believe it adds more confusion than it helps.
One thing that worries me is that, in non-EXPERT mode, these drivers
will be either built-in or modular based on apparent magic. For
example, switching INPUT and HID from m to y will cause all these
drivers to be built into the kernel when they were previously built
as modules. Short of enabling EXPERT mode altogether, the user has no
control over that.
Generally I do not think tristate options should depend on !EXPERT.
Of these, 11 of 15 are currently in the hid subsystem.
The HID_LOGITECH option is even worse than the others. Sub-options
depend on it, and this causes menuconfig and friends to display the
option even though the user can't change its value. The help page for
HID_LOGITECH will not explain why the value can't be changed. It only
says, for example:
Depends on: INPUT [=y] && HID [=y]
and that leaves the user puzzled about why the option is forced to y.
You might argue that this is a Kconfig bug, but that doesn't make it
less annoying for the user.
Even worse is that some of the sub-options of HID_LOGITECH select
INPUT_FF_MEMLESS, which in turn gets out of control for the user. So,
if you set INPUT=y and HID=y (something most general purpose
distributions would do these days, as both modules would get loaded on
a vast majority of systems otherwise), and you want support for
force-feedback game controllers, you can't have that as a module, it
has to be built-in, regardless of how rare these devices are.
Of course, all this madness goes away once EXPERT is enabled, but then
the rest of the kernel configuration becomes more complex, which
totally voids the original point.
For this reason, I would like all HID device tristate options to be
displayed regardless of EXPERT being set or not. We can let the
default settings still depend on EXPERT, that's not intrusive.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2015-02-20 17:33:33 +01:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2009-03-04 16:09:40 +01:00
|
|
|
|
|
|
|
|
|
2011-02-03 16:41:47 +01:00
|
|
|
|
|
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2011-02-03 16:41:47 +01:00
|
|
|
|
|
|
|
|
|
2016-06-17 21:20:46 +02:00
|
|
|
|
2016-06-17 22:29:47 +02:00
|
|
|
|
2016-06-17 21:20:46 +02:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2016-06-21 21:49:29 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-07-04 21:45:54 +02:00
|
|
|
|
2016-07-04 21:47:52 +02:00
|
|
|
|
2016-06-17 21:20:46 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-07-23 23:30:45 +01:00
|
|
|
|
|
|
|
|
|
2026-03-24 20:20:28 +01:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2018-04-12 19:36:47 +02:00
|
|
|
|
2012-02-15 13:40:43 +01:00
|
|
|
|
2018-04-12 19:36:47 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-07-23 23:30:45 +01:00
|
|
|
|
|
|
|
|
|
2014-07-23 23:30:48 +01:00
|
|
|
|
|
|
|
|
|
2012-02-15 13:40:43 +01:00
|
|
|
|
HID: hid-lenovo-go: Add Lenovo Legion Go Series HID Driver
Adds initial framework for a new HID driver, hid-lenovo-go, along with
attributes that report the firmware and hardware version for each
component of the HID device, of which there are 4 parts: The MCU, the
transmission dongle, the left "handle" controller half, and the right
"handle" controller half. Each of these devices are provided an attribute
group to contain its device specific attributes. Additionally, the touchpad
device attributes are logically separated from the other components in
another attribute group.
This driver primarily provides access to the configurable settings of the
Lenovo Legion Go and Lenovo Legion Go 2 controllers running the latest
firmware. As previously noted, the Legion Go controllers recently had a
firmware update[1] which switched from the original "SepentiaUSB" protocol
to a brand new protocol for the Go 2, primarily to ensure backwards and
forwards compatibility between the Go and Go 2 devices. As part of that
update the PIDs for the controllers were changed, so there is no risk of
this driver attaching to controller firmware that it doesn't support.
--
v6:
- Make attributes static.
- Use NULL instead of 0 in mcu_propery_out when there is no data.
v5:
- Make version attributes static, retrieve them using delayed work
during probe.
- Fix endianness of version strings and print as hex.
v3:
- Add hid-lenovo.c and Mark Pearson to LENOVO HID DRIVERS entry in MAINTAINERS
Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-03-10 07:29:20 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-03-24 20:20:28 +01:00
|
|
|
|
HID: hid-lenovo-go: Add Lenovo Legion Go Series HID Driver
Adds initial framework for a new HID driver, hid-lenovo-go, along with
attributes that report the firmware and hardware version for each
component of the HID device, of which there are 4 parts: The MCU, the
transmission dongle, the left "handle" controller half, and the right
"handle" controller half. Each of these devices are provided an attribute
group to contain its device specific attributes. Additionally, the touchpad
device attributes are logically separated from the other components in
another attribute group.
This driver primarily provides access to the configurable settings of the
Lenovo Legion Go and Lenovo Legion Go 2 controllers running the latest
firmware. As previously noted, the Legion Go controllers recently had a
firmware update[1] which switched from the original "SepentiaUSB" protocol
to a brand new protocol for the Go 2, primarily to ensure backwards and
forwards compatibility between the Go and Go 2 devices. As part of that
update the PIDs for the controllers were changed, so there is no risk of
this driver attaching to controller firmware that it doesn't support.
--
v6:
- Make attributes static.
- Use NULL instead of 0 in mcu_propery_out when there is no data.
v5:
- Make version attributes static, retrieve them using delayed work
during probe.
- Fix endianness of version strings and print as hex.
v3:
- Add hid-lenovo.c and Mark Pearson to LENOVO HID DRIVERS entry in MAINTAINERS
Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-03-10 07:29:20 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-03-10 07:29:28 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-03-24 20:20:28 +01:00
|
|
|
|
2026-03-10 07:29:28 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-12-12 22:23:33 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-05-16 11:49:19 +02:00
|
|
|
|
HID: Stop hiding options with !EXPERT
Many HID driver options are hidden unless EXPERT is set. While I
understand the idea of simplifying the kernel configuration for most
users, in practice I believe it adds more confusion than it helps.
One thing that worries me is that, in non-EXPERT mode, these drivers
will be either built-in or modular based on apparent magic. For
example, switching INPUT and HID from m to y will cause all these
drivers to be built into the kernel when they were previously built
as modules. Short of enabling EXPERT mode altogether, the user has no
control over that.
Generally I do not think tristate options should depend on !EXPERT.
Of these, 11 of 15 are currently in the hid subsystem.
The HID_LOGITECH option is even worse than the others. Sub-options
depend on it, and this causes menuconfig and friends to display the
option even though the user can't change its value. The help page for
HID_LOGITECH will not explain why the value can't be changed. It only
says, for example:
Depends on: INPUT [=y] && HID [=y]
and that leaves the user puzzled about why the option is forced to y.
You might argue that this is a Kconfig bug, but that doesn't make it
less annoying for the user.
Even worse is that some of the sub-options of HID_LOGITECH select
INPUT_FF_MEMLESS, which in turn gets out of control for the user. So,
if you set INPUT=y and HID=y (something most general purpose
distributions would do these days, as both modules would get loaded on
a vast majority of systems otherwise), and you want support for
force-feedback game controllers, you can't have that as a module, it
has to be built-in, regardless of how rare these devices are.
Of course, all this madness goes away once EXPERT is enabled, but then
the rest of the kernel configuration becomes more complex, which
totally voids the original point.
For this reason, I would like all HID device tristate options to be
displayed regardless of EXPERT being set or not. We can let the
default settings still depend on EXPERT, that's not intrusive.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2015-02-20 17:33:33 +01:00
|
|
|
|
2021-12-02 12:48:19 +01:00
|
|
|
|
2019-10-04 09:37:15 +02:00
|
|
|
|
2025-02-11 13:02:40 +08:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2008-10-16 01:25:15 +02:00
|
|
|
|
2008-05-16 11:49:19 +02:00
|
|
|
|
2011-09-15 11:34:49 +02:00
|
|
|
|
2020-01-12 23:50:09 +00:00
|
|
|
|
2019-04-24 15:13:52 +02:00
|
|
|
|
HID: logitech-dj: add HIDRAW dependency in Kconfig
hid-logitech-dj.c driver needs hidraw to work correctly. Without
hidraw, hid-logitech-dj.c fails during probe() and Logitech
Unifying devices HID reports aren't recognized.
The unifying receiver has 3 usb interfaces. When hid-logitech-dj driver is
loaded, interfaces 0 and 1 are discarded.
Interface 2 consists of a hid class interface with 3 collections, each of
which sports the 'vendor' usage, thus, there is no reason for hid_input to
claim any of them. On the other hand, hidraw has no issue in claiming the
collections, even if they are 'vendor'. As of today, hid-logitech-dj uses
hidraw api to send configuration/control reports to interface 2 of the
Unifying receiver.
Without the hid-logitech-dj driver, interfaces 0 and 1 are claimed by
hid-input, as they correspond to a keyboard and a mouse. But that is not
relevant to the discussion.
[jkosina@suse.cz: make the changelog more verbose, thanks to Nestor]
Signed-off-by: Olivier Gay <ogay@logitech.com>
Signed-off-by: Nestor Lopez Casado <nlopezcasad@logitech.com>
Signed-off-by: Mathieu Meisser <mmeisser@logitech.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-12-03 00:17:24 +01:00
|
|
|
|
2011-09-15 11:34:49 +02:00
|
|
|
|
2014-09-30 13:18:28 -04:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2020-01-12 23:50:09 +00:00
|
|
|
|
|
|
|
|
|
2012-02-13 14:13:03 +04:00
|
|
|
|
2012-12-27 17:33:02 +01:00
|
|
|
|
2012-02-13 14:13:03 +04:00
|
|
|
|
2011-09-15 11:34:49 +02:00
|
|
|
|
2014-09-30 13:18:27 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-07-11 23:49:20 +02:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2021-07-23 17:08:40 +02:00
|
|
|
|
2014-09-30 13:18:27 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-06 09:09:13 +01:00
|
|
|
|
2014-09-30 13:18:27 -04:00
|
|
|
|
2008-07-04 23:06:45 +02:00
|
|
|
|
2009-05-15 15:46:44 +02:00
|
|
|
|
2008-07-04 23:06:45 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-10-07 19:48:12 +03:00
|
|
|
|
2008-07-04 23:06:45 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-10-07 19:48:12 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-07-04 23:06:45 +02:00
|
|
|
|
2010-01-13 00:25:58 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-08-04 16:24:22 +02:00
|
|
|
|
|
|
|
|
|
2010-09-22 13:19:42 +02:00
|
|
|
|
|
|
|
|
|
2011-08-10 18:11:10 +02:00
|
|
|
|
2010-09-22 13:19:42 +02:00
|
|
|
|
2016-09-18 10:55:42 -06:00
|
|
|
|
2011-08-04 16:24:22 +02:00
|
|
|
|
2016-09-18 10:55:42 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-08-04 16:24:22 +02:00
|
|
|
|
2016-09-18 10:55:42 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-22 13:19:42 +02:00
|
|
|
|
2010-02-06 12:24:36 -05:00
|
|
|
|
2013-04-20 20:13:52 +01:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2013-04-20 20:13:52 +01:00
|
|
|
|
2010-02-06 12:24:36 -05:00
|
|
|
|
|
|
|
|
|
2013-04-20 20:13:52 +01:00
|
|
|
|
2010-02-06 12:24:36 -05:00
|
|
|
|
2019-01-14 17:50:07 +00:00
|
|
|
|
|
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2019-01-14 17:50:07 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-03 19:47:42 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2016-11-03 19:47:42 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-20 21:40:41 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-03-21 20:42:49 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-04-17 00:38:24 +03:00
|
|
|
|
|
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2018-04-17 00:38:24 +03:00
|
|
|
|
|
|
|
|
|
2008-06-20 21:26:11 +02:00
|
|
|
|
HID: Stop hiding options with !EXPERT
Many HID driver options are hidden unless EXPERT is set. While I
understand the idea of simplifying the kernel configuration for most
users, in practice I believe it adds more confusion than it helps.
One thing that worries me is that, in non-EXPERT mode, these drivers
will be either built-in or modular based on apparent magic. For
example, switching INPUT and HID from m to y will cause all these
drivers to be built into the kernel when they were previously built
as modules. Short of enabling EXPERT mode altogether, the user has no
control over that.
Generally I do not think tristate options should depend on !EXPERT.
Of these, 11 of 15 are currently in the hid subsystem.
The HID_LOGITECH option is even worse than the others. Sub-options
depend on it, and this causes menuconfig and friends to display the
option even though the user can't change its value. The help page for
HID_LOGITECH will not explain why the value can't be changed. It only
says, for example:
Depends on: INPUT [=y] && HID [=y]
and that leaves the user puzzled about why the option is forced to y.
You might argue that this is a Kconfig bug, but that doesn't make it
less annoying for the user.
Even worse is that some of the sub-options of HID_LOGITECH select
INPUT_FF_MEMLESS, which in turn gets out of control for the user. So,
if you set INPUT=y and HID=y (something most general purpose
distributions would do these days, as both modules would get loaded on
a vast majority of systems otherwise), and you want support for
force-feedback game controllers, you can't have that as a module, it
has to be built-in, regardless of how rare these devices are.
Of course, all this madness goes away once EXPERT is enabled, but then
the rest of the kernel configuration becomes more complex, which
totally voids the original point.
For this reason, I would like all HID device tristate options to be
displayed regardless of EXPERT being set or not. We can let the
default settings still depend on EXPERT, that's not intrusive.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2015-02-20 17:33:33 +01:00
|
|
|
|
2018-09-05 13:24:47 +02:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2008-10-16 01:25:15 +02:00
|
|
|
|
2008-06-20 21:26:11 +02:00
|
|
|
|
2008-06-25 00:07:50 +02:00
|
|
|
|
HID: Stop hiding options with !EXPERT
Many HID driver options are hidden unless EXPERT is set. While I
understand the idea of simplifying the kernel configuration for most
users, in practice I believe it adds more confusion than it helps.
One thing that worries me is that, in non-EXPERT mode, these drivers
will be either built-in or modular based on apparent magic. For
example, switching INPUT and HID from m to y will cause all these
drivers to be built into the kernel when they were previously built
as modules. Short of enabling EXPERT mode altogether, the user has no
control over that.
Generally I do not think tristate options should depend on !EXPERT.
Of these, 11 of 15 are currently in the hid subsystem.
The HID_LOGITECH option is even worse than the others. Sub-options
depend on it, and this causes menuconfig and friends to display the
option even though the user can't change its value. The help page for
HID_LOGITECH will not explain why the value can't be changed. It only
says, for example:
Depends on: INPUT [=y] && HID [=y]
and that leaves the user puzzled about why the option is forced to y.
You might argue that this is a Kconfig bug, but that doesn't make it
less annoying for the user.
Even worse is that some of the sub-options of HID_LOGITECH select
INPUT_FF_MEMLESS, which in turn gets out of control for the user. So,
if you set INPUT=y and HID=y (something most general purpose
distributions would do these days, as both modules would get loaded on
a vast majority of systems otherwise), and you want support for
force-feedback game controllers, you can't have that as a module, it
has to be built-in, regardless of how rare these devices are.
Of course, all this madness goes away once EXPERT is enabled, but then
the rest of the kernel configuration becomes more complex, which
totally voids the original point.
For this reason, I would like all HID device tristate options to be
displayed regardless of EXPERT being set or not. We can let the
default settings still depend on EXPERT, that's not intrusive.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2015-02-20 17:33:33 +01:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2008-06-25 00:07:50 +02:00
|
|
|
|
|
|
|
|
|
2011-01-07 23:45:50 +01:00
|
|
|
|
|
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2011-01-07 23:45:50 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-22 17:34:01 +01:00
|
|
|
|
2011-05-19 14:18:13 +02:00
|
|
|
|
2025-05-27 22:13:17 +05:30
|
|
|
|
2011-12-23 15:40:59 +01:00
|
|
|
|
2011-05-20 15:59:34 +02:00
|
|
|
|
2011-05-28 02:03:47 +08:00
|
|
|
|
2015-07-20 09:40:28 -07:00
|
|
|
|
2011-05-19 14:18:14 +02:00
|
|
|
|
2011-01-11 16:45:54 +01:00
|
|
|
|
2013-10-26 00:03:49 +02:00
|
|
|
|
2011-05-19 11:37:29 +02:00
|
|
|
|
2011-05-20 15:59:34 +02:00
|
|
|
|
2011-05-19 14:18:15 +02:00
|
|
|
|
2011-01-11 16:45:54 +01:00
|
|
|
|
2011-05-20 15:59:34 +02:00
|
|
|
|
2011-01-31 11:28:22 +01:00
|
|
|
|
2011-08-15 21:12:09 -07:00
|
|
|
|
2011-05-18 15:27:24 +02:00
|
|
|
|
2011-04-22 11:51:48 +02:00
|
|
|
|
2012-02-14 00:50:33 -08:00
|
|
|
|
2011-04-21 16:21:52 +02:00
|
|
|
|
2012-02-04 17:08:50 +01:00
|
|
|
|
2011-12-15 11:09:06 +08:00
|
|
|
|
2011-01-11 16:45:54 +01:00
|
|
|
|
2011-11-29 13:13:10 +01:00
|
|
|
|
2011-05-20 15:59:34 +02:00
|
|
|
|
2013-10-21 12:38:49 -04:00
|
|
|
|
2011-03-18 14:27:53 +01:00
|
|
|
|
2011-05-19 14:18:16 +02:00
|
|
|
|
2011-05-19 14:18:17 +02:00
|
|
|
|
2013-11-21 10:04:30 +01:00
|
|
|
|
2011-07-15 16:58:06 +08:00
|
|
|
|
2012-01-05 11:53:46 +09:00
|
|
|
|
2012-06-19 14:39:54 +02:00
|
|
|
|
2011-01-07 23:45:50 +01:00
|
|
|
|
2011-01-11 16:45:54 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-09-11 13:36:24 -04:00
|
|
|
|
2023-12-04 00:17:21 -08:00
|
|
|
|
2021-09-11 13:36:25 -04:00
|
|
|
|
|
|
|
|
|
2021-09-11 13:36:26 -04:00
|
|
|
|
2021-09-11 13:36:24 -04:00
|
|
|
|
2023-12-04 00:17:21 -08:00
|
|
|
|
2021-09-11 13:36:24 -04:00
|
|
|
|
2023-12-04 00:17:21 -08:00
|
|
|
|
2024-12-11 18:26:48 -08:00
|
|
|
|
2021-09-11 13:36:24 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-09-11 13:36:28 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-12-04 00:17:21 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-09-11 13:36:28 -04:00
|
|
|
|
2017-02-01 11:54:57 -08:00
|
|
|
|
|
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2017-02-01 11:54:57 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-11-19 15:54:46 +01:00
|
|
|
|
2010-08-16 16:26:08 +02:00
|
|
|
|
2008-11-19 15:54:46 +01:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2008-11-19 15:54:46 +01:00
|
|
|
|
|
|
|
|
|
2023-06-08 07:34:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-13 17:05:17 -07:00
|
|
|
|
2023-09-17 08:18:50 -07:00
|
|
|
|
2023-06-08 07:34:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-01-21 14:36:52 +00:00
|
|
|
|
2011-03-21 13:54:22 +01:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2011-03-21 13:54:22 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-01-21 14:36:52 +00:00
|
|
|
|
HID: hid-oxp: Add OneXPlayer configuration driver
Adds OneXPlayer HID configuration driver. In this initial driver patch,
add the RGB interface for the first generation of HID based RGB control.
This interface provides the following attributes:
- brightness: provided by the LED core, this works in a fairly unique
way on this device. The hardware accepts 5 brightness values (0-4),
which affects the brightness of the multicolor and animated effects
built into the MCU firmware. For monocolor settings, the device
expects the hardware brightness value to be pushed to maximum, then we
apply brightness adjustments mathematically based on % (0-100). This
leads to some odd conversion as we need the brightness slider to reach
the full range, but it has no affect when incrementing between the
division points for other effects.
- multi-intensity: provided by the LED core for red, green, and blue.
- effect: Allows the MCU to set 19 individual effects.
- effect_index: Lists the 19 valid effect names for the interface.
- enabled: Allows the MCU to toggle the RGB interface on/off.
- enabled_index: Lists the valid states for enabled.
- speed: Allows the MCU to set the animation rate for the various
effects.
- speed_range: Lists the valid range of speed (0-9).
The MCU also has a few odd quirks that make sending multiple synchronous
events challenging. It will essentially freeze if it receives another
message before it has finished processing the last command. It also will
not reply if you wait on it using a completion. To get around this, we
do a 200ms sleep inside a work queue thread and debounce all but the most
recent message using a 50ms mod_delayed_work. This will cache the last
write, queue the work, then return so userspace can release its write
thread. The work queue is only used for brightness/multi-intensity as
that is the path likely to receive rapid successive writes.
Reviewed-by: Zhouwang Huang <honjow311@gmail.com>
Tested-by: Zhouwang Huang <honjow311@gmail.com>
Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-04-18 21:26:20 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-04-18 21:26:21 -07:00
|
|
|
|
HID: hid-oxp: Add OneXPlayer configuration driver
Adds OneXPlayer HID configuration driver. In this initial driver patch,
add the RGB interface for the first generation of HID based RGB control.
This interface provides the following attributes:
- brightness: provided by the LED core, this works in a fairly unique
way on this device. The hardware accepts 5 brightness values (0-4),
which affects the brightness of the multicolor and animated effects
built into the MCU firmware. For monocolor settings, the device
expects the hardware brightness value to be pushed to maximum, then we
apply brightness adjustments mathematically based on % (0-100). This
leads to some odd conversion as we need the brightness slider to reach
the full range, but it has no affect when incrementing between the
division points for other effects.
- multi-intensity: provided by the LED core for red, green, and blue.
- effect: Allows the MCU to set 19 individual effects.
- effect_index: Lists the 19 valid effect names for the interface.
- enabled: Allows the MCU to toggle the RGB interface on/off.
- enabled_index: Lists the valid states for enabled.
- speed: Allows the MCU to set the animation rate for the various
effects.
- speed_range: Lists the valid range of speed (0-9).
The MCU also has a few odd quirks that make sending multiple synchronous
events challenging. It will essentially freeze if it receives another
message before it has finished processing the last command. It also will
not reply if you wait on it using a completion. To get around this, we
do a 200ms sleep inside a work queue thread and debounce all but the most
recent message using a 50ms mod_delayed_work. This will cache the last
write, queue the work, then return so userspace can release its write
thread. The work queue is only used for brightness/multi-intensity as
that is the path likely to receive rapid successive writes.
Reviewed-by: Zhouwang Huang <honjow311@gmail.com>
Tested-by: Zhouwang Huang <honjow311@gmail.com>
Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-04-18 21:26:20 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-15 15:46:44 +02:00
|
|
|
|
2010-08-16 16:26:08 +02:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2009-05-15 15:46:44 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-09-18 19:43:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2008-09-18 19:43:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-03 10:33:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2014-09-03 10:33:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-24 23:46:21 +02:00
|
|
|
|
2010-08-16 16:26:08 +02:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2008-10-16 01:25:15 +02:00
|
|
|
|
2008-06-24 23:46:21 +02:00
|
|
|
|
2010-03-30 22:33:50 +02:00
|
|
|
|
|
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2010-03-30 22:33:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-03-30 22:38:09 +02:00
|
|
|
|
2010-04-11 12:17:45 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-03-30 22:34:30 +02:00
|
|
|
|
2010-03-30 22:33:50 +02:00
|
|
|
|
|
|
|
|
|
2010-04-11 12:17:45 +02:00
|
|
|
|
2011-01-20 14:44:16 -08:00
|
|
|
|
|
|
|
|
|
2010-04-11 12:17:45 +02:00
|
|
|
|
|
|
|
|
|
2023-08-28 15:14:22 +02:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2010-04-11 12:17:45 +02:00
|
|
|
|
2012-04-14 00:14:11 +09:00
|
|
|
|
2010-04-11 12:17:45 +02:00
|
|
|
|
|
|
|
|
|
2011-01-20 14:44:16 -08:00
|
|
|
|
|
|
|
|
|
2010-04-11 12:17:45 +02:00
|
|
|
|
|
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2010-04-11 12:17:45 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-01-20 14:44:16 -08:00
|
|
|
|
|
|
|
|
|
2010-04-11 12:17:45 +02:00
|
|
|
|
|
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2010-04-11 12:17:45 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-01-20 14:44:16 -08:00
|
|
|
|
|
|
|
|
|
2010-04-11 12:17:45 +02:00
|
|
|
|
|
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2010-04-11 12:17:45 +02:00
|
|
|
|
|
|
|
|
|
2012-07-30 21:38:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2012-07-30 21:38:28 +02:00
|
|
|
|
|
|
|
|
|
2014-10-31 17:34:42 -07:00
|
|
|
|
|
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2015-06-08 14:27:57 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-10-31 17:34:42 -07:00
|
|
|
|
2021-02-07 13:48:56 -08:00
|
|
|
|
|
|
|
|
|
2021-11-01 15:12:02 +01:00
|
|
|
|
2021-02-07 13:49:02 -08:00
|
|
|
|
2021-02-07 13:48:58 -08:00
|
|
|
|
2021-02-07 13:48:56 -08:00
|
|
|
|
2022-12-12 20:49:35 -08:00
|
|
|
|
2021-02-07 13:48:56 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-02-07 13:49:03 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-09-14 20:43:45 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-06-28 00:04:23 +07:00
|
|
|
|
|
|
|
|
|
2026-07-03 17:45:54 +02:00
|
|
|
|
2025-06-28 00:04:23 +07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-01-16 16:34:25 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-14 17:18:54 -07:00
|
|
|
|
2011-10-17 17:04:58 +02:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2011-10-14 17:18:54 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-20 18:13:37 +02:00
|
|
|
|
2017-09-23 17:33:21 -07:00
|
|
|
|
2017-06-20 18:13:37 +02:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2017-06-20 18:13:37 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-05-19 18:55:16 +02:00
|
|
|
|
2011-12-29 17:20:14 +01:00
|
|
|
|
2010-05-19 18:55:16 +02:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2011-12-29 17:20:14 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-08-29 12:30:18 +02:00
|
|
|
|
2026-06-17 23:00:36 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-02-22 02:10:06 +01:00
|
|
|
|
2014-11-05 15:13:51 +01:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2012-02-22 02:10:06 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-20 20:28:00 +02:00
|
|
|
|
|
|
|
|
|
2015-09-03 17:49:26 +02:00
|
|
|
|
|
|
|
|
|
2012-02-22 02:10:06 +01:00
|
|
|
|
2008-06-25 22:31:48 +02:00
|
|
|
|
2010-08-16 16:26:08 +02:00
|
|
|
|
2021-12-02 12:48:19 +01:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2010-05-17 11:42:39 +01:00
|
|
|
|
2008-06-25 22:31:48 +02:00
|
|
|
|
HID: semitek: new driver for GK6X series keyboards
A number of USB keyboards, using the Semitek firmware, are capable of
handling arbitrary N-key rollover, but due to a buggy report
descriptor, keys beyond the sixth cannot be detected by the generic
HID driver.
There are numerous hardware variants sold by several vendors, mostly
using generic names like "GK61" for the 61-key version. These
keyboards are sometimes known collectively as the "GK6X" series.
The keyboard has three USB interfaces. Interface 0 uses the standard
HID boot protocol, limited to eight modifier keys and six normal keys;
interface 2 uses a custom report format that permits any number of
keys. If more than six keys are pressed simultaneously, the first six
are reported via interface 0 while subsequent keys are reported via
interface 2.
(Interface 1 uses a custom protocol for reprogramming the keyboard;
this can be controlled through userspace tools and is not of concern
for the present driver.)
The report descriptor for interface 2, however, is incorrect (for
report ID 0x04, the input field is marked as "array" rather than
"variable".) The descriptor appears to be correct in other respects,
so we simply replace the incorrect byte before parsing the descriptor.
Signed-off-by: Benjamin Moody <bmoody@member.fsf.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-02-07 13:47:04 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-12-30 23:27:56 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-25 23:47:04 +02:00
|
|
|
|
2026-01-02 22:12:28 +01:00
|
|
|
|
2008-06-25 23:47:04 +02:00
|
|
|
|
2013-05-28 11:22:09 +02:00
|
|
|
|
|
|
|
|
|
2014-02-03 11:17:25 +01:00
|
|
|
|
2021-01-03 22:41:44 +01:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2013-05-27 23:41:05 +02:00
|
|
|
|
2012-09-25 23:02:27 +02:00
|
|
|
|
2026-04-02 17:59:15 +02:00
|
|
|
|
2013-05-27 23:41:05 +02:00
|
|
|
|
2026-04-02 17:59:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-01-02 22:12:28 +01:00
|
|
|
|
2026-04-02 17:59:15 +02:00
|
|
|
|
2008-06-25 23:47:04 +02:00
|
|
|
|
2013-11-09 19:25:57 +01:00
|
|
|
|
2023-08-28 15:14:21 +02:00
|
|
|
|
2013-11-09 19:25:57 +01:00
|
|
|
|
|
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2014-02-01 10:39:58 -05:00
|
|
|
|
|
|
|
|
|
2013-11-09 19:25:57 +01:00
|
|
|
|
2011-05-27 18:40:29 +02:00
|
|
|
|
|
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2011-05-27 18:40:29 +02:00
|
|
|
|
|
|
|
|
|
2018-04-16 14:27:02 +02:00
|
|
|
|
2023-01-25 19:01:25 -08:00
|
|
|
|
2018-05-25 17:30:51 +02:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2023-01-25 19:01:25 -08:00
|
|
|
|
2018-04-16 14:27:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-25 19:01:26 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-31 16:50:24 +01:00
|
|
|
|
2023-07-03 20:10:21 +02:00
|
|
|
|
|
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2023-07-03 20:10:21 +02:00
|
|
|
|
2026-09-01 22:30:44 +02:00
|
|
|
|
|
|
|
|
|
2013-01-31 08:07:07 -07:00
|
|
|
|
2008-06-23 21:56:07 +02:00
|
|
|
|
2010-08-16 16:26:08 +02:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2008-10-16 01:25:15 +02:00
|
|
|
|
2008-06-23 21:56:07 +02:00
|
|
|
|
2014-04-07 13:39:33 -04:00
|
|
|
|
|
|
|
|
|
2017-01-05 09:48:58 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-10-16 10:55:49 +00:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2014-04-07 13:39:33 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-15 15:46:44 +02:00
|
|
|
|
2010-08-16 16:26:08 +02:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2009-05-15 15:46:44 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-12-11 22:07:59 +01:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2008-12-11 22:07:59 +01:00
|
|
|
|
2009-01-26 11:12:25 +01:00
|
|
|
|
2008-12-11 22:07:59 +01:00
|
|
|
|
|
|
|
|
|
2011-11-22 22:52:15 +01:00
|
|
|
|
|
|
|
|
|
2025-09-15 16:46:03 -07:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2011-11-22 22:52:15 +01:00
|
|
|
|
|
|
|
|
|
2026-07-09 22:28:54 -04:00
|
|
|
|
|
|
|
|
|
2026-08-21 11:29:51 +02:00
|
|
|
|
2026-07-09 22:28:54 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-13 11:54:38 +03:00
|
|
|
|
2010-05-21 13:15:17 +02:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2011-10-20 21:26:21 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-13 11:54:38 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2009-05-13 11:54:38 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-02-06 17:36:38 +01:00
|
|
|
|
HID: add support for tivo slide remote
This patch finishes off adding full support for the TiVo Slide remote,
which is a mostly pure HID device from the perspective of the kernel.
There are a few mappings that use a vendor-specific usage page, and a
few keys in the consumer usage page that I think make sense to remap
slightly, to better fit their key labels' intended use. Doing this in a
stand-alone hid-tivo.c makes the modifications only matter for this
specific device.
What's actually connected to the computer is a Broadcom-made usb dongle,
which has an embedded hub, bluetooth adapter, mouse and keyboard
devices. You pair with the dongle, then the remote sends data that its
converted into HID on the keyboard interface (the mouse interface
doesn't do anything interesting, so far as I can tell).
lsusb for this device:
Bus 004 Device 005: ID 0a5c:2190 Broadcom Corp.
Bus 004 Device 004: ID 0a5c:4503 Broadcom Corp.
Bus 004 Device 003: ID 150a:1201
Bus 004 Device 002: ID 0a5c:4500 Broadcom Corp. BCM2046B1 USB 2.0 Hub (part of BCM2046 Bluetooth)
Speaking of the keyboard interface, the remote actually does contain a
keyboard as well. The top slides away, revealing a reasonably functional
qwerty keyboard (not unlike many slide cell phones), thus the product
name.
CC: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-10-14 16:57:42 -04:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
HID: add support for tivo slide remote
This patch finishes off adding full support for the TiVo Slide remote,
which is a mostly pure HID device from the perspective of the kernel.
There are a few mappings that use a vendor-specific usage page, and a
few keys in the consumer usage page that I think make sense to remap
slightly, to better fit their key labels' intended use. Doing this in a
stand-alone hid-tivo.c makes the modifications only matter for this
specific device.
What's actually connected to the computer is a Broadcom-made usb dongle,
which has an embedded hub, bluetooth adapter, mouse and keyboard
devices. You pair with the dongle, then the remote sends data that its
converted into HID on the keyboard interface (the mouse interface
doesn't do anything interesting, so far as I can tell).
lsusb for this device:
Bus 004 Device 005: ID 0a5c:2190 Broadcom Corp.
Bus 004 Device 004: ID 0a5c:4503 Broadcom Corp.
Bus 004 Device 003: ID 150a:1201
Bus 004 Device 002: ID 0a5c:4500 Broadcom Corp. BCM2046B1 USB 2.0 Hub (part of BCM2046 Bluetooth)
Speaking of the keyboard interface, the remote actually does contain a
keyboard as well. The top slides away, revealing a reasonably functional
qwerty keyboard (not unlike many slide cell phones), thus the product
name.
CC: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-10-14 16:57:42 -04:00
|
|
|
|
|
|
|
|
|
2009-01-04 00:36:56 +01:00
|
|
|
|
2010-07-13 22:50:51 +02:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2010-07-13 22:50:51 +02:00
|
|
|
|
|
|
|
|
|
2009-01-04 00:36:56 +01:00
|
|
|
|
2022-09-10 20:36:13 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-01-28 20:08:49 -05:00
|
|
|
|
|
|
|
|
|
2022-09-10 20:36:13 -04:00
|
|
|
|
2013-01-22 12:01:21 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-06-22 22:04:36 +02:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2016-06-22 22:04:36 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-22 12:01:21 -05:00
|
|
|
|
2009-05-15 15:46:44 +02:00
|
|
|
|
2010-05-21 13:15:17 +02:00
|
|
|
|
2021-03-19 19:49:18 +01:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2021-01-31 10:00:45 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-15 15:46:44 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2009-06-29 09:41:29 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-09-18 12:23:31 +02:00
|
|
|
|
2016-11-15 13:02:05 +01:00
|
|
|
|
|
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2016-11-15 13:02:05 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-04-01 14:42:00 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-04-13 21:44:59 +08:00
|
|
|
|
2019-04-01 14:42:00 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-07-24 12:11:18 +01:00
|
|
|
|
2019-04-01 14:42:00 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-05-27 14:25:32 +02:00
|
|
|
|
2019-04-01 14:42:00 +02:00
|
|
|
|
2025-02-01 12:38:54 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-11 17:18:12 +02:00
|
|
|
|
2014-07-24 13:10:09 -07:00
|
|
|
|
2017-07-28 15:18:00 +02:00
|
|
|
|
2010-03-15 19:16:23 +00:00
|
|
|
|
2014-07-24 13:10:09 -07:00
|
|
|
|
|
|
|
|
|
2016-07-13 18:06:12 +02:00
|
|
|
|
2014-07-24 13:10:09 -07:00
|
|
|
|
2014-08-06 14:06:26 -07:00
|
|
|
|
2014-07-24 13:10:09 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-03-15 19:16:23 +00:00
|
|
|
|
2011-07-05 13:45:08 +02:00
|
|
|
|
2013-05-05 23:12:45 +02:00
|
|
|
|
2011-08-17 11:43:22 +02:00
|
|
|
|
2011-09-06 13:50:39 +02:00
|
|
|
|
2011-12-07 21:33:59 +01:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2013-05-05 23:12:45 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-05 13:45:08 +02:00
|
|
|
|
2013-05-05 23:12:45 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-17 14:12:01 +01:00
|
|
|
|
2024-02-16 21:54:47 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-10-12 20:50:54 +00:00
|
|
|
|
|
|
|
|
|
2024-02-16 21:54:47 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-07-27 19:20:02 +02:00
|
|
|
|
|
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2013-07-27 19:20:02 +02:00
|
|
|
|
2014-06-10 14:35:36 -07:00
|
|
|
|
2013-07-27 19:20:02 +02:00
|
|
|
|
|
|
|
|
|
2009-05-15 15:46:44 +02:00
|
|
|
|
2010-05-21 13:15:17 +02:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2008-09-18 12:23:32 +02:00
|
|
|
|
|
|
|
|
|
2009-05-15 15:46:44 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2009-05-15 15:46:44 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-05-14 17:30:59 +01:00
|
|
|
|
2010-05-21 13:15:17 +02:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2010-05-14 17:30:59 +01:00
|
|
|
|
|
|
|
|
|
2012-09-05 13:56:00 +01:00
|
|
|
|
|
|
|
|
|
2022-07-08 18:57:59 -07:00
|
|
|
|
2012-09-05 13:56:00 +01:00
|
|
|
|
|
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2012-09-05 13:56:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-10 11:22:22 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2015-04-10 11:22:22 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-04-12 11:07:43 +02:00
|
|
|
|
2015-04-10 11:22:22 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-06-16 18:45:57 +09:00
|
|
|
|
|
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2016-06-16 18:45:57 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-21 18:49:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-28 09:48:57 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-09-30 17:52:07 -07:00
|
|
|
|
2022-09-30 17:52:08 -07:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2020-01-28 09:48:57 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-11 13:39:12 +02:00
|
|
|
|
2022-08-15 16:29:49 +02:00
|
|
|
|
2023-05-23 17:10:59 +02:00
|
|
|
|
2022-11-24 18:59:37 +01:00
|
|
|
|
2022-06-11 13:39:12 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
HID: huawei: fix CD30 keyboard report descriptor issue
When the Huawei CD30 USB keyboard undergoes 500 reboot cycles,
initialization may fail due to a report descriptor problem.
The error log is as follows:
[pid:175,cpu0,kworker/0:1,6]usb 1-1.2.2: new low-speed USB device number 6 using xhci-hcd
[pid:175,cpu0,kworker/0:1,9]usb 1-1.2.2: New USB device found, idVendor=12d1, idProduct=109b, bcdDevice= 1.03
[pid:175,cpu0,kworker/0:1,0]usb 1-1.2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[pid:175,cpu0,kworker/0:1,1]usb 1-1.2.2: Product: HUAWEI USB Wired Keyboard
[pid:175,cpu0,kworker/0:1,2]usb 1-1.2.2: Manufacturer: HUAWEI
[pid:175,cpu0,kworker/0:1,4]input: HUAWEI HUAWEI USB Wired Keyboard as /devices/platform/efc00000.hisi_usb/efc00000.dwc3/xhci-hcd.1.auto/usb1/1-1/1-1.2/1-1.2.2/1-1.2.2:1.0/0003:12D1:109B.0002/input/input6
[pid:175,cpu0,kworker/0:1,5]hid-generic 0003:12D1:109B.0002: input,hidraw1: USB HID v1.10 Keyboard [HUAWEI HUAWEI USB Wired Keyboard] on usb-xhci-hcd.1.auto-1.2.2/input0
[pid:175,cpu0,kworker/0:1,9]hid-generic 0003:12D1:109B.0003: collection stack underflow
[pid:175,cpu0,kworker/0:1,0]hid-generic 0003:12D1:109B.0003: item 0 0 0 12 parsing failed
[pid:175,cpu0,kworker/0:1,1]hid-generic: probe of 0003:12D1:109B.0003 failed with error -22
...
When encountering such a situation, fix it with the correct report descriptor.
Signed-off-by: Miao Li <limiao@kylinos.cn>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-03-18 17:12:49 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-05-16 11:49:19 +02:00
|
|
|
|
|
|
|
|
|
2022-11-03 16:57:44 +01:00
|
|
|
|
|
|
|
|
|
2012-11-12 15:42:59 +01:00
|
|
|
|
|
|
|
|
|
2016-08-07 02:25:34 -07:00
|
|
|
|
|
|
|
|
|
2020-10-10 01:31:36 +05:30
|
|
|
|
|
|
|
|
|
2021-03-10 23:53:28 +01:00
|
|
|
|
|
|
|
|
|
2025-01-06 10:31:31 +08:00
|
|
|
|
|
|
|
|
|
2025-01-23 14:48:12 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-11-03 16:57:43 +01:00
|
|
|
|