I have a Toughbook CF-31 that comes with a Interlink VersaPad. Out of the box with Windows 7, it works fine. In Ubuntu, it is completely unresponsive. However, I emailed the manufacturer and got a lot of good information. Since I'm not a driver dev and he's not an Ubuntu dev, we're at a bit of a roadblock. Below is our correspondence if anyone has some tech-guru insight.
The touchpad is actually a PS2 device, not a USB or PCI device. We have dug into this issue and have found a an anomoly in the communication from Ubuntu to our VersaPad, and an error in the way our device handles the anomoly.
Please refer to the attached excel file which details the communication from Ubuntu to first a generic Microsoft PS2 wheel mouse, and then to our VersaPad. This is not on a Toughbook, since that machine does not have an external PS2 port. However the results should be very similar to what happens in the Toughbook.
I have highlighted the problem areas in yellow; scroll down to find them. You will see in both cases that Ubuntu tries to set the mouse sampling rate to some disallowed and unusual values. The allowed values, per the PS2 spec , are hex values of 0x0A, 0x14, 0x28, 0x3C, 0x50, 0x64, and 0xC8. Ubuntu is trying to set the sampling rate to 0x66 and 0x88. This may be part of some "magic knock" where certain devices might recognize these codes and respond by going into a special mode. We are not familiar with this particular magic knock if that is really what it is.
Unfortunately, our device does not handle this anomoly in the correct manner. I note also that the Microsoft mouse also fails to follow the spec, but it is apparently close enough. What should happen is that when the host first sends the unrecognized value of 0x66, the device should respond with a request for resend (0xFE). Then the host will resend the most recently sent byte. If the device still does not recognize or like the value, it should respond with an error (0xFC). The VersaPad fails to respond in this way, and then has a bug where it is forever stuck in an error mode.
I have already verified that adding 0x66 and 0x88 to the list of allowed sample rates does indeed let the VersaPad work on Ubuntu. Of course we will also be improving the error handling to be more robust.
However the Toughbook firmware is not field upgradeable, so our bugfix would not help you with your existing Toughbooks, or any new Toughbooks until a Panasonic engineering refresh allows a firmware change. This is unfortunate, and I apologize for any disappointment or frustration that this may cause.
If you have some expertise at the PS2 protocol and how it works in Ubuntu, you may be able to modify the communication to the VersaPad. Removing the attempt to set the sampling rate to unorthodox values will most likely allow the VersaPad to function.
Since this isn’t my technical area of expertise, I do have one question. Where did you edit these hex values in Ubuntu to get the VersaPad to work, and why wouldn’t this work in the case of the Toughbooks? I’m confused if you modified the firmware at a hardware level or a settings file at the OS level. If the latter, then that should work just fine since we will be using Ubuntu and Ubuntu-derived systems.
Thanks again for all your support!
I modified the firmware in a lab version of our VersaPad, which was then connected to the external PS2 port of a generic PC. We are unable to modify the firmware of a closed Toughbook without complete disassembly and painstaking desoldering and resoldering. I was not modifying the firmware inside a PC or a BIOS or anything like that.
You would be free to post our discussion as you like, but please do me the favor of an email if you ever come to an understanding of the following questions:
-why does Ubuntu try to set the sample rate to 0x66 and then 0x88?
-how do you modify that behavior?
Also, if you ever encounter a fix, such as for example a driver patch or something like that, I would be happy to document the communication stream between the OS and the VersaPad. And I would love a copy.