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

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

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

* 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;

};

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.

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,

	},

};