nhu/kernel_a52xq
Watch
1
Fork
You've already forked kernel_a52xq
 0
mirror of https://github.com/a52xq-dev/kernel.git synced 2026-10-18 21:58:11 +07:00
Code Issues Projects Releases Wiki Activity

Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input

Browse source 
Pull input subsystem updates from Dmitry Torokhov:

 - a big update from Mauro converting input documentation to ReST format

 - Synaptics PS/2 is now aware of SMBus companion devices, which means
   that we can now use native RMI4 protocol to handle touchpads, instead
   of relying on legacy PS/2 mode.

 - we removed support from BMA180 accelerometer from input devices as it
   is now handled properly by IIO

 - update to TSC2007 to corretcly report pressure

 - other miscellaneous driver fixes.

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: (152 commits)
  Input: ar1021_i2c - use BIT to check for a bit
  Input: twl4030-pwrbutton - use input_set_capability() helper
  Input: twl4030-pwrbutton - use correct device for irq request
  Input: ar1021_i2c - enable touch mode during open
  Input: add uinput documentation
  dt-bindings: input: add bindings document for ar1021_i2c driver
  dt-bindings: input: rotary-encoder: fix typo
  Input: xen-kbdfront - add module parameter for setting resolution
  ARM: pxa/raumfeld: fix compile error in rotary controller resources
  Input: xpad - do not suggest writing to Dominic
  Input: xpad - don't use literal blocks inside footnotes
  Input: xpad - note that usb/devices is now at /sys/kernel/debug/
  Input: docs - freshen up introduction
  Input: docs - split input docs into kernel- and user-facing
  Input: docs - note that MT-A protocol is obsolete
  Input: docs - update joystick documentation a bit
  Input: docs - remove disclaimer/GPL notice
  Input: fix "Game console" heading level in joystick documentation
  Input: rotary-encoder - remove references to platform data from docs
  Input: move documentation for Amiga CD32
  ...
This commit is contained in:
Linus Torvalds 2017-05-03 12:38:20 -07:00
commit 16a12fa9ae
129 changed files with 7608 additions and 5390 deletions
Download patch file Download diff file Expand all files Collapse all files

2
Documentation/conf.py
View file

