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