litmus-rt.git/drivers/hid/Kconfig, branch master

Merge branch 'for-4.1/sensor-hub' into for-linus

2015-04-13T21:43:34+00:00

Conflicts:
	drivers/iio/common/hid-sensors/hid-sensor-trigger.c
	include/linux/hid-sensor-hub.h

Merge branches 'for-4.0/upstream-fixes', 'for-4.1/genius', 'for-4.1/huion-uclogic-merge', 'for-4.1/i2c-hid', 'for-4.1/kconfig-drop-expert-dependency', 'for-4.1/logitech', 'for-4.1/multitouch', 'for-4.1/rmi', 'for-4.1/sony', 'for-4.1/upstream' and 'for-4.1/wacom' into for-linus

2015-04-13T21:41:15+00:00

HID: sensor: Custom and Generic sensor support

2015-04-10T20:22:55+00:00

HID Sensor Spec defines two usage ids for custom sensors

	HID_USAGE_SENSOR_TYPE_OTHER_CUSTOM (0x09, 0xE1)
	HID_USAGE_SENSOR_TYPE_OTHER_GENERIC(0x09, 0xE2)

	In addition the standard also defines usage ids for custom fields.
The purpose of these sensors is to extend the functionality or provide a way to
obfuscate the data being communicated by a sensor. Without knowing the mapping
between the data and its encapsulated form, it is difficult for an driver to
determine what data is being communicated by the sensor.  This allows some
differentiating use cases, where vendor can provide applications.  Since these
can't be represented by standard sensor interfaces like IIO, we present these
as fields with

- type (input/output)
- units
- min/max
- get/set value

In addition an dev interface to transfer report events. Details about this
interface is described in /Documentation/hid/hid-sensor.txt.  Manufacturers
should not use these ids for any standard sensors, otherwise the the
product/vendor id can be added to black list.

Signed-off-by: Srinivas Pandruvada 
Reviewed-by: Jonathan Cameron 
Signed-off-by: Jiri Kosina

HID: plantronics: fix Kconfig default

2015-03-16T15:16:29+00:00

This driver didn't exist until before v3.19.
Why would suddenly everybody want to build it?

Signed-off-by: Stefan Richter 
Signed-off-by: Jiri Kosina

HID: Stop hiding options with !EXPERT

2015-03-16T14:59:59+00:00

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 
Signed-off-by: Jiri Kosina

HID: Kconfig: add USB_HID dependency to UC-LOGIC

2015-03-04T16:33:22+00:00

In commit 08177f4 (HID: uclogic: merge hid-huion driver in hid-uclogic)
HID_HUION depends explicitely on USB_HID because it contained quite some
USB-isms.

Now that hid-uclogic is the new home of Huion tablets, we need to also
add the dependency on USB_HID to this driver.

Reported-by: Jiri Kosina 
Reported-by: kbuild test robot 
Signed-off-by: Benjamin Tissoires 
Signed-off-by: Jiri Kosina

HID: uclogic: merge hid-huion driver in hid-uclogic

2015-03-03T20:31:54+00:00

Merge the hid-huion driver into hid-uclogic as all the devices supported
by hid-huion are in fact UC-Logic devices.

Signed-off-by: Nikolai Kondrashov 
Signed-off-by: Benjamin Tissoires 
Signed-off-by: Jiri Kosina

Merge branches 'for-3.19/upstream-fixes', 'for-3.20/apple', 'for-3.20/betop', 'for-3.20/lenovo', 'for-3.20/logitech', 'for-3.20/rmi', 'for-3.20/upstream' and 'for-3.20/wacom' into for-linus

2015-02-09T10:17:45+00:00

HID: fix Kconfig text

2015-01-06T21:19:43+00:00

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Benjamin Tissoires 
Signed-off-by: Jiri Kosina

HID: add BETOP game controller force feedback support

2014-12-22T13:42:39+00:00

Adds force feedback support for BETOP USB game controllers.
These devices are mass produced in China.

Signed-off-by: Huang Bo 
Signed-off-by: Jiri Kosina