2006-12-08 17:41:30 +00:00
|
|
|
#
|
|
|
|
|
# HID driver configuration
|
|
|
|
|
#
|
2012-06-25 14:55:41 +00:00
|
|
|
menu "HID support"
|
|
|
|
|
depends on INPUT
|
2006-12-08 17:41:30 +00:00
|
|
|
|
|
|
|
|
config HID
|
2012-06-25 14:55:41 +00:00
|
|
|
tristate "HID bus support"
|
2006-12-22 17:09:16 +00:00
|
|
|
depends on INPUT
|
2006-12-08 17:41:30 +00:00
|
|
|
default y
|
|
|
|
|
---help---
|
2007-01-03 22:03:14 +00:00
|
|
|
A human interface device (HID) is a type of computer device that
|
|
|
|
|
interacts directly with and takes input from humans. The term "HID"
|
|
|
|
|
most commonly used to refer to the USB-HID specification, but other
|
|
|
|
|
devices (such as, but not strictly limited to, Bluetooth) are
|
|
|
|
|
designed using HID specification (this involves certain keyboards,
|
2012-06-25 14:55:41 +00:00
|
|
|
mice, tablets, etc). This option adds the HID bus to the kernel,
|
|
|
|
|
together with generic HID layer code. The HID devices are added and
|
|
|
|
|
removed from the HID bus by the transport-layer drivers, such as
|
|
|
|
|
usbhid (USB_HID) and hidp (BT_HIDP).
|
2007-01-03 22:03:14 +00:00
|
|
|
|
|
|
|
|
For docs and specs, see http://www.usb.org/developers/hidpage/
|
|
|
|
|
|
2009-01-06 09:15:27 +00:00
|
|
|
If unsure, say Y.
|
2006-12-08 17:41:30 +00:00
|
|
|
|
2012-06-25 14:55:41 +00:00
|
|
|
if HID
|
|
|
|
|
|
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 08:49:14 +00:00
|
|
|
config HID_BATTERY_STRENGTH
|
2012-04-24 08:51:30 +00:00
|
|
|
bool "Battery level reporting for HID devices"
|
2014-12-17 13:53:54 +00:00
|
|
|
depends on HID
|
|
|
|
|
select POWER_SUPPLY
|
2012-04-18 14:05:17 +00:00
|
|
|
default n
|
2012-04-24 08:51:30 +00:00
|
|
|
---help---
|
|
|
|
|
This option adds support of reporting battery strength (for HID devices
|
|
|
|
|
that support this feature) through power_supply class so that userspace
|
|
|
|
|
tools, such as upower, can display it.
|
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 08:49:14 +00:00
|
|
|
|
2007-05-14 07:57:40 +00:00
|
|
|
config HIDRAW
|
|
|
|
|
bool "/dev/hidraw raw HID device support"
|
|
|
|
|
depends on HID
|
|
|
|
|
---help---
|
|
|
|
|
Say Y here if you want to support HID devices (from the USB
|
|
|
|
|
specification standpoint) that aren't strictly user interface
|
|
|
|
|
devices, like monitor controls and Uninterruptable Power Supplies.
|
|
|
|
|
|
|
|
|
|
This module supports these devices separately using a separate
|
|
|
|
|
event interface on /dev/hidraw.
|
|
|
|
|
|
|
|
|
|
There is also a /dev/hiddev configuration option in the USB HID
|
|
|
|
|
configuration menu. In comparison to hiddev, this device does not process
|
|
|
|
|
the hid events at all (no parsing, no lookups). This lets applications
|
|
|
|
|
to work on raw hid events when they want to, and avoid using transport-specific
|
|
|
|
|
userspace libhid/libusb libraries.
|
|
|
|
|
|
|
|
|
|
If unsure, say Y.
|
|
|
|
|
|
2012-06-10 13:16:13 +00:00
|
|
|
config UHID
|
|
|
|
|
tristate "User-space I/O driver support for HID subsystem"
|
|
|
|
|
depends on HID
|
|
|
|
|
default n
|
|
|
|
|
---help---
|
|
|
|
|
Say Y here if you want to provide HID I/O Drivers from user-space.
|
|
|
|
|
This allows to write I/O drivers in user-space and feed the data from
|
|
|
|
|
the device into the kernel. The kernel parses the HID reports, loads the
|
|
|
|
|
corresponding HID Device Driver or provides input devices on top of your
|
|
|
|
|
user-space device.
|
|
|
|
|
|
|
|
|
|
This driver cannot be used to parse HID-reports in user-space and write
|
|
|
|
|
special HID-drivers. You should use hidraw for that.
|
|
|
|
|
Instead, this driver allows to write the transport-layer driver in
|
|
|
|
|
user-space like USB-HID and Bluetooth-HID do in kernel-space.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
|
|
|
|
To compile this driver as a module, choose M here: the
|
|
|
|
|
module will be called uhid.
|
|
|
|
|
|
2012-04-23 10:07:07 +00:00
|
|
|
config HID_GENERIC
|
|
|
|
|
tristate "Generic HID driver"
|
|
|
|
|
depends on HID
|
2012-06-25 14:55:41 +00:00
|
|
|
default HID
|
2012-04-23 10:07:07 +00:00
|
|
|
---help---
|
2012-06-25 14:55:41 +00:00
|
|
|
Support for generic devices on the HID bus. This includes most
|
|
|
|
|
keyboards and mice, joysticks, tablets and digitizers.
|
2012-04-23 10:07:07 +00:00
|
|
|
|
|
|
|
|
To compile this driver as a module, choose M here: the module
|
|
|
|
|
will be called hid-generic.
|
|
|
|
|
|
|
|
|
|
If unsure, say Y.
|
|
|
|
|
|
2012-06-25 14:55:41 +00:00
|
|
|
menu "Special HID drivers"
|
|
|
|
|
depends on HID
|
|
|
|
|
|
2008-06-23 21:31:09 +00:00
|
|
|
config HID_A4TECH
|
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 16:33:33 +00:00
|
|
|
tristate "A4 tech mice"
|
2013-02-25 10:31:45 +00:00
|
|
|
depends on HID
|
2011-01-20 22:44:16 +00:00
|
|
|
default !EXPERT
|
2008-06-23 21:31:09 +00:00
|
|
|
---help---
|
|
|
|
|
Support for A4 tech X5 and WOP-35 / Trust 450L mice.
|
|
|
|
|
|
2011-03-11 08:27:34 +00:00
|
|
|
config HID_ACRUX
|
|
|
|
|
tristate "ACRUX game controller support"
|
2013-02-25 10:31:46 +00:00
|
|
|
depends on HID
|
2011-03-11 08:27:34 +00:00
|
|
|
---help---
|
|
|
|
|
Say Y here if you want to enable support for ACRUX game controllers.
|
|
|
|
|
|
|
|
|
|
config HID_ACRUX_FF
|
2011-08-04 07:25:56 +00:00
|
|
|
bool "ACRUX force feedback support"
|
2011-03-11 08:27:34 +00:00
|
|
|
depends on HID_ACRUX
|
2010-07-19 10:13:23 +00:00
|
|
|
select INPUT_FF_MEMLESS
|
|
|
|
|
---help---
|
|
|
|
|
Say Y here if you want to enable force feedback support for ACRUX
|
|
|
|
|
game controllers.
|
|
|
|
|
|
2008-06-18 21:36:49 +00:00
|
|
|
config HID_APPLE
|
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 16:33:33 +00:00
|
|
|
tristate "Apple {i,Power,Mac}Books"
|
2013-02-25 10:31:45 +00:00
|
|
|
depends on HID
|
2011-01-20 22:44:16 +00:00
|
|
|
default !EXPERT
|
2008-06-18 21:36:49 +00:00
|
|
|
---help---
|
|
|
|
|
Support for some Apple devices which less or more break
|
|
|
|
|
HID specification.
|
|
|
|
|
|
2008-10-15 23:25:15 +00:00
|
|
|
Say Y here if you want support for keyboards of Apple iBooks, PowerBooks,
|
|
|
|
|
MacBooks, MacBook Pros and Apple Aluminum.
|
2008-06-18 21:36:49 +00:00
|
|
|
|
2013-04-17 16:15:15 +00:00
|
|
|
config HID_APPLEIR
|
|
|
|
|
tristate "Apple infrared receiver"
|
|
|
|
|
depends on (USB_HID)
|
|
|
|
|
---help---
|
|
|
|
|
Support for Apple infrared remote control. All the Apple computers from
|
|
|
|
|
2005 onwards include such a port, except the unibody Macbook (2009),
|
|
|
|
|
and Mac Pros. This receiver is also used in the Apple TV set-top box
|
|
|
|
|
prior to the 2010 model.
|
|
|
|
|
|
|
|
|
|
Say Y here if you want support for Apple infrared remote control.
|
|
|
|
|
|
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 07:18:42 +00:00
|
|
|
config HID_ASUS
|
|
|
|
|
tristate "Asus"
|
|
|
|
|
depends on I2C_HID
|
|
|
|
|
---help---
|
2016-04-03 14:15:16 +00:00
|
|
|
Support for Asus notebook built-in keyboard via i2c.
|
|
|
|
|
|
|
|
|
|
Supported devices:
|
|
|
|
|
- EeeBook X205TA
|
|
|
|
|
- VivoBook E200HA
|
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 07:18:42 +00:00
|
|
|
|
2012-04-10 22:29:04 +00:00
|
|
|
config HID_AUREAL
|
|
|
|
|
tristate "Aureal"
|
2013-02-25 10:31:45 +00:00
|
|
|
depends on HID
|
2012-04-10 22:29:04 +00:00
|
|
|
---help---
|
|
|
|
|
Support for Aureal Cy se W-01RN Remote Controller and other Aureal derived remotes.
|
|
|
|
|
|
2008-06-24 21:24:57 +00:00
|
|
|
config HID_BELKIN
|
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 16:33:33 +00:00
|
|
|
tristate "Belkin Flip KVM and Wireless keyboard"
|
2013-02-25 10:31:45 +00:00
|
|
|
depends on HID
|
2011-01-20 22:44:16 +00:00
|
|
|
default !EXPERT
|
2008-06-24 21:24:57 +00:00
|
|
|
---help---
|
|
|
|
|
Support for Belkin Flip KVM and Wireless keyboard.
|
|
|
|
|
|
2014-11-26 10:21:03 +00:00
|
|
|
config HID_BETOP_FF
|
|
|
|
|
tristate "Betop Production Inc. force feedback support"
|
|
|
|
|
depends on USB_HID
|
|
|
|
|
select INPUT_FF_MEMLESS
|
|
|
|
|
---help---
|
|
|
|
|
Say Y here if you want to enable force feedback support for devices by
|
|
|
|
|
BETOP Production Ltd.
|
|
|
|
|
Currently the following devices are known to be supported:
|
|
|
|
|
- BETOP 2185 PC & BFM MODE
|
|
|
|
|
|
2008-06-24 18:42:25 +00:00
|
|
|
config HID_CHERRY
|
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 16:33:33 +00:00
|
|
|
tristate "Cherry Cymotion keyboard"
|
2013-02-25 10:31:45 +00:00
|
|
|
depends on HID
|
2011-01-20 22:44:16 +00:00
|
|
|
default !EXPERT
|
2008-06-24 18:42:25 +00:00
|
|
|
---help---
|
2008-10-15 23:25:15 +00:00
|
|
|
Support for Cherry Cymotion keyboard.
|
2008-06-24 18:42:25 +00:00
|
|
|
|
2008-06-24 20:48:52 +00:00
|
|
|
config HID_CHICONY
|
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 16:33:33 +00:00
|
|
|
tristate "Chicony Tactical pad"
|
2013-02-25 10:31:45 +00:00
|
|
|
depends on HID
|
2011-01-20 22:44:16 +00:00
|
|
|
default !EXPERT
|
2008-06-24 20:48:52 +00:00
|
|
|
---help---
|
|
|
|
|
Support for Chicony Tactical pad.
|
|
|
|
|
|
2015-09-30 13:14:20 +00:00
|
|
|
config HID_CORSAIR
|
|
|
|
|
tristate "Corsair devices"
|
|
|
|
|
depends on HID && USB && LEDS_CLASS
|
|
|
|
|
---help---
|
|
|
|
|
Support for Corsair devices that are not fully compliant with the
|
|
|
|
|
HID standard.
|
|
|
|
|
|
|
|
|
|
Supported devices:
|
|
|
|
|
- Vengeance K90
|
|
|
|
|
|
2010-05-12 13:18:59 +00:00
|
|
|
config HID_PRODIKEYS
|
2010-05-12 13:27:00 +00:00
|
|
|
tristate "Prodikeys PC-MIDI Keyboard support"
|
2013-02-25 10:31:46 +00:00
|
|
|
depends on HID && SND
|
2010-05-12 13:18:59 +00:00
|
|
|
select SND_RAWMIDI
|
|
|
|
|
---help---
|
|
|
|
|
Support for Prodikeys PC-MIDI Keyboard device support.
|
|
|
|
|
Say Y here to enable support for this device.
|
|
|
|
|
- Prodikeys PC-MIDI keyboard.
|
|
|
|
|
The Prodikeys PC-MIDI acts as a USB Audio device, with one MIDI
|
|
|
|
|
input and one MIDI output. These MIDI jacks appear as
|
|
|
|
|
a sound "card" in the ALSA sound system.
|
|
|
|
|
Note: if you say N here, this device will still function as a basic
|
|
|
|
|
multimedia keyboard, but will lack support for the musical keyboard
|
|
|
|
|
and some additional multimedia keys.
|
|
|
|
|
|
2016-01-22 03:59:43 +00:00
|
|
|
config HID_CMEDIA
|
|
|
|
|
tristate "CMedia CM6533 HID audio jack controls"
|
|
|
|
|
depends on HID
|
|
|
|
|
---help---
|
|
|
|
|
Support for CMedia CM6533 HID audio jack controls.
|
|
|
|
|
|
2014-02-04 18:42:48 +00:00
|
|
|
config HID_CP2112
|
|
|
|
|
tristate "Silicon Labs CP2112 HID USB-to-SMBus Bridge support"
|
2014-02-18 08:40:17 +00:00
|
|
|
depends on USB_HID && I2C && GPIOLIB
|
2014-02-04 18:42:48 +00:00
|
|
|
---help---
|
|
|
|
|
Support for Silicon Labs CP2112 HID USB to SMBus Master Bridge.
|
|
|
|
|
This is a HID device driver which registers as an i2c adapter
|
|
|
|
|
and gpiochip to expose these functions of the CP2112. The
|
|
|
|
|
customizable USB descriptor fields are exposed as sysfs attributes.
|
|
|
|
|
|
2008-06-23 20:54:08 +00:00
|
|
|
config HID_CYPRESS
|
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 16:33:33 +00:00
|
|
|
tristate "Cypress mouse and barcode readers"
|
2013-02-25 10:31:45 +00:00
|
|
|
depends on HID
|
2011-01-20 22:44:16 +00:00
|
|
|
default !EXPERT
|
2008-06-23 20:54:08 +00:00
|
|
|
---help---
|
2008-10-15 23:25:15 +00:00
|
|
|
Support for cypress mouse and barcode readers.
|
2008-06-23 20:54:08 +00:00
|
|
|
|
2009-05-15 13:46:44 +00:00
|
|
|
config HID_DRAGONRISE
|
2010-08-16 14:26:08 +00:00
|
|
|
tristate "DragonRise Inc. game controller"
|
2013-02-25 10:31:46 +00:00
|
|
|
depends on HID
|
2009-05-15 13:46:44 +00:00
|
|
|
---help---
|
2011-01-28 11:50:53 +00:00
|
|
|
Say Y here if you have DragonRise Inc. game controllers.
|
|
|
|
|
These might be branded as:
|
|
|
|
|
- Tesun USB-703
|
|
|
|
|
- Media-tech MT1504 "Rogue"
|
|
|
|
|
- DVTech JS19 "Gear"
|
|
|
|
|
- Defender Game Master
|
2009-05-15 13:46:44 +00:00
|
|
|
|
|
|
|
|
config DRAGONRISE_FF
|
2010-08-16 14:26:08 +00:00
|
|
|
bool "DragonRise Inc. force feedback"
|
2009-05-15 13:46:44 +00:00
|
|
|
depends on HID_DRAGONRISE
|
2009-03-04 09:12:04 +00:00
|
|
|
select INPUT_FF_MEMLESS
|
|
|
|
|
---help---
|
|
|
|
|
Say Y here if you want to enable force feedback support for DragonRise Inc.
|
|
|
|
|
game controllers.
|
|
|
|
|
|
2010-11-01 19:13:37 +00:00
|
|
|
config HID_EMS_FF
|
|
|
|
|
tristate "EMS Production Inc. force feedback support"
|
2013-02-25 10:31:46 +00:00
|
|
|
depends on HID
|
2010-11-01 19:13:37 +00:00
|
|
|
select INPUT_FF_MEMLESS
|
|
|
|
|
---help---
|
|
|
|
|
Say Y here if you want to enable force feedback support for devices by
|
|
|
|
|
EMS Production Ltd.
|
|
|
|
|
Currently the following devices are known to be supported:
|
|
|
|
|
- Trio Linker Plus II
|
|
|
|
|
|
2010-06-28 16:54:25 +00:00
|
|
|
config HID_ELECOM
|
2010-08-16 14:26:08 +00:00
|
|
|
tristate "ELECOM BM084 bluetooth mouse"
|
2013-02-25 10:31:45 +00:00
|
|
|
depends on HID
|
2010-06-28 16:54:25 +00:00
|
|
|
---help---
|
|
|
|
|
Support for the ELECOM BM084 (bluetooth mouse).
|
|
|
|
|
|
2013-05-07 09:40:58 +00:00
|
|
|
config HID_ELO
|
|
|
|
|
tristate "ELO USB 4000/4500 touchscreen"
|
|
|
|
|
depends on USB_HID
|
|
|
|
|
---help---
|
|
|
|
|
Support for the ELO USB 4000/4500 touchscreens. Note that this is for
|
|
|
|
|
different devices than those handled by CONFIG_TOUCHSCREEN_USB_ELO.
|
|
|
|
|
|
2008-06-24 19:11:21 +00:00
|
|
|
config HID_EZKEY
|
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 16:33:33 +00:00
|
|
|
tristate "Ezkey BTC 8193 keyboard"
|
2013-02-25 10:31:45 +00:00
|
|
|
depends on HID
|
2011-01-20 22:44:16 +00:00
|
|
|
default !EXPERT
|
2008-06-24 19:11:21 +00:00
|
|
|
---help---
|
2008-10-15 23:25:15 +00:00
|
|
|
Support for Ezkey BTC 8193 keyboard.
|
2008-06-24 19:11:21 +00:00
|
|
|
|
2015-08-13 15:11:27 +00:00
|
|
|
config HID_GEMBIRD
|
|
|
|
|
tristate "Gembird Joypad"
|
|
|
|
|
depends on HID
|
|
|
|
|
---help---
|
|
|
|
|
Support for Gembird JPD-DualForce 2.
|
|
|
|
|
|
2015-10-26 08:15:58 +00:00
|
|
|
config HID_GFRM
|
|
|
|
|
tristate "Google Fiber TV Box remote control support"
|
|
|
|
|
depends on HID
|
|
|
|
|
---help---
|
|
|
|
|
Support for Google Fiber TV Box remote controls
|
|
|
|
|
|
2011-06-26 21:07:31 +00:00
|
|
|
config HID_HOLTEK
|
2012-07-06 15:05:04 +00:00
|
|
|
tristate "Holtek HID devices"
|
2011-06-26 21:07:31 +00:00
|
|
|
depends on USB_HID
|
|
|
|
|
---help---
|
2012-07-06 15:05:04 +00:00
|
|
|
Support for Holtek based devices:
|
|
|
|
|
- Holtek On Line Grip based game controller
|
|
|
|
|
- Trust GXT 18 Gaming Keyboard
|
2013-05-20 23:31:08 +00:00
|
|
|
- Sharkoon Drakonia / Perixx MX-2000 gaming mice
|
2013-05-20 23:31:09 +00:00
|
|
|
- Tracer Sniper TRM-503 / NOVA Gaming Slider X200 /
|
|
|
|
|
Zalman ZM-GM1
|
2013-10-01 17:22:05 +00:00
|
|
|
- SHARKOON DarkGlider Gaming mouse
|
2013-10-21 21:42:22 +00:00
|
|
|
- LEETGION Hellion Gaming Mouse
|
2011-06-26 21:07:31 +00:00
|
|
|
|
|
|
|
|
config HOLTEK_FF
|
|
|
|
|
bool "Holtek On Line Grip force feedback support"
|
|
|
|
|
depends on HID_HOLTEK
|
|
|
|
|
select INPUT_FF_MEMLESS
|
|
|
|
|
---help---
|
|
|
|
|
Say Y here if you have a Holtek On Line Grip based game controller
|
|
|
|
|
and want to have force feedback support for it.
|
|
|
|
|
|
2014-06-18 16:05:02 +00:00
|
|
|
config HID_GT683R
|
|
|
|
|
tristate "MSI GT68xR LED support"
|
|
|
|
|
depends on LEDS_CLASS && USB_HID
|
|
|
|
|
---help---
|
|
|
|
|
Say Y here if you want to enable support for the three MSI GT68xR LEDs
|
|
|
|
|
|
|
|
|
|
This driver support following modes:
|
|
|
|
|
- Normal: LEDs are fully on when enabled
|
|
|
|
|
- Audio: LEDs brightness depends on sound level
|
|
|
|
|
- Breathing: LEDs brightness varies at human breathing rate
|
|
|
|
|
|
|
|
|
|
Currently the following devices are know to be supported:
|
|
|
|
|
- MSI GT683R
|
|
|
|
|
|
2011-02-17 14:12:45 +00:00
|
|
|
config HID_KEYTOUCH
|
2011-03-22 09:29:17 +00:00
|
|
|
tristate "Keytouch HID devices"
|
2013-02-25 10:31:45 +00:00
|
|
|
depends on HID
|
2011-02-17 14:12:45 +00:00
|
|
|
---help---
|
|
|
|
|
Support for Keytouch HID devices not fully compliant with
|
|
|
|
|
the specification. Currently supported:
|
|
|
|
|
- Keytouch IEC 60945
|
|
|
|
|
|
2009-03-11 10:43:27 +00:00
|
|
|
config HID_KYE
|
2012-02-28 11:01:46 +00:00
|
|
|
tristate "KYE/Genius devices"
|
2013-02-25 10:31:46 +00:00
|
|
|
depends on HID
|
2009-03-11 10:43:27 +00:00
|
|
|
---help---
|
2012-02-28 11:01:46 +00:00
|
|
|
Support for KYE/Genius devices not fully compliant with HID standard:
|
|
|
|
|
- Ergo Mouse
|
|
|
|
|
- EasyPen i405X tablet
|
|
|
|
|
- MousePen i608X tablet
|
|
|
|
|
- EasyPen M610X tablet
|
2009-03-11 10:43:27 +00:00
|
|
|
|
2010-08-09 16:44:17 +00:00
|
|
|
config HID_UCLOGIC
|
2010-08-09 17:56:01 +00:00
|
|
|
tristate "UC-Logic"
|
2015-03-04 16:24:55 +00:00
|
|
|
depends on USB_HID
|
2010-08-09 16:44:17 +00:00
|
|
|
---help---
|
2015-03-03 17:44:01 +00:00
|
|
|
Support for UC-Logic and Huion tablets.
|
2010-08-09 16:44:17 +00:00
|
|
|
|
2010-08-20 15:21:11 +00:00
|
|
|
config HID_WALTOP
|
|
|
|
|
tristate "Waltop"
|
2013-02-25 10:31:45 +00:00
|
|
|
depends on HID
|
2010-08-20 15:21:11 +00:00
|
|
|
---help---
|
|
|
|
|
Support for Waltop tablets.
|
|
|
|
|
|
2008-07-24 21:35:13 +00:00
|
|
|
config HID_GYRATION
|
2010-08-16 14:26:08 +00:00
|
|
|
tristate "Gyration remote control"
|
2013-02-25 10:31:45 +00:00
|
|
|
depends on HID
|
2008-07-24 21:35:13 +00:00
|
|
|
---help---
|
2008-10-15 23:25:15 +00:00
|
|
|
Support for Gyration remote control.
|
2008-07-24 21:35:13 +00:00
|
|
|
|
2012-10-31 11:10:10 +00:00
|
|
|
config HID_ICADE
|
|
|
|
|
tristate "ION iCade arcade controller"
|
2013-02-25 10:31:45 +00:00
|
|
|
depends on HID
|
2012-10-31 11:10:10 +00:00
|
|
|
---help---
|
|
|
|
|
Support for the ION iCade arcade controller to work as a joystick.
|
|
|
|
|
|
|
|
|
|
To compile this driver as a module, choose M here: the
|
|
|
|
|
module will be called hid-icade.
|
|
|
|
|
|
2009-07-13 12:19:58 +00:00
|
|
|
config HID_TWINHAN
|
2010-08-16 14:26:08 +00:00
|
|
|
tristate "Twinhan IR remote control"
|
2013-02-25 10:31:45 +00:00
|
|
|
depends on HID
|
2009-07-13 12:19:58 +00:00
|
|
|
---help---
|
|
|
|
|
Support for Twinhan IR remote control.
|
|
|
|
|
|
2009-03-04 15:09:40 +00:00
|
|
|
config HID_KENSINGTON
|
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 16:33:33 +00:00
|
|
|
tristate "Kensington Slimblade Trackball"
|
2013-02-25 10:31:45 +00:00
|
|
|
depends on HID
|
2011-01-20 22:44:16 +00:00
|
|
|
default !EXPERT
|
2009-03-04 15:09:40 +00:00
|
|
|
---help---
|
|
|
|
|
Support for Kensington Slimblade Trackball.
|
|
|
|
|
|
2011-02-03 15:41:47 +00:00
|
|
|
config HID_LCPOWER
|
|
|
|
|
tristate "LC-Power"
|
2013-02-25 10:31:45 +00:00
|
|
|
depends on HID
|
2011-02-03 15:41:47 +00:00
|
|
|
---help---
|
|
|
|
|
Support for LC-Power RC1000MCE RF remote control.
|
|
|
|
|
|
2016-06-17 19:20:46 +00:00
|
|
|
config HID_LED
|
2016-06-17 20:29:47 +00:00
|
|
|
tristate "Simple RGB LED support"
|
2016-06-17 19:20:46 +00:00
|
|
|
depends on HID
|
|
|
|
|
depends on LEDS_CLASS
|
|
|
|
|
---help---
|
2016-06-21 19:49:29 +00:00
|
|
|
Support for simple RGB LED devices. Currently supported are:
|
|
|
|
|
- Riso Kagaku Webmail Notifier
|
|
|
|
|
- Dream Cheeky Webmail Notifier and Friends Alert
|
|
|
|
|
- ThingM blink(1)
|
2016-06-17 19:20:46 +00:00
|
|
|
|
|
|
|
|
To compile this driver as a module, choose M here: the
|
|
|
|
|
module will be called hid-led.
|
|
|
|
|
|
2014-07-23 22:30:45 +00:00
|
|
|
config HID_LENOVO
|
|
|
|
|
tristate "Lenovo / Thinkpad devices"
|
2013-09-11 20:12:24 +00:00
|
|
|
depends on HID
|
2012-06-17 10:52:34 +00:00
|
|
|
select NEW_LEDS
|
2012-02-15 12:40:43 +00:00
|
|
|
select LEDS_CLASS
|
|
|
|
|
---help---
|
2014-07-23 22:30:45 +00:00
|
|
|
Support for Lenovo devices that are not fully compliant with HID standard.
|
2012-02-15 12:40:43 +00:00
|
|
|
|
2014-07-23 22:30:45 +00:00
|
|
|
Say Y if you want support for the non-compliant features of the Lenovo
|
|
|
|
|
Thinkpad standalone keyboards, e.g:
|
|
|
|
|
- ThinkPad USB Keyboard with TrackPoint (supports extra LEDs and trackpoint
|
|
|
|
|
configuration)
|
2014-07-23 22:30:48 +00:00
|
|
|
- ThinkPad Compact Bluetooth Keyboard with TrackPoint (supports Fn keys)
|
|
|
|
|
- ThinkPad Compact USB Keyboard with TrackPoint (supports Fn keys)
|
2012-02-15 12:40:43 +00:00
|
|
|
|
2008-05-16 09:49:19 +00:00
|
|
|
config HID_LOGITECH
|
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 16:33:33 +00:00
|
|
|
tristate "Logitech devices"
|
2013-02-25 10:31:45 +00:00
|
|
|
depends on HID
|
2011-01-20 22:44:16 +00:00
|
|
|
default !EXPERT
|
2008-05-16 09:49:19 +00:00
|
|
|
---help---
|
2008-10-15 23:25:15 +00:00
|
|
|
Support for Logitech devices that are not fully compliant with HID standard.
|
2008-05-16 09:49:19 +00:00
|
|
|
|
2011-09-15 09:34:49 +00:00
|
|
|
config HID_LOGITECH_DJ
|
|
|
|
|
tristate "Logitech Unifying receivers full support"
|
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-02 23:17:24 +00:00
|
|
|
depends on HIDRAW
|
2011-09-15 09:34:49 +00:00
|
|
|
depends on HID_LOGITECH
|
2014-09-30 17:18:28 +00:00
|
|
|
select HID_LOGITECH_HIDPP
|
2011-09-15 09:34:49 +00:00
|
|
|
---help---
|
|
|
|
|
Say Y if you want support for Logitech Unifying receivers and devices.
|
|
|
|
|
Unifying receivers are capable of pairing up to 6 Logitech compliant
|
2012-02-13 10:13:03 +00:00
|
|
|
devices to the same receiver. Without this driver it will be handled by
|
2012-12-27 16:33:02 +00:00
|
|
|
generic USB_HID driver and all incoming events will be multiplexed
|
2012-02-13 10:13:03 +00:00
|
|
|
into a single mouse and a single keyboard device.
|
2011-09-15 09:34:49 +00:00
|
|
|
|
2014-09-30 17:18:27 +00:00
|
|
|
config HID_LOGITECH_HIDPP
|
|
|
|
|
tristate "Logitech HID++ devices support"
|
|
|
|
|
depends on HID_LOGITECH
|
|
|
|
|
---help---
|
|
|
|
|
Support for Logitech devices relyingon the HID++ Logitech specification
|
|
|
|
|
|
|
|
|
|
Say Y if you want support for Logitech devices relying on the HID++
|
|
|
|
|
specification. Such devices are the various Logitech Touchpads (T650,
|
|
|
|
|
T651, TK820), some mice (Zone Touch mouse), or even keyboards (Solar
|
2015-01-06 08:09:13 +00:00
|
|
|
Keyboard).
|
2014-09-30 17:18:27 +00:00
|
|
|
|
2008-07-04 21:06:45 +00:00
|
|
|
config LOGITECH_FF
|
2009-05-15 13:46:44 +00:00
|
|
|
bool "Logitech force feedback support"
|
2008-07-04 21:06:45 +00:00
|
|
|
depends on HID_LOGITECH
|
|
|
|
|
select INPUT_FF_MEMLESS
|
|
|
|
|
help
|
|
|
|
|
Say Y here if you have one of these devices:
|
|
|
|
|
- Logitech WingMan Cordless RumblePad
|
|
|
|
|
- Logitech WingMan Cordless RumblePad 2
|
|
|
|
|
- Logitech WingMan Force 3D
|
|
|
|
|
- Logitech Formula Force EX
|
2009-06-23 10:11:31 +00:00
|
|
|
- Logitech WingMan Formula Force GP
|
2008-07-04 21:06:45 +00:00
|
|
|
|
|
|
|
|
and if you want to enable force feedback for them.
|
|
|
|
|
Note: if you say N here, this device will still be supported, but without
|
|
|
|
|
force feedback.
|
|
|
|
|
|
|
|
|
|
config LOGIRUMBLEPAD2_FF
|
2013-10-07 16:48:12 +00:00
|
|
|
bool "Logitech force feedback support (variant 2)"
|
2008-07-04 21:06:45 +00:00
|
|
|
depends on HID_LOGITECH
|
|
|
|
|
select INPUT_FF_MEMLESS
|
|
|
|
|
help
|
2013-10-07 16:48:12 +00:00
|
|
|
Say Y here if you want to enable force feedback support for:
|
|
|
|
|
- Logitech RumblePad
|
|
|
|
|
- Logitech Rumblepad 2
|
|
|
|
|
- Logitech Formula Vibration Feedback Wheel
|
2008-07-04 21:06:45 +00:00
|
|
|
|
2010-01-12 23:25:58 +00:00
|
|
|
config LOGIG940_FF
|
|
|
|
|
bool "Logitech Flight System G940 force feedback support"
|
|
|
|
|
depends on HID_LOGITECH
|
|
|
|
|
select INPUT_FF_MEMLESS
|
|
|
|
|
help
|
|
|
|
|
Say Y here if you want to enable force feedback support for Logitech
|
|
|
|
|
Flight System G940 devices.
|
|
|
|
|
|
2011-08-04 14:24:22 +00:00
|
|
|
config LOGIWHEELS_FF
|
|
|
|
|
bool "Logitech wheels configuration and force feedback support"
|
2010-09-22 11:19:42 +00:00
|
|
|
depends on HID_LOGITECH
|
|
|
|
|
select INPUT_FF_MEMLESS
|
2011-08-10 16:11:10 +00:00
|
|
|
default LOGITECH_FF
|
2010-09-22 11:19:42 +00:00
|
|
|
help
|
2011-08-04 14:24:22 +00:00
|
|
|
Say Y here if you want to enable force feedback and range setting
|
|
|
|
|
support for following Logitech wheels:
|
|
|
|
|
- Logitech Driving Force
|
|
|
|
|
- Logitech Driving Force Pro
|
|
|
|
|
- Logitech Driving Force GT
|
|
|
|
|
- Logitech G25
|
|
|
|
|
- Logitech G27
|
|
|
|
|
- Logitech MOMO/MOMO 2
|
|
|
|
|
- Logitech Formula Force EX
|
2010-09-22 11:19:42 +00:00
|
|
|
|
2010-02-06 17:24:36 +00:00
|
|
|
config HID_MAGICMOUSE
|
2013-04-20 19:13:52 +00:00
|
|
|
tristate "Apple Magic Mouse/Trackpad multi-touch support"
|
2013-02-25 10:31:45 +00:00
|
|
|
depends on HID
|
2010-02-06 17:24:36 +00:00
|
|
|
---help---
|
2013-04-20 19:13:52 +00:00
|
|
|
Support for the Apple Magic Mouse/Trackpad multi-touch.
|
2010-02-06 17:24:36 +00:00
|
|
|
|
|
|
|
|
Say Y here if you want support for the multi-touch features of the
|
2013-04-20 19:13:52 +00:00
|
|
|
Apple Wireless "Magic" Mouse and the Apple Wireless "Magic" Trackpad.
|
2010-02-06 17:24:36 +00:00
|
|
|
|
2008-06-20 19:26:11 +00:00
|
|
|
config HID_MICROSOFT
|
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 16:33:33 +00:00
|
|
|
tristate "Microsoft non-fully HID-compliant devices"
|
2013-02-25 10:31:45 +00:00
|
|
|
depends on HID
|
2011-01-20 22:44:16 +00:00
|
|
|
default !EXPERT
|
2008-06-20 19:26:11 +00:00
|
|
|
---help---
|
2008-10-15 23:25:15 +00:00
|
|
|
Support for Microsoft devices that are not fully compliant with HID standard.
|
2008-06-20 19:26:11 +00:00
|
|
|
|
2008-06-24 22:07:50 +00:00
|
|
|
config HID_MONTEREY
|
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 16:33:33 +00:00
|
|
|
tristate "Monterey Genius KB29E keyboard"
|
2013-02-25 10:31:45 +00:00
|
|
|
depends on HID
|
2011-01-20 22:44:16 +00:00
|
|
|
default !EXPERT
|
2008-06-24 22:07:50 +00:00
|
|
|
---help---
|
|
|
|
|
Support for Monterey Genius KB29E.
|
|
|
|
|
|
2011-01-07 22:45:50 +00:00
|
|
|
config HID_MULTITOUCH
|
|
|
|
|
tristate "HID Multitouch panels"
|
2013-02-25 10:31:46 +00:00
|
|
|
depends on HID
|
2011-01-07 22:45:50 +00:00
|
|
|
---help---
|
|
|
|
|
Generic support for HID multitouch panels.
|
|
|
|
|
|
|
|
|
|
Say Y here if you have one of the following devices:
|
2011-03-22 16:34:01 +00:00
|
|
|
- 3M PCT touch screens
|
2011-05-19 12:18:13 +00:00
|
|
|
- ActionStar dual touch panels
|
2011-12-23 14:40:59 +00:00
|
|
|
- Atmel panels
|
2011-05-20 13:59:34 +00:00
|
|
|
- Cando dual touch panels
|
2011-05-27 18:03:47 +00:00
|
|
|
- Chunghwa panels
|
2015-07-20 16:40:28 +00:00
|
|
|
- CJTouch panels
|
2011-05-19 12:18:14 +00:00
|
|
|
- CVTouch panels
|
2011-01-11 15:45:54 +00:00
|
|
|
- Cypress TrueTouch panels
|
2013-10-25 22:03:49 +00:00
|
|
|
- Elan Microelectronics touch panels
|
2011-05-19 09:37:29 +00:00
|
|
|
- Elo TouchSystems IntelliTouch Plus panels
|
2011-05-20 13:59:34 +00:00
|
|
|
- GeneralTouch 'Sensing Win7-TwoFinger' panels
|
2011-05-19 12:18:15 +00:00
|
|
|
- GoodTouch panels
|
2011-01-11 15:45:54 +00:00
|
|
|
- Hanvon dual touch panels
|
2011-05-20 13:59:34 +00:00
|
|
|
- Ilitek dual touch panels
|
2011-01-31 10:28:22 +00:00
|
|
|
- IrTouch Infrared USB panels
|
2011-08-16 04:12:09 +00:00
|
|
|
- LG Display panels (Dell ST2220Tc)
|
2011-05-18 13:27:24 +00:00
|
|
|
- Lumio CrystalTouch panels
|
2011-04-22 09:51:48 +00:00
|
|
|
- MosArt dual-touch panels
|
2012-02-14 08:50:33 +00:00
|
|
|
- Panasonic multitouch panels
|
2011-04-21 14:21:52 +00:00
|
|
|
- PenMount dual touch panels
|
2012-02-04 16:08:50 +00:00
|
|
|
- Perixx Peripad 701 touchpad
|
2011-12-15 03:09:06 +00:00
|
|
|
- PixArt optical touch screen
|
2011-01-11 15:45:54 +00:00
|
|
|
- Pixcir dual touch panels
|
2011-11-29 12:13:10 +00:00
|
|
|
- Quanta panels
|
2011-05-20 13:59:34 +00:00
|
|
|
- eGalax dual-touch panels, including the Joojoo and Wetab tablets
|
2013-10-21 16:38:49 +00:00
|
|
|
- SiS multitouch panels
|
2011-03-18 13:27:53 +00:00
|
|
|
- Stantum multitouch panels
|
2011-05-19 12:18:16 +00:00
|
|
|
- Touch International Panels
|
2011-05-19 12:18:17 +00:00
|
|
|
- Unitec Panels
|
2013-11-21 09:04:30 +00:00
|
|
|
- Wistron optical touch panels
|
2011-07-15 08:58:06 +00:00
|
|
|
- XAT optical touch panels
|
2012-01-05 02:53:46 +00:00
|
|
|
- Xiroku optical touch panels
|
2012-06-19 12:39:54 +00:00
|
|
|
- Zytronic touch panels
|
2011-01-07 22:45:50 +00:00
|
|
|
|
2011-01-11 15:45:54 +00:00
|
|
|
If unsure, say N.
|
|
|
|
|
|
|
|
|
|
To compile this driver as a module, choose M here: the
|
|
|
|
|
module will be called hid-multitouch.
|
|
|
|
|
|
2008-11-19 14:54:46 +00:00
|
|
|
config HID_NTRIG
|
2010-08-16 14:26:08 +00:00
|
|
|
tristate "N-Trig touch screen"
|
2008-11-19 14:54:46 +00:00
|
|
|
depends on USB_HID
|
|
|
|
|
---help---
|
|
|
|
|
Support for N-Trig touch screen.
|
|
|
|
|
|
2010-01-21 14:36:52 +00:00
|
|
|
config HID_ORTEK
|
2011-03-21 12:54:22 +00:00
|
|
|
tristate "Ortek PKB-1700/WKB-2000/Skycable wireless keyboard and mouse trackpad"
|
2013-02-25 10:31:45 +00:00
|
|
|
depends on HID
|
2010-01-21 14:36:52 +00:00
|
|
|
---help---
|
2011-03-21 12:54:22 +00:00
|
|
|
There are certain devices which have LogicalMaximum wrong in the keyboard
|
|
|
|
|
usage page of their report descriptor. The most prevailing ones so far
|
|
|
|
|
are manufactured by Ortek, thus the name of the driver. Currently
|
|
|
|
|
supported devices by this driver are
|
|
|
|
|
|
|
|
|
|
- Ortek PKB-1700
|
|
|
|
|
- Ortek WKB-2000
|
|
|
|
|
- Skycable wireless presenter
|
2010-01-21 14:36:52 +00:00
|
|
|
|
2009-05-15 13:46:44 +00:00
|
|
|
config HID_PANTHERLORD
|
2010-08-16 14:26:08 +00:00
|
|
|
tristate "Pantherlord/GreenAsia game controller"
|
2013-02-25 10:31:46 +00:00
|
|
|
depends on HID
|
2009-05-15 13:46:44 +00:00
|
|
|
---help---
|
|
|
|
|
Say Y here if you have a PantherLord/GreenAsia based game controller
|
|
|
|
|
or adapter.
|
|
|
|
|
|
2008-09-18 17:43:32 +00:00
|
|
|
config PANTHERLORD_FF
|
|
|
|
|
bool "Pantherlord force feedback support"
|
|
|
|
|
depends on HID_PANTHERLORD
|
|
|
|
|
select INPUT_FF_MEMLESS
|
2009-05-15 13:46:44 +00:00
|
|
|
---help---
|
2008-09-18 17:43:32 +00:00
|
|
|
Say Y here if you have a PantherLord/GreenAsia based game controller
|
|
|
|
|
or adapter and want to enable force feedback support for it.
|
|
|
|
|
|
2014-09-03 08:33:53 +00:00
|
|
|
config HID_PENMOUNT
|
|
|
|
|
tristate "Penmount touch device"
|
|
|
|
|
depends on USB_HID
|
|
|
|
|
---help---
|
|
|
|
|
This selects a driver for the PenMount 6000 touch controller.
|
|
|
|
|
|
|
|
|
|
The driver works around a problem in the report descript allowing
|
|
|
|
|
the userspace to touch events instead of mouse events.
|
|
|
|
|
|
|
|
|
|
Say Y here if you have a Penmount based touch controller.
|
|
|
|
|
|
2008-06-24 21:46:21 +00:00
|
|
|
config HID_PETALYNX
|
2010-08-16 14:26:08 +00:00
|
|
|
tristate "Petalynx Maxter remote control"
|
2013-02-25 10:31:45 +00:00
|
|
|
depends on HID
|
2008-06-24 21:46:21 +00:00
|
|
|
---help---
|
2008-10-15 23:25:15 +00:00
|
|
|
Support for Petalynx Maxter remote control.
|
2008-06-24 21:46:21 +00:00
|
|
|
|
2010-03-30 20:33:50 +00:00
|
|
|
config HID_PICOLCD
|
|
|
|
|
tristate "PicoLCD (graphic version)"
|
2013-02-25 10:31:47 +00:00
|
|
|
depends on HID
|
2010-03-30 20:33:50 +00:00
|
|
|
---help---
|
|
|
|
|
This provides support for Minibox PicoLCD devices, currently
|
|
|
|
|
only the graphical ones are supported.
|
|
|
|
|
|
|
|
|
|
This includes support for the following device features:
|
|
|
|
|
- Keypad
|
|
|
|
|
- Switching between Firmware and Flash mode
|
2010-03-30 20:38:09 +00:00
|
|
|
- EEProm / Flash access (via debugfs)
|
2010-04-11 10:17:45 +00:00
|
|
|
Features selectively enabled:
|
|
|
|
|
- Framebuffer for monochrome 256x64 display
|
|
|
|
|
- Backlight control
|
|
|
|
|
- Contrast control
|
|
|
|
|
- General purpose outputs
|
2010-03-30 20:34:30 +00:00
|
|
|
Features that are not (yet) supported:
|
2010-03-30 20:33:50 +00:00
|
|
|
- IR
|
|
|
|
|
|
2010-04-11 10:17:45 +00:00
|
|
|
config HID_PICOLCD_FB
|
2011-01-20 22:44:16 +00:00
|
|
|
bool "Framebuffer support" if EXPERT
|
|
|
|
|
default !EXPERT
|
2010-04-11 10:17:45 +00:00
|
|
|
depends on HID_PICOLCD
|
|
|
|
|
depends on HID_PICOLCD=FB || FB=y
|
|
|
|
|
select FB_DEFERRED_IO
|
|
|
|
|
select FB_SYS_FILLRECT
|
|
|
|
|
select FB_SYS_COPYAREA
|
|
|
|
|
select FB_SYS_IMAGEBLIT
|
|
|
|
|
select FB_SYS_FOPS
|
|
|
|
|
---help---
|
|
|
|
|
Provide access to PicoLCD's 256x64 monochrome display via a
|
2012-04-13 15:14:11 +00:00
|
|
|
framebuffer device.
|
2010-04-11 10:17:45 +00:00
|
|
|
|
|
|
|
|
config HID_PICOLCD_BACKLIGHT
|
2011-01-20 22:44:16 +00:00
|
|
|
bool "Backlight control" if EXPERT
|
|
|
|
|
default !EXPERT
|
2010-04-11 10:17:45 +00:00
|
|
|
depends on HID_PICOLCD
|
|
|
|
|
depends on HID_PICOLCD=BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=y
|
|
|
|
|
---help---
|
|
|
|
|
Provide access to PicoLCD's backlight control via backlight
|
|
|
|
|
class.
|
|
|
|
|
|
|
|
|
|
config HID_PICOLCD_LCD
|
2011-01-20 22:44:16 +00:00
|
|
|
bool "Contrast control" if EXPERT
|
|
|
|
|
default !EXPERT
|
2010-04-11 10:17:45 +00:00
|
|
|
depends on HID_PICOLCD
|
|
|
|
|
depends on HID_PICOLCD=LCD_CLASS_DEVICE || LCD_CLASS_DEVICE=y
|
|
|
|
|
---help---
|
|
|
|
|
Provide access to PicoLCD's LCD contrast via lcd class.
|
|
|
|
|
|
|
|
|
|
config HID_PICOLCD_LEDS
|
2011-01-20 22:44:16 +00:00
|
|
|
bool "GPO via leds class" if EXPERT
|
|
|
|
|
default !EXPERT
|
2010-04-11 10:17:45 +00:00
|
|
|
depends on HID_PICOLCD
|
|
|
|
|
depends on HID_PICOLCD=LEDS_CLASS || LEDS_CLASS=y
|
|
|
|
|
---help---
|
|
|
|
|
Provide access to PicoLCD's GPO pins via leds class.
|
|
|
|
|
|
2012-07-30 19:38:28 +00:00
|
|
|
config HID_PICOLCD_CIR
|
|
|
|
|
bool "CIR via RC class" if EXPERT
|
|
|
|
|
default !EXPERT
|
|
|
|
|
depends on HID_PICOLCD
|
|
|
|
|
depends on HID_PICOLCD=RC_CORE || RC_CORE=y
|
|
|
|
|
---help---
|
|
|
|
|
Provide access to PicoLCD's CIR interface via remote control (LIRC).
|
|
|
|
|
|
2014-11-01 00:34:42 +00:00
|
|
|
config HID_PLANTRONICS
|
|
|
|
|
tristate "Plantronics USB HID Driver"
|
|
|
|
|
depends on HID
|
|
|
|
|
---help---
|
2015-06-08 21:27:57 +00:00
|
|
|
Provides HID support for Plantronics USB audio devices.
|
|
|
|
|
Correctly maps vendor unique volume up/down HID usages to
|
|
|
|
|
KEY_VOLUMEUP and KEY_VOLUMEDOWN events and prevents core mapping
|
|
|
|
|
of other vendor unique HID usages to random mouse events.
|
|
|
|
|
|
|
|
|
|
Say M here if you may ever plug in a Plantronics USB audio device.
|
2014-11-01 00:34:42 +00:00
|
|
|
|
2011-10-15 00:18:54 +00:00
|
|
|
config HID_PRIMAX
|
2011-10-17 15:04:58 +00:00
|
|
|
tristate "Primax non-fully HID-compliant devices"
|
2013-02-25 10:31:45 +00:00
|
|
|
depends on HID
|
2011-10-15 00:18:54 +00:00
|
|
|
---help---
|
|
|
|
|
Support for Primax devices that are not fully compliant with the
|
|
|
|
|
HID standard.
|
|
|
|
|
|
2010-05-19 16:55:16 +00:00
|
|
|
config HID_ROCCAT
|
2011-12-29 16:20:14 +00:00
|
|
|
tristate "Roccat device support"
|
2010-05-19 16:55:16 +00:00
|
|
|
depends on USB_HID
|
|
|
|
|
---help---
|
2011-12-29 16:20:14 +00:00
|
|
|
Support for Roccat devices.
|
|
|
|
|
Say Y here if you have a Roccat mouse or keyboard and want
|
|
|
|
|
support for its special functionalities.
|
2010-08-29 10:30:18 +00:00
|
|
|
|
2012-02-22 01:10:06 +00:00
|
|
|
config HID_SAITEK
|
2014-11-05 14:13:51 +00:00
|
|
|
tristate "Saitek (Mad Catz) non-fully HID-compliant devices"
|
2013-02-25 10:31:45 +00:00
|
|
|
depends on HID
|
2012-02-22 01:10:06 +00:00
|
|
|
---help---
|
|
|
|
|
Support for Saitek devices that are not fully compliant with the
|
|
|
|
|
HID standard.
|
|
|
|
|
|
2014-05-20 18:28:00 +00:00
|
|
|
Supported devices:
|
|
|
|
|
- PS1000 Dual Analog Pad
|
2015-09-03 15:49:26 +00:00
|
|
|
- Saitek R.A.T.7, R.A.T.9, M.M.O.7 Gaming Mice
|
|
|
|
|
- Mad Catz R.A.T.5, R.A.T.9 Gaming Mice
|
2012-02-22 01:10:06 +00:00
|
|
|
|
2008-06-25 20:31:48 +00:00
|
|
|
config HID_SAMSUNG
|
2010-08-16 14:26:08 +00:00
|
|
|
tristate "Samsung InfraRed remote control or keyboards"
|
2013-02-25 10:31:45 +00:00
|
|
|
depends on HID
|
2008-06-25 20:31:48 +00:00
|
|
|
---help---
|
2010-05-17 10:42:39 +00:00
|
|
|
Support for Samsung InfraRed remote control or keyboards.
|
2008-06-25 20:31:48 +00:00
|
|
|
|
2008-06-25 21:47:04 +00:00
|
|
|
config HID_SONY
|
2014-02-01 15:39:58 +00:00
|
|
|
tristate "Sony PS2/3/4 accessories"
|
2008-06-25 21:47:04 +00:00
|
|
|
depends on USB_HID
|
2013-05-28 09:22:09 +00:00
|
|
|
depends on NEW_LEDS
|
|
|
|
|
depends on LEDS_CLASS
|
2014-02-03 10:17:25 +00:00
|
|
|
select POWER_SUPPLY
|
2008-06-25 21:47:04 +00:00
|
|
|
---help---
|
2013-05-27 21:41:05 +00:00
|
|
|
Support for
|
2012-09-25 21:02:27 +00:00
|
|
|
|
2013-05-27 21:41:05 +00:00
|
|
|
* Sony PS3 6-axis controllers
|
2014-02-01 15:39:58 +00:00
|
|
|
* Sony PS4 DualShock 4 controllers
|
2013-05-27 21:41:05 +00:00
|
|
|
* Buzz controllers
|
2013-06-13 10:03:49 +00:00
|
|
|
* Sony PS3 Blue-ray Disk Remote Control (Bluetooth)
|
|
|
|
|
* Logitech Harmony adapter for Sony Playstation 3 (Bluetooth)
|
2008-06-25 21:47:04 +00:00
|
|
|
|
2013-11-09 18:25:57 +00:00
|
|
|
config SONY_FF
|
2014-02-01 15:39:58 +00:00
|
|
|
bool "Sony PS2/3/4 accessories force feedback support"
|
2013-11-09 18:25:57 +00:00
|
|
|
depends on HID_SONY
|
|
|
|
|
select INPUT_FF_MEMLESS
|
|
|
|
|
---help---
|
2014-02-01 15:39:58 +00:00
|
|
|
Say Y here if you have a Sony PS2/3/4 accessory and want to enable
|
|
|
|
|
force feedback support for it.
|
2013-11-09 18:25:57 +00:00
|
|
|
|
2011-05-27 16:40:29 +00:00
|
|
|
config HID_SPEEDLINK
|
|
|
|
|
tristate "Speedlink VAD Cezanne mouse support"
|
2013-02-25 10:31:46 +00:00
|
|
|
depends on HID
|
2011-05-27 16:40:29 +00:00
|
|
|
---help---
|
|
|
|
|
Support for Speedlink Vicious and Divine Cezanne mouse.
|
|
|
|
|
|
2013-01-31 15:50:24 +00:00
|
|
|
config HID_STEELSERIES
|
2013-01-31 15:07:07 +00:00
|
|
|
tristate "Steelseries SRW-S1 steering wheel support"
|
2013-02-25 10:31:46 +00:00
|
|
|
depends on HID
|
2013-01-31 15:07:07 +00:00
|
|
|
---help---
|
|
|
|
|
Support for Steelseries SRW-S1 steering wheel
|
|
|
|
|
|
2008-06-23 19:56:07 +00:00
|
|
|
config HID_SUNPLUS
|
2010-08-16 14:26:08 +00:00
|
|
|
tristate "Sunplus wireless desktop"
|
2013-02-25 10:31:45 +00:00
|
|
|
depends on HID
|
2008-06-23 19:56:07 +00:00
|
|
|
---help---
|
2008-10-15 23:25:15 +00:00
|
|
|
Support for Sunplus wireless desktop.
|
2008-06-23 19:56:07 +00:00
|
|
|
|
2014-04-07 17:39:33 +00:00
|
|
|
config HID_RMI
|
|
|
|
|
tristate "Synaptics RMI4 device support"
|
|
|
|
|
depends on HID
|
|
|
|
|
---help---
|
|
|
|
|
Support for Synaptics RMI4 touchpads.
|
|
|
|
|
Say Y here if you have a Synaptics RMI4 touchpads over i2c-hid or usbhid
|
|
|
|
|
and want support for its special functionalities.
|
|
|
|
|
|
2009-05-15 13:46:44 +00:00
|
|
|
config HID_GREENASIA
|
2010-08-16 14:26:08 +00:00
|
|
|
tristate "GreenAsia (Product ID 0x12) game controller support"
|
2013-02-25 10:31:46 +00:00
|
|
|
depends on HID
|
2009-05-15 13:46:44 +00:00
|
|
|
---help---
|
|
|
|
|
Say Y here if you have a GreenAsia (Product ID 0x12) based game
|
|
|
|
|
controller or adapter.
|
|
|
|
|
|
|
|
|
|
config GREENASIA_FF
|
|
|
|
|
bool "GreenAsia (Product ID 0x12) force feedback support"
|
|
|
|
|
depends on HID_GREENASIA
|
2008-12-11 21:07:59 +00:00
|
|
|
select INPUT_FF_MEMLESS
|
|
|
|
|
---help---
|
|
|
|
|
Say Y here if you have a GreenAsia (Product ID 0x12) based game controller
|
2009-01-26 10:12:25 +00:00
|
|
|
(like MANTA Warrior MM816 and SpeedLink Strike2 SL-6635) or adapter
|
2008-12-11 21:07:59 +00:00
|
|
|
and want to enable force feedback support for it.
|
|
|
|
|
|
2011-11-22 21:52:15 +00:00
|
|
|
config HID_HYPERV_MOUSE
|
|
|
|
|
tristate "Microsoft Hyper-V mouse driver"
|
|
|
|
|
depends on HYPERV
|
|
|
|
|
---help---
|
|
|
|
|
Select this option to enable the Hyper-V mouse driver.
|
|
|
|
|
|
2009-05-13 08:54:38 +00:00
|
|
|
config HID_SMARTJOYPLUS
|
2010-05-21 11:15:17 +00:00
|
|
|
tristate "SmartJoy PLUS PS2/USB adapter support"
|
2013-02-25 10:31:46 +00:00
|
|
|
depends on HID
|
2009-05-13 08:54:38 +00:00
|
|
|
---help---
|
2011-10-20 20:26:21 +00:00
|
|
|
Support for SmartJoy PLUS PS2/USB adapter, Super Dual Box,
|
|
|
|
|
Super Joy Box 3 Pro, Super Dual Box Pro, and Super Joy Box 5 Pro.
|
|
|
|
|
|
|
|
|
|
Note that DDR (Dance Dance Revolution) mode is not supported, nor
|
|
|
|
|
is pressure sensitive buttons on the pro models.
|
2009-05-13 08:54:38 +00:00
|
|
|
|
|
|
|
|
config SMARTJOYPLUS_FF
|
|
|
|
|
bool "SmartJoy PLUS PS2/USB adapter force feedback support"
|
|
|
|
|
depends on HID_SMARTJOYPLUS
|
|
|
|
|
select INPUT_FF_MEMLESS
|
|
|
|
|
---help---
|
|
|
|
|
Say Y here if you have a SmartJoy PLUS PS2/USB adapter and want to
|
|
|
|
|
enable force feedback support for it.
|
|
|
|
|
|
2012-02-06 16:36:38 +00:00
|
|
|
config HID_TIVO
|
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 20:57:42 +00:00
|
|
|
tristate "TiVo Slide Bluetooth remote control support"
|
2013-02-25 10:31:45 +00:00
|
|
|
depends on HID
|
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 20:57:42 +00:00
|
|
|
---help---
|
|
|
|
|
Say Y if you have a TiVo Slide Bluetooth remote control.
|
|
|
|
|
|
2009-01-03 23:36:56 +00:00
|
|
|
config HID_TOPSEED
|
2010-07-13 20:50:51 +00:00
|
|
|
tristate "TopSeed Cyberlink, BTC Emprex, Conceptronic remote control support"
|
2013-02-25 10:31:45 +00:00
|
|
|
depends on HID
|
2009-01-03 23:36:56 +00:00
|
|
|
---help---
|
2010-07-13 20:50:51 +00:00
|
|
|
Say Y if you have a TopSeed Cyberlink or BTC Emprex or Conceptronic
|
|
|
|
|
CLLRCMCE remote control.
|
2009-01-03 23:36:56 +00:00
|
|
|
|
2013-01-22 17:01:21 +00:00
|
|
|
config HID_THINGM
|
|
|
|
|
tristate "ThingM blink(1) USB RGB LED"
|
2013-02-25 10:31:45 +00:00
|
|
|
depends on HID
|
2013-01-22 17:01:21 +00:00
|
|
|
depends on LEDS_CLASS
|
|
|
|
|
---help---
|
|
|
|
|
Support for the ThingM blink(1) USB RGB LED. This driver registers a
|
|
|
|
|
Linux LED class instance, plus additional sysfs attributes to control
|
|
|
|
|
RGB colors, fade time and playing. The device is exposed through hidraw
|
|
|
|
|
to access other functions.
|
|
|
|
|
|
2009-05-15 13:46:44 +00:00
|
|
|
config HID_THRUSTMASTER
|
2010-05-21 11:15:17 +00:00
|
|
|
tristate "ThrustMaster devices support"
|
2013-02-25 10:31:46 +00:00
|
|
|
depends on HID
|
2009-05-15 13:46:44 +00:00
|
|
|
---help---
|
|
|
|
|
Say Y here if you have a THRUSTMASTER FireStore Dual Power 2 or
|
|
|
|
|
a THRUSTMASTER Ferrari GT Rumble Wheel.
|
|
|
|
|
|
|
|
|
|
config THRUSTMASTER_FF
|
|
|
|
|
bool "ThrustMaster devices force feedback support"
|
|
|
|
|
depends on HID_THRUSTMASTER
|
2008-09-18 10:23:31 +00:00
|
|
|
select INPUT_FF_MEMLESS
|
2009-05-15 13:46:44 +00:00
|
|
|
---help---
|
2009-06-29 07:41:29 +00:00
|
|
|
Say Y here if you have a THRUSTMASTER FireStore Dual Power 2 or 3,
|
|
|
|
|
a THRUSTMASTER Dual Trigger 3-in-1 or a THRUSTMASTER Ferrari GT
|
|
|
|
|
Rumble Force or Force Feedback Wheel.
|
2008-09-18 10:23:31 +00:00
|
|
|
|
2009-05-11 15:18:12 +00:00
|
|
|
config HID_WACOM
|
2014-07-24 20:10:09 +00:00
|
|
|
tristate "Wacom Intuos/Graphire tablet support (USB)"
|
2013-02-25 10:31:45 +00:00
|
|
|
depends on HID
|
2010-03-15 19:16:23 +00:00
|
|
|
select POWER_SUPPLY
|
2014-07-24 20:10:09 +00:00
|
|
|
select NEW_LEDS
|
|
|
|
|
select LEDS_CLASS
|
|
|
|
|
help
|
2014-08-06 21:06:26 +00:00
|
|
|
Say Y here if you want to use the USB or BT version of the Wacom Intuos
|
2014-07-24 20:10:09 +00:00
|
|
|
or Graphire tablet.
|
|
|
|
|
|
|
|
|
|
To compile this driver as a module, choose M here: the
|
|
|
|
|
module will be called wacom.
|
2010-03-15 19:16:23 +00:00
|
|
|
|
2011-07-05 11:45:08 +00:00
|
|
|
config HID_WIIMOTE
|
2013-05-05 21:12:45 +00:00
|
|
|
tristate "Nintendo Wii / Wii U peripherals"
|
2013-02-25 10:31:45 +00:00
|
|
|
depends on HID
|
2011-08-17 09:43:22 +00:00
|
|
|
depends on LEDS_CLASS
|
2011-09-06 11:50:39 +00:00
|
|
|
select POWER_SUPPLY
|
2011-12-07 20:33:59 +00:00
|
|
|
select INPUT_FF_MEMLESS
|
2011-07-05 11:45:08 +00:00
|
|
|
---help---
|
2013-05-05 21:12:45 +00:00
|
|
|
Support for Nintendo Wii and Wii U Bluetooth peripherals. Supported
|
|
|
|
|
devices are the Wii Remote and its extension devices, but also devices
|
|
|
|
|
based on the Wii Remote like the Wii U Pro Controller or the
|
|
|
|
|
Wii Balance Board.
|
2011-07-05 11:45:08 +00:00
|
|
|
|
2013-05-05 21:12:45 +00:00
|
|
|
Support for all official Nintendo extensions is available, however, 3rd
|
|
|
|
|
party extensions might not be supported. Please report these devices to:
|
|
|
|
|
http://github.com/dvdhrm/xwiimote/issues
|
|
|
|
|
|
|
|
|
|
Other Nintendo Wii U peripherals that are IEEE 802.11 based (including
|
|
|
|
|
the Wii U Gamepad) might be supported in the future. But currently
|
|
|
|
|
support is limited to Bluetooth based devices.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
|
|
|
|
To compile this driver as a module, choose M here: the
|
|
|
|
|
module will be called hid-wiimote.
|
2011-11-17 13:12:01 +00:00
|
|
|
|
2013-07-27 17:20:02 +00:00
|
|
|
config HID_XINMO
|
|
|
|
|
tristate "Xin-Mo non-fully compliant devices"
|
|
|
|
|
depends on HID
|
|
|
|
|
---help---
|
|
|
|
|
Support for Xin-Mo devices that are not fully compliant with the HID
|
2014-06-10 21:35:36 +00:00
|
|
|
standard. Currently only supports the Xin-Mo Dual Arcade. Say Y here
|
2013-07-27 17:20:02 +00:00
|
|
|
if you have a Xin-Mo Dual Arcade controller.
|
|
|
|
|
|
2009-05-15 13:46:44 +00:00
|
|
|
config HID_ZEROPLUS
|
2010-05-21 11:15:17 +00:00
|
|
|
tristate "Zeroplus based game controller support"
|
2013-02-25 10:31:46 +00:00
|
|
|
depends on HID
|
2009-05-15 13:46:44 +00:00
|
|
|
---help---
|
2008-09-18 10:23:32 +00:00
|
|
|
Say Y here if you have a Zeroplus based game controller.
|
|
|
|
|
|
2009-05-15 13:46:44 +00:00
|
|
|
config ZEROPLUS_FF
|
|
|
|
|
bool "Zeroplus based game controller force feedback support"
|
|
|
|
|
depends on HID_ZEROPLUS
|
|
|
|
|
select INPUT_FF_MEMLESS
|
|
|
|
|
---help---
|
|
|
|
|
Say Y here if you have a Zeroplus based game controller and want
|
|
|
|
|
to have force feedback support for it.
|
|
|
|
|
|
2010-05-14 16:30:59 +00:00
|
|
|
config HID_ZYDACRON
|
2010-05-21 11:15:17 +00:00
|
|
|
tristate "Zydacron remote control support"
|
2013-02-25 10:31:45 +00:00
|
|
|
depends on HID
|
2010-05-14 16:30:59 +00:00
|
|
|
---help---
|
|
|
|
|
Support for Zydacron remote control.
|
|
|
|
|
|
2012-09-05 12:56:00 +00:00
|
|
|
config HID_SENSOR_HUB
|
|
|
|
|
tristate "HID Sensors framework support"
|
2014-06-10 12:04:58 +00:00
|
|
|
depends on HID && HAS_IOMEM
|
2012-09-05 12:56:00 +00:00
|
|
|
select MFD_CORE
|
|
|
|
|
default n
|
2013-03-05 08:49:01 +00:00
|
|
|
---help---
|
2012-09-05 12:56:00 +00:00
|
|
|
Support for HID Sensor framework. This creates a MFD instance
|
|
|
|
|
for a sensor hub and identifies all the sensors connected to it.
|
|
|
|
|
Each sensor is registered as a MFD cell, so that sensor specific
|
|
|
|
|
processing can be done in a separate driver. Each sensor
|
|
|
|
|
drivers can use the service provided by this driver to register
|
|
|
|
|
for events and handle data streams. Each sensor driver can format
|
|
|
|
|
data and present to user mode using input or IIO interface.
|
|
|
|
|
|
2015-04-10 18:22:22 +00:00
|
|
|
config HID_SENSOR_CUSTOM_SENSOR
|
|
|
|
|
tristate "HID Sensors hub custom sensor support"
|
|
|
|
|
depends on HID_SENSOR_HUB
|
|
|
|
|
default n
|
|
|
|
|
---help---
|
|
|
|
|
HID Sensor hub specification allows definition of some custom and
|
|
|
|
|
generic sensors. Unlike other HID sensors, they can't be exported
|
|
|
|
|
via Linux IIO because of custom fields. This is up to the manufacturer
|
|
|
|
|
to decide how to interpret these special sensor ids and process in
|
|
|
|
|
the user space. Currently some manufacturers are using these ids for
|
|
|
|
|
sensor calibration and debugging other sensors. Manufacturers
|
|
|
|
|
should't use these special custom sensor ids to export any of the
|
|
|
|
|
standard sensors.
|
|
|
|
|
Select this config option for custom/generic sensor support.
|
|
|
|
|
|
2008-05-16 09:49:19 +00:00
|
|
|
endmenu
|
|
|
|
|
|
2012-06-25 14:55:41 +00:00
|
|
|
endif # HID
|
|
|
|
|
|
|
|
|
|
source "drivers/hid/usbhid/Kconfig"
|
|
|
|
|
|
2012-11-12 14:42:59 +00:00
|
|
|
source "drivers/hid/i2c-hid/Kconfig"
|
|
|
|
|
|
2012-06-25 14:55:41 +00:00
|
|
|
endmenu
|
