HAL and Synaptics

I’ve had Touchfreeze working on my EEE for a little while, but lately I noticed it had stopped working. I never really figured out why it stopped working, but it did prompt me to make some config changes and learn some new stuff Linux related. For instance, did you know that you don’t even need your xorg.conf (well, almost)?

Yep. Apparently HAL is what takes care of a lot of that stuff. From my reading, it seems to be the direction things are headed. There’s an excellent primer article here on it. There’s also a bunch of links at the bottom that are informative. I point them out because they led me to resolving my touchpad problems on my EEE.

If you’re like me, then the following will probably look familiar to you:

Section "InputDevice"
    Identifier   "Synaptics Touchpad"
    Driver        "synaptics"
    Option       "CorePointer"
    Option       "Device"          "/dev/input/event9"
    Option       "Protocol"        "auto-dev"
    Option       "SHMConfig"       "on"
    Option       "VertEdgeScroll   "1"
    Option       "TapButton1"      "1"
    Option       "TapButton2"      "2"
    Option       "TapButton3"      "3"
EndSection

That’s the xorg.conf section for configuring the synaptics driver to do some useful stuff with the touchpad that it won’t do out of the box. If you’re curious, you can figure out the “Device” option value by doing something like this:

hal_device | grep input\.device.*Elantech -B 7 -A 20

Anyway, it turns out that HAL can be used to configure your touchpad. In fact, if you’ve installed the xserver synaptics package, then you’ve probably got what you need to get it running. Check in /usr/share/hal/fdi/policy/20thirdparty for a file named 11-x11-synaptics.fdi. The file has the skeleton for using HAL to configure the synaptics driver.

Here’s what my file now looks like:

<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
    <device>
        <match key="info.capabilities" contains="input.touchpad">
            <merge key="input.x11_driver" type="string">synaptics</merge>
            <merge key="input.x11_options.TouchpadOff" type="string">0</merge>
            <merge key="input.x11_options.VertEdgeScroll" type="string">1</merge>
            <merge key="input.x11_options.TapButton1" type="string">1</merge>
            <merge key="input.x11_options.TapButton2" type="string">2</merge>
            <merge key="input.x11_options.TapButton3" type="string">3</merge>
            <merge key="input.x11_options.MaxSpeed" type="string">1.0</merge>
            <merge key="input.x11_options.AccelFactor" type="string"><0.05</merge>
        </match>
    </device>
</deviceinfo>

This file should be saved to /etc/hal/fdi/policy using some kind of numbered file name. I just kept the filename as I found it- I don’t know if this would be appropriate if there were more fdi files in the hal config folder.

After saving the file, restart hal as follows:

/etc/init.d/hal restart

Next, remove any references to the touchpad or mouse from your xorg.conf file.  Interstingly, I removed keyboard references as well and things continued to work.  Finally, restart your X server- I just quit out of my WM and then restarted using the startx command. That should be it.

If you enter the hal-device command from above, complete with grep, you should see the options specified in the fdi file in the output. If not, double check for typos, make sure you’ve restarted hal and make sure you’ve restarted X.  Also, make sure you’ve got hal installed and configured properly in the first place (if you’re running something with a good package manager, it should be fairly straightforward to do so).

I’ve mentioned this before, but I’m running Debian Squeeze/Testing so keep that in mind if you choose to give this approach a whirl.  Also, I’ve got a special psmouse.ko file that was built to overcome limitations in the current kernel. You can find that module file here.