software-trackpoint input driver

[Andrew Deason]

On Fri, 23 Aug 2013 15:09:16 +1000
Peter Hutterer <peter.hutterer at who-t.net> wrote:

> On Wed, Aug 21, 2013 at 11:38:38PM -0500, Andrew Deason wrote:
> > I have a USB trackpoint device I would like to use with X on Linux
> > (the trackpoint is the nub mouse thing on some keyboards, usually
> > known for laptop keyboards). All current input drivers seem to
> > interpret movement data for it incorrectly, and I'd like to fix
> > that. But I'm unfamiliar with xorg development, so I'm not sure
> > where such code "should" go.
> 
> what product is this? do you have a link to a description or a photo?

The "model number" is SK-8835, the FRU part number is 02R0400, and the
USB vendor/prod identifier is 06cb:0009. This appears to be the Lenovo
page for it:
<http://support.lenovo.com/en_US/detail.page?LegacyDocID=MIGR-45868>

Mine looks a little different from that picture (for one thing, mine has
an IBM logo, and no ThinkPad marking). I assume it just changed slightly
at some point, probably during the IBM->Lenovo transition.

> also, how common is this?

I don't know; this is the first USB one I've used. The PS/2 ones
certainly do not work this way, but lacking any other information, I
assume the other USB trackpoint devices work similarly (there are
several other models).

>From looking around on the web, I'm not the first person to notice that
the default motion with this trackpoint on Linux is not great. Other
people have tried working around it by changing acceleration etc, but I
don't really think it's possible to get the same feel while ignoring the
pressure axis. (The situation on Linux is a little better if
synaptics_usb is actually _disabled_, since that means it gets handled
as a generic HID device.)

> anyway. evdev could support this but it would require a custom pointer
> acceleration method similar to what synaptics has. and have that
> enabled for this device only (i.e. optional, with an entry in the
> quicks.conf to apply it for this device).

I defer to you guys, of course, but is that necessary? It's not good
enough to have the reported x movement be something like REL_X *
ABS_PRESSURE, and just feed that into an existing acceleration profile?

Another alternative is to put the device into the generic-HID-mouse
mode, and maybe with different acceleration settings that would yield a
similar result. That would take the pressure into account, albeit by the
device and not by us. I'm not sure if it's possible to get the same
results that way, but I'm sure it's better than what happens now.

> not a big fan of this either, tbh, because chances are this will break
> at random time because we don't have any upstream developers testing
> it.

Hmm, the machine I use this on every day does run Debian unstable, but
they're still on a modified evdev 2.7.0, so I guess that's not helpful.
If there was an easy way to keep up with running newer versions, I
wouldn't mind doing that, if that helps at all.

-- 
Andrew Deason
adeason at dson.org