> Sender: [EMAIL PROTECTED]
> From: Mike Touloumtzis <[EMAIL PROTECTED]>
> Date: Tue, 11 Jul 2000 10:57:08 -0700
> To: Charlie Flynn <[EMAIL PROTECTED]>
> Cc: Mike Touloumtzis <[EMAIL PROTECTED]>, [EMAIL PROTECTED],
> [EMAIL PROTECTED]
> Subject: [Handhelds] Re: Touch Screen Driver Generic Interface for all Linux
> SA11x0 platforms.
> -----
> On Wed, Jul 12, 2000 at 12:26:37AM +1000, Charlie Flynn wrote:
> > Thanks for the reply Mike.
> >
> > I haven't come across a Digitizer before so are you saying that a
> > simple redesign of the TS_EVENT structure is all that is needed
> > to accommodate the Digitizer or does the Digitizer require other
> > special considerations? In other words will this spec accommodate the
> > Digitizer without too much modification?
> >
>
> A digitizer is just a touch screen input device. The Palm Pilot has
> a digitizer; so does the Psion Series 5. In the lingo I've been used
> to, digitizer + LCD == touch screen[1]. It sometimes connotes high
> resolution, especially WRT to the graphic artist market. My experience is
> mainly in Japanese consumer electronics; handwriting recognition is taken
> much more seriously there than in the U.S. and European markets, because
> everyone learns to write characters (even English ones) using a consistent
> stroke order, so vector handwriting recognition works very well.
>
> Unfortunately, the word "digitizer" is overloaded, and also refers to
> various forms of specialized A/D equipment, like ultra-high-resolution
> physical surface scanners, and optical scanners. But it's pretty
> unambiguous in the consumer electronics market; there's not a lot of
> overlap.
>
> The type of information you get out a digitizer varies from coarse
> worse-than-pixel resolution (this type might be used in a greasy-sceen
> supermarket kiosk) to a current peak of about 10,000 lines per inch
> (for high-end graphic artist drawing tablets).
10K LPI!!!! I don't believe they could possibly really be at that
resolution, though the hardware might make claims to be that high...
The second question is how large do tablets get?
The product of LPI (LPC) and the size tells us how big the coordinates
should be...
By this theory, it sounds like 16 bits/coordinate may be enough, but at
32 bits/coordinate, it can't possibly be wrong (since this would imply
a physical size for the digitizer of 6 miles or so). Since at 16 bits
we are a bit close for taste (1K line resolution results in a 5 foot
digitizer size), it sounds like coordinate values should be 32 bits to
be safe.
>
> Handwriting recognition on consumer electronics devices is typically done
> using vector paths at digitizer resolution; in addition to X+Y coordinates,
> the following info might be available from the hardware: pressure, stylus
> angle, stylus height (mainly for RF devices like the Cross input pad, I
> think; I have no experience with this). The Jot HWR system stores a whole
> bunch of info per path:
>
> "The ink is stored in vectorized form (important for resizing and
> representation on higher resolution output devices) and currently may
> include the following attributes[35]: stroke order, bounding coordinates,
> groups of strokes, timing, pressure, stylus angle (in x and y directions),
> pen color (including opacity), scaling and offset, height over the
> digitizer surface, buttons on the pen, and pen tip type. Speed and
> pressure, for example, are important for signature verification, and
> color may be used for user identification in a multi-user environment."[2]
>
> Some of these attributes come from the hardware, while others are clearly
> plugged in by software and probably wouldn't play a role in a kernel API.
> Timing info is plugged in by software, but must be very high-precision
> and so should probably be handled by the kernel (by sticking a
> gettimeofday()-derived timestamp on input data points).
Yup. More on time stamps below.
I'm a bit skeptical about pen color: are there devices that can change
colors of pens dynamically? Can they change pen types dynamically?
If yes, then I suppose the data might be packed into each event, and
if no, just via an interface to determine once...
>
> Good ink display is also best done with a sub-pixel coordinate system,
> for the same reasons that sub-pixel sampling is good for antialiasing
> and other graphical effects.
>
> 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.
>
> -- Timestamps are important because they allow pen velocity to be
> measured.
Yes. I agree completely. X needs timestamps associated with
device events to allow proper serialization among different devices
as well.
So I think timestamps should present in device driver events I can try
work around their absense, but it is a pain, and always more questionable
than if the device driver generates the timestamps itself. In short,
user space timestamps are fundamentally unreliable and don't work well...
The next question is units: is more than a millisecond resolution time
stamp needed? Or do we return a struct timeval? (another 64 bits on
32 bit machines). X's timestamps are a 32 bit value in milliseconds,
(32 bits).
Just go the the Linux kernel list, where they are discussing worst case
latencies for user space stuff at the moment: while they are working
to minimize the latencies, the worst case are frightenly high.
>
> -- 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.
We did allow for new datatypes and padded structures in X. The core X
stuff isn't so badly overdesigned, but some of the extensions went of the
deep end...
>
> -- 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.
Question: is a single affine transform going to get more than 90% of the
devices out there? If so, lets run with this, and be done with it; leave
the others to suffer for their own sins of bad hardware...
>
> 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).
>
I believe it is important that things be "sane" when you power up a system.
To me, this means that I need to be told somehow how to convert hardware
device coordinates to something that applications (read X) can use.
This argues to me to report the raw coordinates to user space, along with
calibration data (which can be approximate when first started, but then
updated with correct values if the user recalibrates the device).
Since you might (or might not) run a calibration application under a window
system, I think there should be a way to set the default calibration
information in the driver, rather than have to recalibrate for each
application that comes along. In some sense, this is rediculous (since
all the calls would be doing is saving information for later), but the
practical impact is large. Saving the information between processes is
non-trivial...
And for the record, devices that spew events continuously forever should
be banned: it is certainly the case that this should not cause user space
processes to be woken up continuously to deal with (non)events they don't
care about. Informing applications that nothing has changed is brain-death
beyond belief. (not on my battery power, you don't!).
And yes, the kernel should buffer events for clients: clients get busy
for a while, and it is much cheaper to to pick up a bunch of events at
once when you are busy than handle them one at a time. This minimizes
the overhead when you need to minimize it (when you are busy).
- Jim
--
Jim Gettys
Technology and Corporate Development
Compaq Computer Corporation
[EMAIL PROTECTED]
unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
++ Please use [EMAIL PROTECTED] for ++
++ kernel-related discussions. ++
