Enable Synaptics mode for CL1A/CL1B/CL1C touchpad

[martin.langhoff]

To document steps needed to get touchpad working with the synaptics driver, which includes features such as "vertical scroll" control.

We'd need to

• Enable Synaptics support in kmod and rebuild
• Test / debug interaction with EC
• Teach olpc-kbdshim about rotating data in this protocol
• In xorg.conf set synaptics driver to use the 'device' olpc-kbdshim exposes

[martin.langhoff]

Note: the "background" bug to this, explaining why it Synaptics mode has been disabled, is #8901 .

FWIW, I have built a psmouse.ko with synaptics. Testing on 10.1.2 and CL1C hardware...

• Installed psmouse.ko
• rmmod / modprobe, seen as SynPS/2
• Configured x.org to use synaptics based on #8942 -- note that no scrolling settings are requested. Restarted X.org
• Touchpad works correctly, no jumpiness observed
• Tried the various tests outlined in #8901 -- could see no problems. Fast typing was accurate and without lags, even with some fingers hovering over TP.
• Vertical scrolling on the right-hand-side of the TP works. Tested in TurtleArt and Terminal. No horizontal scrolling (probably not on by default).
• S/R -- if we are resuming on TP activity the "first stroke" is missed. This is a regression. With 'our' driver the first stroke is usually registered (but acts more like a jump).
• The xorg synaptics driver grabs the raw device and ignores olpc-kbdshim -- which does not understand the synaptics protocol anyway.
• Seems passing proto=bare reverts the synaptic-enabled driver to the old behaviour.

[martin.langhoff]

Replacement psmouse.ko for 10.1.2 XO-1.5

[dsd]

Once you make olpc-kbdshim pick up the device, I think you'll have to teach it to understand and pass on any of the advanced features (e.g. vertical scrolling) that you want to enable. Also, no xorg.conf change will be needed.

[pgf]

i'm not sure whether this is driven by a deployment or not, but if so, i hope they're aware that kbdshim already gives unambiguous touchpad scrolling via the grab keys.

[dsd]

Andres did some work on this and found the synaptics driver to be totally unusable. Namely, it triggered a recalibration about 10 seconds after starting, and that caused the pad to become super sensitive and unusable. The upstream kernel now rejects synaptics driver for OLPC laptops.

Not that I doubt Andres's findings, it would be nice to have a 2nd person try the driver and see if those results are consistent, and to double check that there's no obvious way to ask the hardware not to calibrate itself so badly.

[dsd]

Just to clarify, that comment relates to the synaptics kernel driver, not to the synaptics userspace driver (which supports all absolute-input devices, not just synaptics touchpads).

[dsd]

I confirm Andres's findings on XO-1.75 and XO-1.5. After enabling the kernel-side support for synaptics protocol, the cursor in userspace goes super-sensitive.

However, the above test was done without the xorg-x11-drv-synaptics userspace driver available, and I suspect the same was true in dilinger's test. installing xorg-x11-drv-synaptics (i.e. pairing the kernel and userspace drivers) avoids the cursor crazyness, confirmed on XO-1.5 and XO-1.75, and also shown by Jon N in #11198.

This suggests that the userspace driver is doing something to put the pad into "sane mode" (or just doing a huge amount of packet filtering+dropping). This should be investigated - maybe theres something simple the kernel could be doing so that things work OK with synaptics kernel driver and standard userspace mouse drivers.

