[RFC][PATCH] General axis valuator support

[Peter Hutterer]

On Wed, Jan 14, 2009 at 03:25:04AM -0800, Matt Helsley wrote:
> On Sun, Jan 11, 2009 at 8:01 PM, Peter Hutterer <peter.hutterer at who-t.net> wrote:
> > Some comments purely related to your comments, not your code. I won't be
> > able to look at your code today.
> >
> > On Sun, Jan 11, 2009 at 07:37:49PM -0800, Matt Helsley wrote:
> >> Currently X, Y, and PRESSURE are special case axes in xf86-input-evdev.
> >> This patch supports axes in a more general way. There are a few open
> >> questions and TODOs:
> >>
> >> TODO:
> >>       Add REL axes. Since we currently limit evdev devices to
> >>               exclusively REL or ABS axes we can reuse the same vals
> >>               buffer in the device structure.
> >
> > This is actually a bit tricky. If we allow rel and abs for the same axis, we
> > have to convert all relative events to absolute ones in the driver. Reason
> > being that once the abs axes are set up, the server caps at the ranges.
> 
> Based on this and the XI2 protocol spec discussion it looks like each axis has a
> separate mode (Absolute, Relative). I wasn't expecting that -- I figured it
> would apply to the "whole device".

yes. XI2 will have, XI 1.x doesn't. But even if, this problem doesn't go away
with XI2 either. Trying to paraphrase: the problem is devices trying to post
two different axes through the same axis.
In evdev, we "know" it's different because one comes up through ABS_X and one
through REL_X but once we forward it through the server as X axis, we have to
limit to the axis range.

Example:
Assuming that you set up an axis range 0..100 and you post a absolute event on
90/90, and then a relative event on the same device with 50/50 the axis is
clipped to 100/100.
> 
> > This is made slightly more complicated by the fact that a few devices (some
> > popular mouse/keyboard combos) announce an ABS_X range of 256/256, so any
> > relative X axis movement would get scaled to that range.
> 
> For those we could look at the corresponding axis in rel_bitmask and, if it exists,
> we don't set up any corresponding abs axis in the server. Then we ignore any
> input_events for ABS_<axis>. Of course we're then assuming that events from the two
> axes are in fact related to the same user action...

this is basically what evdev currently does, although it does it with a
sledgehammer and per-axis fine-tuning is needed.
> Perhaps the really clever thing to do would be to compare the values coming in
> during a "sample" input period. If the REL_ and ABS_ values correspond then we
> know the axes are related.
> 
> Unless there's something totally obvious I'm missing I don't think it's a problem
> we can cleanly solve.

correct, and I would opt for giving relative abs precedence for now and (at a
later point) adding configuration options to override this precedence.

> One other thing that occured to me: the EV_SYN events are largely ignored. This
> means that a "pair" of X,Y movements are reported with as two X events --
> movement along X then movement along Y for example -- rather than one, correct?
> This is likely unnoticeable since the relative distance between these points are
> likely too small -- especially on reliable and modern devices. However it still seems
> like these input events should be accumulated in the pEvdev device and only
> Post'ed when we see an EV_SYN. Has anyone ever tried this at some point?

I thought that's what we did but we obviously don't. go for it :)


Cheers,
  Peter