Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 16 3月, 2015 1 次提交
    • J
      HID: Stop hiding options with !EXPERT · 7af05e73
      由 Jean Delvare 提交于 
      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: NJean Delvare <jdelvare@suse.de>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      7af05e73
  3. 07 1月, 2015 1 次提交
  5. 22 12月, 2014 1 次提交
  7. 18 12月, 2014 1 次提交
  9. 05 11月, 2014 1 次提交
  11. 03 11月, 2014 1 次提交
  13. 29 10月, 2014 2 次提交
  15. 04 9月, 2014 1 次提交
  17. 07 8月, 2014 1 次提交
  19. 29 7月, 2014 2 次提交
  21. 26 7月, 2014 1 次提交
  23. 01 7月, 2014 1 次提交
  25. 11 6月, 2014 2 次提交
  27. 21 5月, 2014 1 次提交
  29. 09 4月, 2014 1 次提交
  31. 18 2月, 2014 2 次提交
  33. 04 2月, 2014 1 次提交
  35. 03 2月, 2014 1 次提交
  37. 03 12月, 2013 1 次提交
    • O
      HID: logitech-dj: add HIDRAW dependency in Kconfig · dcdc50e7
      由 Olivier Gay 提交于 
      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: NOlivier Gay <ogay@logitech.com>
Signed-off-by: NNestor Lopez Casado <nlopezcasad@logitech.com>
Signed-off-by: NMathieu Meisser <mmeisser@logitech.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      dcdc50e7
  39. 21 11月, 2013 1 次提交
  41. 11 11月, 2013 1 次提交
    • S
      HID: sony: Add force feedback support for Dualshock3 USB · a08c22c0
      由 Sven Eckelmann 提交于 
      Sony Dualshock 3 controllers have two motors which can be used to provide
simple force feedback rumble effects. The right motor is can be used to create
a weak rumble effect but does not allow to set the force. The left motor is
used to create a strong rumble effect with adjustable intensity.

The state of both motors can be changed using HID_OUTPUT_REPORT packets and
have no timing information. FF memless is used to keep track of the timing and
the sony driver just generates the necessary URBs.
Signed-off-by: NSven Eckelmann <sven@narfation.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      a08c22c0
  43. 30 10月, 2013 1 次提交
  45. 25 10月, 2013 2 次提交
  47. 15 10月, 2013 1 次提交
  49. 09 10月, 2013 1 次提交
  51. 02 10月, 2013 1 次提交
  53. 24 9月, 2013 1 次提交
  55. 13 9月, 2013 1 次提交
  57. 29 7月, 2013 1 次提交
  59. 13 6月, 2013 1 次提交
  61. 03 6月, 2013 2 次提交
  63. 29 5月, 2013 1 次提交
    • J
      HID: add driver for ELO 4000/4500 · d23efc19
      由 Jiri Slaby 提交于 
      This is a driver for ELO 4000/4500 devices which report themselves as
HID devices, but do not really send HID events on touch. So we
introduce a new HID 'quirk' driver with a raw_event handler where we
take care of those events.

What we need additionally is an input_configured hook, because the
device does not mention anything about PRESSURE and TOUCH in its
report descriptor, but it actually generate those. So we set the bits
in the corresponding input_dev in that hook.

Thanks to Petr Ostadal who was willing to test the driver. The rest of
Cc's listed below had something to do with that driver over the years
in our enterprise tree.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Tested-by: NPetr Ostadal <postadal@suse.cz>
Cc: Oliver Neukum <oliver@neukum.org>
Cc: Vojtech Pavlik <vojtech@suse.cz>
Cc: Egbert Eich <eich@suse.com>
Cc: Libor Pechacek <lpechacek@suse.cz>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      d23efc19
  65. 28 5月, 2013 2 次提交
    • M
      HID: add support for Huion 580 tablet · 68e353fe
      由 Martin Rusko 提交于 
      Add hid-huion.c with support for Huion 580 tablet, which is simple
8x5" tablet with 4000LPI resolution and 2048 levels pressure-sensitive
pen manufactured by the Chinese company Huion.

The driver fixes incorrect report descriptor sent by the device,
performs custom initialization required to switch the tablet into
its native resolution mode and inverts the in-range bit.
Signed-off-by: NMartin Rusko <martin.rusko@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      68e353fe
    • C
      HID: Add support for Holtek gaming mouse 04d9:a04a · d4f51890
      由 Christian Ohm 提交于 
      This mouse is sold as Tracer Sniper TRM-503, NOVA Gaming Slider X200 and
Zalman ZM-GM1, and reports too high usage maximum and logical maximum
(like 04d9:a067, but its report descriptor is different). This patch
adds its USB ID and fixes the report descriptor in the same way.

Note: I don't actually have such a mouse to test, I took the report
descriptor posted at https://bugzilla.novell.com/show_bug.cgi?id=774676,
compared it to the one from 04d9:a067 and changed the offsets
accordingly (all numbers minus 9, since it is 9 bytes shorter, and the
difference is before the values that need changing). That Surely Works™.
Signed-off-by: NChristian Ohm <chr.ohm@gmx.net>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      d4f51890