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
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: (64 commits) Input: tc3589x-keypad - add missing kerneldoc Input: ucb1400-ts - switch to using dev_xxx() for diagnostic messages Input: ucb1400_ts - convert to threaded IRQ Input: ucb1400_ts - drop inline annotations Input: usb1400_ts - add __devinit/__devexit section annotations Input: ucb1400_ts - set driver owner Input: ucb1400_ts - convert to use dev_pm_ops Input: psmouse - make sure we do not use stale methods Input: evdev - do not block waiting for an event if fd is nonblock Input: evdev - if no events and non-block, return EAGAIN not 0 Input: evdev - only allow reading events if a full packet is present Input: add driver for pixcir i2c touchscreens Input: samsung-keypad - implement runtime power management support Input: tegra-kbc - report wakeup key for some platforms Input: tegra-kbc - add device tree bindings Input: add driver for AUO In-Cell touchscreens using pixcir ICs Input: mpu3050 - configure the sampling method Input: mpu3050 - ensure we enable interrupts Input: mpu3050 - add of_match table for device-tree probing Input: sentelic - document the latest hardware ... Fix up fairly trivial conflicts (device tree matching conflicting with some independent cleanups) in drivers/input/keyboard/samsung-keypad.c
This commit is contained in:
Linus Torvalds
@@ -15,9 +15,9 @@ Contact: linux-input@vger.kernel.org
|
||||
Description:
|
||||
Attribute group for control of the status LEDs and the OLEDs.
|
||||
This attribute group is only available for Intuos 4 M, L,
|
||||
and XL (with LEDs and OLEDs) and Cintiq 21UX2 (LEDs only).
|
||||
Therefore its presence implicitly signifies the presence of
|
||||
said LEDs and OLEDs on the tablet device.
|
||||
and XL (with LEDs and OLEDs) and Cintiq 21UX2 and Cintiq 24HD
|
||||
(LEDs only). Therefore its presence implicitly signifies the
|
||||
presence of said LEDs and OLEDs on the tablet device.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status0_luminance
|
||||
Date: August 2011
|
||||
@@ -41,16 +41,17 @@ Date: August 2011
|
||||
Contact: linux-input@vger.kernel.org
|
||||
Description:
|
||||
Writing to this file sets which one of the four (for Intuos 4)
|
||||
or of the right four (for Cintiq 21UX2) status LEDs is active (0..3).
|
||||
The other three LEDs on the same side are always inactive.
|
||||
or of the right four (for Cintiq 21UX2 and Cintiq 24HD) status
|
||||
LEDs is active (0..3). The other three LEDs on the same side are
|
||||
always inactive.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status_led1_select
|
||||
Date: September 2011
|
||||
Contact: linux-input@vger.kernel.org
|
||||
Description:
|
||||
Writing to this file sets which one of the left four (for Cintiq 21UX2)
|
||||
status LEDs is active (0..3). The other three LEDs on the left are always
|
||||
inactive.
|
||||
Writing to this file sets which one of the left four (for Cintiq 21UX2
|
||||
and Cintiq 24HD) status LEDs is active (0..3). The other three LEDs on
|
||||
the left are always inactive.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/buttons_luminance
|
||||
Date: August 2011
|
||||
|
||||
@@ -0,0 +1,18 @@
|
||||
* Tegra keyboard controller
|
||||
|
||||
Required properties:
|
||||
- compatible: "nvidia,tegra20-kbc"
|
||||
|
||||
Optional properties:
|
||||
- debounce-delay: delay in milliseconds per row scan for debouncing
|
||||
- repeat-delay: delay in milliseconds before repeat starts
|
||||
- ghost-filter: enable ghost filtering for this device
|
||||
- wakeup-source: configure keyboard as a wakeup source for suspend/resume
|
||||
|
||||
Example:
|
||||
|
||||
keyboard: keyboard {
|
||||
compatible = "nvidia,tegra20-kbc";
|
||||
reg = <0x7000e200 0x100>;
|
||||
ghost-filter;
|
||||
};
|
||||
@@ -0,0 +1,188 @@
|
||||
ALPS Touchpad Protocol
|
||||
----------------------
|
||||
|
||||
Introduction
|
||||
------------
|
||||
|
||||
Currently the ALPS touchpad driver supports four protocol versions in use by
|
||||
ALPS touchpads, called versions 1, 2, 3, and 4. Information about the various
|
||||
protocol versions is contained in the following sections.
|
||||
|
||||
Detection
|
||||
---------
|
||||
|
||||
All ALPS touchpads should respond to the "E6 report" command sequence:
|
||||
E8-E6-E6-E6-E9. An ALPS touchpad should respond with either 00-00-0A or
|
||||
00-00-64.
|
||||
|
||||
If the E6 report is successful, the touchpad model is identified using the "E7
|
||||
report" sequence: E8-E7-E7-E7-E9. The response is the model signature and is
|
||||
matched against known models in the alps_model_data_array.
|
||||
|
||||
With protocol versions 3 and 4, the E7 report model signature is always
|
||||
73-02-64. To differentiate between these versions, the response from the
|
||||
"Enter Command Mode" sequence must be inspected as described below.
|
||||
|
||||
Command Mode
|
||||
------------
|
||||
|
||||
Protocol versions 3 and 4 have a command mode that is used to read and write
|
||||
one-byte device registers in a 16-bit address space. The command sequence
|
||||
EC-EC-EC-E9 places the device in command mode, and the device will respond
|
||||
with 88-07 followed by a third byte. This third byte can be used to determine
|
||||
whether the devices uses the version 3 or 4 protocol.
|
||||
|
||||
To exit command mode, PSMOUSE_CMD_SETSTREAM (EA) is sent to the touchpad.
|
||||
|
||||
While in command mode, register addresses can be set by first sending a
|
||||
specific command, either EC for v3 devices or F5 for v4 devices. Then the
|
||||
address is sent one nibble at a time, where each nibble is encoded as a
|
||||
command with optional data. This enoding differs slightly between the v3 and
|
||||
v4 protocols.
|
||||
|
||||
Once an address has been set, the addressed register can be read by sending
|
||||
PSMOUSE_CMD_GETINFO (E9). The first two bytes of the response contains the
|
||||
address of the register being read, and the third contains the value of the
|
||||
register. Registers are written by writing the value one nibble at a time
|
||||
using the same encoding used for addresses.
|
||||
|
||||
Packet Format
|
||||
-------------
|
||||
|
||||
In the following tables, the following notation is used.
|
||||
|
||||
CAPITALS = stick, miniscules = touchpad
|
||||
|
||||
?'s can have different meanings on different models, such as wheel rotation,
|
||||
extra buttons, stick buttons on a dualpoint, etc.
|
||||
|
||||
PS/2 packet format
|
||||
------------------
|
||||
|
||||
byte 0: 0 0 YSGN XSGN 1 M R L
|
||||
byte 1: X7 X6 X5 X4 X3 X2 X1 X0
|
||||
byte 2: Y7 Y6 Y5 Y4 Y3 Y2 Y1 Y0
|
||||
|
||||
Note that the device never signals overflow condition.
|
||||
|
||||
ALPS Absolute Mode - Protocol Verion 1
|
||||
--------------------------------------
|
||||
|
||||
byte 0: 1 0 0 0 1 x9 x8 x7
|
||||
byte 1: 0 x6 x5 x4 x3 x2 x1 x0
|
||||
byte 2: 0 ? ? l r ? fin ges
|
||||
byte 3: 0 ? ? ? ? y9 y8 y7
|
||||
byte 4: 0 y6 y5 y4 y3 y2 y1 y0
|
||||
byte 5: 0 z6 z5 z4 z3 z2 z1 z0
|
||||
|
||||
ALPS Absolute Mode - Protocol Version 2
|
||||
---------------------------------------
|
||||
|
||||
byte 0: 1 ? ? ? 1 ? ? ?
|
||||
byte 1: 0 x6 x5 x4 x3 x2 x1 x0
|
||||
byte 2: 0 x10 x9 x8 x7 ? fin ges
|
||||
byte 3: 0 y9 y8 y7 1 M R L
|
||||
byte 4: 0 y6 y5 y4 y3 y2 y1 y0
|
||||
byte 5: 0 z6 z5 z4 z3 z2 z1 z0
|
||||
|
||||
Dualpoint device -- interleaved packet format
|
||||
---------------------------------------------
|
||||
|
||||
byte 0: 1 1 0 0 1 1 1 1
|
||||
byte 1: 0 x6 x5 x4 x3 x2 x1 x0
|
||||
byte 2: 0 x10 x9 x8 x7 0 fin ges
|
||||
byte 3: 0 0 YSGN XSGN 1 1 1 1
|
||||
byte 4: X7 X6 X5 X4 X3 X2 X1 X0
|
||||
byte 5: Y7 Y6 Y5 Y4 Y3 Y2 Y1 Y0
|
||||
byte 6: 0 y9 y8 y7 1 m r l
|
||||
byte 7: 0 y6 y5 y4 y3 y2 y1 y0
|
||||
byte 8: 0 z6 z5 z4 z3 z2 z1 z0
|
||||
|
||||
ALPS Absolute Mode - Protocol Version 3
|
||||
---------------------------------------
|
||||
|
||||
ALPS protocol version 3 has three different packet formats. The first two are
|
||||
associated with touchpad events, and the third is associatd with trackstick
|
||||
events.
|
||||
|
||||
The first type is the touchpad position packet.
|
||||
|
||||
byte 0: 1 ? x1 x0 1 1 1 1
|
||||
byte 1: 0 x10 x9 x8 x7 x6 x5 x4
|
||||
byte 2: 0 y10 y9 y8 y7 y6 y5 y4
|
||||
byte 3: 0 M R L 1 m r l
|
||||
byte 4: 0 mt x3 x2 y3 y2 y1 y0
|
||||
byte 5: 0 z6 z5 z4 z3 z2 z1 z0
|
||||
|
||||
Note that for some devices the trackstick buttons are reported in this packet,
|
||||
and on others it is reported in the trackstick packets.
|
||||
|
||||
The second packet type contains bitmaps representing the x and y axes. In the
|
||||
bitmaps a given bit is set if there is a finger covering that position on the
|
||||
given axis. Thus the bitmap packet can be used for low-resolution multi-touch
|
||||
data, although finger tracking is not possible. This packet also encodes the
|
||||
number of contacts (f1 and f0 in the table below).
|
||||
|
||||
byte 0: 1 1 x1 x0 1 1 1 1
|
||||
byte 1: 0 x8 x7 x6 x5 x4 x3 x2
|
||||
byte 2: 0 y7 y6 y5 y4 y3 y2 y1
|
||||
byte 3: 0 y10 y9 y8 1 1 1 1
|
||||
byte 4: 0 x14 x13 x12 x11 x10 x9 y0
|
||||
byte 5: 0 1 ? ? ? ? f1 f0
|
||||
|
||||
This packet only appears after a position packet with the mt bit set, and
|
||||
ususally only appears when there are two or more contacts (although
|
||||
ocassionally it's seen with only a single contact).
|
||||
|
||||
The final v3 packet type is the trackstick packet.
|
||||
|
||||
byte 0: 1 1 x7 y7 1 1 1 1
|
||||
byte 1: 0 x6 x5 x4 x3 x2 x1 x0
|
||||
byte 2: 0 y6 y5 y4 y3 y2 y1 y0
|
||||
byte 3: 0 1 0 0 1 0 0 0
|
||||
byte 4: 0 z4 z3 z2 z1 z0 ? ?
|
||||
byte 5: 0 0 1 1 1 1 1 1
|
||||
|
||||
ALPS Absolute Mode - Protocol Version 4
|
||||
---------------------------------------
|
||||
|
||||
Protocol version 4 has an 8-byte packet format.
|
||||
|
||||
byte 0: 1 ? x1 x0 1 1 1 1
|
||||
byte 1: 0 x10 x9 x8 x7 x6 x5 x4
|
||||
byte 2: 0 y10 y9 y8 y7 y6 y5 y4
|
||||
byte 3: 0 1 x3 x2 y3 y2 y1 y0
|
||||
byte 4: 0 ? ? ? 1 ? r l
|
||||
byte 5: 0 z6 z5 z4 z3 z2 z1 z0
|
||||
byte 6: bitmap data (described below)
|
||||
byte 7: bitmap data (described below)
|
||||
|
||||
The last two bytes represent a partial bitmap packet, with 3 full packets
|
||||
required to construct a complete bitmap packet. Once assembled, the 6-byte
|
||||
bitmap packet has the following format:
|
||||
|
||||
byte 0: 0 1 x7 x6 x5 x4 x3 x2
|
||||
byte 1: 0 x1 x0 y4 y3 y2 y1 y0
|
||||
byte 2: 0 0 ? x14 x13 x12 x11 x10
|
||||
byte 3: 0 x9 x8 y9 y8 y7 y6 y5
|
||||
byte 4: 0 0 0 0 0 0 0 0
|
||||
byte 5: 0 0 0 0 0 0 0 y10
|
||||
|
||||
There are several things worth noting here.
|
||||
|
||||
1) In the bitmap data, bit 6 of byte 0 serves as a sync byte to
|
||||
identify the first fragment of a bitmap packet.
|
||||
|
||||
2) The bitmaps represent the same data as in the v3 bitmap packets, although
|
||||
the packet layout is different.
|
||||
|
||||
3) There doesn't seem to be a count of the contact points anywhere in the v4
|
||||
protocol packets. Deriving a count of contact points must be done by
|
||||
analyzing the bitmaps.
|
||||
|
||||
4) There is a 3 to 1 ratio of position packets to bitmap packets. Therefore
|
||||
MT position can only be updated for every third ST position update, and
|
||||
the count of contact points can only be updated every third packet as
|
||||
well.
|
||||
|
||||
So far no v4 devices with tracksticks have been encountered.
|
||||
@@ -0,0 +1,103 @@
|
||||
Driver for tilt-switches connected via GPIOs
|
||||
============================================
|
||||
|
||||
Generic driver to read data from tilt switches connected via gpios.
|
||||
Orientation can be provided by one or more than one tilt switches,
|
||||
i.e. each tilt switch providing one axis, and the number of axes
|
||||
is also not limited.
|
||||
|
||||
|
||||
Data structures:
|
||||
----------------
|
||||
|
||||
The array of struct gpio in the gpios field is used to list the gpios
|
||||
that represent the current tilt state.
|
||||
|
||||
The array of struct gpio_tilt_axis describes the axes that are reported
|
||||
to the input system. The values set therein are used for the
|
||||
input_set_abs_params calls needed to init the axes.
|
||||
|
||||
The array of struct gpio_tilt_state maps gpio states to the corresponding
|
||||
values to report. The gpio state is represented as a bitfield where the
|
||||
bit-index corresponds to the index of the gpio in the struct gpio array.
|
||||
In the same manner the values stored in the axes array correspond to
|
||||
the elements of the gpio_tilt_axis-array.
|
||||
|
||||
|
||||
Example:
|
||||
--------
|
||||
|
||||
Example configuration for a single TS1003 tilt switch that rotates around
|
||||
one axis in 4 steps and emitts the current tilt via two GPIOs.
|
||||
|
||||
static int sg060_tilt_enable(struct device *dev) {
|
||||
/* code to enable the sensors */
|
||||
};
|
||||
|
||||
static void sg060_tilt_disable(struct device *dev) {
|
||||
/* code to disable the sensors */
|
||||
};
|
||||
|
||||
static struct gpio sg060_tilt_gpios[] = {
|
||||
{ SG060_TILT_GPIO_SENSOR1, GPIOF_IN, "tilt_sensor1" },
|
||||
{ SG060_TILT_GPIO_SENSOR2, GPIOF_IN, "tilt_sensor2" },
|
||||
};
|
||||
|
||||
static struct gpio_tilt_state sg060_tilt_states[] = {
|
||||
{
|
||||
.gpios = (0 << 1) | (0 << 0),
|
||||
.axes = (int[]) {
|
||||
0,
|
||||
},
|
||||
}, {
|
||||
.gpios = (0 << 1) | (1 << 0),
|
||||
.axes = (int[]) {
|
||||
1, /* 90 degrees */
|
||||
},
|
||||
}, {
|
||||
.gpios = (1 << 1) | (1 << 0),
|
||||
.axes = (int[]) {
|
||||
2, /* 180 degrees */
|
||||
},
|
||||
}, {
|
||||
.gpios = (1 << 1) | (0 << 0),
|
||||
.axes = (int[]) {
|
||||
3, /* 270 degrees */
|
||||
},
|
||||
},
|
||||
};
|
||||
|
||||
static struct gpio_tilt_axis sg060_tilt_axes[] = {
|
||||
{
|
||||
.axis = ABS_RY,
|
||||
.min = 0,
|
||||
.max = 3,
|
||||
.fuzz = 0,
|
||||
.flat = 0,
|
||||
},
|
||||
};
|
||||
|
||||
static struct gpio_tilt_platform_data sg060_tilt_pdata= {
|
||||
.gpios = sg060_tilt_gpios,
|
||||
.nr_gpios = ARRAY_SIZE(sg060_tilt_gpios),
|
||||
|
||||
.axes = sg060_tilt_axes,
|
||||
.nr_axes = ARRAY_SIZE(sg060_tilt_axes),
|
||||
|
||||
.states = sg060_tilt_states,
|
||||
.nr_states = ARRAY_SIZE(sg060_tilt_states),
|
||||
|
||||
.debounce_interval = 100,
|
||||
|
||||
.poll_interval = 1000,
|
||||
.enable = sg060_tilt_enable,
|
||||
.disable = sg060_tilt_disable,
|
||||
};
|
||||
|
||||
static struct platform_device sg060_device_tilt = {
|
||||
.name = "gpio-tilt-polled",
|
||||
.id = -1,
|
||||
.dev = {
|
||||
.platform_data = &sg060_tilt_pdata,
|
||||
},
|
||||
};
|
||||
File diff suppressed because it is too large
Load Diff
Reference in New Issue
Block a user