From d4b347b29b4d14647c7394f7167bf6785dc98e50 Mon Sep 17 00:00:00 2001 From: Seth Forshee Date: Mon, 7 Nov 2011 19:53:15 -0800 Subject: Input: ALPS - move protocol information to Documentation In preparation for new protocol support, move the protocol information currently documented in alps.c to Documentation/input/alps.txt, where it can be expanded without cluttering up the driver. Signed-off-by: Seth Forshee Acked-by: Chase Douglas Signed-off-by: Dmitry Torokhov --- Documentation/input/alps.txt | 75 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 75 insertions(+) create mode 100644 Documentation/input/alps.txt (limited to 'Documentation') diff --git a/Documentation/input/alps.txt b/Documentation/input/alps.txt new file mode 100644 index 00000000000..ab5478f92a2 --- /dev/null +++ b/Documentation/input/alps.txt @@ -0,0 +1,75 @@ +ALPS Touchpad Protocol +---------------------- + +Introduction +------------ + +Currently the ALPS touchpad driver supports two protocol versions in use by +ALPS touchpads, the "old" and "new" protocol versions. Fundamentally these +differ only in the format of their event packets (in reality many features may +be found on new protocol devices that aren't found on the old protocol +devices, but these are handled transparently as feature differences rather +than protocol differences). + +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. + +Packet Format +------------- + +In the following tables, the following notation us 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 - Old Format +------------------------------- + + 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 - New Format +------------------------------- + + 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 -- cgit v1.2.3 From 7cf801cfc0774b777aa6861cf4a43a90b112b1ed Mon Sep 17 00:00:00 2001 From: Seth Forshee Date: Mon, 7 Nov 2011 19:54:35 -0800 Subject: Input: ALPS - add documentation for protocol versions 3 and 4 Also converts from using "old" and "new" to describe the already-known protocols to using "version 1" and "version 2" to match the code. Signed-off-by: Seth Forshee Acked-by: Chase Douglas Signed-off-by: Dmitry Torokhov --- Documentation/input/alps.txt | 135 +++++++++++++++++++++++++++++++++++++++---- 1 file changed, 124 insertions(+), 11 deletions(-) (limited to 'Documentation') diff --git a/Documentation/input/alps.txt b/Documentation/input/alps.txt index ab5478f92a2..f274c28b510 100644 --- a/Documentation/input/alps.txt +++ b/Documentation/input/alps.txt @@ -4,12 +4,9 @@ ALPS Touchpad Protocol Introduction ------------ -Currently the ALPS touchpad driver supports two protocol versions in use by -ALPS touchpads, the "old" and "new" protocol versions. Fundamentally these -differ only in the format of their event packets (in reality many features may -be found on new protocol devices that aren't found on the old protocol -devices, but these are handled transparently as feature differences rather -than protocol differences). +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 --------- @@ -22,10 +19,37 @@ 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 us used. +In the following tables, the following notation is used. CAPITALS = stick, miniscules = touchpad @@ -41,8 +65,8 @@ PS/2 packet format Note that the device never signals overflow condition. -ALPS Absolute Mode - Old Format -------------------------------- +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 @@ -51,8 +75,8 @@ ALPS Absolute Mode - Old Format byte 4: 0 y6 y5 y4 y3 y2 y1 y0 byte 5: 0 z6 z5 z4 z3 z2 z1 z0 -ALPS Absolute Mode - New Format -------------------------------- +ALPS Absolute Mode - Protocol Version 2 +--------------------------------------- byte 0: 1 ? ? ? 1 ? ? ? byte 1: 0 x6 x5 x4 x3 x2 x1 x0 @@ -73,3 +97,92 @@ Dualpoint device -- interleaved packet format 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. -- cgit v1.2.3 From 3bfd5c5baf66e975b0f365a0cda8d75bf2953ebe Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Heiko=20St=C3=BCbner?= Date: Tue, 29 Nov 2011 11:04:09 -0800 Subject: Input: add generic GPIO-tilt driver There exist tilt switches that simply report their tilt-state via some gpios. The number and orientation of their axes can vary depending on the switch used and the build of the device. Also two or more one-axis switches could be combined to provide multi-dimensional orientation. One example of a device using such a switch is the family of Qisda ebook readers, where the switch provides information about the landscape / portrait orientation of the device. The example in Documentation/input/gpio-tilt.txt documents exactly this one-axis device. Signed-off-by: Heiko Stuebner Signed-off-by: Dmitry Torokhov --- Documentation/input/gpio-tilt.txt | 103 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 103 insertions(+) create mode 100644 Documentation/input/gpio-tilt.txt (limited to 'Documentation') diff --git a/Documentation/input/gpio-tilt.txt b/Documentation/input/gpio-tilt.txt new file mode 100644 index 00000000000..06d60c3ff5e --- /dev/null +++ b/Documentation/input/gpio-tilt.txt @@ -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, + }, +}; -- cgit v1.2.3 From 246835fccdc0dadeda20cd51f7ec868031fa8142 Mon Sep 17 00:00:00 2001 From: Jason Gerecke Date: Mon, 12 Dec 2011 00:12:04 -0800 Subject: Input: wacom - add LED support for Cintiq 24HD The Cintiq 24HD has three LEDs on the left side of the tablet and three LEDs on the right side of the tablet. Switching to LED 0, 1, or 2 will enable the top, middle, or bottom LED for the respective side. Switching to LED 3 turns off the LEDs on the respective side. Signed-off-by: Jason Gerecke Reviewed-by: Ping Cheng Signed-off-by: Dmitry Torokhov --- Documentation/ABI/testing/sysfs-driver-wacom | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-driver-wacom b/Documentation/ABI/testing/sysfs-driver-wacom index 82d4df13644..0130d6683c1 100644 --- a/Documentation/ABI/testing/sysfs-driver-wacom +++ b/Documentation/ABI/testing/sysfs-driver-wacom @@ -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/-:./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/-:./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/-:./wacom_led/buttons_luminance Date: August 2011 -- cgit v1.2.3 From e24f734ef12571e7106d948208cc9aeae74de876 Mon Sep 17 00:00:00 2001 From: Tai-hwa Liang Date: Fri, 23 Dec 2011 01:14:28 -0800 Subject: Input: sentelic - document the latest hardware - Add documentation for the Cx/Dx hardware release; - Fix wrong register offset for retrieving button information; - Document programming sequence for page register R/W; - Document a couple of supported gesture IDs. Signed-off-by: Tai-hwa Liang Signed-off-by: Dmitry Torokhov --- Documentation/input/sentelic.txt | 364 +++++++++++++++++++++++++++++++++++---- 1 file changed, 333 insertions(+), 31 deletions(-) (limited to 'Documentation') diff --git a/Documentation/input/sentelic.txt b/Documentation/input/sentelic.txt index b2ef125b71f..89251e2a3eb 100644 --- a/Documentation/input/sentelic.txt +++ b/Documentation/input/sentelic.txt @@ -1,5 +1,5 @@ -Copyright (C) 2002-2010 Sentelic Corporation. -Last update: Jan-13-2010 +Copyright (C) 2002-2011 Sentelic Corporation. +Last update: Dec-07-2011 ============================================================================== * Finger Sensing Pad Intellimouse Mode(scrolling wheel, 4th and 5th buttons) @@ -140,6 +140,7 @@ BYTE |---------------|BYTE |---------------|BYTE|---------------|BYTE|--------- Byte 1: Bit7~Bit6 => 00, Normal data packet => 01, Absolute coordination packet => 10, Notify packet + => 11, Normal data packet with on-pad click Bit5 => Valid bit, 0 means that the coordinate is invalid or finger up. When both fingers are up, the last two reports have zero valid bit. @@ -164,6 +165,7 @@ BYTE |---------------|BYTE |---------------|BYTE|---------------|BYTE|--------- Byte 1: Bit7~Bit6 => 00, Normal data packet => 01, Absolute coordinates packet => 10, Notify packet + => 11, Normal data packet with on-pad click Bit5 => Valid bit, 0 means that the coordinate is invalid or finger up. When both fingers are up, the last two reports have zero valid bit. @@ -188,6 +190,7 @@ BYTE |---------------|BYTE |---------------|BYTE|---------------|BYTE|--------- Byte 1: Bit7~Bit6 => 00, Normal data packet => 01, Absolute coordinates packet => 10, Notify packet + => 11, Normal data packet with on-pad click Bit5 => 1 Bit4 => when in absolute coordinates mode (valid when EN_PKT_GO is 1): 0: left button is generated by the on-pad command @@ -205,7 +208,7 @@ Byte 4: Bit7 => scroll right button Bit6 => scroll left button Bit5 => scroll down button Bit4 => scroll up button - * Note that if gesture and additional buttoni (Bit4~Bit7) + * Note that if gesture and additional button (Bit4~Bit7) happen at the same time, the button information will not be sent. Bit3~Bit0 => Reserved @@ -227,6 +230,7 @@ BYTE |---------------|BYTE |---------------|BYTE|---------------|BYTE|--------- Byte 1: Bit7~Bit6 => 00, Normal data packet => 01, Absolute coordinates packet => 10, Notify packet + => 11, Normal data packet with on-pad click Bit5 => Valid bit, 0 means that the coordinate is invalid or finger up. When both fingers are up, the last two reports have zero valid bit. @@ -253,6 +257,7 @@ BYTE |---------------|BYTE |---------------|BYTE|---------------|BYTE|--------- Byte 1: Bit7~Bit6 => 00, Normal data packet => 01, Absolute coordination packet => 10, Notify packet + => 11, Normal data packet with on-pad click Bit5 => Valid bit, 0 means that the coordinate is invalid or finger up. When both fingers are up, the last two reports have zero valid bit. @@ -279,8 +284,9 @@ BYTE |---------------|BYTE |---------------|BYTE|---------------|BYTE|--------- Byte 1: Bit7~Bit6 => 00, Normal data packet => 01, Absolute coordination packet => 10, Notify packet + => 11, Normal data packet with on-pad click Bit5 => 1 - Bit4 => when in absolute coordinate mode (valid when EN_PKT_GO is 1): + Bit4 => when in absolute coordinates mode (valid when EN_PKT_GO is 1): 0: left button is generated by the on-pad command 1: left button is generated by the external button Bit3 => 1 @@ -306,6 +312,110 @@ Sample sequence of Multi-finger, Multi-coordinate mode: notify packet (valid bit == 1), abs pkt 1, abs pkt 2, abs pkt 1, abs pkt 2, ..., notify packet (valid bit == 0) +============================================================================== +* Absolute position for STL3888-Cx and STL3888-Dx. +============================================================================== +Single Finger, Absolute Coordinate Mode (SFAC) + Bit 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 +BYTE |---------------|BYTE |---------------|BYTE|---------------|BYTE|---------------| + 1 |0|1|0|P|1|M|R|L| 2 |X|X|X|X|X|X|X|X| 3 |Y|Y|Y|Y|Y|Y|Y|Y| 4 |r|l|B|F|X|X|Y|Y| + |---------------| |---------------| |---------------| |---------------| + +Byte 1: Bit7~Bit6 => 00, Normal data packet + => 01, Absolute coordinates packet + => 10, Notify packet + Bit5 => Coordinate mode(always 0 in SFAC mode): + 0: single-finger absolute coordinates (SFAC) mode + 1: multi-finger, multiple coordinates (MFMC) mode + Bit4 => 0: The LEFT button is generated by on-pad command (OPC) + 1: The LEFT button is generated by external button + Default is 1 even if the LEFT button is not pressed. + Bit3 => Always 1, as specified by PS/2 protocol. + Bit2 => Middle Button, 1 is pressed, 0 is not pressed. + Bit1 => Right Button, 1 is pressed, 0 is not pressed. + Bit0 => Left Button, 1 is pressed, 0 is not pressed. +Byte 2: X coordinate (xpos[9:2]) +Byte 3: Y coordinate (ypos[9:2]) +Byte 4: Bit1~Bit0 => Y coordinate (xpos[1:0]) + Bit3~Bit2 => X coordinate (ypos[1:0]) + Bit4 => 4th mouse button(forward one page) + Bit5 => 5th mouse button(backward one page) + Bit6 => scroll left button + Bit7 => scroll right button + +Multi Finger, Multiple Coordinates Mode (MFMC): + Bit 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 +BYTE |---------------|BYTE |---------------|BYTE|---------------|BYTE|---------------| + 1 |0|1|1|P|1|F|R|L| 2 |X|X|X|X|X|X|X|X| 3 |Y|Y|Y|Y|Y|Y|Y|Y| 4 |r|l|B|F|X|X|Y|Y| + |---------------| |---------------| |---------------| |---------------| + +Byte 1: Bit7~Bit6 => 00, Normal data packet + => 01, Absolute coordination packet + => 10, Notify packet + Bit5 => Coordinate mode (always 1 in MFMC mode): + 0: single-finger absolute coordinates (SFAC) mode + 1: multi-finger, multiple coordinates (MFMC) mode + Bit4 => 0: The LEFT button is generated by on-pad command (OPC) + 1: The LEFT button is generated by external button + Default is 1 even if the LEFT button is not pressed. + Bit3 => Always 1, as specified by PS/2 protocol. + Bit2 => Finger index, 0 is the first finger, 1 is the second finger. + If bit 1 and 0 are all 1 and bit 4 is 0, the middle external + button is pressed. + Bit1 => Right Button, 1 is pressed, 0 is not pressed. + Bit0 => Left Button, 1 is pressed, 0 is not pressed. +Byte 2: X coordinate (xpos[9:2]) +Byte 3: Y coordinate (ypos[9:2]) +Byte 4: Bit1~Bit0 => Y coordinate (xpos[1:0]) + Bit3~Bit2 => X coordinate (ypos[1:0]) + Bit4 => 4th mouse button(forward one page) + Bit5 => 5th mouse button(backward one page) + Bit6 => scroll left button + Bit7 => scroll right button + + When one of the two fingers is up, the device will output four consecutive +MFMC#0 report packets with zero X and Y to represent 1st finger is up or +four consecutive MFMC#1 report packets with zero X and Y to represent that +the 2nd finger is up. On the other hand, if both fingers are up, the device +will output four consecutive single-finger, absolute coordinate(SFAC) packets +with zero X and Y. + +Notify Packet for STL3888-Cx/Dx + Bit 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 +BYTE |---------------|BYTE |---------------|BYTE|---------------|BYTE|---------------| + 1 |1|0|0|P|1|M|R|L| 2 |C|C|C|C|C|C|C|C| 3 |0|0|F|F|0|0|0|i| 4 |r|l|u|d|0|0|0|0| + |---------------| |---------------| |---------------| |---------------| + +Byte 1: Bit7~Bit6 => 00, Normal data packet + => 01, Absolute coordinates packet + => 10, Notify packet + Bit5 => Always 0 + Bit4 => 0: The LEFT button is generated by on-pad command(OPC) + 1: The LEFT button is generated by external button + Default is 1 even if the LEFT button is not pressed. + Bit3 => 1 + Bit2 => Middle Button, 1 is pressed, 0 is not pressed. + Bit1 => Right Button, 1 is pressed, 0 is not pressed. + Bit0 => Left Button, 1 is pressed, 0 is not pressed. +Byte 2: Message type: + 0xba => gesture information + 0xc0 => one finger hold-rotating gesture +Byte 3: The first parameter for the received message: + 0xba => gesture ID (refer to the 'Gesture ID' section) + 0xc0 => region ID +Byte 4: The second parameter for the received message: + 0xba => N/A + 0xc0 => finger up/down information + +Sample sequence of Multi-finger, Multi-coordinates mode: + + notify packet (valid bit == 1), MFMC packet 1 (byte 1, bit 2 == 0), + MFMC packet 2 (byte 1, bit 2 == 1), MFMC packet 1, MFMC packet 2, + ..., notify packet (valid bit == 0) + + That is, when the device is in MFMC mode, the host will receive + interleaved absolute coordinate packets for each finger. + ============================================================================== * FSP Enable/Disable packet ============================================================================== @@ -348,9 +458,10 @@ http://www.computer-engineering.org/ps2mouse/ ============================================================================== 1. Identify FSP by reading device ID(0x00) and version(0x01) register -2. Determine number of buttons by reading status2 (0x0b) register +2a. For FSP version < STL3888 Cx, determine number of buttons by reading + the 'test mode status' (0x20) register: - buttons = reg[0x0b] & 0x30 + buttons = reg[0x20] & 0x30 if buttons == 0x30 or buttons == 0x20: # two/four buttons @@ -365,6 +476,10 @@ http://www.computer-engineering.org/ps2mouse/ Refer to 'Finger Sensing Pad PS/2 Mouse Intellimouse' section A for packet parsing detail +2b. For FSP version >= STL3888 Cx: + Refer to 'Finger Sensing Pad PS/2 Mouse Intellimouse' + section A for packet parsing detail (ignore byte 4, bit ~ 7) + ============================================================================== * Programming Sequence for Register Reading/Writing ============================================================================== @@ -374,7 +489,7 @@ Register inversion requirement: Following values needed to be inverted(the '~' operator in C) before being sent to FSP: - 0xe9, 0xee, 0xf2 and 0xff. + 0xe8, 0xe9, 0xee, 0xf2, 0xf3 and 0xff. Register swapping requirement: @@ -415,7 +530,18 @@ Register reading sequence: 8. send 0xe9(status request) PS/2 command to FSP; - 9. the response read from FSP should be the requested register value. + 9. the 4th byte of the response read from FSP should be the + requested register value(?? indicates don't care byte): + + host: 0xe9 + 3888: 0xfa (??) (??) (val) + + * Note that since the Cx release, the hardware will return 1's + complement of the register value at the 3rd byte of status request + result: + + host: 0xe9 + 3888: 0xfa (??) (~val) (val) Register writing sequence: @@ -465,71 +591,194 @@ Register writing sequence: 9. the register writing sequence is completed. + * Note that since the Cx release, the hardware will return 1's + complement of the register value at the 3rd byte of status request + result. Host can optionally send another 0xe9 (status request) PS/2 + command to FSP at the end of register writing to verify that the + register writing operation is successful (?? indicates don't care + byte): + + host: 0xe9 + 3888: 0xfa (??) (~val) (val) + +============================================================================== +* Programming Sequence for Page Register Reading/Writing +============================================================================== + + In order to overcome the limitation of maximum number of registers +supported, the hardware separates register into different groups called +'pages.' Each page is able to include up to 255 registers. + + The default page after power up is 0x82; therefore, if one has to get +access to register 0x8301, one has to use following sequence to switch +to page 0x83, then start reading/writing from/to offset 0x01 by using +the register read/write sequence described in previous section. + +Page register reading sequence: + + 1. send 0xf3 PS/2 command to FSP; + + 2. send 0x66 PS/2 command to FSP; + + 3. send 0x88 PS/2 command to FSP; + + 4. send 0xf3 PS/2 command to FSP; + + 5. send 0x83 PS/2 command to FSP; + + 6. send 0x88 PS/2 command to FSP; + + 7. send 0xe9(status request) PS/2 command to FSP; + + 8. the response read from FSP should be the requested page value. + +Page register writing sequence: + + 1. send 0xf3 PS/2 command to FSP; + + 2. send 0x38 PS/2 command to FSP; + + 3. send 0x88 PS/2 command to FSP; + + 4. send 0xf3 PS/2 command to FSP; + + 5. if the page address being written is not required to be + inverted(refer to the 'Register inversion requirement' section), + goto step 6 + + 5a. send 0x47 PS/2 command to FSP; + + 5b. send the inverted page address to FSP and goto step 9; + + 6. if the page address being written is not required to be + swapped(refer to the 'Register swapping requirement' section), + goto step 7 + + 6a. send 0x44 PS/2 command to FSP; + + 6b. send the swapped page address to FSP and goto step 9; + + 7. send 0x33 PS/2 command to FSP; + + 8. send the page address to FSP; + + 9. the page register writing sequence is completed. + +============================================================================== +* Gesture ID +============================================================================== + + Unlike other devices which sends multiple fingers' coordinates to host, +FSP processes multiple fingers' coordinates internally and convert them +into a 8 bits integer, namely 'Gesture ID.' Following is a list of +supported gesture IDs: + + ID Description + 0x86 2 finger straight up + 0x82 2 finger straight down + 0x80 2 finger straight right + 0x84 2 finger straight left + 0x8f 2 finger zoom in + 0x8b 2 finger zoom out + 0xc0 2 finger curve, counter clockwise + 0xc4 2 finger curve, clockwise + 0x2e 3 finger straight up + 0x2a 3 finger straight down + 0x28 3 finger straight right + 0x2c 3 finger straight left + 0x38 palm + ============================================================================== * Register Listing ============================================================================== + Registers are represented in 16 bits values. The higher 8 bits represent +the page address and the lower 8 bits represent the relative offset within +that particular page. Refer to the 'Programming Sequence for Page Register +Reading/Writing' section for instructions on how to change current page +address. + offset width default r/w name -0x00 bit7~bit0 0x01 RO device ID +0x8200 bit7~bit0 0x01 RO device ID -0x01 bit7~bit0 0xc0 RW version ID +0x8201 bit7~bit0 RW version ID + 0xc1: STL3888 Ax + 0xd0 ~ 0xd2: STL3888 Bx + 0xe0 ~ 0xe1: STL3888 Cx + 0xe2 ~ 0xe3: STL3888 Dx -0x02 bit7~bit0 0x01 RO vendor ID +0x8202 bit7~bit0 0x01 RO vendor ID -0x03 bit7~bit0 0x01 RO product ID +0x8203 bit7~bit0 0x01 RO product ID -0x04 bit3~bit0 0x01 RW revision ID +0x8204 bit3~bit0 0x01 RW revision ID -0x0b RO test mode status 1 - bit3 1 RO 0: rotate 180 degree, 1: no rotation +0x820b test mode status 1 + bit3 1 RO 0: rotate 180 degree + 1: no rotation + *only supported by H/W prior to Cx - bit5~bit4 RO number of buttons - 11 => 2, lbtn/rbtn - 10 => 4, lbtn/rbtn/scru/scrd - 01 => 6, lbtn/rbtn/scru/scrd/scrl/scrr - 00 => 6, lbtn/rbtn/scru/scrd/fbtn/bbtn +0x820f register file page control + bit2 0 RW 1: rotate 180 degree + 0: no rotation + *supported since Cx -0x0f RW register file page control bit0 0 RW 1 to enable page 1 register files + *only supported by H/W prior to Cx -0x10 RW system control 1 +0x8210 RW system control 1 bit0 1 RW Reserved, must be 1 bit1 0 RW Reserved, must be 0 - bit4 1 RW Reserved, must be 0 - bit5 0 RW register clock gating enable + bit4 0 RW Reserved, must be 0 + bit5 1 RW register clock gating enable 0: read only, 1: read/write enable (Note that following registers does not require clock gating being enabled prior to write: 05 06 07 08 09 0c 0f 10 11 12 16 17 18 23 2e 40 41 42 43. In addition to that, this bit must be 1 when gesture mode is enabled) -0x31 RW on-pad command detection +0x8220 test mode status + bit5~bit4 RO number of buttons + 11 => 2, lbtn/rbtn + 10 => 4, lbtn/rbtn/scru/scrd + 01 => 6, lbtn/rbtn/scru/scrd/scrl/scrr + 00 => 6, lbtn/rbtn/scru/scrd/fbtn/bbtn + *only supported by H/W prior to Cx + +0x8231 RW on-pad command detection bit7 0 RW on-pad command left button down tag enable 0: disable, 1: enable + *only supported by H/W prior to Cx -0x34 RW on-pad command control 5 +0x8234 RW on-pad command control 5 bit4~bit0 0x05 RW XLO in 0s/4/1, so 03h = 0010.1b = 2.5 (Note that position unit is in 0.5 scanline) + *only supported by H/W prior to Cx bit7 0 RW on-pad tap zone enable 0: disable, 1: enable + *only supported by H/W prior to Cx -0x35 RW on-pad command control 6 +0x8235 RW on-pad command control 6 bit4~bit0 0x1d RW XHI in 0s/4/1, so 19h = 1100.1b = 12.5 (Note that position unit is in 0.5 scanline) + *only supported by H/W prior to Cx -0x36 RW on-pad command control 7 +0x8236 RW on-pad command control 7 bit4~bit0 0x04 RW YLO in 0s/4/1, so 03h = 0010.1b = 2.5 (Note that position unit is in 0.5 scanline) + *only supported by H/W prior to Cx -0x37 RW on-pad command control 8 +0x8237 RW on-pad command control 8 bit4~bit0 0x13 RW YHI in 0s/4/1, so 11h = 1000.1b = 8.5 (Note that position unit is in 0.5 scanline) + *only supported by H/W prior to Cx -0x40 RW system control 5 +0x8240 RW system control 5 bit1 0 RW FSP Intellimouse mode enable 0: disable, 1: enable + *only supported by H/W prior to Cx bit2 0 RW movement + abs. coordinate mode enable 0: disable, 1: enable @@ -537,6 +786,7 @@ offset width default r/w name bit 1 is not set. However, the format is different from that of bit 1. In addition, when bit 1 and bit 2 are set at the same time, bit 2 will override bit 1.) + *only supported by H/W prior to Cx bit3 0 RW abs. coordinate only mode enable 0: disable, 1: enable @@ -544,9 +794,11 @@ offset width default r/w name bit 1 is not set. However, the format is different from that of bit 1. In addition, when bit 1, bit 2 and bit 3 are set at the same time, bit 3 will override bit 1 and 2.) + *only supported by H/W prior to Cx bit5 0 RW auto switch enable 0: disable, 1: enable + *only supported by H/W prior to Cx bit6 0 RW G0 abs. + notify packet format enable 0: disable, 1: enable @@ -554,18 +806,68 @@ offset width default r/w name bit 2 and 3. That is, if any of those bit is 1, host will receive absolute coordinates; otherwise, host only receives packets with relative coordinate.) + *only supported by H/W prior to Cx bit7 0 RW EN_PS2_F2: PS/2 gesture mode 2nd finger packet enable 0: disable, 1: enable + *only supported by H/W prior to Cx -0x43 RW on-pad control +0x8243 RW on-pad control bit0 0 RW on-pad control enable 0: disable, 1: enable (Note that if this bit is cleared, bit 3/5 will be ineffective) + *only supported by H/W prior to Cx bit3 0 RW on-pad fix vertical scrolling enable 0: disable, 1: enable + *only supported by H/W prior to Cx bit5 0 RW on-pad fix horizontal scrolling enable 0: disable, 1: enable + *only supported by H/W prior to Cx + +0x8290 RW software control register 1 + bit0 0 RW absolute coordination mode + 0: disable, 1: enable + *supported since Cx + + bit1 0 RW gesture ID output + 0: disable, 1: enable + *supported since Cx + + bit2 0 RW two fingers' coordinates output + 0: disable, 1: enable + *supported since Cx + + bit3 0 RW finger up one packet output + 0: disable, 1: enable + *supported since Cx + + bit4 0 RW absolute coordination continuous mode + 0: disable, 1: enable + *supported since Cx + + bit6~bit5 00 RW gesture group selection + 00: basic + 01: suite + 10: suite pro + 11: advanced + *supported since Cx + + bit7 0 RW Bx packet output compatible mode + 0: disable, 1: enable *supported since Cx + *supported since Cx + + +0x833d RW on-pad command control 1 + bit7 1 RW on-pad command detection enable + 0: disable, 1: enable + *supported since Cx + +0x833e RW on-pad command detection + bit7 0 RW on-pad command left button down tag + enable. Works only in H/W based PS/2 + data packet mode. + 0: disable, 1: enable + *supported since Cx -- cgit v1.2.3 From a445c7f0afb9114ef3de2d123f2c851787cf9d11 Mon Sep 17 00:00:00 2001 From: Olof Johansson Date: Thu, 29 Dec 2011 09:58:16 -0800 Subject: Input: tegra-kbc - add device tree bindings This adds a simple device tree binding to the tegra keyboard controller. Also, mark the default keymap as __devinitdata since it is not referenced after boot. Signed-off-by: Olof Johansson Signed-off-by: Dmitry Torokhov --- Documentation/devicetree/bindings/input/tegra-kbc.txt | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) create mode 100644 Documentation/devicetree/bindings/input/tegra-kbc.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/input/tegra-kbc.txt b/Documentation/devicetree/bindings/input/tegra-kbc.txt new file mode 100644 index 00000000000..5ecfa99089b --- /dev/null +++ b/Documentation/devicetree/bindings/input/tegra-kbc.txt @@ -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; +}; -- cgit v1.2.3