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).
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).
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.
-- 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.
-- 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.
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).
miket
[1] Not quite--there are electromagnetic digitizers in addition to
pressure sensitive ones; I wouldn't refer to them as "touch
screens" even when used with an LCD. But handheld devices usually
seem to be touch based.
[2] http://www.amug.org/amug/sigs/newton/nanug/PenReport/Handwriting.html
unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
++ Please use [EMAIL PROTECTED] for ++
++ kernel-related discussions. ++
