I upgraded to v1.9 of the kernel driver but I'm still not getting consistant response from the tablet. I also changed to using /dev/input/mouse0 for the USB mouse and Synaptics pad in the xorg.conf file. This change should prevent any chance that the tablet is sending mouse events and mucking up the mouse or pad (I really only use the USB mouse – the pad I only use when watching mythtv in bed).

So, it's time to dig into the kernel. The first thing I noticed was that there are two structures for configuring the tablet: aiptek->curSetting and aiptek->newSetting. The latter starts as a copy of the former and is supposed to be updated when the user writes something to the config files under /sys/bus/usb/drivers/aiptek/. A comment in the driver says that the changes to netSetting are not committed until the use writes something to “execute” in that directory. That isn't well documented. However, doing the following still has not effect on my system:

cd /sys/bus/usb/drivers/aiptek/
echo relative > coordinate_mode
echo set > execute

These are just random notes on the driver:

• initialization of the macro keys (the stuff along the top of the tablet) but no sys interface for changing those to user defined key strokes. It might be nice to add that later.
• The sysfs interface has a bunch of store_() functions that save the value input by the user to the aiptek->newSetting structure. When something (anything) is written to the “execute” sysfs interface, aiptek->newSetting is copied to aiptek->curSetting using memcopy(). Then aiptek_program_tablet() is called, which tests the settings in curSetting and calls the appropriate aiptek_command().
• tablet() reporgrams *all* the settings in curSetting each time it is called. This could be made better by having execute call a function called “aiptek_change_tablet()” which tests if newSetting is different than curSetting and only runs those commands instead of reprogramming the whole thing each time. If the setting has changed, then update curSetting. This will work as long as the USB report sent to the tablet does not have to contain the entire settings list, which I seriously doubt (if the current code is representative of that).
• The device atttributes for the sysfs files appear correct (at a glance) for the coordinate_mode and a few others. You can see this also by looking at the permissions on the files, but checking the code just reinforces that information.
• info() is a macro defined in a bunch of header files in the kernel source (and not in this module source) but I think for this module it uses the definition found in usb.h. Not positive of that, but it's probably a reasonable guess.

I think the first thing I'd like to try is to add a debug sysfs interface so I can enable and disable debug output easily. Before I do that, though, I think I should be working out of the cvs tree, just in case I want to submit the changes back into the tree. So I'm off to get the code out of CVS.