Also, on XO-1.5, I do (very clearly) see another problem described already on the XO-1.5, regardless of userspace driver in use, which is that the keyboard is inoperable when the mouse is being used, and for a few seconds afterwards (#8901).

Andres, perhaps you could retest your XO-1.5 sensitivity problem against xorg-x11-drv-synaptics in userspace?

[pgf]

did your test include olpc-kbdshim? (it may be that kbdshim simply ignored the device, since it only picks up REL-mode devices.)

also, if it's the case that this protocol uses 6-byte packets, we should be sure and test on XO-1 as well, since there was a time when packets greater than 3 bytes were broken by the EC's internal latencies.

[dsd]

I made sure kbdshim wasn't running.

[martin.langhoff]

olpc-kbdshim running shouldn't make a difference IIRC. I have no problem with using xorg-x11-drv-synaptics, in fact I assume it's a requirement for the switch over.

The pending issues are

* olpc-kbdshim should either detect the device, or ignore it. Recent discussion about ebook mode seemed to imply that we didn't really need to rotate touchpad input, and that we'd silence or redirect tp input to /dev/null when in ebook mode. * better resume on touchpad stroke * #8901 - my naive speculation is that the protocol uses more data traffic than vanilla PS/2 and the EC isn't keeping up. We've had a similar issue with MPPT keeping the EC busy...

[dsd]

olpc-kbdshim should detect the device and understand/translate the absolute data. It is needed for input rotation in non-ebook mode, and for preventing the system from going to sleep on mouse input, and perhaps other things.

[pgf]

Replying to dsd:

olpc-kbdshim should detect the device and understand/translate the absolute data. It is needed for input rotation in non-ebook mode, and for preventing the system from going to sleep on mouse input, and perhaps other things.

agreed. not hard, just haven't needed to do it until now.

[pgf]

btw, i just spotted this, from comment #1:

S/R -- if we are resuming on TP activity the "first stroke" is missed. This is a regression. With 'our' driver the first stroke is usually registered (but acts more like a jump). 

this may be a result of running the touchpad in a longer packet-size mode. from my earlier investigation, the synaptics pad can buffer 3 bytes. (ALPS just buffers 1.) if the pad is sending 3 byte packets, you'll have one whole packet buffered coming out of suspend. in 6-byte mode, you'd only buffer half a packet, which would cause more loss, and will likely cause a driver resync.

[martin.langhoff]

Fix formatting of my pending issues list:

• olpc-kbdshim should either detect the device, or ignore it. Recent discussion about ebook mode seemed to imply that we didn't really need to rotate touchpad input, and that we'd silence or redirect tp input to /dev/null when in ebook mode.
• better resume on touchpad stroke
• #8901 - my naive speculation is that the protocol uses more data traffic than vanilla PS/2 and the EC isn't keeping up. We've had a similar issue with MPPT keeping the EC busy...

WRT input rotation, we have no use case for rotated touchpad input -- we have use cases for rotated input in ebook mode only.

I agree that we probably want olpc-kbdshim to still handle the data stream for power mgmt reasons and to silence the input when in ebook mode.

[pgf]

this:

WRT input rotation, we have no use case for rotated touchpad input -- we have use cases for rotated input in ebook mode only.

isn't true: the laptop software stack isn't useable in ebook-mode only, since many operations (menus, button clicking) require the touchpad. as soon as you crack open the laptop (from ebook mode) to get at the touchpad, you're no longer in ebook mode -- the magnetic detector no longer has an affect. so rotation is very much needed in non-ebook mode.

[martin.langhoff]

Replying to pgf:

the laptop software stack isn't useable in ebook-mode

I agree with that part - but let's separate the two things

• Sugar and activities are not usable in ebook mode. We need to fix this with UI work.
• Not-quite-closing the XO in ebook mode and smuggling a finger to the TP is not a workaround, and trying to support this mode of use is a bad idea.

[dsd]

Procedure for Richard:

Target hardware is XO-1.5 with synaptics touchpad. To identify this, grep Synaptics /proc/bus/input/devices

Start from any recent 11.3.0 build such as http://build.laptop.org/11.3.0/os8/xo-1.5/os8.zd4

Install test kernel:

rpm -Uvh http://dev.laptop.org/~dsd/20111004/kernel-2.6.35.13_xo1.5-20111004.1557.olpc.1d237ac.i586.rpm
rsync -av --delete-before /boot/ /bootpart/boot/
reboot

Check that synaptics kernel driver is enabled:

grep SynPS /proc/bus/input/devices

If you notice the mouse going crazy in X, or you have difficulty typing the above command because they keyboard isn't working right, that's equally valid evidence that the synaptics kernel driver has kicked in :)

now install http://kojipkgs.fedoraproject.org/packages/xorg-x11-drv-synaptics/1.3.0/1.fc14/i686/xorg-x11-drv-synaptics-1.3.0-1.fc14.i686.rpm and reboot again

Now the mouse should be fine again, but you should experience problems typing while using the mouse (or simply having fingers nearby). This is the problem to then diagnose with the EC hookup.

If you want to see the kernels view of i8042 interrupts and data:

echo 1 > /sys/module/i8042/parameters/debug

The output lines will be e.g.

32 <- i8042 (interrupt, 1, 12)

In the above example, 32 is the byte read from I8042_DATA_REG. 1 is the port number and 12 is the IRQ. Mouse stuff comes in on IRQ 12 and keyboard on IRQ 1.

This info is logged in dmesg by default. If you enable log messages to be sent over serial (with e.g. dmesg -n 8), the huge amount of data sent by synaptics pad in this mode causes such a slowdown that problems occur (failed resyncs etc).

I find it easier to have it just logging to dmesg internally, then reproduce the issue, then examine dmesg logs.

In a couple of tests I just made, typing the characters "myna" while moving the mouse, the "n" is the only character that hit the screen. According to the logs, there was a huge amount of mouse data, then at the very end Linux received the 0x31 'n' make code once, then the 0xb1 'n' break code 7 times, with no sign of the other keys that I pressed.

[rsmith]

Replying to dsd:

