software-trackpoint input driver

[Andrew Deason]

On Fri, 23 Aug 2013 20:52:43 -0500
Andrew Deason <adeason+lists at dson.org> wrote:

> > 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?

After looking into this a little more, it's seeming more likely that I
was completely wrong about ABS_PRESSURE. From what I can tell now, you
are indeed supposed to only look at the X and Y values to calculate
pointer movement. The Z axis (ABS_PRESSURE), is just for things like
"Press to Select", which I don't really care about (though somebody
might). Sorry.

I'm mostly getting this from the Trackpoint Engineering Specification,
which I found here: <http://blogs.epfl.ch/icenet/documents/Ykt3Eext.pdf>
(the relevant pages are 24, 43, and 44). I don't expect you to spend
time reading that, but the end result is that there is a specific
acceleration function that they use, which just depends on the X and Y
forces. It's not a simple function, but it looks like it's a few
different linear functions for different ranges of input movement. They
give a graph on page 43, if you want to see. That graph does not include
"negative inertia", though, which is a separate effect that is easily
applied (it's a simple function that is explicitly provided).

So yes, that says to me like it should be a custom acceleration method,
unless that "transfer function" looks like it is possible to emulate
using an existing acceleration profile (I don't see any that sounds
similar). Or unless you want a general "trackpoint acceleration method"
for use with other devices if they want them for some reason. Would that
mean this can still live in evdev, by default enabled by detecting this
kind of device? I'm not quite clear on how the "device-dependent"
acceleration profile is intended to be used.

Also, according to the trackpoint spec linked above, it seems like that
acceleration curve they give is intended to be fed into a mouse driver
that also does its own acceleration. So it seems like maybe this should
be handled orthogonally to an acceleration profile, and we should still
have e.g. linear, polynomial, etc, applied after the trackpoint
"transfer function"? Or does that just sound disgusting?

-- 
Andrew Deason
adeason at dson.org