1.1. Introduction¶
Aug 30, 2018 Download ALPS Keyboard & Mouse drivers, firmware, bios, tools, utilities.
Currently the ALPS touchpad driver supports seven protocol versions in use byALPS touchpads, called versions 1, 2, 3, 4, 5, 6, 7 and 8.
- Configuring Alps Touchpad under Ubuntu Linux. Note that the defaults for the updated touchpad driver do not work well with the Alps touchpad, which is why all of.
- 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 andintegrated into a variety of laptops and netbooks. These new touchpadshave enough behavior differences that the alps_model_data definitiontable, describing the properties of the different versions, is no longeradequate. The design choices were to re-define the alps_model_datatable, with the risk of regression testing existing devices, or isolatethe new devices outside of the alps_model_data table. The latter designchoice 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 willgenerically 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 thedifferent 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 actualhardware type.
1.2. 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 or00-00-64 if no buttons are pressed. The bits 0-2 of the first byte will be 1sif some buttons are pressed.
If the E6 report is successful, the touchpad model is identified using the 'E7report' sequence: E8-E7-E7-E7-E9. The response is the model signature and ismatched against known models in the alps_model_data_array.
For older touchpads supporting protocol versions 3 and 4, the E7 reportmodel signature is always 73-02-64. To differentiate between theseversions, the response from the 'Enter Command Mode' sequence must beinspected as described below.
The new ALPS touchpads have an E7 signature of 73-03-50 or 73-03-0A butseem to be better differentiated by the EC Command Mode response.
1.3. Command Mode¶
Protocol versions 3 and 4 have a command mode that is used to read and writeone-byte device registers in a 16-bit address space. The command sequenceEC-EC-EC-E9 places the device in command mode, and the device will respondwith 88-07 followed by a third byte. This third byte can be used to determinewhether 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 aspecific command, either EC for v3 devices or F5 for v4 devices. Then theaddress is sent one nibble at a time, where each nibble is encoded as acommand with optional data. This encoding differs slightly between the v3 andv4 protocols.
Once an address has been set, the addressed register can be read by sendingPSMOUSE_CMD_GETINFO (E9). The first two bytes of the response contains theaddress of the register being read, and the third contains the value of theregister. Registers are written by writing the value one nibble at a timeusing the same encoding used for addresses.
For the new ALPS touchpads, the EC command is used to enter commandmode. The response in the new ALPS touchpads is significantly different,and more important in determining the behavior. This code has beenseparated from the original alps_model_data table and put in thealps_identify function. For example, there seem to be two hardware initsequences for the 'Dolphin' touchpads as determined by the second byteof the EC response.
1.4. Packet Format¶
In the following tables, the following notation is used:
?'s can have different meanings on different models, such as wheel rotation,extra buttons, stick buttons on a dualpoint, etc.
1.5. PS/2 packet format¶
Note that the device never signals overflow condition.
Dell Alps Touchpad Driver Linux
For protocol version 2 devices when the trackpoint is used, and no fingersare on the touchpad, the M R L bits signal the combined status of both thepointingstick and touchpad buttons.
1.6. ALPS Absolute Mode - Protocol Version 1¶
1.7. ALPS Absolute Mode - Protocol Version 2¶
Protocol Version 2 DualPoint devices send standard PS/2 mouse packets forthe DualPoint Stick. The M, R and L bits signal the combined status of boththe pointingstick and touchpad buttons, except for Dell dualpoint deviceswhere the pointingstick buttons get reported separately in the PSM, PSRand PSL bits.
1.8. Dualpoint device -- interleaved packet format¶
Devices which use the interleaving format normally send standard PS/2 mousepackets for the DualPoint Stick + ALPS Absolute Mode packets for thetouchpad, switching to the interleaved packet format when both the stick andthe touchpad are used at the same time.
1.9. ALPS Absolute Mode - Protocol Version 3¶
ALPS protocol version 3 has three different packet formats. The first two areassociated with touchpad events, and the third is associated with trackstickevents.
The first type is the touchpad position packet:
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 thebitmaps a given bit is set if there is a finger covering that position on thegiven axis. Thus the bitmap packet can be used for low-resolution multi-touchdata, although finger tracking is not possible. This packet also encodes thenumber of contacts (f1 and f0 in the table below):
This packet only appears after a position packet with the mt bit set, andusually only appears when there are two or more contacts (althoughoccasionally it's seen with only a single contact).
The final v3 packet type is the trackstick packet:
TP means Tap SW status when tap processing is enabled or Press status when pressprocessing is enabled. SW means scroll up when 4 buttons are available.
1.10. ALPS Absolute Mode - Protocol Version 4¶
Protocol version 4 has an 8-byte packet format:
The last two bytes represent a partial bitmap packet, with 3 full packetsrequired to construct a complete bitmap packet. Once assembled, the 6-bytebitmap packet has the following format:
There are several things worth noting here.
- In the bitmap data, bit 6 of byte 0 serves as a sync byte toidentify the first fragment of a bitmap packet.
- The bitmaps represent the same data as in the v3 bitmap packets, althoughthe packet layout is different.
- There doesn't seem to be a count of the contact points anywhere in the v4protocol packets. Deriving a count of contact points must be done byanalyzing the bitmaps.
- There is a 3 to 1 ratio of position packets to bitmap packets. ThereforeMT position can only be updated for every third ST position update, andthe count of contact points can only be updated every third packet aswell.
So far no v4 devices with tracksticks have been encountered.
1.11. ALPS Absolute Mode - Protocol Version 5¶
This is basically Protocol Version 3 but with different logic for packetdecode. It uses the same alps_process_touchpad_packet_v3 call with aspecialized decode_fields function pointer to correctly interpret thepackets. This appears to only be used by the Dolphin devices.
For single-touch, the 6-byte packet format is:
For mt, the format is:
1.12. ALPS Absolute Mode - Protocol Version 6¶
For trackstick packet, the format is:
For touchpad packet, the format is:
(v6 touchpad does not have middle button)
1.13. ALPS Absolute Mode - Protocol Version 7¶
For trackstick packet, the format is:
For touchpad packet, the format is:
1.14. 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):
SWM, SWR, SWL: Middle, Right, and Left button states
Touchpad 1 Finger packet (APD = 0x0):
TAPF: ???LFB: ???
Touchpad 2 Finger packet (APD = 0x1):
CONT: A 3-or-4 Finger packet is to follow
Touchpad 3-or-4 Finger packet (APD = 0x3):
OVF: 5th finger detected
Copyright (C) 2007-2008 Arjan Opmeer <arjan@opmeer.net>
Extra information for hardware version 1 found andprovided by Steve Havelka
Version 2 (EeePC) hardware support based on patchesreceived from Woody at Xandros and forwarded to meby user StewieGriffin at the eeeuser.com forum
9.1. Introduction¶
Currently the Linux Elantech touchpad driver is aware of four differenthardware versions unimaginatively called version 1,version 2, version 3and version 4. Version 1 is found in 'older' laptops and uses 4 bytes perpacket. Version 2 seems to be introduced with the EeePC and uses 6 bytesper packet, and provides additional features such as position of two fingers,and width of the touch. Hardware version 3 uses 6 bytes per packet (andfor 2 fingers the concatenation of two 6 bytes packets) and allows trackingof up to 3 fingers. Hardware version 4 uses 6 bytes per packet, and cancombine a status packet with multiple head or motion packets. Hardware version4 allows tracking up to 5 fingers.
Some Hardware version 3 and version 4 also have a trackpoint which uses aseparate packet format. It is also 6 bytes per packet.
The driver tries to support both hardware versions and should be compatiblewith the Xorg Synaptics touchpad driver and its graphical configurationutilities.
Note that a mouse button is also associated with either the touchpad or thetrackpoint when a trackpoint is available. Disabling the Touchpad in xorg(TouchPadOff=0) will also disable the buttons associated with the touchpad.
Additionally the operation of the touchpad can be altered by adjusting thecontents of some of its internal registers. These registers are representedby the driver as sysfs entries under /sys/bus/serio/drivers/psmouse/serio?that can be read from and written to.
Currently only the registers for hardware version 1 are somewhat understood.Hardware version 2 seems to use some of the same registers but it is notknown whether the bits in the registers represent the same thing or mighthave changed their meaning.
On top of that, some register settings have effect only when the touchpad isin relative mode and not in absolute mode. As the Linux Elantech touchpaddriver always puts the hardware into absolute mode not all informationmentioned below can be used immediately. But because there is no freelyavailable Elantech documentation the information is provided here anyway forcompleteness sake.
9.2. Extra knobs¶
Currently the Linux Elantech touchpad driver provides three extra knobs under/sys/bus/serio/drivers/psmouse/serio? for the user.
debug
Turn different levels of debugging ON or OFF.
By echoing '0' to this file all debugging will be turned OFF.
Currently a value of '1' will turn on some basic debugging and a value of'2' will turn on packet debugging. For hardware version 1 the default isOFF. For version 2 the default is '1'.
Turning packet debugging on will make the driver dump every packetreceived to the syslog before processing it. Be warned that this cangenerate quite a lot of data!
paritycheck
Turns parity checking ON or OFF.
By echoing '0' to this file parity checking will be turned OFF. Anynon-zero value will turn it ON. For hardware version 1 the default is ON.For version 2 the default it is OFF.
Hardware version 1 provides basic data integrity verification bycalculating a parity bit for the last 3 bytes of each packet. The drivercan check these bits and reject any packet that appears corrupted. Usingthis knob you can bypass that check.
Hardware version 2 does not provide the same parity bits. Only some basicdata consistency checking can be done. For now checking is disabled bydefault. Currently even turning it on will do nothing.
crc_enabled
Sets crc_enabled to 0/1. The name 'crc_enabled' is the official name ofthis integrity check, even though it is not an actual cyclic redundancycheck.
Depending on the state of crc_enabled, certain basic data integrityverification is done by the driver on hardware version 3 and 4. Thedriver will reject any packet that appears corrupted. Using this knob,The state of crc_enabled can be altered with this knob.
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'.
9.3. Differentiating hardware versions¶
To detect the hardware version, read the version number as param[0].param[1].param[2]:
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:
In the wild, there appear to be more versions, such as 04.03.01, 04.04.11. Thereappears to be almost no difference, except for EF113, which does not reportpressure/width and has different data consistency checks.
Probably all the versions with param[0] <= 01 can be considered as4 bytes/firmware 1. The versions < 02.08.00, with the exception of 02.00.30, as4 bytes/firmware 2. Everything >= 02.08.00 can be considered as 6 bytes.
9.4. Hardware version 1¶
9.4.1. Registers¶
By echoing a hexadecimal value to a register it contents can be altered.
For example:
reg_10:
reg_11:
reg_20:
reg_21:
reg_22:
reg_23:
reg_24:
reg_25:
reg_26:
9.4.2. Native relative mode 4 byte packet format¶
byte 0:
byte 1:
byte 2:
byte 3:
9.4.3. Native absolute mode 4 byte packet format¶
EF013 and EF019 have a special behaviour (due to a bug in the firmware?), andwhen 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 1:
byte 2:
byte 3:
9.5. Hardware version 2¶
9.5.1. Registers¶
By echoing a hexadecimal value to a register it contents can be altered.
For example:
reg_10:
reg_11:
reg_21:
reg_22:
9.5.2. Native absolute mode 6 byte packet format¶
9.5.2.1. Parity checking and packet re-synchronization¶
There is no parity checking, however some consistency checks can be performed.
For instance for EF113:
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).
9.5.2.2. One/Three finger touch¶
byte 0:
byte 1:
byte 2:
byte 3:
byte 4:
byte 5:
9.5.2.3. Two finger touch¶
Note that the two pairs of coordinates are not exactly the coordinates of thetwo 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 squaredefined by these two points.
byte 0:
byte 1:
byte 2:
byte 3:
byte 4:
byte 5:
9.6. Hardware version 3¶
9.6.2. Native absolute mode 6 byte packet format¶
1 and 3 finger touch shares the same 6-byte packet format, except that3 finger touch only reports the position of the center of all three fingers.
Firmware would send 12 bytes of data for 2 finger touch.
Note on debounce:In case the box has unstable power supply or other electricity issues, orwhen number of finger changes, F/W would send 'debounce packet' to informdriver that the hardware is in debounce status.The debouce packet has the following signature:
When we encounter this kind of packet, we just ignore it.
9.6.2.1. One/Three finger touch¶
byte 0:
byte 1:
byte 2:
byte 3:
byte 4:
byte 5:
9.6.2.2. Two finger touch¶
The packet format is exactly the same for two finger touch, except the hardwaresends 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 atotal of 12 bytes are sent.
9.7. Hardware version 4¶
9.7.2. 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 rathercomplex.
Whenever the numbers or identities of the fingers changes, the hardware sends astatus packet to indicate how many and which fingers is on touchpad, followed byhead packets or motion packets. A head packet contains data of finger id, fingerposition (absolute x, y values), width, and pressure. A motion packet containstwo fingers' position delta.
For example, when status packet tells there are 2 fingers on touchpad, then wecan expect two following head packets. If the finger status doesn't change,the following packets would be motion packets, only sending delta of fingerposition, until we receive a status packet.
One exception is one finger touch. when a status packet tells us there is onlyone finger, the hardware would just send head packets afterwards.
9.7.2.1. Status packet¶
byte 0:
byte 1:
Dell Alps Touchpad Driver Vista
byte 2:
byte 3:
byte 4:
byte 5:
9.7.2.2. Head packet¶
byte 0:
byte 1:
byte 2:
byte 3:
byte 4:
byte 5:
9.7.2.3. Motion packet¶
byte 0:
byte 1:
byte 2:
byte 3:
byte 4:
byte 5:
9.8. Trackpoint (for Hardware version 3 and 4)¶
9.8.1. Registers¶
No special registers have been identified.
9.8.2. Native relative mode 6 byte packet format¶
9.8.2.1. Status Packet¶
byte 0:
byte 1:
byte 2:
byte 3:
Alps Touchpad Driver Update
byte 4:
byte 5: