[PATCH] evdev: Support the "Calibration" string option.

[Peter Hutterer]

On Thu, Nov 19, 2009 at 12:14:31AM +0100, Tias wrote:
> >>Unfortunately, evdev chose the name 'SwapAxes' instead of 'SwapXY'. But
> >>with the patch from the email below, the gap with the established
> >>drivers is increased by putting all calibration values in one joined
> >>'Calibration <minx> <maxx> <miny> <maxy>'
> >>
> >>I would like to argue for using the same standard config names for the
> >>evdev driver. This would allow people to easily switch to and from the
> >>evdev driver: just change the name of the driver. It would also ease the
> >>work of calibration software and FDI policy files: the same
> >>min/maxX/Y can be used for all touchscreen drivers.
> >>
> >>
> >>Attached is a patch that changes the evdev driver to also use SwapXY
> >>and to use MinX,MaxX,MinY,MaxY for calibration. The manpage is
> >>updated too.
> >>Signed-off-by: Tias Guns <tias at ulyssis.org>
> >
> >sorry, no. your arguments are good, but I don't want to have two different
> >options that configure the same thing. it makes it harder to triage bugs and
> >debug for very little benefit. the only time this is really an issue is when
> >you're switching drivers between old driver and evdev, in which case some
> >configuration is involved anyway. we've already released 2.3 with the
> >options we have, removing them now is not an option.
> 
> We could keep the current option too, and just add a second one. You
> decide, but still I don't see a problem with 2 configuration
> options, possibly both or only one being documented.

undocumented options are the worst ones, imo. a few months or years down the
track nobody remembers whether it was an oversight or intentionally
undocumented. people will start using them anyway, which means deprecating
them them results in time wasted triaging bugs, getting users to switch
over. all for a arguably small benefit - options-compatibility with a
different driver.

> Imho, the importance of the compatibility of evdev depends on its
> ambition wrt. touchscreens. Currently the only advantage of evdev is
> that it allows dynamic calibration. 

evdev is first and foremost a mouse and keyboard driver. it does support
touchpads to some extent, albeit without the fancy features synaptics
provides. it does to some extent support tablets and touchscreens, albeit
without the fancy features wacom provides.

> Other then that, evtouch has a dejittering-like MoveLimit and right-click
> emulation with LongTouchTimer.
> It also seems that distributions like ubuntu are creating FDI policy
> files[1] for every touchscreen with its (default) Min/MaxX/Y values,
> and with driver evtouch. If evdev wants to replace evtouch it should
> allow an easy transition from evtouch (or any other driver) to
> evdev, no ?

i don't actually know how evtouch works internally, last time I tried it
didn't build against 1.7 at which point I lost interest. It doesn't seem to
be very actively maintained (unless google hides the active upstream from
me).
I don't know how many features evtouch provides aside from dejittering and
the right-click emulation (both of which would be perfectly appropriate for
evdev btw).

from a distro POV a smooth transition from evtouch to evdev would surely be
handy, but from an upstream POV I'd rather not clutter up the driver. a
transition is a once-off thing, hacks in the driver tend to stay around for
long.
 
> >in the case of Calibration, I think is the better name - it does actually
> >work differently to the MinX/Y.. options. The driver will still initialize
> >with the defaults given to it by the kernel. The calibration merely serves
> >to squash the actual coordinate range into the one obtained from the kernel.
> >MinX/Y... etc. actually change the coordinate range the device and the
> >server use.
> 
> So if I understand correctly, the difference is that evdevs 'Axis
> Valuators' are not changed when using a new calibration ? The
> dynapro driver did indeed do that, but the evtouch doesn't seem to
> do this either (just checked the valuator information with xinput
> list).

correct. the X input 1 protocol specificiation doesn't accommodate for
changing axis valuators, hence the server doesn't provide the abilities to
do so. XI2 supports it in the protocol, but not yet in the server.

Cheers,
  Peter