From patchwork Sat Apr 1 18:15:53 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mauro Carvalho Chehab X-Patchwork-Id: 9658173 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id BE7B560353 for ; Sat, 1 Apr 2017 18:17:17 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 96129205A4 for ; Sat, 1 Apr 2017 18:17:17 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 8AFF527317; Sat, 1 Apr 2017 18:17:17 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 4FDA9205A4 for ; Sat, 1 Apr 2017 18:17:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752029AbdDASRL (ORCPT ); Sat, 1 Apr 2017 14:17:11 -0400 Received: from bombadil.infradead.org ([65.50.211.133]:33502 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752014AbdDASQh (ORCPT ); Sat, 1 Apr 2017 14:16:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=Sender:References:In-Reply-To: Message-Id:Date:Subject:Cc:To:From:Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=NqMOY1CtL0eNfIzWLuPnF4w1c1ueaJVR5aMirBAIR4Y=; b=QCpm6/NZ6MVvF0/+xGWKdchLs GJ2ZnOcbrU9IOGea/3BYuZU8w3LDGu6cpajufe6Sa5A9dIZ98HYA6qeg1ucebpxtHnv8MECaANBik XKura6BVnsgiw09mbxpci0whhPMaNHM65DDVxMu2z7RX9nxqH7UL+GAzinTFHDyTgQRGng22kGPKM jDusMiZ3Tlg/j70DJPffog7/7Kvn0hI1OPDdIMsHOLvgl8B0fKZOqbarGm1pVko+bQECUistx2aaV s1WlWAJd1K6PInYiNNZ+4tKZdvsTbJNNJjroT4MGnxmAOhK/EGMq+NAj69f3zBJaXsandznm36nko FHEKD/5cA==; Received: from [191.33.187.215] (helo=smtp.w2.samsung.com) by bombadil.infradead.org with esmtpsa (Exim 4.87 #1 (Red Hat Linux)) id 1cuNZe-0005dO-Sr; Sat, 01 Apr 2017 18:16:31 +0000 Received: from mchehab by smtp.w2.samsung.com with local (Exim 4.87) (envelope-from ) id 1cuNZR-0002Z6-Sz; Sat, 01 Apr 2017 15:16:17 -0300 From: Mauro Carvalho Chehab To: linux-input@vger.kernel.org, Dmitry Torokhov Cc: Mauro Carvalho Chehab , Linux Doc Mailing List , Jonathan Corbet Subject: [PATCH 10/33] docs: input/elantech: convert it to ReST format Date: Sat, 1 Apr 2017 15:15:53 -0300 Message-Id: X-Mailer: git-send-email 2.9.3 In-Reply-To: References: <1756e375bc7fbc9daae3ca1267cb96972d7962a2.1491069870.git.mchehab@s-opensource.com> <40f1698c0fe55c303f70eac042540c1ce3b76385.1491069870.git.mchehab@s-opensource.com> <564bab77d213c4995418de5debc9149f01b44c67.1491069870.git.mchehab@s-opensource.com> <57e5da3e598139b8ab24ff1dda1afaa612bd3e9b.1491069870.git.mchehab@s-opensource.com> <55ed0f35fc4dc65436ef2cf4abcf5e458b70add7.1491069870.git.mchehab@s-opensource.com> In-Reply-To: References: Sender: linux-input-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-input@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP This file require minimum adjustments to be a valid ReST file. Do it, in order to be able to parse it with Sphinx. We opted to remove section numbers, as this can be automatically generated on Sphinx, by using :numbered: tag at index. Signed-off-by: Mauro Carvalho Chehab --- Documentation/input/elantech.txt | 306 +++++++++++++++++++++------------------ 1 file changed, 165 insertions(+), 141 deletions(-) diff --git a/Documentation/input/elantech.txt b/Documentation/input/elantech.txt index 1ec0db7879d3..bb1302246506 100644 --- a/Documentation/input/elantech.txt +++ b/Documentation/input/elantech.txt @@ -10,9 +10,7 @@ Elantech Touchpad Driver received from Woody at Xandros and forwarded to me by user StewieGriffin at the eeeuser.com forum - -Contents -~~~~~~~~ +.. Contents 1. Introduction 2. Extra knobs @@ -45,8 +43,8 @@ Contents -1. Introduction - ~~~~~~~~~~~~ +Introduction +~~~~~~~~~~~~ Currently the Linux Elantech touchpad driver is aware of four different hardware versions unimaginatively called version 1,version 2, version 3 @@ -88,11 +86,8 @@ available Elantech documentation the information is provided here anyway for completeness sake. -///////////////////////////////////////////////////////////////////////////// - - -2. Extra knobs - ~~~~~~~~~~~ +Extra knobs +~~~~~~~~~~~ Currently the Linux Elantech touchpad driver provides three extra knobs under /sys/bus/serio/drivers/psmouse/serio? for the user. @@ -142,18 +137,17 @@ Currently the Linux Elantech touchpad driver provides three extra knobs under Reading the crc_enabled value will show the active value. Echoing "0" or "1" to this file will set the state to "0" or "1". -///////////////////////////////////////////////////////////////////////////// +Differentiating hardware versions +================================= -3. Differentiating hardware versions - ================================= - -To detect the hardware version, read the version number as param[0].param[1].param[2] +To detect the hardware version, read the version number as param[0].param[1].param[2]:: 4 bytes version: (after the arrow is the name given in the Dell-provided driver) 02.00.22 => EF013 02.06.00 => EF019 + In the wild, there appear to be more versions, such as 00.01.64, 01.00.21, -02.00.00, 02.00.04, 02.00.06. +02.00.00, 02.00.04, 02.00.06:: 6 bytes: 02.00.30 => EF113 @@ -162,6 +156,7 @@ In the wild, there appear to be more versions, such as 00.01.64, 01.00.21, 02.0B.00 => EF215 04.01.XX => Scroll_EF051 04.02.XX => EF051 + In the wild, there appear to be more versions, such as 04.03.01, 04.04.11. There appears to be almost no difference, except for EF113, which does not report pressure/width and has different data consistency checks. @@ -170,21 +165,20 @@ Probably all the versions with param[0] <= 01 can be considered as 4 bytes/firmware 1. The versions < 02.08.00, with the exception of 02.00.30, as 4 bytes/firmware 2. Everything >= 02.08.00 can be considered as 6 bytes. -///////////////////////////////////////////////////////////////////////////// -4. Hardware version 1 - ================== +Hardware version 1 +~~~~~~~~~~~~~~~~~~ -4.1 Registers - ~~~~~~~~~ +Registers +--------- By echoing a hexadecimal value to a register it contents can be altered. -For example: +For example:: echo -n 0x16 > reg_10 -* reg_10 +* reg_10:: bit 7 6 5 4 3 2 1 0 B C T D L A S E @@ -198,7 +192,7 @@ For example: C: 1 = enable corner tap B: 1 = swap left and right button -* reg_11 +* reg_11:: bit 7 6 5 4 3 2 1 0 1 0 0 H V 1 F P @@ -208,40 +202,41 @@ For example: V: 1 = enable vertical scroll area H: 1 = enable horizontal scroll area -* reg_20 +* reg_20:: single finger width? -* reg_21 +* reg_21:: scroll area width (small: 0x40 ... wide: 0xff) -* reg_22 +* reg_22:: drag lock time out (short: 0x14 ... long: 0xfe; 0xff = tap again to release) -* reg_23 +* reg_23:: tap make timeout? -* reg_24 +* reg_24:: tap release timeout? -* reg_25 +* reg_25:: smart edge cursor speed (0x02 = slow, 0x03 = medium, 0x04 = fast) -* reg_26 +* reg_26:: smart edge activation area width? -4.2 Native relative mode 4 byte packet format - ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Native relative mode 4 byte packet format +----------------------------------------- + +byte 0:: -byte 0: bit 7 6 5 4 3 2 1 0 c c p2 p1 1 M R L @@ -251,20 +246,23 @@ byte 0: p1..p2 = byte 1 and 2 odd parity bit c = 1 when corner tap detected -byte 1: +byte 1:: + bit 7 6 5 4 3 2 1 0 dx7 dx6 dx5 dx4 dx3 dx2 dx1 dx0 dx7..dx0 = x movement; positive = right, negative = left byte 1 = 0xf0 when corner tap detected -byte 2: +byte 2:: + bit 7 6 5 4 3 2 1 0 dy7 dy6 dy5 dy4 dy3 dy2 dy1 dy0 dy7..dy0 = y movement; positive = up, negative = down -byte 3: +byte 3:: + parity checking enabled (reg_11, P = 1): bit 7 6 5 4 3 2 1 0 @@ -296,14 +294,15 @@ byte 3: positive = down -4.3 Native absolute mode 4 byte packet format - ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Native absolute mode 4 byte packet format +----------------------------------------- EF013 and EF019 have a special behaviour (due to a bug in the firmware?), and when 1 finger is touching, the first 2 position reports must be discarded. This counting is reset whenever a different number of fingers is reported. -byte 0: +byte 0:: + firmware version 1.x: bit 7 6 5 4 3 2 1 0 @@ -322,7 +321,8 @@ byte 0: p1..p3 = byte 1..3 odd parity bit n1..n0 = number of fingers on touchpad -byte 1: +byte 1:: + firmware version 1.x: bit 7 6 5 4 3 2 1 0 @@ -337,65 +337,68 @@ byte 1: bit 7 6 5 4 3 2 1 0 . . . . x9 x8 y9 y8 -byte 2: +byte 2:: + bit 7 6 5 4 3 2 1 0 x7 x6 x5 x4 x3 x2 x1 x0 x9..x0 = absolute x value (horizontal) -byte 3: +byte 3:: + bit 7 6 5 4 3 2 1 0 y7 y6 y5 y4 y3 y2 y1 y0 y9..y0 = absolute y value (vertical) -///////////////////////////////////////////////////////////////////////////// +Hardware version 2 +~~~~~~~~~~~~~~~~~~ -5. Hardware version 2 - ================== - - -5.1 Registers - ~~~~~~~~~ +Registers +--------- By echoing a hexadecimal value to a register it contents can be altered. -For example: +For example:: echo -n 0x56 > reg_10 -* reg_10 +* reg_10:: bit 7 6 5 4 3 2 1 0 0 1 0 1 0 1 D 0 D: 1 = enable drag and drop -* reg_11 +* reg_11:: bit 7 6 5 4 3 2 1 0 1 0 0 0 S 0 1 0 S: 1 = enable vertical scroll -* reg_21 +* reg_21:: unknown (0x00) -* reg_22 +* reg_22:: drag and drop release time out (short: 0x70 ... long 0x7e; 0x7f = never i.e. tap again to release) -5.2 Native absolute mode 6 byte packet format - ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -5.2.1 Parity checking and packet re-synchronization +Native absolute mode 6 byte packet format +----------------------------------------- + +Parity checking and packet re-synchronization +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + There is no parity checking, however some consistency checks can be performed. -For instance for EF113: +For instance for EF113:: + SA1= packet[0]; A1 = packet[1]; B1 = packet[2]; @@ -410,7 +413,8 @@ For instance for EF113: (((SA1 & 0xC0) != 0x80) && (( C1 & 0xF0) != 0x00)) ) // check Byte 5 // error detected -For all the other ones, there are just a few constant bits: +For all the other ones, there are just a few constant bits:: + if( ((packet[0] & 0x0C) != 0x04) || ((packet[3] & 0x0f) != 0x02) ) // error detected @@ -418,10 +422,10 @@ For all the other ones, there are just a few constant bits: In case an error is detected, all the packets are shifted by one (and packet[0] is discarded). -5.2.2 One/Three finger touch - ~~~~~~~~~~~~~~~~ +One/Three finger touch +^^^^^^^^^^^^^^^^^^^^^^ -byte 0: +byte 0:: bit 7 6 5 4 3 2 1 0 n1 n0 w3 w2 . . R L @@ -429,19 +433,19 @@ byte 0: L, R = 1 when Left, Right mouse button pressed n1..n0 = number of fingers on touchpad -byte 1: +byte 1:: bit 7 6 5 4 3 2 1 0 p7 p6 p5 p4 x11 x10 x9 x8 -byte 2: +byte 2:: bit 7 6 5 4 3 2 1 0 x7 x6 x5 x4 x3 x2 x1 x0 x11..x0 = absolute x value (horizontal) -byte 3: +byte 3:: bit 7 6 5 4 3 2 1 0 n4 vf w1 w0 . . . b2 @@ -460,14 +464,14 @@ byte 3: 6 = Another one 7 = Another one -byte 4: +byte 4:: bit 7 6 5 4 3 2 1 0 p3 p1 p2 p0 y11 y10 y9 y8 p7..p0 = pressure (not EF113) -byte 5: +byte 5:: bit 7 6 5 4 3 2 1 0 y7 y6 y5 y4 y3 y2 y1 y0 @@ -475,15 +479,15 @@ byte 5: y11..y0 = absolute y value (vertical) -5.2.3 Two finger touch - ~~~~~~~~~~~~~~~~ +Two finger touch +^^^^^^^^^^^^^^^^ Note that the two pairs of coordinates are not exactly the coordinates of the two fingers, but only the pair of the lower-left and upper-right coordinates. So the actual fingers might be situated on the other diagonal of the square defined by these two points. -byte 0: +byte 0:: bit 7 6 5 4 3 2 1 0 n1 n0 ay8 ax8 . . R L @@ -491,47 +495,46 @@ byte 0: L, R = 1 when Left, Right mouse button pressed n1..n0 = number of fingers on touchpad -byte 1: +byte 1:: bit 7 6 5 4 3 2 1 0 ax7 ax6 ax5 ax4 ax3 ax2 ax1 ax0 ax8..ax0 = lower-left finger absolute x value -byte 2: +byte 2:: bit 7 6 5 4 3 2 1 0 ay7 ay6 ay5 ay4 ay3 ay2 ay1 ay0 ay8..ay0 = lower-left finger absolute y value -byte 3: +byte 3:: bit 7 6 5 4 3 2 1 0 . . by8 bx8 . . . . -byte 4: +byte 4:: bit 7 6 5 4 3 2 1 0 bx7 bx6 bx5 bx4 bx3 bx2 bx1 bx0 bx8..bx0 = upper-right finger absolute x value -byte 5: +byte 5:: bit 7 6 5 4 3 2 1 0 by7 by8 by5 by4 by3 by2 by1 by0 by8..by0 = upper-right finger absolute y value -///////////////////////////////////////////////////////////////////////////// +Hardware version 3 +~~~~~~~~~~~~~~~~~~ -6. Hardware version 3 - ================== +Registers +--------- -6.1 Registers - ~~~~~~~~~ -* reg_10 +* reg_10:: bit 7 6 5 4 3 2 1 0 0 0 0 0 R F T A @@ -541,8 +544,9 @@ byte 5: F: 1 = disable ABS Position Filter R: 1 = enable real hardware resolution -6.2 Native absolute mode 6 byte packet format - ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Native absolute mode 6 byte packet format +----------------------------------------- + 1 and 3 finger touch shares the same 6-byte packet format, except that 3 finger touch only reports the position of the center of all three fingers. @@ -552,19 +556,21 @@ Note on debounce: In case the box has unstable power supply or other electricity issues, or when number of finger changes, F/W would send "debounce packet" to inform driver that the hardware is in debounce status. -The debouce packet has the following signature: +The debouce packet has the following signature:: + byte 0: 0xc4 byte 1: 0xff byte 2: 0xff byte 3: 0x02 byte 4: 0xff byte 5: 0xff + When we encounter this kind of packet, we just ignore it. -6.2.1 One/Three finger touch - ~~~~~~~~~~~~~~~~~~~~~~ +One/Three finger touch +^^^^^^^^^^^^^^^^^^^^^^ -byte 0: +byte 0:: bit 7 6 5 4 3 2 1 0 n1 n0 w3 w2 0 1 R L @@ -572,63 +578,63 @@ byte 0: L, R = 1 when Left, Right mouse button pressed n1..n0 = number of fingers on touchpad -byte 1: +byte 1:: bit 7 6 5 4 3 2 1 0 p7 p6 p5 p4 x11 x10 x9 x8 -byte 2: +byte 2:: bit 7 6 5 4 3 2 1 0 x7 x6 x5 x4 x3 x2 x1 x0 x11..x0 = absolute x value (horizontal) -byte 3: +byte 3:: bit 7 6 5 4 3 2 1 0 0 0 w1 w0 0 0 1 0 w3..w0 = width of the finger touch -byte 4: +byte 4:: bit 7 6 5 4 3 2 1 0 p3 p1 p2 p0 y11 y10 y9 y8 p7..p0 = pressure -byte 5: +byte 5:: bit 7 6 5 4 3 2 1 0 y7 y6 y5 y4 y3 y2 y1 y0 y11..y0 = absolute y value (vertical) -6.2.2 Two finger touch - ~~~~~~~~~~~~~~~~ +Two finger touch +^^^^^^^^^^^^^^^^ The packet format is exactly the same for two finger touch, except the hardware sends two 6 byte packets. The first packet contains data for the first finger, the second packet has data for the second finger. So for two finger touch a total of 12 bytes are sent. -///////////////////////////////////////////////////////////////////////////// +Hardware version 4 +~~~~~~~~~~~~~~~~~~ -7. Hardware version 4 - ================== +Registers +--------- -7.1 Registers - ~~~~~~~~~ -* reg_07 +* reg_07:: bit 7 6 5 4 3 2 1 0 0 0 0 0 0 0 0 A A: 1 = enable absolute tracking -7.2 Native absolute mode 6 byte packet format - ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Native absolute mode 6 byte packet format +----------------------------------------- + v4 hardware is a true multitouch touchpad, capable of tracking up to 5 fingers. Unfortunately, due to PS/2's limited bandwidth, its packet format is rather complex. @@ -647,45 +653,49 @@ position, until we receive a status packet. One exception is one finger touch. when a status packet tells us there is only one finger, the hardware would just send head packets afterwards. -7.2.1 Status packet - ~~~~~~~~~~~~~ +Status packet +^^^^^^^^^^^^^ -byte 0: +byte 0:: bit 7 6 5 4 3 2 1 0 . . . . 0 1 R L L, R = 1 when Left, Right mouse button pressed -byte 1: +byte 1:: bit 7 6 5 4 3 2 1 0 . . . ft4 ft3 ft2 ft1 ft0 ft4 ft3 ft2 ft1 ft0 ftn = 1 when finger n is on touchpad -byte 2: not used +byte 2:: -byte 3: + not used + +byte 3:: bit 7 6 5 4 3 2 1 0 . . . 1 0 0 0 0 constant bits -byte 4: +byte 4:: bit 7 6 5 4 3 2 1 0 p . . . . . . . p = 1 for palm -byte 5: not used +byte 5:: -7.2.2 Head packet - ~~~~~~~~~~~ + not used -byte 0: +Head packet +^^^^^^^^^^^ + +byte 0:: bit 7 6 5 4 3 2 1 0 w3 w2 w1 w0 0 1 R L @@ -693,43 +703,43 @@ byte 0: L, R = 1 when Left, Right mouse button pressed w3..w0 = finger width (spans how many trace lines) -byte 1: +byte 1:: bit 7 6 5 4 3 2 1 0 p7 p6 p5 p4 x11 x10 x9 x8 -byte 2: +byte 2:: bit 7 6 5 4 3 2 1 0 x7 x6 x5 x4 x3 x2 x1 x0 x11..x0 = absolute x value (horizontal) -byte 3: +byte 3:: bit 7 6 5 4 3 2 1 0 id2 id1 id0 1 0 0 0 1 id2..id0 = finger id -byte 4: +byte 4:: bit 7 6 5 4 3 2 1 0 p3 p1 p2 p0 y11 y10 y9 y8 p7..p0 = pressure -byte 5: +byte 5:: bit 7 6 5 4 3 2 1 0 y7 y6 y5 y4 y3 y2 y1 y0 y11..y0 = absolute y value (vertical) -7.2.3 Motion packet - ~~~~~~~~~~~~~ +Motion packet +^^^^^^^^^^^^^ -byte 0: +byte 0:: bit 7 6 5 4 3 2 1 0 id2 id1 id0 w 0 1 R L @@ -739,35 +749,35 @@ byte 0: w = 1 when delta overflows (> 127 or < -128), in this case firmware sends us (delta x / 5) and (delta y / 5) -byte 1: +byte 1:: bit 7 6 5 4 3 2 1 0 x7 x6 x5 x4 x3 x2 x1 x0 x7..x0 = delta x (two's complement) -byte 2: +byte 2:: bit 7 6 5 4 3 2 1 0 y7 y6 y5 y4 y3 y2 y1 y0 y7..y0 = delta y (two's complement) -byte 3: +byte 3:: bit 7 6 5 4 3 2 1 0 id2 id1 id0 1 0 0 1 0 id2..id0 = finger id -byte 4: +byte 4:: bit 7 6 5 4 3 2 1 0 x7 x6 x5 x4 x3 x2 x1 x0 x7..x0 = delta x (two's complement) -byte 5: +byte 5:: bit 7 6 5 4 3 2 1 0 y7 y6 y5 y4 y3 y2 y1 y0 @@ -778,33 +788,47 @@ byte 5: byte 3 ~ 5 for another -8. Trackpoint (for Hardware version 3 and 4) - ========================================= -8.1 Registers - ~~~~~~~~~ +Trackpoint (for Hardware version 3 and 4) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Registers +--------- + No special registers have been identified. -8.2 Native relative mode 6 byte packet format - ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -8.2.1 Status Packet - ~~~~~~~~~~~~~ +Native relative mode 6 byte packet format +----------------------------------------- + +Status Packet +^^^^^^^^^^^^^ + +byte 0:: -byte 0: bit 7 6 5 4 3 2 1 0 0 0 sx sy 0 M R L -byte 1: + +byte 1:: + bit 7 6 5 4 3 2 1 0 ~sx 0 0 0 0 0 0 0 -byte 2: + +byte 2:: + bit 7 6 5 4 3 2 1 0 ~sy 0 0 0 0 0 0 0 -byte 3: + +byte 3:: + bit 7 6 5 4 3 2 1 0 0 0 ~sy ~sx 0 1 1 0 -byte 4: + +byte 4:: + bit 7 6 5 4 3 2 1 0 x7 x6 x5 x4 x3 x2 x1 x0 -byte 5: + +byte 5:: + bit 7 6 5 4 3 2 1 0 y7 y6 y5 y4 y3 y2 y1 y0