----- Original Message -----
From: "Mike Touloumtzis" <[EMAIL PROTECTED]>
To: "Charlie Flynn" <[EMAIL PROTECTED]>
Cc: "Mike Touloumtzis" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Tuesday, July 11, 2000 1:57 PM
Subject: [Handhelds] Re: Touch Screen Driver Generic Interface for all Linux
SA11x0 platforms.
> In writing a digitizer driver API, there are a few main things to keep
> in mind:
>
> -- Allow room for plenty of resolution, and don't assume pixel coords
> will equal digitizer coords.
This is another reason why I think the best thing is to just feed the raw
data to userspace and divide it up there, avoiding any attempt to calibrate
or smooth data in the kernel.
> -- Timestamps are important because they allow pen velocity to be
> measured.
Agreed. Yet another reason for not munging things in the kernel. Give
every point to userspace so that all timing is known.
> -- Allow room for expansion to new data types in the API (for instance,
> pen pressure info). Translation: pad structures a little :-). I
> wouldn't want to try to overdesign this; that way lies X. I would
> at read a bunch of data sheets before trying to settle on a canonical
> API, though.
Userspace.
> -- Some digitizers have non-linear input systems and need input munging
> beyond the simple device-independant translation/rotation/deskew that
> calibration can provide. Most devices work fine with the equivalent
> of a single affine transform at most, but I know of at least one
> shipping touchscreen PDA/phone in Japan that essentially requires a
> system of linear equations to normalize coordinates, and also has
> two "dead zones" that must be worked around.
Userspace. BTW, I've released a solved system of linear equations in my
touch panel driver for microwindows. Several people got involved in the
creation of those equations, and they work well.
> A driver API should be clear about whether it normalizes coordinates
> (in which case it must be possible to feed it calibration points from
> a userspace app) or whether it passes raw digitizer input to higher
> layers (in which case those layers must have hardware-dependent
> code--this is the gpm approach).
The kerenel should keep it's grubby fingers off the data. :-)
Regards,
Brad
unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
++ Please use [EMAIL PROTECTED] for ++
++ kernel-related discussions. ++
