aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2014-01-24 17:17:30 -0800
committerLinus Torvalds <torvalds@linux-foundation.org>2014-01-24 17:17:30 -0800
commit1b59bab55e36082b1db3dc81bb32475616487a98 (patch)
tree0cf4af345f159b7056465053c28b5d5089566650 /Documentation
parentb788769e0641daf90a8d7e800081285f8ca80bd9 (diff)
parent55df811f2066fcaec2548248f0a1a6a0c12dc6b8 (diff)
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
Pull input subsystem updates from Dmitry Torokhov: "Just a swath of driver fixes and cleanups, no new drivers this time (although ALPS now supports one of the newer protocols, more to come)" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: (57 commits) Input: wacom - add support for DTU-1031 Input: wacom - fix wacom->shared guards for dual input devices Input: edt_ft5x06 - use devm_* functions where appropriate Input: hyperv-keyboard - pass through 0xE1 prefix Input: logips2pp - fix spelling s/reciver/receiver/ Input: delete non-required instances of include <linux/init.h> Input: twl4030-keypad - convert to using managed resources Input: twl6040-vibra - remove unneeded check for CONFIG_OF Input: twl4030-keypad - add device tree support Input: twl6040-vibra - add missing of_node_put Input: twl4030-vibra - add missing of_node_put Input: i8042 - cleanup SERIO_I8042 dependencies Input: i8042 - select ARCH_MIGHT_HAVE_PC_SERIO on x86 Input: i8042 - select ARCH_MIGHT_HAVE_PC_SERIO on unicore32 Input: i8042 - select ARCH_MIGHT_HAVE_PC_SERIO on sparc Input: i8042 - select ARCH_MIGHT_HAVE_PC_SERIO for SH_CAYMAN Input: i8042 - select ARCH_MIGHT_HAVE_PC_SERIO on powerpc Input: i8042 - select ARCH_MIGHT_HAVE_PC_SERIO on mips Input: i8042 - select ARCH_MIGHT_HAVE_PC_SERIO on IA64 Input: i8042 - select ARCH_MIGHT_HAVE_PC_SERIO on ARM/Footbridge ...
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/devicetree/bindings/input/gpio-beeper.txt13
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt41
-rw-r--r--Documentation/devicetree/bindings/input/twl4030-keypad.txt27
-rw-r--r--Documentation/devicetree/bindings/input/twl4030-pwrbutton.txt21
-rw-r--r--Documentation/input/gamepad.txt6
-rw-r--r--Documentation/input/joystick-api.txt38
-rw-r--r--Documentation/input/joystick.txt8
7 files changed, 128 insertions, 26 deletions
diff --git a/Documentation/devicetree/bindings/input/gpio-beeper.txt b/Documentation/devicetree/bindings/input/gpio-beeper.txt
new file mode 100644
index 000000000000..a5086e37fce6
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/gpio-beeper.txt
@@ -0,0 +1,13 @@
+* GPIO beeper device tree bindings
+
+Register a beeper connected to GPIO pin.
+
+Required properties:
+- compatible: Should be "gpio-beeper".
+- gpios: From common gpio binding; gpio connection to beeper enable pin.
+
+Example:
+ beeper: beeper {
+ compatible = "gpio-beeper";
+ gpios = <&gpio3 23 GPIO_ACTIVE_HIGH>;
+ };
diff --git a/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt b/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt
new file mode 100644
index 000000000000..ec365e172236
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt
@@ -0,0 +1,41 @@
+* Texas Instruments tsc2007 touchscreen controller
+
+Required properties:
+- compatible: must be "ti,tsc2007".
+- reg: I2C address of the chip.
+- ti,x-plate-ohms: X-plate resistance in ohms.
+
+Optional properties:
+- gpios: the interrupt gpio the chip is connected to (trough the penirq pin).
+ The penirq pin goes to low when the panel is touched.
+ (see GPIO binding[1] for more details).
+- interrupt-parent: the phandle for the gpio controller
+ (see interrupt binding[0]).
+- interrupts: (gpio) interrupt to which the chip is connected
+ (see interrupt binding[0]).
+- ti,max-rt: maximum pressure.
+- ti,fuzzx: specifies the absolute input fuzz x value.
+ If set, it will permit noise in the data up to +- the value given to the fuzz
+ parameter, that is used to filter noise from the event stream.
+- ti,fuzzy: specifies the absolute input fuzz y value.
+- ti,fuzzz: specifies the absolute input fuzz z value.
+- ti,poll-period: how much time to wait (in milliseconds) before reading again the
+ values from the tsc2007.
+
+[0]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
+[1]: Documentation/devicetree/bindings/gpio/gpio.txt
+
+Example:
+ &i2c1 {
+ /* ... */
+ tsc2007@49 {
+ compatible = "ti,tsc2007";
+ reg = <0x49>;
+ interrupt-parent = <&gpio4>;
+ interrupts = <0x0 0x8>;
+ gpios = <&gpio4 0 0>;
+ ti,x-plate-ohms = <180>;
+ };
+
+ /* ... */
+ };
diff --git a/Documentation/devicetree/bindings/input/twl4030-keypad.txt b/Documentation/devicetree/bindings/input/twl4030-keypad.txt
new file mode 100644
index 000000000000..e4be2f76a717
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/twl4030-keypad.txt
@@ -0,0 +1,27 @@
+* TWL4030's Keypad Controller device tree bindings
+
+TWL4030's Keypad controller is used to interface a SoC with a matrix-type
+keypad device. The keypad controller supports multiple row and column lines.
+A key can be placed at each intersection of a unique row and a unique column.
+The keypad controller can sense a key-press and key-release and report the
+event using a interrupt to the cpu.
+
+This binding is based on the matrix-keymap binding with the following
+changes:
+
+ * keypad,num-rows and keypad,num-columns are required.
+
+Required SoC Specific Properties:
+- compatible: should be one of the following
+ - "ti,twl4030-keypad": For controllers compatible with twl4030 keypad
+ controller.
+- interrupt: should be one of the following
+ - <1>: For controllers compatible with twl4030 keypad controller.
+
+Example:
+ twl_keypad: keypad {
+ compatible = "ti,twl4030-keypad";
+ interrupts = <1>;
+ keypad,num-rows = <8>;
+ keypad,num-columns = <8>;
+ };
diff --git a/Documentation/devicetree/bindings/input/twl4030-pwrbutton.txt b/Documentation/devicetree/bindings/input/twl4030-pwrbutton.txt
new file mode 100644
index 000000000000..c864a46cddcf
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/twl4030-pwrbutton.txt
@@ -0,0 +1,21 @@
+Texas Instruments TWL family (twl4030) pwrbutton module
+
+This module is part of the TWL4030. For more details about the whole
+chip see Documentation/devicetree/bindings/mfd/twl-familly.txt.
+
+This module provides a simple power button event via an Interrupt.
+
+Required properties:
+- compatible: should be one of the following
+ - "ti,twl4030-pwrbutton": For controllers compatible with twl4030
+- interrupts: should be one of the following
+ - <8>: For controllers compatible with twl4030
+
+Example:
+
+&twl {
+ twl_pwrbutton: pwrbutton {
+ compatible = "ti,twl4030-pwrbutton";
+ interrupts = <8>;
+ };
+};
diff --git a/Documentation/input/gamepad.txt b/Documentation/input/gamepad.txt
index 31bb6a4029ef..3f6d8a5e9cdc 100644
--- a/Documentation/input/gamepad.txt
+++ b/Documentation/input/gamepad.txt
@@ -68,7 +68,7 @@ features that you need, first. How each feature is mapped is described below.
Legacy drivers often don't comply to these rules. As we cannot change them
for backwards-compatibility reasons, you need to provide fixup mappings in
user-space yourself. Some of them might also provide module-options that
-change the mappings so you can adivce users to set these.
+change the mappings so you can advise users to set these.
All new gamepads are supposed to comply with this mapping. Please report any
bugs, if they don't.
@@ -150,10 +150,10 @@ Menu-Pad:
BTN_START
Many pads also have a third button which is branded or has a special symbol
and meaning. Such buttons are mapped as BTN_MODE. Examples are the Nintendo
- "HOME" button, the XBox "X"-button or Sony "P" button.
+ "HOME" button, the XBox "X"-button or Sony "PS" button.
Rumble:
- Rumble is adverticed as FF_RUMBLE.
+ Rumble is advertised as FF_RUMBLE.
----------------------------------------------------------------------------
Written 2013 by David Herrmann <dh.herrmann@gmail.com>
diff --git a/Documentation/input/joystick-api.txt b/Documentation/input/joystick-api.txt
index c507330740cd..943b18eac918 100644
--- a/Documentation/input/joystick-api.txt
+++ b/Documentation/input/joystick-api.txt
@@ -16,14 +16,14 @@ joystick.
By default, the device is opened in blocking mode.
- int fd = open ("/dev/js0", O_RDONLY);
+ int fd = open ("/dev/input/js0", O_RDONLY);
2. Event Reading
~~~~~~~~~~~~~~~~
struct js_event e;
- read (fd, &e, sizeof(struct js_event));
+ read (fd, &e, sizeof(e));
where js_event is defined as
@@ -34,8 +34,8 @@ where js_event is defined as
__u8 number; /* axis/button number */
};
-If the read is successful, it will return sizeof(struct js_event), unless
-you wanted to read more than one event per read as described in section 3.1.
+If the read is successful, it will return sizeof(e), unless you wanted to read
+more than one event per read as described in section 3.1.
2.1 js_event.type
@@ -99,9 +99,9 @@ may work well if you handle JS_EVENT_INIT events separately,
if ((js_event.type & ~JS_EVENT_INIT) == JS_EVENT_BUTTON) {
if (js_event.value)
- buttons_state |= (1 << js_event.number);
- else
- buttons_state &= ~(1 << js_event.number);
+ buttons_state |= (1 << js_event.number);
+ else
+ buttons_state &= ~(1 << js_event.number);
}
is much safer since it can't lose sync with the driver. As you would
@@ -144,14 +144,14 @@ all events on the queue (that is, until you get a -1).
For example,
while (1) {
- while (read (fd, &e, sizeof(struct js_event)) > 0) {
- process_event (e);
- }
- /* EAGAIN is returned when the queue is empty */
- if (errno != EAGAIN) {
- /* error */
- }
- /* do something interesting with processed events */
+ while (read (fd, &e, sizeof(e)) > 0) {
+ process_event (e);
+ }
+ /* EAGAIN is returned when the queue is empty */
+ if (errno != EAGAIN) {
+ /* error */
+ }
+ /* do something interesting with processed events */
}
One reason for emptying the queue is that if it gets full you'll start
@@ -181,7 +181,7 @@ at a time using the typical read(2) functionality. For that, you would
replace the read above with something like
struct js_event mybuffer[0xff];
- int i = read (fd, mybuffer, sizeof(struct mybuffer));
+ int i = read (fd, mybuffer, sizeof(mybuffer));
In this case, read would return -1 if the queue was empty, or some
other value in which the number of events read would be i /
@@ -269,9 +269,9 @@ The driver offers backward compatibility, though. Here's a quick summary:
struct JS_DATA_TYPE js;
while (1) {
if (read (fd, &js, JS_RETURN) != JS_RETURN) {
- /* error */
- }
- usleep (1000);
+ /* error */
+ }
+ usleep (1000);
}
As you can figure out from the example, the read returns immediately,
diff --git a/Documentation/input/joystick.txt b/Documentation/input/joystick.txt
index 304262bb661a..8d027dc86c1f 100644
--- a/Documentation/input/joystick.txt
+++ b/Documentation/input/joystick.txt
@@ -116,7 +116,7 @@ your needs:
For testing the joystick driver functionality, there is the jstest
program in the utilities package. You run it by typing:
- jstest /dev/js0
+ jstest /dev/input/js0
And it should show a line with the joystick values, which update as you
move the stick, and press its buttons. The axes should all be zero when the
@@ -136,7 +136,7 @@ joystick should be autocalibrated by the driver automagically. However, with
some analog joysticks, that either do not use linear resistors, or if you
want better precision, you can use the jscal program
- jscal -c /dev/js0
+ jscal -c /dev/input/js0
included in the joystick package to set better correction coefficients than
what the driver would choose itself.
@@ -145,7 +145,7 @@ what the driver would choose itself.
calibration using the jstest command, and if you do, you then can save the
correction coefficients into a file
- jscal -p /dev/js0 > /etc/joystick.cal
+ jscal -p /dev/input/js0 > /etc/joystick.cal
And add a line to your rc script executing that file
@@ -556,7 +556,7 @@ interface, and "old" for the "0.x" interface. You run it by typing:
5. FAQ
~~~~~~
-Q: Running 'jstest /dev/js0' results in "File not found" error. What's the
+Q: Running 'jstest /dev/input/js0' results in "File not found" error. What's the
cause?
A: The device files don't exist. Create them (see section 2.2).

Privacy Policy