[PATCH evdev 2/2] Always report all valuators on absolute devices

[Éric Brunet]

Hi!

> ok, this patch looked good at first, so I applied it locally.
> Unfortunately, it breaks a couple of tests in XIT, specifically
> EvdevMixedDeviceTest.AbsXYAndRelScroll/*.
> 
> [...]

Ouch... I am summarizing, to be sure I understood:

a) sometimes, a device marked as "Absolute" can have in its pEvdev->vals some   
   relative information.
b) that relative information must not be submitted several times. With my 
   patch, as the valuator is not cleared, it keeps being resubmitted
c) without my patch, if within the same frame ABS and REL events are both 
   submitted, they will be posted to the Xserver twice, one has relative 
   motion (which will make the cursor jumps a lot as absolute x/y will be
   interpreted as relative) and then as an Absolute motion (which will
   interpret in a weird way the relative information). That's new bug 84445.

I found an extra problem with my patch:

d) EvdevSwapAbsValuators and EvdevApplyCalibration are called when processing 
   SYN events on the values stored in pEvdev->vals. If I keep values from the
   previous SYN, the transformations (invert, swap, ...) will be applied to 
   some already transformed values !

Solving point b) is relatively easy, I think: I just need to special case the 
smoothwheel axes and make a special point of erasing them from the vald at the 
end of each SYN event. An alternative would be to always erase pEvdev->vals 
unless the device is a tablet (no wheel on them, I hope!)

Point d) could be fixed by applying transformations (Calibration and 
SwapAbsValuators) when the event itself is received, rather than late in the 
game. It might actually make the code simpler, too, especially with Swapping.
Is there any good reason to apply transformations so late in the game?

On a related point, I have just noticed a problem with EVDEV_RELATIVE_MODE:
in EvdevProcessValuators, abs values are converted into rel values, and then
pEvdev->abs_queued is set to 0. However, it could happen that, say, a pressure 
information has been sent within the same frame and weird things would happen.


Solving point c) seems more difficult. The way I see it would be to
   * split pEvdev->vals into pEvdev->abs_vals and pEvdev->rel_vals
   * pEvdev->abs_vals only contains the last accurate information on 
     the device. All transformations (Swap, Invert, Calibration) have
     already been applied. It is never erased. In particular, it makes
     pEvdev->prox useless (with my patch as it is, I think pEvdev->prox
     is close to be useless, no?).
   * pEvdev->rel_vals is erased at each SYN event
   * when receiving an ABS value, transformation are applied at once, and
     if in EVDEV_RELATIVE_MODE, the delta is computed at once (and stored
     in rel_vals ?

What do you think, is this the way to go? I might try to start working a 
little bit on this, but I cannot promise to carry out this till the end as
it would mean understanding very well the code... All the parts about 
multitouch are very mysterious to me still.



Cheers,

	Éric