linux/drivers/hid/Kconfig

1544 lines
45 KiB

HID: Kconfig: Fix build error from CONFIG_HID_HAPTIC Temporarily change CONFIG_HID_HAPTIC to be bool instead of tristate, until we implement a permanent solution. Recently the CONFIG_HID_HAPTIC Kconfig option was reported as causing the following build errors: MODPOST Module.symvers ERROR: modpost: "hid_haptic_init" [drivers/hid/hid-multitouch.ko] undefined! ERROR: modpost: "hid_haptic_pressure_increase" [drivers/hid/hid-multitouch.ko] undefined! ERROR: modpost: "hid_haptic_check_pressure_unit" [drivers/hid/hid-multitouch.ko] undefined! ERROR: modpost: "hid_haptic_input_configured" [drivers/hid/hid-multitouch.ko] undefined! ERROR: modpost: "hid_haptic_input_mapping" [drivers/hid/hid-multitouch.ko] undefined! ERROR: modpost: "hid_haptic_feature_mapping" [drivers/hid/hid-multitouch.ko] undefined! ERROR: modpost: "hid_haptic_pressure_reset" [drivers/hid/hid-multitouch.ko] undefined! make[3]: *** [/home/thl/var/linux.dev/scripts/Makefile.modpost:147: Module.symvers] Error 1 when the kernel is compiled with the following configuration: CONFIG_HID=y CONFIG_HID_MULTITOUCH=m CONFIG_HID_HAPTIC=m To resolve this, temporarily change the CONFIG_HID_HAPTIC option to be bool, until we arrive at a permanent solution to enable CONFIG_HID_HAPTIC to be tristate. For a more detailed discussion, see [1]. [1]: https://lore.kernel.org/linux-input/auypydfkhx2eg7vp764way4batdilzc35inqda3exwzs3tk3ff@oagat6g46zto/ Signed-off-by: Jonathan Denose <jdenose@google.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-10-13 20:54:57 +00: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
2016-03-21 16:18:42 +09:00
2016-03-21 16:18:42 +09: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
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
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
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
HID: hyperx: add driver for the HyperX QuadCast 2 mute button The tap-to-mute button of the HyperX QuadCast 2 (03f0:07b4) is handled entirely in the device firmware. The firmware gates the audio internally but never sends the Telephony "Phone Mute" usage (0x2f) that its own report descriptor advertises, and it does not touch the UAC feature unit either. Consequently neither an evdev key event nor an ALSA mixer change is ever generated, and userspace has no way to learn that the microphone was muted: desktops keep showing the microphone as live, and conferencing applications keep displaying an unmuted microphone while transmitting silence. The mute state is reported through a vendor-defined collection instead: 06 c0 ff Usage Page (Vendor-Defined 0xFFC0) a1 01 Collection (Application) 06 c1 ff Usage Page (Vendor-Defined 0xFFC1) 85 77 Report ID (0x77) 09 f0 Usage (0xF0) 75 08 95 3f Report Size (8), Report Count (63) 81 02 Input (Data,Var,Abs) Pressing the button emits a 64-byte report on that collection: 77 06 00 00 ... microphone unmuted 77 06 01 00 ... microphone muted where byte 1 identifies the mute event and byte 2 carries the resulting state. As the payload is an opaque vendor blob carrying no HID usages, hid-input cannot map it and a hwdb entry cannot express it either. Add a driver that decodes the report and emits KEY_MICMUTE, which makes the button behave like any other microphone mute key. Note that the device reports the resulting absolute state, whereas KEY_MICMUTE is a momentary key that userspace acts on as a toggle, so the driver emits one keypress per state change. Tested on a HyperX QuadCast 2 (03f0:07b4). Signed-off-by: Benjamin Blume <benjaminblume@posteo.de> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-07-13 12:42:13 +00:00
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
HID: hid-lenovo-go: fix LEDS dependencies The newly added hid-lenovo-go and hid-lenovo-go-s drivers attempt to 'select LEDS_CLASS', which has a dependency on NEW_LEDS, causing a build failure when NEW_LEDS itself it disabled: WARNING: unmet direct dependencies detected for LEDS_CLASS Depends on [n]: NEW_LEDS [=n] Selected by [m]: - HID_LENOVO_GO [=m] && HID_SUPPORT [=y] && HID [=m] && USB_HID [=m] - HID_LENOVO_GO_S [=m] && HID_SUPPORT [=y] && HID [=m] && USB_HID [=m] WARNING: unmet direct dependencies detected for LEDS_CLASS_MULTICOLOR Depends on [n]: NEW_LEDS [=n] && LEDS_CLASS [=m] Selected by [m]: - HID_LENOVO_GO [=m] && HID_SUPPORT [=y] && HID [=m] && USB_HID [=m] - HID_LENOVO_GO_S [=m] && HID_SUPPORT [=y] && HID [=m] && USB_HID [=m] ERROR: modpost: "led_set_brightness_nopm" [drivers/leds/led-class.ko] undefined! ERROR: modpost: "led_set_brightness" [drivers/leds/led-class.ko] undefined! ERROR: modpost: "led_get_color_name" [drivers/leds/led-class-multicolor.ko] undefined! ERROR: modpost: "led_set_brightness" [drivers/leds/led-class-multicolor.ko] undefined! Device drivers generally should not select other subsystems like this, as that tends to cause dependency problems including loops in the dependency graph. Change these two and the older hid-lenovo driver to behave the same way as all other HID drivers and use 'depends on LEDS_CLASS' or 'depends on LEDS_CLASS_MULTICOLOR' instead, which itself has NEW_LEDS and LEDS_CLASS as dependencies. Fixes: a23f3497bf20 ("HID: hid-lenovo-go-s: Add Lenovo Legion Go S Series HID Driver") Fixes: d69ccfcbc955 ("HID: hid-lenovo-go: Add Lenovo Legion Go Series HID Driver") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-03-24 20:20:28 +01:00
HID: hid-lenovo-go: Add Lenovo Legion Go Series HID Driver Adds initial framework for a new HID driver, hid-lenovo-go, along with attributes that report the firmware and hardware version for each component of the HID device, of which there are 4 parts: The MCU, the transmission dongle, the left "handle" controller half, and the right "handle" controller half. Each of these devices are provided an attribute group to contain its device specific attributes. Additionally, the touchpad device attributes are logically separated from the other components in another attribute group. This driver primarily provides access to the configurable settings of the Lenovo Legion Go and Lenovo Legion Go 2 controllers running the latest firmware. As previously noted, the Legion Go controllers recently had a firmware update[1] which switched from the original "SepentiaUSB" protocol to a brand new protocol for the Go 2, primarily to ensure backwards and forwards compatibility between the Go and Go 2 devices. As part of that update the PIDs for the controllers were changed, so there is no risk of this driver attaching to controller firmware that it doesn't support. -- v6: - Make attributes static. - Use NULL instead of 0 in mcu_propery_out when there is no data. v5: - Make version attributes static, retrieve them using delayed work during probe. - Fix endianness of version strings and print as hex. v3: - Add hid-lenovo.c and Mark Pearson to LENOVO HID DRIVERS entry in MAINTAINERS Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca> Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-03-10 07:29:20 +00:00
HID: hid-lenovo-go: fix LEDS dependencies The newly added hid-lenovo-go and hid-lenovo-go-s drivers attempt to 'select LEDS_CLASS', which has a dependency on NEW_LEDS, causing a build failure when NEW_LEDS itself it disabled: WARNING: unmet direct dependencies detected for LEDS_CLASS Depends on [n]: NEW_LEDS [=n] Selected by [m]: - HID_LENOVO_GO [=m] && HID_SUPPORT [=y] && HID [=m] && USB_HID [=m] - HID_LENOVO_GO_S [=m] && HID_SUPPORT [=y] && HID [=m] && USB_HID [=m] WARNING: unmet direct dependencies detected for LEDS_CLASS_MULTICOLOR Depends on [n]: NEW_LEDS [=n] && LEDS_CLASS [=m] Selected by [m]: - HID_LENOVO_GO [=m] && HID_SUPPORT [=y] && HID [=m] && USB_HID [=m] - HID_LENOVO_GO_S [=m] && HID_SUPPORT [=y] && HID [=m] && USB_HID [=m] ERROR: modpost: "led_set_brightness_nopm" [drivers/leds/led-class.ko] undefined! ERROR: modpost: "led_set_brightness" [drivers/leds/led-class.ko] undefined! ERROR: modpost: "led_get_color_name" [drivers/leds/led-class-multicolor.ko] undefined! ERROR: modpost: "led_set_brightness" [drivers/leds/led-class-multicolor.ko] undefined! Device drivers generally should not select other subsystems like this, as that tends to cause dependency problems including loops in the dependency graph. Change these two and the older hid-lenovo driver to behave the same way as all other HID drivers and use 'depends on LEDS_CLASS' or 'depends on LEDS_CLASS_MULTICOLOR' instead, which itself has NEW_LEDS and LEDS_CLASS as dependencies. Fixes: a23f3497bf20 ("HID: hid-lenovo-go-s: Add Lenovo Legion Go S Series HID Driver") Fixes: d69ccfcbc955 ("HID: hid-lenovo-go: Add Lenovo Legion Go Series HID Driver") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-03-24 20:20:28 +01:00
HID: hid-lenovo-go: Add Lenovo Legion Go Series HID Driver Adds initial framework for a new HID driver, hid-lenovo-go, along with attributes that report the firmware and hardware version for each component of the HID device, of which there are 4 parts: The MCU, the transmission dongle, the left "handle" controller half, and the right "handle" controller half. Each of these devices are provided an attribute group to contain its device specific attributes. Additionally, the touchpad device attributes are logically separated from the other components in another attribute group. This driver primarily provides access to the configurable settings of the Lenovo Legion Go and Lenovo Legion Go 2 controllers running the latest firmware. As previously noted, the Legion Go controllers recently had a firmware update[1] which switched from the original "SepentiaUSB" protocol to a brand new protocol for the Go 2, primarily to ensure backwards and forwards compatibility between the Go and Go 2 devices. As part of that update the PIDs for the controllers were changed, so there is no risk of this driver attaching to controller firmware that it doesn't support. -- v6: - Make attributes static. - Use NULL instead of 0 in mcu_propery_out when there is no data. v5: - Make version attributes static, retrieve them using delayed work during probe. - Fix endianness of version strings and print as hex. v3: - Add hid-lenovo.c and Mark Pearson to LENOVO HID DRIVERS entry in MAINTAINERS Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca> Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-03-10 07:29:20 +00:00
HID: hid-lenovo-go: fix LEDS dependencies The newly added hid-lenovo-go and hid-lenovo-go-s drivers attempt to 'select LEDS_CLASS', which has a dependency on NEW_LEDS, causing a build failure when NEW_LEDS itself it disabled: WARNING: unmet direct dependencies detected for LEDS_CLASS Depends on [n]: NEW_LEDS [=n] Selected by [m]: - HID_LENOVO_GO [=m] && HID_SUPPORT [=y] && HID [=m] && USB_HID [=m] - HID_LENOVO_GO_S [=m] && HID_SUPPORT [=y] && HID [=m] && USB_HID [=m] WARNING: unmet direct dependencies detected for LEDS_CLASS_MULTICOLOR Depends on [n]: NEW_LEDS [=n] && LEDS_CLASS [=m] Selected by [m]: - HID_LENOVO_GO [=m] && HID_SUPPORT [=y] && HID [=m] && USB_HID [=m] - HID_LENOVO_GO_S [=m] && HID_SUPPORT [=y] && HID [=m] && USB_HID [=m] ERROR: modpost: "led_set_brightness_nopm" [drivers/leds/led-class.ko] undefined! ERROR: modpost: "led_set_brightness" [drivers/leds/led-class.ko] undefined! ERROR: modpost: "led_get_color_name" [drivers/leds/led-class-multicolor.ko] undefined! ERROR: modpost: "led_set_brightness" [drivers/leds/led-class-multicolor.ko] undefined! Device drivers generally should not select other subsystems like this, as that tends to cause dependency problems including loops in the dependency graph. Change these two and the older hid-lenovo driver to behave the same way as all other HID drivers and use 'depends on LEDS_CLASS' or 'depends on LEDS_CLASS_MULTICOLOR' instead, which itself has NEW_LEDS and LEDS_CLASS as dependencies. Fixes: a23f3497bf20 ("HID: hid-lenovo-go-s: Add Lenovo Legion Go S Series HID Driver") Fixes: d69ccfcbc955 ("HID: hid-lenovo-go: Add Lenovo Legion Go Series HID Driver") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-03-24 20:20:28 +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
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
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
HID: hid-oxp: Add OneXPlayer configuration driver Adds OneXPlayer HID configuration driver. In this initial driver patch, add the RGB interface for the first generation of HID based RGB control. This interface provides the following attributes: - brightness: provided by the LED core, this works in a fairly unique way on this device. The hardware accepts 5 brightness values (0-4), which affects the brightness of the multicolor and animated effects built into the MCU firmware. For monocolor settings, the device expects the hardware brightness value to be pushed to maximum, then we apply brightness adjustments mathematically based on % (0-100). This leads to some odd conversion as we need the brightness slider to reach the full range, but it has no affect when incrementing between the division points for other effects. - multi-intensity: provided by the LED core for red, green, and blue. - effect: Allows the MCU to set 19 individual effects. - effect_index: Lists the 19 valid effect names for the interface. - enabled: Allows the MCU to toggle the RGB interface on/off. - enabled_index: Lists the valid states for enabled. - speed: Allows the MCU to set the animation rate for the various effects. - speed_range: Lists the valid range of speed (0-9). The MCU also has a few odd quirks that make sending multiple synchronous events challenging. It will essentially freeze if it receives another message before it has finished processing the last command. It also will not reply if you wait on it using a completion. To get around this, we do a 200ms sleep inside a work queue thread and debounce all but the most recent message using a 50ms mod_delayed_work. This will cache the last write, queue the work, then return so userspace can release its write thread. The work queue is only used for brightness/multi-intensity as that is the path likely to receive rapid successive writes. Reviewed-by: Zhouwang Huang <honjow311@gmail.com> Tested-by: Zhouwang Huang <honjow311@gmail.com> Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-04-18 21:26:20 -07:00
HID: hid-oxp: Add OneXPlayer configuration driver Adds OneXPlayer HID configuration driver. In this initial driver patch, add the RGB interface for the first generation of HID based RGB control. This interface provides the following attributes: - brightness: provided by the LED core, this works in a fairly unique way on this device. The hardware accepts 5 brightness values (0-4), which affects the brightness of the multicolor and animated effects built into the MCU firmware. For monocolor settings, the device expects the hardware brightness value to be pushed to maximum, then we apply brightness adjustments mathematically based on % (0-100). This leads to some odd conversion as we need the brightness slider to reach the full range, but it has no affect when incrementing between the division points for other effects. - multi-intensity: provided by the LED core for red, green, and blue. - effect: Allows the MCU to set 19 individual effects. - effect_index: Lists the 19 valid effect names for the interface. - enabled: Allows the MCU to toggle the RGB interface on/off. - enabled_index: Lists the valid states for enabled. - speed: Allows the MCU to set the animation rate for the various effects. - speed_range: Lists the valid range of speed (0-9). The MCU also has a few odd quirks that make sending multiple synchronous events challenging. It will essentially freeze if it receives another message before it has finished processing the last command. It also will not reply if you wait on it using a completion. To get around this, we do a 200ms sleep inside a work queue thread and debounce all but the most recent message using a 50ms mod_delayed_work. This will cache the last write, queue the work, then return so userspace can release its write thread. The work queue is only used for brightness/multi-intensity as that is the path likely to receive rapid successive writes. Reviewed-by: Zhouwang Huang <honjow311@gmail.com> Tested-by: Zhouwang Huang <honjow311@gmail.com> Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-04-18 21:26:20 -07:00
HID: intel-thc: fix CONFIG_HID dependency In drivers/hid/, most drivers depend on CONFIG_HID, while a couple of the drivers in subdirectories instead depend on CONFIG_HID_SUPPORT and use 'select HID'. With the newly added INTEL_THC_HID, this causes a build warning for a circular dependency: WARNING: unmet direct dependencies detected for HID Depends on [m]: HID_SUPPORT [=y] && INPUT [=m] Selected by [y]: - INTEL_THC_HID [=y] && HID_SUPPORT [=y] && X86_64 [=y] && PCI [=y] && ACPI [=y] WARNING: unmet direct dependencies detected for INPUT_FF_MEMLESS Depends on [m]: INPUT [=m] Selected by [y]: - HID_MICROSOFT [=y] && HID_SUPPORT [=y] && HID [=y] - GREENASIA_FF [=y] && HID_SUPPORT [=y] && HID [=y] && HID_GREENASIA [=y] - HID_WIIMOTE [=y] && HID_SUPPORT [=y] && HID [=y] && LEDS_CLASS [=y] - ZEROPLUS_FF [=y] && HID_SUPPORT [=y] && HID [=y] && HID_ZEROPLUS [=y] Selected by [m]: - HID_ACRUX_FF [=y] && HID_SUPPORT [=y] && HID [=y] && HID_ACRUX [=m] - HID_EMS_FF [=m] && HID_SUPPORT [=y] && HID [=y] - HID_GOOGLE_STADIA_FF [=m] && HID_SUPPORT [=y] && HID [=y] - PANTHERLORD_FF [=y] && HID_SUPPORT [=y] && HID [=y] && HID_PANTHERLORD [=m] It's better to be consistent and always use 'depends on HID' for HID drivers. The notable exception here is USB_KBD/USB_MOUSE, which are alternative implementations that do not depend on the HID subsystem. Do this by extending the "if HID" section below, which means that a few of the duplicate "depends on HID" and "depends on INPUT" statements can be removed in the process. Fixes: 1b2d05384c29 ("HID: intel-thc-hid: Add basic THC driver skeleton") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Reviewed-by: Maximilian Luz <luzmaximilian@gmail.com> Reviewed-by: Even Xu <even.xu@intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-01-23 14:48:12 +01:00