@ -348,6 +348,8 @@ latex_documents = [
'The kernel development community', 'manual'),
('driver-api/index', 'driver-api.tex', 'The kernel driver API manual',
'The kernel development community', 'manual'),
('input/index', 'linux-input.tex', 'The Linux input driver subsystem',
'The kernel development community', 'manual'),
('kernel-documentation', 'kernel-documentation.tex', 'The Linux Kernel Documentation',
'The kernel development community', 'manual'),
('process/index', 'development-process.tex', 'Linux Kernel Development Documentation',

2
Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt
View file

@ -24,6 +24,8 @@ Optional Properties:
- debounce-delay-ms: debounce interval in milliseconds
- col-scan-delay-us: delay, measured in microseconds, that is needed
before we can scan keypad after activating column gpio
- drive-inactive-cols: drive inactive columns during scan,
default is to turn inactive columns into inputs.
Example:
matrix-keypad {

1
Documentation/devicetree/bindings/input/pwm-beeper.txt
View file

@ -8,6 +8,7 @@ Required properties:
Optional properties:
- amp-supply: phandle to a regulator that acts as an amplifier for the beeper
- beeper-hz: bell frequency in Hz
Example:

1
Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.txt
View file

@ -7,6 +7,7 @@ PROPERTIES
Value type: <string>
Definition: must be one of:
"qcom,pm8058-vib"
"qcom,pm8916-vib"
"qcom,pm8921-vib"
- reg:

2
Documentation/devicetree/bindings/input/rotary-encoder.txt
View file

@ -12,7 +12,7 @@ Optional properties:
- rotary-encoder,relative-axis: register a relative axis rather than an
absolute one. Relative axis will only generate +1/-1 events on the input
device, hence no steps need to be passed.
- rotary-encoder,rollover: Automatic rollove when the rotary value becomes
- rotary-encoder,rollover: Automatic rollover when the rotary value becomes
greater than the specified steps or smaller than 0. For absolute axis only.
- rotary-encoder,steps-per-period: Number of steps (stable states) per period.
The values have the following meaning:

19
Documentation/devicetree/bindings/input/touchscreen/ad7879.txt
View file

@ -35,6 +35,7 @@ Optional properties:
- adi,conversion-interval: : 0 : convert one time only
1-255: 515us + val * 35us (up to 9.440ms)
This property has to be a '/bits/ 8' value
- gpio-controller : Switch AUX/VBAT/GPIO pin to GPIO mode
Example:
@ -51,3 +52,21 @@ Example:
adi,averaging = /bits/ 8 <1>;
adi,conversion-interval = /bits/ 8 <255>;
};
ad7879@1 {
compatible = "adi,ad7879";
spi-max-frequency = <5000000>;
reg = <1>;
spi-cpol;
spi-cpha;
gpio-controller;
interrupt-parent = <&gpio1>;
interrupts = <13 IRQ_TYPE_EDGE_FALLING>;
touchscreen-max-pressure = <4096>;
adi,resistance-plate-x = <120>;
adi,first-conversion-delay = /bits/ 8 <3>;
adi,acquisition-time = /bits/ 8 <1>;
adi,median-filter-size = /bits/ 8 <2>;
adi,averaging = /bits/ 8 <1>;
adi,conversion-interval = /bits/ 8 <255>;
};

94
Documentation/devicetree/bindings/input/touchscreen/ads7846.txt Normal file
View file

@ -0,0 +1,94 @@
Device tree bindings for TI's ADS7843, ADS7845, ADS7846, ADS7873, TSC2046
SPI driven touch screen controllers.
The node for this driver must be a child node of a SPI controller, hence
all mandatory properties described in
Documentation/devicetree/bindings/spi/spi-bus.txt
must be specified.
Additional required properties:
compatible Must be one of the following, depending on the
model:
"ti,tsc2046"
"ti,ads7843"
"ti,ads7845"
"ti,ads7846"
"ti,ads7873"
interrupt-parent
interrupts An interrupt node describing the IRQ line the chip's
!PENIRQ pin is connected to.
vcc-supply A regulator node for the supply voltage.
Optional properties:
ti,vref-delay-usecs vref supply delay in usecs, 0 for
external vref (u16).
ti,vref-mv The VREF voltage, in millivolts (u16).
Set to 0 to use internal references
(ADS7846).
ti,keep-vref-on set to keep vref on for differential
measurements as well
ti,swap-xy swap x and y axis
ti,settle-delay-usec Settling time of the analog signals;
a function of Vcc and the capacitance
on the X/Y drivers. If set to non-zero,
two samples are taken with settle_delay
us apart, and the second one is used.
~150 uSec with 0.01uF caps (u16).
ti,penirq-recheck-delay-usecs If set to non-zero, after samples are
taken this delay is applied and penirq
is rechecked, to help avoid false
events. This value is affected by the
material used to build the touch layer
(u16).
ti,x-plate-ohms Resistance of the X-plate,
in Ohms (u16).
ti,y-plate-ohms Resistance of the Y-plate,
in Ohms (u16).
ti,x-min Minimum value on the X axis (u16).
ti,y-min Minimum value on the Y axis (u16).
ti,x-max Maximum value on the X axis (u16).
ti,y-max Minimum value on the Y axis (u16).
ti,pressure-min Minimum reported pressure value
(threshold) - u16.
ti,pressure-max Maximum reported pressure value (u16).
ti,debounce-max Max number of additional readings per
sample (u16).
ti,debounce-tol Tolerance used for filtering (u16).
ti,debounce-rep Additional consecutive good readings
required after the first two (u16).
ti,pendown-gpio-debounce Platform specific debounce time for the
pendown-gpio (u32).
pendown-gpio GPIO handle describing the pin the !PENIRQ
line is connected to.
wakeup-source use any event on touchscreen as wakeup event.
(Legacy property support: "linux,wakeup")
Example for a TSC2046 chip connected to an McSPI controller of an OMAP SoC::
spi_controller {
tsc2046@0 {
reg = <0>; /* CS0 */
compatible = "ti,tsc2046";
interrupt-parent = <&gpio1>;
interrupts = <8 0>; /* BOOT6 / GPIO 8 */
spi-max-frequency = <1000000>;
pendown-gpio = <&gpio1 8 0>;
vcc-supply = <&reg_vcc3>;
ti,x-min = /bits/ 16 <0>;
ti,x-max = /bits/ 16 <8000>;
ti,y-min = /bits/ 16 <0>;
ti,y-max = /bits/ 16 <4800>;
ti,x-plate-ohms = /bits/ 16 <40>;
ti,pressure-max = /bits/ 16 <255>;
wakeup-source;
};
};

16
Documentation/devicetree/bindings/input/touchscreen/ar1021.txt Normal file
View file

@ -0,0 +1,16 @@
* Microchip AR1020 and AR1021 touchscreen interface (I2C)
Required properties:
- compatible : "microchip,ar1021-i2c"
- reg : I2C slave address
- interrupt-parent : the phandle for the interrupt controller
- interrupts : touch controller interrupt
Example:
touchscreen@4d {
compatible = "microchip,ar1021-i2c";
reg = <0x4d>;
interrupt-parent = <&gpio3>;
interrupts = <11 IRQ_TYPE_LEVEL_HIGH>;
};

18
Documentation/devicetree/bindings/input/touchscreen/max11801-ts.txt Normal file
View file

@ -0,0 +1,18 @@
* MAXI MAX11801 Resistive touch screen controller with i2c interface
Required properties:
- compatible: must be "maxim,max11801"
- reg: i2c slave address
- interrupt-parent: the phandle for the interrupt controller
- interrupts: touch controller interrupt
Example:
&i2c1 {
max11801: touchscreen@48 {
compatible = "maxim,max11801";
reg = <0x48>;
interrupt-parent = <&gpio3>;
interrupts = <31 IRQ_TYPE_EDGE_FALLING>;
};
};

7
Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt
View file

@ -1,7 +1,12 @@
* GSL 1680 touchscreen controller
Required properties:
- compatible : "silead,gsl1680"
- compatible : Must be one of the following, depending on the model:
"silead,gsl1680"
"silead,gsl1688"
"silead,gsl3670"
"silead,gsl3675"
"silead,gsl3692"
- reg : I2C slave address of the chip (0x40)
- interrupt-parent : a phandle pointing to the interrupt controller
serving the interrupt for this chip

19
Documentation/input/cd32.txt
View file

@ -1,19 +0,0 @@
I have written a small patch that let's me use my Amiga CD32
joypad connected to the parallel port. Thought I'd share it with you so
you can add it to the list of supported joysticks (hopefully someone will
find it useful).
It needs the following wiring:
CD32 pad | Parallel port
----------------------------
1 (Up) | 2 (D0)
2 (Down) | 3 (D1)
3 (Left) | 4 (D2)
4 (Right) | 5 (D3)
5 (Fire3) | 14 (AUTOFD)
6 (Fire1) | 17 (SELIN)
7 (+5V) | 1 (STROBE)
8 (Gnd) | 18 (Gnd)
9 (Fire2) | 7 (D5)

10
Documentation/input/conf.py Normal file
View file

@ -0,0 +1,10 @@
# -*- coding: utf-8; mode: python -*-
project = "The Linux input driver subsystem"
tags.add("subproject")
latex_documents = [
('index', 'linux-input.tex', project,
'The kernel development community', 'manual'),
]

387
Documentation/input/devices/alps.rst Normal file
View file

@ -0,0 +1,387 @@
----------------------
ALPS Touchpad Protocol
----------------------
Introduction
------------
Currently the ALPS touchpad driver supports seven protocol versions in use by
ALPS touchpads, called versions 1, 2, 3, 4, 5, 6, 7 and 8.
Since roughly mid-2010 several new ALPS touchpads have been released and
integrated into a variety of laptops and netbooks. These new touchpads
have enough behavior differences that the alps_model_data definition
table, describing the properties of the different versions, is no longer
adequate. The design choices were to re-define the alps_model_data
table, with the risk of regression testing existing devices, or isolate
the new devices outside of the alps_model_data table. The latter design
choice was made. The new touchpad signatures are named: "Rushmore",
"Pinnacle", and "Dolphin", which you will see in the alps.c code.
For the purposes of this document, this group of ALPS touchpads will
generically be called "new ALPS touchpads".
We experimented with probing the ACPI interface _HID (Hardware ID)/_CID
(Compatibility ID) definition as a way to uniquely identify the
different ALPS variants but there did not appear to be a 1:1 mapping.
In fact, it appeared to be an m:n mapping between the _HID and actual
hardware type.
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 no buttons are pressed. The bits 0-2 of the first byte will be 1s
if some buttons are pressed.
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.
For older touchpads supporting 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.
The new ALPS touchpads have an E7 signature of 73-03-50 or 73-03-0A but
seem to be better differentiated by the EC Command Mode response.
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 encoding 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.
For the new ALPS touchpads, the EC command is used to enter command
mode. The response in the new ALPS touchpads is significantly different,
and more important in determining the behavior. This code has been
separated from the original alps_model_data table and put in the
alps_identify function. For example, there seem to be two hardware init
sequences for the "Dolphin" touchpads as determined by the second byte
of the EC response.
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.
For protocol version 2 devices when the trackpoint is used, and no fingers
are on the touchpad, the M R L bits signal the combined status of both the
pointingstick and touchpad buttons.
ALPS Absolute Mode - Protocol Version 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 PSM PSR PSL
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
Protocol Version 2 DualPoint devices send standard PS/2 mouse packets for
the DualPoint Stick. The M, R and L bits signal the combined status of both
the pointingstick and touchpad buttons, except for Dell dualpoint devices
where the pointingstick buttons get reported separately in the PSM, PSR
and PSL bits.
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
Devices which use the interleaving format normally send standard PS/2 mouse
packets for the DualPoint Stick + ALPS Absolute Mode packets for the
touchpad, switching to the interleaved packet format when both the stick and
the touchpad are used at the same time.
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 associated 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
usually only appears when there are two or more contacts (although
occasionally 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.
ALPS Absolute Mode - Protocol Version 5
---------------------------------------
This is basically Protocol Version 3 but with different logic for packet
decode. It uses the same alps_process_touchpad_packet_v3 call with a
specialized decode_fields function pointer to correctly interpret the
packets. This appears to only be used by the Dolphin devices.
For single-touch, the 6-byte packet format is::
byte 0: 1 1 0 0 1 0 0 0
byte 1: 0 x6 x5 x4 x3 x2 x1 x0
byte 2: 0 y6 y5 y4 y3 y2 y1 y0
byte 3: 0 M R L 1 m r l
byte 4: y10 y9 y8 y7 x10 x9 x8 x7
byte 5: 0 z6 z5 z4 z3 z2 z1 z0
For mt, the format is::
byte 0: 1 1 1 n3 1 n2 n1 x24
byte 1: 1 y7 y6 y5 y4 y3 y2 y1
byte 2: ? x2 x1 y12 y11 y10 y9 y8
byte 3: 0 x23 x22 x21 x20 x19 x18 x17
byte 4: 0 x9 x8 x7 x6 x5 x4 x3
byte 5: 0 x16 x15 x14 x13 x12 x11 x10
ALPS Absolute Mode - Protocol Version 6
---------------------------------------
For trackstick packet, the format is::
byte 0: 1 1 1 1 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: ? Y7 X7 ? ? M R L
byte 4: Z7 Z6 Z5 Z4 Z3 Z2 Z1 Z0
byte 5: 0 1 1 1 1 1 1 1
For touchpad packet, the format is::
byte 0: 1 1 1 1 1 1 1 1
byte 1: 0 0 0 0 x3 x2 x1 x0
byte 2: 0 0 0 0 y3 y2 y1 y0
byte 3: ? x7 x6 x5 x4 ? r l
byte 4: ? y7 y6 y5 y4 ? ? ?
byte 5: z7 z6 z5 z4 z3 z2 z1 z0
(v6 touchpad does not have middle button)
ALPS Absolute Mode - Protocol Version 7
---------------------------------------
For trackstick packet, the format is::
byte 0: 0 1 0 0 1 0 0 0
byte 1: 1 1 * * 1 M R L
byte 2: X7 1 X5 X4 X3 X2 X1 X0
byte 3: Z6 1 Y6 X6 1 Y2 Y1 Y0
byte 4: Y7 0 Y5 Y4 Y3 1 1 0
byte 5: T&P 0 Z5 Z4 Z3 Z2 Z1 Z0
For touchpad packet, the format is::
packet-fmt b7 b6 b5 b4 b3 b2 b1 b0
byte 0: TWO & MULTI L 1 R M 1 Y0-2 Y0-1 Y0-0
byte 0: NEW L 1 X1-5 1 1 Y0-2 Y0-1 Y0-0
byte 1: Y0-10 Y0-9 Y0-8 Y0-7 Y0-6 Y0-5 Y0-4 Y0-3
byte 2: X0-11 1 X0-10 X0-9 X0-8 X0-7 X0-6 X0-5
byte 3: X1-11 1 X0-4 X0-3 1 X0-2 X0-1 X0-0
byte 4: TWO X1-10 TWO X1-9 X1-8 X1-7 X1-6 X1-5 X1-4
byte 4: MULTI X1-10 TWO X1-9 X1-8 X1-7 X1-6 Y1-5 1
byte 4: NEW X1-10 TWO X1-9 X1-8 X1-7 X1-6 0 0
byte 5: TWO & NEW Y1-10 0 Y1-9 Y1-8 Y1-7 Y1-6 Y1-5 Y1-4
byte 5: MULTI Y1-10 0 Y1-9 Y1-8 Y1-7 Y1-6 F-1 F-0
L: Left button
R / M: Non-clickpads: Right / Middle button
Clickpads: When > 2 fingers are down, and some fingers
are in the button area, then the 2 coordinates reported
are for fingers outside the button area and these report
extra fingers being present in the right / left button
area. Note these fingers are not added to the F field!
so if a TWO packet is received and R = 1 then there are
3 fingers down, etc.
TWO: 1: Two touches present, byte 0/4/5 are in TWO fmt
0: If byte 4 bit 0 is 1, then byte 0/4/5 are in MULTI fmt
otherwise byte 0 bit 4 must be set and byte 0/4/5 are
in NEW fmt
F: Number of fingers - 3, 0 means 3 fingers, 1 means 4 ...
ALPS Absolute Mode - Protocol Version 8
---------------------------------------
Spoken by SS4 (73 03 14) and SS5 (73 03 28) hardware.
The packet type is given by the APD field, bits 4-5 of byte 3.
Touchpad packet (APD = 0x2)::
b7 b6 b5 b4 b3 b2 b1 b0
byte 0: SWM SWR SWL 1 1 0 0 X7
byte 1: 0 X6 X5 X4 X3 X2 X1 X0
byte 2: 0 Y6 Y5 Y4 Y3 Y2 Y1 Y0
byte 3: 0 T&P 1 0 1 0 0 Y7
byte 4: 0 Z6 Z5 Z4 Z3 Z2 Z1 Z0
byte 5: 0 0 0 0 0 0 0 0
SWM, SWR, SWL: Middle, Right, and Left button states
Touchpad 1 Finger packet (APD = 0x0)::
b7 b6 b5 b4 b3 b2 b1 b0
byte 0: SWM SWR SWL 1 1 X2 X1 X0
byte 1: X9 X8 X7 1 X6 X5 X4 X3
byte 2: 0 X11 X10 LFB Y3 Y2 Y1 Y0
byte 3: Y5 Y4 0 0 1 TAPF2 TAPF1 TAPF0
byte 4: Zv7 Y11 Y10 1 Y9 Y8 Y7 Y6
byte 5: Zv6 Zv5 Zv4 0 Zv3 Zv2 Zv1 Zv0
TAPF: ???
LFB: ???
Touchpad 2 Finger packet (APD = 0x1)::
b7 b6 b5 b4 b3 b2 b1 b0
byte 0: SWM SWR SWL 1 1 AX6 AX5 AX4
byte 1: AX11 AX10 AX9 AX8 AX7 AZ1 AY4 AZ0
byte 2: AY11 AY10 AY9 CONT AY8 AY7 AY6 AY5
byte 3: 0 0 0 1 1 BX6 BX5 BX4
byte 4: BX11 BX10 BX9 BX8 BX7 BZ1 BY4 BZ0
byte 5: BY11 BY10 BY9 0 BY8 BY7 BY5 BY5
CONT: A 3-or-4 Finger packet is to follow
Touchpad 3-or-4 Finger packet (APD = 0x3)::
b7 b6 b5 b4 b3 b2 b1 b0
byte 0: SWM SWR SWL 1 1 AX6 AX5 AX4
byte 1: AX11 AX10 AX9 AX8 AX7 AZ1 AY4 AZ0
byte 2: AY11 AY10 AY9 OVF AY8 AY7 AY6 AY5
byte 3: 0 0 1 1 1 BX6 BX5 BX4
byte 4: BX11 BX10 BX9 BX8 BX7 BZ1 BY4 BZ0
byte 5: BY11 BY10 BY9 0 BY8 BY7 BY5 BY5
OVF: 5th finger detected

263
Documentation/input/devices/amijoy.rst Normal file
View file

@ -0,0 +1,263 @@
~~~~~~~~~~~~~~~~~~~~~~~~~
Amiga joystick extensions
~~~~~~~~~~~~~~~~~~~~~~~~~
Amiga 4-joystick parport extension
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Parallel port pins:
===== ======== ==== ==========
Pin Meaning Pin Meaning
===== ======== ==== ==========
2 Up1 6 Up2
3 Down1 7 Down2
4 Left1 8 Left2
5 Right1 9 Right2
13 Fire1 11 Fire2
18 Gnd1 18 Gnd2
===== ======== ==== ==========
Amiga digital joystick pinout
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
=== ============
Pin Meaning
=== ============
1 Up
2 Down
3 Left
4 Right
5 n/c
6 Fire button
7 +5V (50mA)
8 Gnd
9 Thumb button
=== ============
Amiga mouse pinout
~~~~~~~~~~~~~~~~~~
=== ============
Pin Meaning
=== ============
1 V-pulse
2 H-pulse
3 VQ-pulse
4 HQ-pulse
5 Middle button
6 Left button
7 +5V (50mA)
8 Gnd
9 Right button
=== ============
Amiga analog joystick pinout
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
=== ==============
Pin Meaning
=== ==============
1 Top button
2 Top2 button
3 Trigger button
4 Thumb button
5 Analog X
6 n/c
7 +5V (50mA)
8 Gnd
9 Analog Y
=== ==============
Amiga lightpen pinout
~~~~~~~~~~~~~~~~~~~~~
=== =============
Pin Meaning
=== =============
1 n/c
2 n/c
3 n/c
4 n/c
5 Touch button
6 /Beamtrigger
7 +5V (50mA)
8 Gnd
9 Stylus button
=== =============
-------------------------------------------------------------------------------
======== === ==== ==== ====== ========================================
NAME rev ADDR type chip Description
======== === ==== ==== ====== ========================================
JOY0DAT 00A R Denise Joystick-mouse 0 data (left vert, horiz)
JOY1DAT 00C R Denise Joystick-mouse 1 data (right vert,horiz)
======== === ==== ==== ====== ========================================
These addresses each read a 16 bit register. These in turn
are loaded from the MDAT serial stream and are clocked in on
the rising edge of SCLK. MLD output is used to parallel load
the external parallel-to-serial converter.This in turn is
loaded with the 4 quadrature inputs from each of two game
controller ports (8 total) plus 8 miscellaneous control bits
which are new for LISA and can be read in upper 8 bits of
LISAID.
Register bits are as follows:
- Mouse counter usage (pins 1,3 =Yclock, pins 2,4 =Xclock)
======== === === === === === === === === ====== === === === === === === ===
BIT# 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
======== === === === === === === === === ====== === === === === === === ===
JOY0DAT Y7 Y6 Y5 Y4 Y3 Y2 Y1 Y0 X7 X6 X5 X4 X3 X2 X1 X0
JOY1DAT Y7 Y6 Y5 Y4 Y3 Y2 Y1 Y0 X7 X6 X5 X4 X3 X2 X1 X0
======== === === === === === === === === ====== === === === === === === ===
0=LEFT CONTROLLER PAIR, 1=RIGHT CONTROLLER PAIR.
(4 counters total). The bit usage for both left and right
addresses is shown below. Each 6 bit counter (Y7-Y2,X7-X2) is
clocked by 2 of the signals input from the mouse serial
stream. Starting with first bit received:
+-------------------+-----------------------------------------+
| Serial | Bit Name | Description |
+========+==========+=========================================+
| 0 | M0H | JOY0DAT Horizontal Clock |
+--------+----------+-----------------------------------------+
| 1 | M0HQ | JOY0DAT Horizontal Clock (quadrature) |
+--------+----------+-----------------------------------------+
| 2 | M0V | JOY0DAT Vertical Clock |
+--------+----------+-----------------------------------------+
| 3 | M0VQ | JOY0DAT Vertical Clock (quadrature) |
+--------+----------+-----------------------------------------+
| 4 | M1V | JOY1DAT Horizontal Clock |
+--------+----------+-----------------------------------------+
| 5 | M1VQ | JOY1DAT Horizontal Clock (quadrature) |
+--------+----------+-----------------------------------------+
| 6 | M1V | JOY1DAT Vertical Clock |
+--------+----------+-----------------------------------------+
| 7 | M1VQ | JOY1DAT Vertical Clock (quadrature) |
+--------+----------+-----------------------------------------+
Bits 1 and 0 of each counter (Y1-Y0,X1-X0) may be
read to determine the state of the related input signal pair.
This allows these pins to double as joystick switch inputs.
Joystick switch closures can be deciphered as follows:
+------------+------+---------------------------------+
| Directions | Pin# | Counter bits |
+============+======+=================================+
| Forward | 1 | Y1 xor Y0 (BIT#09 xor BIT#08) |
+------------+------+---------------------------------+
| Left | 3 | Y1 |
+------------+------+---------------------------------+
| Back | 2 | X1 xor X0 (BIT#01 xor BIT#00) |
+------------+------+---------------------------------+
| Right | 4 | X1 |
+------------+------+---------------------------------+
-------------------------------------------------------------------------------
======== === ==== ==== ====== =================================================
NAME rev ADDR type chip Description
======== === ==== ==== ====== =================================================
JOYTEST 036 W Denise Write to all 4 joystick-mouse counters at once.
======== === ==== ==== ====== =================================================
Mouse counter write test data:
========= === === === === === === === === ====== === === === === === === ===
BIT# 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
========= === === === === === === === === ====== === === === === === === ===
JOYxDAT Y7 Y6 Y5 Y4 Y3 Y2 xx xx X7 X6 X5 X4 X3 X2 xx xx
JOYxDAT Y7 Y6 Y5 Y4 Y3 Y2 xx xx X7 X6 X5 X4 X3 X2 xx xx
========= === === === === === === === === ====== === === === === === === ===
-------------------------------------------------------------------------------
======= === ==== ==== ====== ========================================
NAME rev ADDR type chip Description
======= === ==== ==== ====== ========================================
POT0DAT h 012 R Paula Pot counter data left pair (vert, horiz)
POT1DAT h 014 R Paula Pot counter data right pair (vert,horiz)
======= === ==== ==== ====== ========================================
These addresses each read a pair of 8 bit pot counters.
(4 counters total). The bit assignment for both
addresses is shown below. The counters are stopped by signals
from 2 controller connectors (left-right) with 2 pins each.
====== === === === === === === === === ====== === === === === === === ===
BIT# 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
====== === === === === === === === === ====== === === === === === === ===
RIGHT Y7 Y6 Y5 Y4 Y3 Y2 Y1 Y0 X7 X6 X5 X4 X3 X2 X1 X0
LEFT Y7 Y6 Y5 Y4 Y3 Y2 Y1 Y0 X7 X6 X5 X4 X3 X2 X1 X0
====== === === === === === === === === ====== === === === === === === ===
+--------------------------+-------+
| CONNECTORS | PAULA |
+-------+------+-----+-----+-------+
| Loc. | Dir. | Sym | pin | pin |
+=======+======+=====+=====+=======+
| RIGHT | Y | RX | 9 | 33 |
+-------+------+-----+-----+-------+
| RIGHT | X | RX | 5 | 32 |
+-------+------+-----+-----+-------+
| LEFT | Y | LY | 9 | 36 |
+-------+------+-----+-----+-------+
| LEFT | X | LX | 5 | 35 |
+-------+------+-----+-----+-------+
With normal (NTSC or PAL) horiz. line rate, the pots will
give a full scale (FF) reading with about 500kohms in one
frame time. With proportionally faster horiz line times,
the counters will count proportionally faster.
This should be noted when doing variable beam displays.
-------------------------------------------------------------------------------
====== === ==== ==== ====== ================================================
NAME rev ADDR type chip Description
====== === ==== ==== ====== ================================================
POTGO 034 W Paula Pot port (4 bit) bi-direction and data, and pot
counter start.
====== === ==== ==== ====== ================================================
-------------------------------------------------------------------------------
====== === ==== ==== ====== ================================================
NAME rev ADDR type chip Description
====== === ==== ==== ====== ================================================
POTINP 016 R Paula Pot pin data read
====== === ==== ==== ====== ================================================
This register controls a 4 bit bi-direction I/O port
that shares the same 4 pins as the 4 pot counters above.
+-------+----------+---------------------------------------------+
| BIT# | FUNCTION | DESCRIPTION |
+=======+==========+=============================================+
| 15 | OUTRY | Output enable for Paula pin 33 |
+-------+----------+---------------------------------------------+
| 14 | DATRY | I/O data Paula pin 33 |
+-------+----------+---------------------------------------------+
| 13 | OUTRX | Output enable for Paula pin 32 |
+-------+----------+---------------------------------------------+
| 12 | DATRX | I/O data Paula pin 32 |
+-------+----------+---------------------------------------------+
| 11 | OUTLY | Out put enable for Paula pin 36 |
+-------+----------+---------------------------------------------+
| 10 | DATLY | I/O data Paula pin 36 |
+-------+----------+---------------------------------------------+
| 09 | OUTLX | Output enable for Paula pin 35 |
+-------+----------+---------------------------------------------+
| 08 | DATLX | I/O data Paula pin 35 |
+-------+----------+---------------------------------------------+
| 07-01 | X | Not used |
+-------+----------+---------------------------------------------+
| 00 | START | Start pots (dump capacitors,start counters) |
+-------+----------+---------------------------------------------+

94
Documentation/input/devices/appletouch.rst Normal file
View file

@ -0,0 +1,94 @@
.. include:: <isonum.txt>
----------------------------------
Apple Touchpad Driver (appletouch)
----------------------------------
:Copyright: |copy| 2005 Stelian Pop <stelian@popies.net>
appletouch is a Linux kernel driver for the USB touchpad found on post
February 2005 and October 2005 Apple Aluminium Powerbooks.
This driver is derived from Johannes Berg's appletrackpad driver [#f1]_,
but it has been improved in some areas:
* appletouch is a full kernel driver, no userspace program is necessary
* appletouch can be interfaced with the synaptics X11 driver, in order
to have touchpad acceleration, scrolling, etc.
Credits go to Johannes Berg for reverse-engineering the touchpad protocol,
Frank Arnold for further improvements, and Alex Harper for some additional
information about the inner workings of the touchpad sensors. Michael
Hanselmann added support for the October 2005 models.
Usage
-----
In order to use the touchpad in the basic mode, compile the driver and load
the module. A new input device will be detected and you will be able to read
the mouse data from /dev/input/mice (using gpm, or X11).
In X11, you can configure the touchpad to use the synaptics X11 driver, which
will give additional functionalities, like acceleration, scrolling, 2 finger
tap for middle button mouse emulation, 3 finger tap for right button mouse
emulation, etc. In order to do this, make sure you're using a recent version of
the synaptics driver (tested with 0.14.2, available from [#f2]_), and configure
a new input device in your X11 configuration file (take a look below for an
example). For additional configuration, see the synaptics driver documentation::
Section "InputDevice"
Identifier "Synaptics Touchpad"
Driver "synaptics"
Option "SendCoreEvents" "true"
Option "Device" "/dev/input/mice"
Option "Protocol" "auto-dev"
Option "LeftEdge" "0"
Option "RightEdge" "850"
Option "TopEdge" "0"
Option "BottomEdge" "645"
Option "MinSpeed" "0.4"
Option "MaxSpeed" "1"
Option "AccelFactor" "0.02"
Option "FingerLow" "0"
Option "FingerHigh" "30"
Option "MaxTapMove" "20"
Option "MaxTapTime" "100"
Option "HorizScrollDelta" "0"
Option "VertScrollDelta" "30"
Option "SHMConfig" "on"
EndSection
Section "ServerLayout"
...
InputDevice "Mouse"
InputDevice "Synaptics Touchpad"
...
EndSection
Fuzz problems
-------------
The touchpad sensors are very sensitive to heat, and will generate a lot of
noise when the temperature changes. This is especially true when you power-on
the laptop for the first time.
The appletouch driver tries to handle this noise and auto adapt itself, but it
is not perfect. If finger movements are not recognized anymore, try reloading
the driver.
You can activate debugging using the 'debug' module parameter. A value of 0
deactivates any debugging, 1 activates tracing of invalid samples, 2 activates
full tracing (each sample is being traced)::
modprobe appletouch debug=1
or::
echo "1" > /sys/module/appletouch/parameters/debug
.. Links:
.. [#f1] http://johannes.sipsolutions.net/PowerBook/touchpad/
.. [#f2] `<http://web.archive.org/web/*/http://web.telia.com/~u89404340/touchpad/index.html>`_

820
Documentation/input/devices/atarikbd.rst Normal file
View file

@ -0,0 +1,820 @@
====================================
Intelligent Keyboard (ikbd) Protocol
====================================
Introduction
============
The Atari Corp. Intelligent Keyboard (ikbd) is a general purpose keyboard
controller that is flexible enough that it can be used in a variety of
products without modification. The keyboard, with its microcontroller,
provides a convenient connection point for a mouse and switch-type joysticks.
The ikbd processor also maintains a time-of-day clock with one second
resolution.
The ikbd has been designed to be general enough that it can be used with a
variety of new computer products. Product variations in a number of
keyswitches, mouse resolution, etc. can be accommodated.
The ikbd communicates with the main processor over a high speed bi-directional
serial interface. It can function in a variety of modes to facilitate
different applications of the keyboard, joysticks, or mouse. Limited use of
the controller is possible in applications in which only a unidirectional
communications medium is available by carefully designing the default modes.
Keyboard
========
The keyboard always returns key make/break scan codes. The ikbd generates
keyboard scan codes for each key press and release. The key scan make (key
closure) codes start at 1, and are defined in Appendix A. For example, the
ISO key position in the scan code table should exist even if no keyswitch
exists in that position on a particular keyboard. The break code for each key
is obtained by ORing 0x80 with the make code.
The special codes 0xF6 through 0xFF are reserved for use as follows:
=================== ====================================================
Code Command
=================== ====================================================
0xF6 status report
0xF7 absolute mouse position record
0xF8-0xFB relative mouse position records (lsbs determined by
mouse button states)
0xFC time-of-day
0xFD joystick report (both sticks)
0xFE joystick 0 event
0xFF joystick 1 event
=================== ====================================================
The two shift keys return different scan codes in this mode. The ENTER key
and the RETurn key are also distinct.
Mouse
=====
The mouse port should be capable of supporting a mouse with resolution of
approximately 200 counts (phase changes or 'clicks') per inch of travel. The
mouse should be scanned at a rate that will permit accurate tracking at
velocities up to 10 inches per second.
The ikbd can report mouse motion in three distinctly different ways. It can
report relative motion, absolute motion in a coordinate system maintained
within the ikbd, or by converting mouse motion into keyboard cursor control
key equivalents.
The mouse buttons can be treated as part of the mouse or as additional
keyboard keys.
Relative Position Reporting
---------------------------
In relative position mode, the ikbd will return relative mouse position
records whenever a mouse event occurs. A mouse event consists of a mouse
button being pressed or released, or motion in either axis exceeding a
settable threshold of motion. Regardless of the threshold, all bits of
resolution are returned to the host computer.
Note that the ikbd may return mouse relative position reports with
significantly more than the threshold delta x or y. This may happen since no
relative mouse motion events will be generated: (a) while the keyboard has
been 'paused' ( the event will be stored until keyboard communications is
resumed) (b) while any event is being transmitted.
The relative mouse position record is a three byte record of the form
(regardless of keyboard mode)::
%111110xy ; mouse position record flag
; where y is the right button state
; and x is the left button state
X ; delta x as twos complement integer
Y ; delta y as twos complement integer
Note that the value of the button state bits should be valid even if the
MOUSE BUTTON ACTION has set the buttons to act like part of the keyboard.
If the accumulated motion before the report packet is generated exceeds the
+127...-128 range, the motion is broken into multiple packets.
Note that the sign of the delta y reported is a function of the Y origin
selected.
Absolute Position reporting
---------------------------
The ikbd can also maintain absolute mouse position. Commands exist for
resetting the mouse position, setting X/Y scaling, and interrogating the
current mouse position.
Mouse Cursor Key Mode
---------------------
The ikbd can translate mouse motion into the equivalent cursor keystrokes.
The number of mouse clicks per keystroke is independently programmable in
each axis. The ikbd internally maintains mouse motion information to the
highest resolution available, and merely generates a pair of cursor key events
for each multiple of the scale factor.
Mouse motion produces the cursor key make code immediately followed by the
break code for the appropriate cursor key. The mouse buttons produce scan
codes above those normally assigned for the largest envisioned keyboard (i.e.
LEFT=0x74 & RIGHT=0x75).
Joystick
========
Joystick Event Reporting
------------------------
In this mode, the ikbd generates a record whenever the joystick position is
changed (i.e. for each opening or closing of a joystick switch or trigger).
The joystick event record is two bytes of the form::
%1111111x ; Joystick event marker
; where x is Joystick 0 or 1
%x000yyyy ; where yyyy is the stick position
; and x is the trigger
Joystick Interrogation
----------------------
The current state of the joystick ports may be interrogated at any time in
this mode by sending an 'Interrogate Joystick' command to the ikbd.
The ikbd response to joystick interrogation is a three byte report of the form::
0xFD ; joystick report header
%x000yyyy ; Joystick 0
%x000yyyy ; Joystick 1
; where x is the trigger
; and yyy is the stick position
Joystick Monitoring
-------------------
A mode is available that devotes nearly all of the keyboard communications
time to reporting the state of the joystick ports at a user specifiable rate.
It remains in this mode until reset or commanded into another mode. The PAUSE
command in this mode not only stop the output but also temporarily stops
scanning the joysticks (samples are not queued).
Fire Button Monitoring
----------------------
A mode is provided to permit monitoring a single input bit at a high rate. In
this mode the ikbd monitors the state of the Joystick 1 fire button at the
maximum rate permitted by the serial communication channel. The data is packed
8 bits per byte for transmission to the host. The ikbd remains in this mode
until reset or commanded into another mode. The PAUSE command in this mode not
only stops the output but also temporarily stops scanning the button (samples
are not queued).
Joystick Key Code Mode
----------------------
The ikbd may be commanded to translate the use of either joystick into the
equivalent cursor control keystroke(s). The ikbd provides a single breakpoint
velocity joystick cursor.
Joystick events produce the make code, immediately followed by the break code
for the appropriate cursor motion keys. The trigger or fire buttons of the
joysticks produce pseudo key scan codes above those used by the largest key
matrix envisioned (i.e. JOYSTICK0=0x74, JOYSTICK1=0x75).
Time-of-Day Clock
=================
The ikbd also maintains a time-of-day clock for the system. Commands are
available to set and interrogate the timer-of-day clock. Time-keeping is
maintained down to a resolution of one second.
Status Inquiries
================
The current state of ikbd modes and parameters may be found by sending status
inquiry commands that correspond to the ikbd set commands.
Power-Up Mode
=============
The keyboard controller will perform a simple self-test on power-up to detect
major controller faults (ROM checksum and RAM test) and such things as stuck
keys. Any keys down at power-up are presumed to be stuck, and their BREAK
(sic) code is returned (which without the preceding MAKE code is a flag for a
keyboard error). If the controller self-test completes without error, the code
0xF0 is returned. (This code will be used to indicate the version/release of
the ikbd controller. The first release of the ikbd is version 0xF0, should
there be a second release it will be 0xF1, and so on.)
The ikbd defaults to a mouse position reporting with threshold of 1 unit in
either axis and the Y=0 origin at the top of the screen, and joystick event
reporting mode for joystick 1, with both buttons being logically assigned to
the mouse. After any joystick command, the ikbd assumes that joysticks are
connected to both Joystick0 and Joystick1. Any mouse command (except MOUSE
DISABLE) then causes port 0 to again be scanned as if it were a mouse, and
both buttons are logically connected to it. If a mouse disable command is
received while port 0 is presumed to be a mouse, the button is logically
assigned to Joystick1 (until the mouse is reenabled by another mouse command).
ikbd Command Set
================
This section contains a list of commands that can be sent to the ikbd. Command
codes (such as 0x00) which are not specified should perform no operation
(NOPs).
RESET
-----
::
0x80
0x01
N.B. The RESET command is the only two byte command understood by the ikbd.
Any byte following an 0x80 command byte other than 0x01 is ignored (and causes
the 0x80 to be ignored).
A reset may also be caused by sending a break lasting at least 200mS to the
ikbd.
Executing the RESET command returns the keyboard to its default (power-up)
mode and parameter settings. It does not affect the time-of-day clock.
The RESET command or function causes the ikbd to perform a simple self-test.
If the test is successful, the ikbd will send the code of 0xF0 within 300mS
of receipt of the RESET command (or the end of the break, or power-up). The
ikbd will then scan the key matrix for any stuck (closed) keys. Any keys found
closed will cause the break scan code to be generated (the break code arriving
without being preceded by the make code is a flag for a key matrix error).
SET MOUSE BUTTON ACTION
-----------------------
::
0x07
%00000mss ; mouse button action
; (m is presumed = 1 when in MOUSE KEYCODE mode)
; mss=0xy, mouse button press or release causes mouse
; position report
; where y=1, mouse key press causes absolute report
; and x=1, mouse key release causes absolute report
; mss=100, mouse buttons act like keys
This command sets how the ikbd should treat the buttons on the mouse. The
default mouse button action mode is %00000000, the buttons are treated as part
of the mouse logically.
When buttons act like keys, LEFT=0x74 & RIGHT=0x75.
SET RELATIVE MOUSE POSITION REPORTING
-------------------------------------
::
0x08
Set relative mouse position reporting. (DEFAULT) Mouse position packets are
generated asynchronously by the ikbd whenever motion exceeds the setable
threshold in either axis (see SET MOUSE THRESHOLD). Depending upon the mouse
key mode, mouse position reports may also be generated when either mouse
button is pressed or released. Otherwise the mouse buttons behave as if they
were keyboard keys.
SET ABSOLUTE MOUSE POSITIONING
------------------------------
::
0x09
XMSB ; X maximum (in scaled mouse clicks)
XLSB
YMSB ; Y maximum (in scaled mouse clicks)
YLSB
Set absolute mouse position maintenance. Resets the ikbd maintained X and Y
coordinates.
In this mode, the value of the internally maintained coordinates does NOT wrap
between 0 and large positive numbers. Excess motion below 0 is ignored. The
command sets the maximum positive value that can be attained in the scaled
coordinate system. Motion beyond that value is also ignored.
SET MOUSE KEYCODE MOSE
----------------------
::
0x0A
deltax ; distance in X clicks to return (LEFT) or (RIGHT)
deltay ; distance in Y clicks to return (UP) or (DOWN)
Set mouse monitoring routines to return cursor motion keycodes instead of
either RELATIVE or ABSOLUTE motion records. The ikbd returns the appropriate
cursor keycode after mouse travel exceeding the user specified deltas in
either axis. When the keyboard is in key scan code mode, mouse motion will
cause the make code immediately followed by the break code. Note that this
command is not affected by the mouse motion origin.
SET MOUSE THRESHOLD
-------------------
::
0x0B
X ; x threshold in mouse ticks (positive integers)
Y ; y threshold in mouse ticks (positive integers)
This command sets the threshold before a mouse event is generated. Note that
it does NOT affect the resolution of the data returned to the host. This
command is valid only in RELATIVE MOUSE POSITIONING mode. The thresholds
default to 1 at RESET (or power-up).
SET MOUSE SCALE
---------------
::
0x0C
X ; horizontal mouse ticks per internal X
Y ; vertical mouse ticks per internal Y
This command sets the scale factor for the ABSOLUTE MOUSE POSITIONING mode.
In this mode, the specified number of mouse phase changes ('clicks') must
occur before the internally maintained coordinate is changed by one
(independently scaled for each axis). Remember that the mouse position
information is available only by interrogating the ikbd in the ABSOLUTE MOUSE
POSITIONING mode unless the ikbd has been commanded to report on button press
or release (see SET MOSE BUTTON ACTION).
INTERROGATE MOUSE POSITION
--------------------------
::
0x0D
Returns:
0xF7 ; absolute mouse position header
BUTTONS
0000dcba ; where a is right button down since last interrogation
; b is right button up since last
; c is left button down since last
; d is left button up since last
XMSB ; X coordinate
XLSB
YMSB ; Y coordinate
YLSB
The INTERROGATE MOUSE POSITION command is valid when in the ABSOLUTE MOUSE
POSITIONING mode, regardless of the setting of the MOUSE BUTTON ACTION.
LOAD MOUSE POSITION
-------------------
::
0x0E
0x00 ; filler
XMSB ; X coordinate
XLSB ; (in scaled coordinate system)
YMSB ; Y coordinate
YLSB
This command allows the user to preset the internally maintained absolute
mouse position.
SET Y=0 AT BOTTOM
-----------------
::
0x0F
This command makes the origin of the Y axis to be at the bottom of the
logical coordinate system internal to the ikbd for all relative or absolute
mouse motion. This causes mouse motion toward the user to be negative in sign
and away from the user to be positive.
SET Y=0 AT TOP
--------------
::
0x10
Makes the origin of the Y axis to be at the top of the logical coordinate
system within the ikbd for all relative or absolute mouse motion. (DEFAULT)
This causes mouse motion toward the user to be positive in sign and away from
the user to be negative.
RESUME
------
::
0x11
Resume sending data to the host. Since any command received by the ikbd after
its output has been paused also causes an implicit RESUME this command can be
thought of as a NO OPERATION command. If this command is received by the ikbd
and it is not PAUSED, it is simply ignored.
DISABLE MOUSE
-------------
::
0x12
All mouse event reporting is disabled (and scanning may be internally
disabled). Any valid mouse mode command resumes mouse motion monitoring. (The
valid mouse mode commands are SET RELATIVE MOUSE POSITION REPORTING, SET
ABSOLUTE MOUSE POSITIONING, and SET MOUSE KEYCODE MODE. )
N.B. If the mouse buttons have been commanded to act like keyboard keys, this
command DOES affect their actions.
PAUSE OUTPUT
------------
::
0x13
Stop sending data to the host until another valid command is received. Key
matrix activity is still monitored and scan codes or ASCII characters enqueued
(up to the maximum supported by the microcontroller) to be sent when the host
allows the output to be resumed. If in the JOYSTICK EVENT REPORTING mode,
joystick events are also queued.
Mouse motion should be accumulated while the output is paused. If the ikbd is
in RELATIVE MOUSE POSITIONING REPORTING mode, motion is accumulated beyond the
normal threshold limits to produce the minimum number of packets necessary for
transmission when output is resumed. Pressing or releasing either mouse button
causes any accumulated motion to be immediately queued as packets, if the
mouse is in RELATIVE MOUSE POSITION REPORTING mode.
Because of the limitations of the microcontroller memory this command should
be used sparingly, and the output should not be shut of for more than <tbd>
milliseconds at a time.
The output is stopped only at the end of the current 'even'. If the PAUSE
OUTPUT command is received in the middle of a multiple byte report, the packet
will still be transmitted to conclusion and then the PAUSE will take effect.
When the ikbd is in either the JOYSTICK MONITORING mode or the FIRE BUTTON
MONITORING mode, the PAUSE OUTPUT command also temporarily stops the
monitoring process (i.e. the samples are not enqueued for transmission).
SET JOYSTICK EVENT REPORTING
----------------------------
::
0x14
Enter JOYSTICK EVENT REPORTING mode (DEFAULT). Each opening or closure of a
joystick switch or trigger causes a joystick event record to be generated.
SET JOYSTICK INTERROGATION MODE
-------------------------------
::
0x15
Disables JOYSTICK EVENT REPORTING. Host must send individual JOYSTICK
INTERROGATE commands to sense joystick state.
JOYSTICK INTERROGATE
--------------------
::
0x16
Return a record indicating the current state of the joysticks. This command
is valid in either the JOYSTICK EVENT REPORTING mode or the JOYSTICK
INTERROGATION MODE.
SET JOYSTICK MONITORING
-----------------------
::
0x17
rate ; time between samples in hundredths of a second
Returns: (in packets of two as long as in mode)
%000000xy ; where y is JOYSTICK1 Fire button
; and x is JOYSTICK0 Fire button
%nnnnmmmm ; where m is JOYSTICK1 state
; and n is JOYSTICK0 state
Sets the ikbd to do nothing but monitor the serial command line, maintain the
time-of-day clock, and monitor the joystick. The rate sets the interval
between joystick samples.
N.B. The user should not set the rate higher than the serial communications
channel will allow the 2 bytes packets to be transmitted.
SET FIRE BUTTON MONITORING
--------------------------
::
0x18
Returns: (as long as in mode)
%bbbbbbbb ; state of the JOYSTICK1 fire button packed
; 8 bits per byte, the first sample if the MSB
Set the ikbd to do nothing but monitor the serial command line, maintain the
time-of-day clock, and monitor the fire button on Joystick 1. The fire button
is scanned at a rate that causes 8 samples to be made in the time it takes for
the previous byte to be sent to the host (i.e. scan rate = 8/10 * baud rate).
The sample interval should be as constant as possible.
SET JOYSTICK KEYCODE MODE
-------------------------
::
0x19
RX ; length of time (in tenths of seconds) until
; horizontal velocity breakpoint is reached
RY ; length of time (in tenths of seconds) until
; vertical velocity breakpoint is reached
TX ; length (in tenths of seconds) of joystick closure
; until horizontal cursor key is generated before RX
; has elapsed
TY ; length (in tenths of seconds) of joystick closure
; until vertical cursor key is generated before RY
; has elapsed
VX ; length (in tenths of seconds) of joystick closure
; until horizontal cursor keystrokes are generated
; after RX has elapsed
VY ; length (in tenths of seconds) of joystick closure
; until vertical cursor keystrokes are generated
; after RY has elapsed
In this mode, joystick 0 is scanned in a way that simulates cursor keystrokes.
On initial closure, a keystroke pair (make/break) is generated. Then up to Rn
tenths of seconds later, keystroke pairs are generated every Tn tenths of
seconds. After the Rn breakpoint is reached, keystroke pairs are generated
every Vn tenths of seconds. This provides a velocity (auto-repeat) breakpoint
feature.
Note that by setting RX and/or Ry to zero, the velocity feature can be
disabled. The values of TX and TY then become meaningless, and the generation
of cursor 'keystrokes' is set by VX and VY.
DISABLE JOYSTICKS
-----------------
::
0x1A
Disable the generation of any joystick events (and scanning may be internally
disabled). Any valid joystick mode command resumes joystick monitoring. (The
joystick mode commands are SET JOYSTICK EVENT REPORTING, SET JOYSTICK
INTERROGATION MODE, SET JOYSTICK MONITORING, SET FIRE BUTTON MONITORING, and
SET JOYSTICK KEYCODE MODE.)
TIME-OF-DAY CLOCK SET
---------------------
::
0x1B
YY ; year (2 least significant digits)
MM ; month
DD ; day
hh ; hour
mm ; minute
ss ; second
All time-of-day data should be sent to the ikbd in packed BCD format.
Any digit that is not a valid BCD digit should be treated as a 'don't care'
and not alter that particular field of the date or time. This permits setting
only some subfields of the time-of-day clock.
INTERROGATE TIME-OF-DAT CLOCK
-----------------------------
::
0x1C
Returns:
0xFC ; time-of-day event header
YY ; year (2 least significant digits)
MM ; month
DD ; day
hh ; hour
mm ; minute
ss ; second
All time-of-day is sent in packed BCD format.
MEMORY LOAD
-----------
::
0x20
ADRMSB ; address in controller
ADRLSB ; memory to be loaded
NUM ; number of bytes (0-128)
{ data }
This command permits the host to load arbitrary values into the ikbd
controller memory. The time between data bytes must be less than 20ms.
MEMORY READ
-----------
::
0x21
ADRMSB ; address in controller
ADRLSB ; memory to be read
Returns:
0xF6 ; status header
0x20 ; memory access
{ data } ; 6 data bytes starting at ADR
This command permits the host to read from the ikbd controller memory.
CONTROLLER EXECUTE
------------------
::
0x22
ADRMSB ; address of subroutine in
ADRLSB ; controller memory to be called
This command allows the host to command the execution of a subroutine in the
ikbd controller memory.
STATUS INQUIRIES
----------------
::
Status commands are formed by inclusively ORing 0x80 with the
relevant SET command.
Example:
0x88 (or 0x89 or 0x8A) ; request mouse mode
Returns:
0xF6 ; status response header
mode ; 0x08 is RELATIVE
; 0x09 is ABSOLUTE
; 0x0A is KEYCODE
param1 ; 0 is RELATIVE
; XMSB maximum if ABSOLUTE
; DELTA X is KEYCODE
param2 ; 0 is RELATIVE
; YMSB maximum if ABSOLUTE
; DELTA Y is KEYCODE
param3 ; 0 if RELATIVE
; or KEYCODE
; YMSB is ABSOLUTE
param4 ; 0 if RELATIVE
; or KEYCODE
; YLSB is ABSOLUTE
0 ; pad
0
The STATUS INQUIRY commands request the ikbd to return either the current mode
or the parameters associated with a given command. All status reports are
padded to form 8 byte long return packets. The responses to the status
requests are designed so that the host may store them away (after stripping
off the status report header byte) and later send them back as commands to
ikbd to restore its state. The 0 pad bytes will be treated as NOPs by the
ikbd.
Valid STATUS INQUIRY commands are::
0x87 mouse button action
0x88 mouse mode
0x89
0x8A
0x8B mnouse threshold
0x8C mouse scale
0x8F mouse vertical coordinates
0x90 ( returns 0x0F Y=0 at bottom
0x10 Y=0 at top )
0x92 mouse enable/disable
( returns 0x00 enabled)
0x12 disabled )
0x94 joystick mode
0x95
0x96
0x9A joystick enable/disable
( returns 0x00 enabled
0x1A disabled )
It is the (host) programmer's responsibility to have only one unanswered
inquiry in process at a time.
STATUS INQUIRY commands are not valid if the ikbd is in JOYSTICK MONITORING
mode or FIRE BUTTON MONITORING mode.
SCAN CODES
==========
The key scan codes returned by the ikbd are chosen to simplify the
implementation of GSX.
GSX Standard Keyboard Mapping
======= ============
Hex Keytop
======= ============
01 Esc
02 1
03 2
04 3
05 4
06 5
07 6
08 7
09 8
0A 9
0B 0
0C \-
0D \=
0E BS
0F TAB
10 Q
11 W
12 E
13 R
14 T
15 Y
16 U
17 I
18 O
19 P
1A [
1B ]
1C RET
1D CTRL
1E A
1F S
20 D
21 F
22 G
23 H
24 J
25 K
26 L
27 ;
28 '
29 \`
2A (LEFT) SHIFT
2B \\
2C Z
2D X
2E C
2F V
30 B
31 N
32 M
33 ,
34 .
35 /
36 (RIGHT) SHIFT
37 { NOT USED }
38 ALT
39 SPACE BAR
3A CAPS LOCK
3B F1
3C F2
3D F3
3E F4
3F F5
40 F6
41 F7
42 F8
43 F9
44 F10
45 { NOT USED }
46 { NOT USED }
47 HOME
48 UP ARROW
49 { NOT USED }
4A KEYPAD -
4B LEFT ARROW
4C { NOT USED }
4D RIGHT ARROW
4E KEYPAD +
4F { NOT USED }
50 DOWN ARROW
51 { NOT USED }
52 INSERT
53 DEL
54 { NOT USED }
5F { NOT USED }
60 ISO KEY
61 UNDO
62 HELP
63 KEYPAD (
64 KEYPAD /
65 KEYPAD *
66 KEYPAD *
67 KEYPAD 7
68 KEYPAD 8
69 KEYPAD 9
6A KEYPAD 4
6B KEYPAD 5
6C KEYPAD 6
6D KEYPAD 1
6E KEYPAD 2
6F KEYPAD 3
70 KEYPAD 0
71 KEYPAD .
72 KEYPAD ENTER
======= ============

70
Documentation/input/devices/bcm5974.rst Normal file
View file

@ -0,0 +1,70 @@
.. include:: <isonum.txt>
------------------------
BCM5974 Driver (bcm5974)
------------------------
:Copyright: |copy| 2008-2009 Henrik Rydberg <rydberg@euromail.se>
The USB initialization and package decoding was made by Scott Shawcroft as
part of the touchd user-space driver project:
:Copyright: |copy| 2008 Scott Shawcroft (scott.shawcroft@gmail.com)
The BCM5974 driver is based on the appletouch driver:
:Copyright: |copy| 2001-2004 Greg Kroah-Hartman (greg@kroah.com)
:Copyright: |copy| 2005 Johannes Berg (johannes@sipsolutions.net)
:Copyright: |copy| 2005 Stelian Pop (stelian@popies.net)
:Copyright: |copy| 2005 Frank Arnold (frank@scirocco-5v-turbo.de)
:Copyright: |copy| 2005 Peter Osterlund (petero2@telia.com)
:Copyright: |copy| 2005 Michael Hanselmann (linux-kernel@hansmi.ch)
:Copyright: |copy| 2006 Nicolas Boichat (nicolas@boichat.ch)
This driver adds support for the multi-touch trackpad on the new Apple
Macbook Air and Macbook Pro laptops. It replaces the appletouch driver on
those computers, and integrates well with the synaptics driver of the Xorg
system.
Known to work on Macbook Air, Macbook Pro Penryn and the new unibody
Macbook 5 and Macbook Pro 5.
Usage
-----
The driver loads automatically for the supported usb device ids, and
becomes available both as an event device (/dev/input/event*) and as a
mouse via the mousedev driver (/dev/input/mice).
USB Race
--------
The Apple multi-touch trackpads report both mouse and keyboard events via
different interfaces of the same usb device. This creates a race condition
with the HID driver, which, if not told otherwise, will find the standard
HID mouse and keyboard, and claim the whole device. To remedy, the usb
product id must be listed in the mouse_ignore list of the hid driver.
Debug output
------------
To ease the development for new hardware version, verbose packet output can
be switched on with the debug kernel module parameter. The range [1-9]
yields different levels of verbosity. Example (as root)::
echo -n 9 > /sys/module/bcm5974/parameters/debug
tail -f /var/log/debug
echo -n 0 > /sys/module/bcm5974/parameters/debug
Trivia
------
The driver was developed at the ubuntu forums in June 2008 [#f1]_, and now has
a more permanent home at bitmath.org [#f2]_.
.. Links
.. [#f1] http://ubuntuforums.org/showthread.php?t=840040
.. [#f2] http://bitmath.org/code/

139
Documentation/input/devices/cma3000_d0x.rst Normal file
View file

@ -0,0 +1,139 @@
CMA3000-D0x Accelerometer
=========================
Supported chips:
* VTI CMA3000-D0x
Datasheet:
CMA3000-D0X Product Family Specification 8281000A.02.pdf
<http://www.vti.fi/en/>
:Author: Hemanth V <hemanthv@ti.com>
Description
-----------
CMA3000 Tri-axis accelerometer supports Motion detect, Measurement and
Free fall modes.
Motion Detect Mode:
Its the low power mode where interrupts are generated only
when motion exceeds the defined thresholds.
Measurement Mode:
This mode is used to read the acceleration data on X,Y,Z
axis and supports 400, 100, 40 Hz sample frequency.
Free fall Mode:
This mode is intended to save system resources.
Threshold values:
Chip supports defining threshold values for above modes
which includes time and g value. Refer product specifications for
more details.
CMA3000 chip supports mutually exclusive I2C and SPI interfaces for
communication, currently the driver supports I2C based communication only.
Initial configuration for bus mode is set in non volatile memory and can later
be modified through bus interface command.
Driver reports acceleration data through input subsystem. It generates ABS_MISC
event with value 1 when free fall is detected.
Platform data need to be configured for initial default values.
Platform Data
-------------
fuzz_x:
Noise on X Axis
fuzz_y:
Noise on Y Axis
fuzz_z:
Noise on Z Axis
g_range:
G range in milli g i.e 2000 or 8000
mode:
Default Operating mode
mdthr:
Motion detect g range threshold value
mdfftmr:
Motion detect and free fall time threshold value
ffthr:
Free fall g range threshold value
Input Interface
---------------
Input driver version is 1.0.0
Input device ID: bus 0x18 vendor 0x0 product 0x0 version 0x0
Input device name: "cma3000-accelerometer"
Supported events::
Event type 0 (Sync)
Event type 3 (Absolute)
Event code 0 (X)
Value 47
Min -8000
Max 8000
Fuzz 200
Event code 1 (Y)
Value -28
Min -8000
Max 8000
Fuzz 200
Event code 2 (Z)
Value 905
Min -8000
Max 8000
Fuzz 200
Event code 40 (Misc)
Value 0
Min 0
Max 1
Event type 4 (Misc)
Register/Platform parameters Description
----------------------------------------
mode::
0: power down mode
1: 100 Hz Measurement mode
2: 400 Hz Measurement mode
3: 40 Hz Measurement mode
4: Motion Detect mode (default)
5: 100 Hz Free fall mode
6: 40 Hz Free fall mode
7: Power off mode
grange::
2000: 2000 mg or 2G Range
8000: 8000 mg or 8G Range
mdthr::
X: X * 71mg (8G Range)
X: X * 18mg (2G Range)
mdfftmr::
X: (X & 0x70) * 100 ms (MDTMR)
(X & 0x0F) * 2.5 ms (FFTMR 400 Hz)
(X & 0x0F) * 10 ms (FFTMR 100 Hz)
ffthr::
X: (X >> 2) * 18mg (2G Range)
X: (X & 0x0F) * 71 mg (8G Range)

43
Documentation/input/devices/cs461x.rst Normal file
View file

@ -0,0 +1,43 @@
Crystal SoundFusion CS4610/CS4612/CS461 joystick
================================================
This is a new low-level driver to support analog joystick attached to
Crystal SoundFusion CS4610/CS4612/CS4615. This code is based upon
Vortex/Solo drivers as an example of decoration style, and ALSA
0.5.8a kernel drivers as an chipset documentation and samples.
This version does not have cooked mode support; the basic code
is present here, but have not tested completely. The button analysis
is completed in this mode, but the axis movement is not.
Raw mode works fine with analog joystick front-end driver and cs461x
driver as a backend. I've tested this driver with CS4610, 4-axis and
4-button joystick; I mean the jstest utility. Also I've tried to
play in xracer game using joystick, and the result is better than
keyboard only mode.
The sensitivity and calibrate quality have not been tested; the two
reasons are performed: the same hardware cannot work under Win95 (blue
screen in VJOYD); I have no documentation on my chip; and the existing
behavior in my case was not raised the requirement of joystick calibration.
So the driver have no code to perform hardware related calibration.
This driver have the basic support for PCI devices only; there is no
ISA or PnP ISA cards supported.
The driver works with ALSA drivers simultaneously. For example, the xracer
uses joystick as input device and PCM device as sound output in one time.
There are no sound or input collisions detected. The source code have
comments about them; but I've found the joystick can be initialized
separately of ALSA modules. So, you can use only one joystick driver
without ALSA drivers. The ALSA drivers are not needed to compile or
run this driver.
There are no debug information print have been placed in source, and no
specific options required to work this driver. The found chipset parameters
are printed via printk(KERN_INFO "..."), see the /var/log/messages to
inspect cs461x: prefixed messages to determine possible card detection
errors.
Regards,
Viktor

54
Documentation/input/devices/edt-ft5x06.rst Normal file
View file

@ -0,0 +1,54 @@
EDT ft5x06 based Polytouch devices
----------------------------------
The edt-ft5x06 driver is useful for the EDT "Polytouch" family of capacitive
touch screens. Note that it is *not* suitable for other devices based on the
focaltec ft5x06 devices, since they contain vendor-specific firmware. In
particular this driver is not suitable for the Nook tablet.
It has been tested with the following devices:
* EP0350M06
* EP0430M06
* EP0570M06
* EP0700M06
The driver allows configuration of the touch screen via a set of sysfs files:
/sys/class/input/eventX/device/device/threshold:
allows setting the "click"-threshold in the range from 20 to 80.
/sys/class/input/eventX/device/device/gain:
allows setting the sensitivity in the range from 0 to 31. Note that
lower values indicate higher sensitivity.
/sys/class/input/eventX/device/device/offset:
allows setting the edge compensation in the range from 0 to 31.
/sys/class/input/eventX/device/device/report_rate:
allows setting the report rate in the range from 3 to 14.
For debugging purposes the driver provides a few files in the debug
filesystem (if available in the kernel). In /sys/kernel/debug/edt_ft5x06
you'll find the following files:
num_x, num_y:
(readonly) contains the number of sensor fields in X- and
Y-direction.
mode:
allows switching the sensor between "factory mode" and "operation
mode" by writing "1" or "0" to it. In factory mode (1) it is
possible to get the raw data from the sensor. Note that in factory
mode regular events don't get delivered and the options described
above are unavailable.
raw_data:
contains num_x * num_y big endian 16 bit values describing the raw
values for each sensor field. Note that each read() call on this
files triggers a new readout. It is recommended to provide a buffer
big enough to contain num_x * num_y * 2 bytes.
Note that reading raw_data gives a I/O error when the device is not in factory
mode. The same happens when reading/writing to the parameter files when the
device is not in regular operation mode.

Some files were not shown because too many files have changed in this diff Show more