Just my 2 cents
I think that it will be good idea to design the API not only fow only for 2D
tablets
but also for 3D (or maybe even generic N-D) input devices....
Vadim
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Steve Hill
Sent: mercredi 12 juillet 2000 21:18
To: Paul Koning
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [Handhelds] Re: Touch Screen Driver Generic Interface for
all Linux SA11x0 platforms.
Paul Koning wrote:
>
> Of course accuracy isn't anywhere near that, but so long as the device
> is monotonic, having the extra bits is potentially useful.
>
I would agree.
> Steve> I used tablets that were 12"x12" and 36"x24", but I have seen
> Steve> them as large as 48"x36".
>
> I've seen them quite a lot bigger than that. I remember pictures of
> tablets used for work on maps that were clearly bigger than a standard
> old-time draftman's drafting table. Maybe six feet or so longest
> dimension, perhaps even more.
>
Whoops, I forgot about the mapping agencies too.
> My strong prerefence is to play it safe. Squeezing coordinates into
> 16 bits doesn't buy much and it's sufficiently close to the edge that
> 32 bits is clearly the safer answer.
>
You've got my vote for it.
> I vaguely remember seeing mention of Wacom support in Linux and
> possibly in X. Certainly that device would be an important test case
> for any API, along with the perhaps more familiar architect-style puck
> tablets. The sort of parameters that the Wacom device sends relate to
> its need to emulate artist tools. Take a look at the "airbrush". I
> don't have one, my Wacom is too old. But a regular "double action"
> airbrush (the non-computer kind) has two control inputs apart from
> position: air volume and paint volume, which are independent. And
> position is in three coordinates, not just two (distance from the
> paper matters a lot). If the Wacom device emulates all that, it means
> that each sample would consist of five analog values (x, y, z, air,
> paint).
>
Owen Tayler maintains the XInput HOWTO document which you can find at
(http://www.gtk.org/~otaylor/xinput/howto/). I haven't looked at in a
while though. It appears support is there for Wacom and Summagraphics
just to name a few. This uses X to handle the data i.e. the user land
side which goes back to an earlier comment by Brad that the data should
come raw from the kernel to be handled by the application.
> Hm. Off the wall thought. Would it make sense for a digitizer API to
> be applicable to 3d input devices as well, things like 3d pointers,
> sensor gloves, stuff like that? There seems to be a lot of overlap,
> but it may be too much of a distraction.
>
I would have to say no. Something says to me "no" because things start
popping in my head like Euler angles, infancy IMHO of 3d input devices,
etc. I would be interested in other peoples thoughts, but we should
probably start a different thread.
-Steve
--
Steven J. Hill - Embedded SW Engineer
Public Key: 'finger [EMAIL PROTECTED]'
FPR1: E124 6E1C AF8E 7802 A815
FPR2: 7D72 829C 3386 4C4A E17D
unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
++ Please use [EMAIL PROTECTED] for
++
++ kernel-related discussions.
++
unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
++ Please use [EMAIL PROTECTED] for ++
++ kernel-related discussions. ++
