summaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
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 0000000..a5086e3
--- /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 0000000..ec365e1
--- /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 0000000..e4be2f7
--- /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 0000000..c864a46
--- /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 31bb6a4..3f6d8a5 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 c507330..943b18e 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 304262b..8d027dc 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).
OpenPOWER on IntegriCloud