You've already forked linux-apfs
mirror of
https://github.com/linux-apfs/linux-apfs.git
synced 2026-05-01 15:00:59 -07:00
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 ...
This commit is contained in:
Linus Torvalds
@@ -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>;
|
||||
};
|
||||
@@ -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>;
|
||||
};
|
||||
|
||||
/* ... */
|
||||
};
|
||||
@@ -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>;
|
||||
};
|
||||
@@ -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>;
|
||||
};
|
||||
};
|
||||
@@ -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>
|
||||
|
||||
@@ -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,
|
||||
|
||||
@@ -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).
|
||||
|
||||
|
||||
Reference in New Issue
Block a user