Install test kernel: {{{ rpm -Uvh http://dev.laptop.org/~dsd/20111004/kernel-2.6.35.13_xo1.5-20111004.1557.olpc.1d237ac.i586.rpm rsync -av --delete-before /boot/ /bootpart/boot/ reboot }}} Check that synaptics kernel driver is enabled: {{{ grep SynPS /proc/bus/input/devices }}}

I'm not having any luck. I have a unit that reports it has a Synaptics touchpad wiht the stock kernel but when I install the above kernel (on os8) I don't get any touchpad activity and /proc/bus/input/devices shows no sign of a Synaptics device anymore.

[rsmith]

Replying to rsmith:

I'm not having any luck.

User error. Wasn't including the trailing '/' on rsync so the kernel was not properly installed.

I've duplicated it. I see two things so far. 1) is that a constant stream of touchpad data seems to take priority and starve out keyboard data. 2) is that when the keyboard data that stored up is sent it seems to only be 1 character and multiple key release codes seem to be sent.

One difference is that in synaptics mode the touchpad constantly streams packets if it senses a touch whereas when its in legacy mode it only sends data when is senses motion. If its possible A simple middle of the road workaround might be to make the synaptics mode behave like the legacy mode. If nothing else it would help with debugging the stream of data.

[dsd]

Page 21 of the synaptics specs says:

In Absolute mode, the TouchPad reports packets continuously at the specified packet rate, either full or half speed, whenever the finger is on or near the pad. (Specifically, the TouchPad begins sending packets when Z is 8 or more.) The TouchPad also begins sending packets whenever any button is pressed or released. Once the TouchPad begins transmitting, it continues to send packets for one second after Z falls below 8 and the buttons stop changing. The TouchPad does this partly to allow host software to use the packet stream as a time base for gesture decoding, and also to minimize the impact if the system occasionally drops a packet.

http://www.synaptics.com/sites/default/files/511-000275-01rA.pdf

I will email them to see if any simple behaviour change is possible. Nothing is hinted in the specs.

It is possible to switch the mouse into half-rate mode which may help you with debugging (and I think would be sensible for us to do anyway).

echo -n 40 > /sys/bus/serio/drivers/psmouse/serio*/rate

valid values are 40 and 80, 80 is the default.

[dsd]

Their reply is that there is no way to turn off this continuous transmission without going back to relative mode.

In the interests of power saving and so on, I am thinking that relative mode is probably more appropriate for us (and our Synaptics contact hinted the same). I think this transmission behaviour change is good justification for relative mode support to be added to the synaptics driver upstream in Linux, which would allow us to drive the mouse in relative mode but still be able to disable tap-to-click through standard interfaces.

However, I still think this EC issue is worth looking into if you can spare the time. Running the device at half rate in absolute mode causes 6*40=240 bytes of incoming data per second, which is exactly the same as if we run at full rate in relative mode (3*80=240), and is less data than we will now receive for AVC pads (4*80=320). So if 240bytes/sec from the mouse can starve the keyboard, then it is possible that we may also have problems in our other configurations. (btw, i have confirmed that running absolute mode at half rate has the same keyboard-starving effect that you saw with full rate)

[rsmith]

Replying to dsd:

However, I still think this EC issue is worth looking into if you can spare the time. Running the device at half rate in absolute mode causes 6*40=240 bytes of incoming data per second, which is exactly the same as if we run at full rate in relative mode (3*80=240), and is less data than we will now receive for AVC pads (4*80=320). So if 240bytes/sec from the mouse can starve the keyboard, then it is possible that we may also have problems in our other configurations. (btw, i have confirmed that running absolute mode at half rate has the same keyboard-starving effect that you saw with full rate)

In abosolute mode the problem isn't really so much the absolute rate as much is the constant stream of data. You can't go faster than the EC will process the data because the PS/2 lines are flow controlled. Full rate would be 480 bytes per second which is a byte ever 2ms. The handlers for the transition from PS/2 bus to LPC bus in the EC are main loop driven (ie not in interrupt context) and the loop time is > 2ms. (I've not measured it recently but I know its > 2ms) So there's no point in operating at full rate. At 4ms/byte of half rate it might keep up but I'll have to check.

The keyboard and and touchpad data both have to go upstream via the same data register for the LPC bus. With PS2 data essentially always available in this case the keyboard data isn't getting a chance to get processed. I tried a few trivial things to try and help this but it appears to be more complex than that.

Relative mode may be the short term win in the mean time because the data stream will have gaps that allow for keys to make it up the chain.

[dsd]

Synaptics confirmed that Relative mode is more appropriate for us - as an embedded system we want to avoid such a heavy stream of data.

Patches have been accepted into the upstream kernel that add a "SynRelPS/2" protocol as part of the synaptics driver. This puts the mouse in relative mode but exposes the hardware tap-to-click control (which defaults to tap-to-click disabled in hardware, like it does in absolute mode). This is being handled in #11383 (for 12.1.0).

As noted in #8901 the sensitivity issue with Synaptics mode is because the driver reports packets while the finger is close to the pad. Old versions of xf86-input-evdev were interpreting these as mouse movements; this caused dilinger to disable the mode at the kernel level for OLPC. However, the xf86-input-evdev version included in F16 fixes this as it ignores evdev events from the kernel which do not state that the finger is on the pad.

The EC bug (in that it falls to its knees in the presence of the synaptics absolute mode packet flood) is still present and can continue to be diagnosed on this ticket and in #8901.