Subject: Touch Screen Driver Generic Interface for all Linux SA11x0 platforms.

From: Charlie Flynn <[email-masked]>
Date: Wed, 05 Jul 2000 17:59:20 +1000

Hello,

My name is Charlie Flynn and I have just completed V1.0 of a  touch
screen driver  for the Compaq iPAQ H3600 running Linux 2.4.0-test1.

I was thinking it would be a good idea if we had a generic interface to
the touch screen drivers of all Linux SA11x0  platforms.

This would allow clients ( such as the X windows device dependent layer
) to work, without modification, with all Linux SA11x0 touch screen
drivers.

I know it's a bit late to ask this ;-) but is there already a document
describing a generic TSD interface for these platforms?

Assuming there isn't such a document and also assuming people think it's
worth pursuing I can start the ball rolling by posting a draft spec to
the linux-arm-kernel mailing list which I assume would be the most
appropriate place to discuss this issue.

Regards
--Charlie

unsubscribe: body of `unsubscribe linux-arm' to [email-masked]
++        Please use [email-masked] for           ++
++                        kernel-related discussions.                      ++

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Wed, 5 Jul 2000 09:43:17 +0100 (BST)

> the touch screen drivers of all Linux SA11x0  platforms.

Indeed, or all Linux platforms if possible.  You might try to
find out about the following device, listed in
linux/Documentation/devices.txt:

 10 char        Non-serial mice, misc features
                 11 = /dev/vrtpanel     Vr41xx embedded touch panel

> describing a generic TSD interface for these platforms?

Yes, there is a driver for the touchscreen on the assabet/graphicsclient,
but it is written to be specific to the hardware on those machines.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |            http://www.arm.linux.org.uk/            /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |

---

From: Charlie Flynn <[email-masked]>
Date: Mon, 10 Jul 2000 22:43:55 +1000

Hi,

I attach my first cut of a generic touch screen driver specification as promised
from my earlier email.
This specification is based around my experience with the Compaq iPAQ H3600 touch
screen driver, however I have tried to make it as generic as possible for all
Linux platforms.

If nothing else I hope it will at least start the ball rolling in the quest to
gain consensus on what a generic touch screen driver will eventually look like.

I will also put this spec in html format on the www.handhelds.org web site.

Since there has also been some interest in the [email-masked] mailing
list I will post it in both lists for now with a view to maybe moving the
discussion to one (which one?) of the lists.

Regards
--Charlie

+++++++++++++++++++++++++++

MAJOR NUMBER
--------------------
(TBD)
A generic Touch Screen major number to be registered according to the procedure
documented in../linux/Documentation/devices.txt.
A major number 10 seems the most likely candidate.

DEVICE NODES and MINOR NUMBERS
----------------------------------------------

/dev/ts    - This is the device used to read calibrated touch screen events

A generic Touch Screen device name (/dev/ts)  and minor number (TBD) to be
registered according to the procedure documented in
../linux/Documentation/devices.txt.

TOUCH SCREEN EVENT STRUCTURE (TS_EVENT)
-----------------------------------------------------------

This is the structure contains the X and Y pixel coordinates of a single touch
screen event. It is passed from the driver to the user by the read() function.

typedef struct {
    short pressure;    /* used to determine if the touch screen pen is UP or
DOWN  (Note 1) */
    short x;                /* If  pen is DOWN then this is the pixel X
coordinate */
    short y;                /* If  pen is DOWN then this is the pixel Y
coordinate  */
    /* any more ? */
} TS_EVENT;

USER LEVEL FILE OPERATIONS
--------------------------------------
In addition to open(), close() and ioctl() functions, blocking and non-blocking
reads and asynchronous notification (SIGIO) should be supported at the user
level. The select/poll mechanism will be used for non-blocking reads.
See the EXAMPLES section for pointers to example code on the above functions.

KERNEL LEVEL FILE OPERATIONS
------------------------------------------

The following file operations pertain to device /dev/ts.

_read()
Blocking reads will block until a complete TS_EVENT structure (see below) can be
returned.

_fasync()
Will send a SIGIO to user when there is an event to report. An event is defined
as reception of a complete TS_EVENT structure.

_poll()
If there are 1 or more TS_EVENT structures to be read from the driver, then this
function will return the (POLLIN | POLLRDNORM) flags otherwise a zero will be
returned.

_ioctl()
The list of ioctls will depend on the hardware used to implement the touch screen
(example UCB1200).
Initialisation ioctls will be called by the driver’s init_module() or equivalent.

The calibration application (if adopted in user space) will have it’s own ioctls
(see CALIBRATION section).

The ioctl command numbers should be ‘mangled’ using the _IO,_IOW,_IOR,_IOWR
macros as defined in  <linux/ioctl.h>
A ‘magic number’ of ‘?’ should be used (see CALIBRATION section)

TOUCH SCREEN EXAMPLE  CODE
------------------------------------------

The following example code can be found in the ../apps/h3600_test directory in
the handhelds.org CVS tree.

ts_poll.c  - example of a non-blocking read using the poll/select mechanism.
ts_read.c  - example of a blocking read.
fasynctst.c - example of how asynchronous notifications are handled in user
space.

The driver which implements most of this specification  is called h3650_ts.c and
can be found in the ../drivers/char directory in the handhelds.org CVS tree.

CALIBRATION
------------------
(This section assumes the calibration mechanism will be an application)

The (H3600) calibration parameters are calculated by a separate calibration
application. It uses the Itsy calibration paradigm. The touch screen sensor is
assumed linear, conforming to the equations of a straight line:

Xcal = mxXraw + Cx
Ycal = myYraw + Cy

Calibration information is held in the TS_CAL structure and is passed to and from
the driver using the TS_GET_CALIBRATE and TS_SET_CALIBRATE ioctls.

#define  TS_SET_CALIBRATE _IOW(IOC_MAGIC,2,TS_CAL);
#define  TS_GET_CALIBRATE _IOW(IOC_MAGIC,3,TS_CAL);

The TS_CAL structure is used to convert RAW touch screen coordinates (Xraw and
Yraw) to calibrated touch screen coordinates (Xcal and Ycal).

typedef struct {
    int xscale;
    int xtrans;
    int yscale;
    int ytrans;
    int xyswap;
} TS_CAL;

The TS_SET_RAW_ON/OFF ioctl pair will switch between raw and calibrated data. The
calibration application will instruct the driver to return only RAW events using
the TS_SET_RAW_ON ioctl and when calibrated the calibration application will
switch the driver back to returning calibrated events using the TS_SET_RAW_OFF
(Note 2)

#define  TS_SET_RAW_ON  _IO(IOC_MAGIC,0);
#define  TS_SET_RAW_OFF  _IO(IOC_MAGIC,1);

TOUCH SCREEN CALIBRATION APPLICATION EXAMPLE  CODE
-----------------------------------------------------------------------------

The H3600 calibration application can be found in ../apps/ts_calibrate.c in the
handhelds.org CVS tree. This code is extensively commented and will explain how
the Itsy calibration application works. Note is uses a device called
/dev/h3600_tsraw to get raw data. This device may be superceded by the
TS_SET_RAW_ON/OFF ioctls.

Notes
1. Some systems return pressure as a value between 0 and xxxx which is used to
determine the pen status (UP or DOWN). The Compaq iPAQ H3600 just returns
pressure=0 (UP) or pressure=1 (DOWN). If UP then X and Y coordinates are set to
–1. Should this member variable be called something else?
2. The Compaq H3600 driver does not use this mechanism at present.

+++++++++++++++++++++++++++

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Mon, 10 Jul 2000 14:21:59 +0100 (BST)

> I will also put this spec in html format on the www.handhelds.org web site.

It should also sit elsewhere as well.  Some suggestions:

1. Main ARM Linux site
2. HPA should have a copy (since he admins the device database, and should
   be able to answer questions like "What is the API provided by major x
   minor y)
3. in the Documentation/ part of the kernel source tree.

> Since there has also been some interest in the [email-masked]
> mailing list I will post it in both lists for now with a view to maybe
> moving the discussion to one (which one?) of the lists.

I don't mean to cause offence to those people at handhelds.org or any
of the other mailing lists, but it strikes me that we're getting too
many mailing lists covering the same sort of areas, which is ending up
with a loss of clarity and greater confusion.  We currently have:

	[email-masked]

		For announcements about new features/projects etc only
		(moderated)

	[email-masked]

		For discussions about kernels/kernel APIs
		(unmoderated)

	[email-masked] OR
	[email-masked]

		For anything that doesn't fall into the above categories.
		(unmoderated)

	[email-masked]

		?

	[email-masked]

		StrongARM-1100 stuff ?

	[email-masked]

		Linux on ARM7110 ?

I would prefer to see all kernel stuff discussed on linux-arm-kernel, so
that there is one central place where people can go to look for stuff, in
much the same way as the main linux-kernel list.

I'd also like these "other" mailing lists provide a clear definition of
their purpose so that it can be documented and readily available to people.

Please, don't loose sight that we're not huge community (yet)!
   _____

---

From: Deborah Wallach <[email-masked]>
Date: Mon, 10 Jul 2000 10:30:28 -0700

[email-masked]

		   StrongARM-1100 stuff ?

I created this list for sa1100-specific linux issues (back when the sa1100
port was less well-integrated with the general arm port).  It's possible
that it's no longer needed.  Clearly, if it stays around it needs to have
sa1100 as well as sa1110 in its charter.  Nicolas, I'm willing to let you
define the charter... what do you think?

			-Debby

---

From: "A Page in the Life of ..." <[email-masked]>
Date: Mon, 10 Jul 2000 13:42:18 -0400

-=> I created this list for sa1100-specific linux issues (back when the sa1100
-=> port was less well-integrated with the general arm port).  It's possible
-=> that it's no longer needed.  Clearly, if it stays around it needs to have
-=> sa1100 as well as sa1110 in its charter.  Nicolas, I'm willing to let you
-=> define the charter... what do you think?

If you don't redifine the charter ... is there anywhere that folks are
talking about sa1110 -> CompactFlash/IBM microdrive direct driver issues in
linux?  I've found stuff on going through pcmcia, but nothing on the direct
stuff ... is it because there isn't anything, or there aren't any wire
specs or what?

Dave K>

---

From: Nicolas Pitre <[email-masked]>
Date: Mon, 10 Jul 2000 14:04:32 -0400 (EDT)

On Mon, 10 Jul 2000, Deborah Wallach wrote:

> that it's no longer needed.  

Does anyone on the [email-masked] feel that this list is still
required?  I used it for my patch announcements and though it would be a
good place for very SA11x0-specific Linux support discussions.  Maybe this
list can stay with its focus, maybe all the other lists can already do the
job.

Maybe concerned people can tell what they think?

In all cases I would like to see someone to host an web archive of that
list with
as many old messages as we can gather.  There were a lot of useful
informations that went through.

Nicolas

---

From: Nicolas Pitre <[email-masked]>
Date: Mon, 10 Jul 2000 14:32:47 -0400 (EDT)

> stuff ... is it because there isn't anything, or there aren't any wire

It's because it should just work already.  CompactFlash works for me on
Assabet and the IBM microdrive is working for someone else who own one.
The current SA1100 PCMCIA with the standard IDE support in the kernel are
the only drivers required.

Nicolas

---

From: Mike Touloumtzis <[email-masked]>
Date: Mon, 10 Jul 2000 13:47:27 -0700

On Mon, Jul 10, 2000 at 10:43:55PM +1000, Charlie Flynn wrote:
> 
> This is the structure contains the X and Y pixel coordinates of a
> single touch screen event. It is passed from the driver to the user by
> the read() function.
>

Hi Charlie,

Pixel coordinates won't be enough, in general.  Digitizers used for
handwriting recognition often have much higher resolution than the
LCDs, and the extra information is vital for good handwriting
recognition, particularly for Asian languages.

I've integrated Asian handwriting recognition libraries into OSes
which were not designed with this in mind, and I had to hack things
up get digitizer-resolution coordinates.

Plus, I think it'd be nice to decouple the digitizer API from a
specific screen resolution.

miket

---

From: Charlie Flynn <[email-masked]>
Date: Wed, 12 Jul 2000 00:26:37 +1000

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?

--Charlie

---

From: Wookey <[email-masked]>
Date: Tue, 11 Jul 2000 18:40:18 +0100 (BST)

On Mon 10 Jul, Russell King - ARM Linux Admin wrote:

> many mailing lists covering the same sort of areas

> 		Linux on ARM7110 ?

This is now basically the 'Linux on Psion PDAs' list

> their purpose so that it can be documented and readily available to people.

I generated this description of the various lists (for our ARMlinux
manual) a while back. If anyone has comments/disagrees etc please say so.
It will go online shortly.

   Mailing lists:
          There are several, depending on your level of experience/area
          of interest.

          There is a mailing list specifically for people new to
          ARMLinux, where you are positively encouraged to ask 'stupid
          questions.' This is <[75][email-masked]>.
          We recommend that all users join this list so that the
          community can help each other out and compare notes. To
          subscribe go to
[file://localhost/websites/www.armlinux.org/cgi-bin/mailman/listinfo/index.html] the local copy of the site
          http://www.armlinux.org and fill in the form. When you have
          finished go on-line and submit it. Alternatively you can fill
          in the form directly on-line.

          There is also <[77][email-masked]>. This is the
          'main' ARMLinux list which covers ARMLinux topics not specific
          to ARMLinux-newbie or linux-arm-kernel. This covers all
          architectures that ARMLinux is used on. Users who have ceased
          to be 'newbies' will find this of interest. To subscribe send
          'subscribe linux-arm' (in the body of the message) to
          <[78][email-masked].>

          <[79][email-masked]> is for
          kernel-related discussions, generally of a technical nature.
          This normally covers the kernel, compilers, related tools and
          new hardware. If you are a Linux beginner you won't understand
          a word of what goes on here :-) This is the place for those
          interested in the grubby stuff. To subscribe send 'subscribe
          linux-arm-kernel' (in the body of the message) to
          <[80][email-masked]>

          There are other lists not directly related to this distribution
          of ARMLinux that may nevertheless be of interest.
          <[81][email-masked]> relates to work on and
          discussion of the Debian port. In a similar vein,
          <[82][email-masked]> is concerned with the Psion 5 port
          of ARMLinux whilst <[83][email-masked]> is for those
          who are interested in the StrongARM 1100 Linux port (Itsy,
          LART, PLEB)

I should of course now add handhelds.org and emdebian.org to this list, and
linux-arm-announce, whose existence I had failed to notice (tut).

I agree with Russell's fundamental point that too much splitting is not
good, but equally I think that linux-arm and linux-arm-kernel are both
quite busy. I suspect that the sa1100 list is perhaps the one that might
be most appropriately re-integrated, and the linux-7110 list (which is
very low traffic) could also perhaps benefit from talking more to the
mainstream (eg a recent question there about a kernel oops didn't get
useful resonse directly because the people who knew the answers don't
read it). The other lists all have a well-enough defined purpose that
I don't think integration would help.

just my two pennorth.

Wookey
-- 
Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK  Tel (00 44) 1223 811679
work: http://www.aleph1.co.uk/     play: http://www.chaos.org.uk/~wookey/

---

From: Mike Touloumtzis <[email-masked]>
Date: Tue, 11 Jul 2000 10:57:08 -0700

On Wed, Jul 12, 2000 at 12:26:37AM +1000, Charlie Flynn wrote:
> 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

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Tue, 11 Jul 2000 20:50:58 +0100 (BST)

>           in the form directly on-line.

Yet more splitting, that even I wasn't aware of. ;(

>           new hardware.

Not compilers I'm afraid.

> quite busy.

Please define "busy".  From the linux-arm* lists combined, the maximum that
I've had (not including my postings) from them in one month (April 2000) is
331 messages in 30 days.  Of those, there were 161 messages on the linux-arm
list.  That's an total average of 11 messages a day, or 5 per day for
linux-arm.  Note that it normally averages 2 to 3 messages per day.  This
is "silent" compared with other lists such as "linux-kernel" who have 140+
messages a day, and the "mgetty" list which has about 4 per day.  I just
get very amused with people saying that the linux-arm* lists are busy.

I'm not sure that the correct answer is to create parallel lists with the
same subject area, but to have a clearly defined separation between the
lists (eg, linux-arm and linux-arm-kernel).  In general, the "right"
splits are on subject matter, not machine type since many problems span
most linux-arm machine types (eg, "how do I build a cross compiler" "does
xxx work on ARM Linux" "building cross libraries" "angel boot loader"
etc) and to fragment the community over these issues can only lead to
poorer information.

For instance, I believe that we have at least a third person announcing
that they will create a site where an x86 ARM cross toolchain will be
available from.  However, because it is distributed across a wide number
of hosts, it gets lost, and then someone else comes along and announces
the same thing.  Eventually we end up with some people going to one site,
and someone else creating another toolchain.

I have always offered to provide FTP space on the main site - in fact
there has always been a set of cron scripts running which automagically
mail me when stuff gets uploaded into /pub/linux/arm/incoming so that
it can be moved into the appropriate area, but I've yet to see anyone
take up on this.

As it stands, the "community" is becoming very fragmented with little or
even no communication between the parties, especially the 'armlinux.org'
group who appear to keep themselves completely to themselves.  This is
BAD, since it will lead to decay of quality, not improvement.

Oh, while we're on the subject of mailing lists, I'd like to table a
motion to close down [email-masked] and move to
[email-masked].  The reasons for this is:

1. vger.rutgers.edu is rather overloaded now, to the point where 
   the admins are refusing to setup new mailing lists.
2. Since Southampton Uni has finally closed my mail accounts (yay),
   I no longer get the administrivia mail from vger.
3. lists.arm.linux.org.uk is easier to administer, and is seen (I hope)
   as the central point for ARM Linux.
4. lists.arm.linux.org.uk has a faster response time than vger.

That's my 2p's worth tonight.
   _____

---

From: "Bradley D. LaRonde" <[email-masked]>
Date: Tue, 11 Jul 2000 16:25:54 -0400

----- Original Message -----
From: "Mike Touloumtzis" <[email-masked]>
To: "Charlie Flynn" <[email-masked]>
Cc: "Mike Touloumtzis" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Tuesday, July 11, 2000 1:57 PM
Subject: [Handhelds] Re: Touch Screen Driver Generic Interface for all Linux
SA11x0 platforms.

>    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

Agreed.  Yet another reason for not munging things in the kernel.  Give
every point to userspace so that all timing is known.

>    at read a bunch of data sheets before trying to settle on a canonical

Userspace.

>    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.

>    code--this is the gpm approach).

The kerenel should keep it's grubby fingers off the data.  :-)

Regards,
Brad

---

From: Paul Koning <[email-masked]>
Date: Tue, 11 Jul 2000 16:49:19 -0400 (EDT)

>>>>> "Bradley" == Bradley D LaRonde <[email-masked]> writes:

 >> ...

 Bradley> This is another reason why I think the best thing is to just
 Bradley> feed the raw data to userspace and divide it up there,
 Bradley> avoiding any attempt to calibrate or smooth data in the
 Bradley> kernel.

I'd agree with that, provided you also get a query function that lets
you discover what units are used for all those raw data items.  That's
a bit like X which gives you pixels (not world coordinates or
millimeters or whatnot) but lets you find out how big the pixel is.
(And unlike a certain other operating system which not only pretends to
use inches, but then doesn't actually use the same size inches
everyone else does.)

 >> -- Timestamps are important because they allow pen velocity to be

 Bradley> Agreed.  Yet another reason for not munging things in the
 Bradley> kernel.  Give every point to userspace so that all timing is
 Bradley> known.

I can't tell whether you meant "have the kernel timestamp every point
and give the result to userspace" or "have the kernel give every point
to userspace so the application can do the timestamping".

The latter won't work, of course...

 >> -- 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.

 Bradley> Userspace.

Sure, though here in particular the need to query units is important.
Also, I think you would want to linearize things, if the raw hardware
has an oddball transfer function.

    paul

---

From: Nicolas Pitre <[email-masked]>
Date: Tue, 11 Jul 2000 17:06:44 -0400 (EDT)

> every point to userspace so that all timing is known.

You won't have reliable time stamping in user space.  This has to be done
at the interrupt level.

Nicolas

---

From: "Bradley D. LaRonde" <[email-masked]>
Date: Tue, 11 Jul 2000 17:00:48 -0400

----- Original Message -----
From: "Paul Koning" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, July 11, 2000 4:49 PM
Subject: Re: [Handhelds] Re: Touch Screen Driver Generic Interface for all
Linux SA11x0 platforms.

> use inches, but then doesn't actually use the same size inches

No, I mean send raw, unitless data to userspace.

> The latter won't work, of course...

The touch panel that I work with takes samples at regular intervals.  If all
of those samples are delivered to userspace, then you can tell the timing of
data relative to other data, but not the absolute timing.  I suppose the
kernel driver could put an absolute timestamp on every data point, but I
can't offhand see the usefullness in that, and it certainly would eat
kernel/userspace bandwidth.  What would you need to compare any absolute
time against?

> has an oddball transfer function.

I'm saying that I think that all interpretation and distribution of the data
should be done in userspace, where it can be more easily engineered,
debugged, and extended.

Regards,
Brad

---

From: Russ Nelson <[email-masked]>
Date: Tue, 11 Jul 2000 17:35:09 -0400 (EDT)

> You won't have reliable time stamping in user space.  This has to be done

Some people are assuming that the digitizer is spitting out points at
a constant interval.  Others are assuming that the digitizer is only
spitting out deltas.

-- 
-russ nelson <[email-masked]>  http://russnelson.com
Crynwr sells support for free software  | PGPok | 
521 Pleasant Valley Rd. | +1 315 268 1925 voice | Is Unix compatible with
Potsdam, NY 13676-3213  | +1 315 268 9201 FAX   | Linux?

---

From: "Russ Nelson" <[email-masked]>
Date: Tue, 11 Jul 2000 18:09:28 -0400 (EDT)

Bradley D. LaRonde writes:
 > Yup, I'm a constant interval assumer.  :-)
 > 
 > To all:  is that safe to assume?  Is there touch panel hardware out there
 > that won't do this?

It's easier to generate deltas with a timestamp than it is to generate 
constant interval data, if you're given the "wrong" thing.

---

From: "Bradley D. LaRonde" <[email-masked]>
Date: Tue, 11 Jul 2000 18:03:50 -0400

----- Original Message -----
From: "Russ Nelson" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Tuesday, July 11, 2000 5:35 PM
Subject: Re: [Handhelds] Re: Touch Screen Driver Generic Interface for
allLinux SA11x0 platforms.

Regards,
Brad

---

From: Nicolas Pitre <[email-masked]>
Date: Tue, 11 Jul 2000 18:27:26 -0400 (EDT)

> should be done in userspace, where it can be more easily engineered,

The extreme stand on user space is not always so good.  At some point you
need a common base so the job doesn't have to be duplicated for every and
all clients.

That's the role of the kernel to present a coherent view of all
peripherals types to user space apps, wether is is a sound card, a
framebuffer device, a touchscreen panel, etc.  Otherwise, we would already
manage ethernet interfaces in user space, IDE chipsets, etc.

The "all in the kernel" approach isn't good either, far from it.  However
a good balance is required for not duplicating the work for all user space
clients.  Since the kernel is the common point of communication for all
hardware components and all software apps, we need to use it in order not
to waste too much time on skattered user space maintenance.  Thus the need
for a well defined kernel interface.

A good compromise might involve a common basic interface for presenting
data that all types of touchscreens can provide, with the possibility for
a user space app that wants more to turn the driver into a raw mode. The
same principle is currently implemented with termios (think of cooked vs
raw modes), keyboards (translated, keycodes or scancodes), etc.

This way, all windowing systems using the basic interface would work
automagically without modifications whenever a new touchscreen driver is
produced which is not the case with the "all in user space" approach.

What I would change from the original proposition is the following:

For each TS events, a struct with the x, y, pressure coordinate and time
stamp be returned with int values rather than short.  This allows for a
much larger scale while limiting alignment and size problems on
architectures that doesn't support shorts naturally.

Next, some ioctls that allows the client to probe for the x scale, y scale
and pressure scale allowed by the hardware.  Maybe also probe for the type
of coordinates i.e. linear, polar or whatever could be common usage. If a
certain hardware doesn't do sane coordinate and requires a special
transform then it would have to be done in the driver so it could fit into
the nearest standard coordinate type -- just like different color modes
and representations are presented through the generic framebuffer
interface.

Probably the driver would benifit from an isteresis processing which
parameters are configurable from user space, based on queried scale
ranges.  This has to be done in the kernel too so the user space client is
not waken up unnecessary by the noise.

But all interpretation of coordinates in order to match screen pixels,
calibration, etc. has to be done in user space since that's what likely
to change meaning from one application to another.

Nicolas

---

From: "Bradley D. LaRonde" <[email-masked]>
Date: Tue, 11 Jul 2000 18:38:09 -0400

----- Original Message -----
From: "Russ Nelson" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Tuesday, July 11, 2000 6:09 PM
Subject: Re: [Handhelds] Re: Touch Screen Driver Generic Interface for

> constant interval data, if you're given the "wrong" thing.

Ugh, I can just see it now, people taking a least-common-demoninator
approach because it adapts better to hypothetical delta-spewing hardware.

Regards,
Brad

---

From: "Bradley D. LaRonde" <[email-masked]>
Date: Tue, 11 Jul 2000 18:43:16 -0400

----- Original Message -----
From: "Nicolas Pitre" <[email-masked]>
To: "Bradley D. LaRonde" <[email-masked]>
Cc: "Paul Koning" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Tuesday, July 11, 2000 6:27 PM
Subject: Re: [Handhelds] Re: Touch Screen Driver Generic Interface for
allLinux SA11x0 platforms.

> need a common base so the job doesn't have to be duplicated for every and

Just because it isn't in the kernel doesn't mean there can't be a comon
base.  Share libs and userspace processes can also do abstraction.

Regards,
Brad

---

From: Chris Rutter <[email-masked]>
Date: Tue, 11 Jul 2000 23:52:12 +0100 (BST)

> and someone else creating another toolchain.

If you mean the emdebian.org people, they are pretty accurately targeting
these problems with coordination from some ARM Linux types; I don't think
at all that this is how their effort will end up.

> it can be moved into the appropriate area, but I've yet to see anyone

I think terming ftp.arm.linux.org.uk `the main site' is a little
contentious; ftp.netwinder.org (amongst others) contains at least as
much data important to the Linux/ARM project.  So eventually, I hope,
will ftp.armlinux.org.

> even no communication between the parties,

The Linux/ARM project is, certainly in places, stricken with this problem;
projects proceed in their relatively insulated autonomous groups, not,
I think, owing to any sort of unsociability, but just a lack of conscious
organisation at a higher level: it is a question that needs thought as to
whether and what kind of higher organisation is desirable.

armlinux.org is, incidentally, a part of my effort to remedy this sort of
problem.

> especially the 'armlinux.org'

armlinux.org really is little more than a WHOIS record at the moment:
this accusation is a paranoid one.  There is no `armlinux.org group' or
mafia; it is a domain name (and collection of i386/ARM machines) intended
to help foster open development, communcation, and web/FTP/shell space
for whoever might need it.

c.

---

From: Mike Touloumtzis <[email-masked]>
Date: Tue, 11 Jul 2000 17:15:41 -0700

In case it wasn't clear from my message--I'm in favor of passing raw
digitizer data to userspace, but with kernel-generated timestamps for
accuracy (without that, even the amount of jitter generated by interrupt
latency could hurt measurements). Most digitizers use regular sampling
intervals, but I have used some that don't (including ones that can't
generate interrupts and have to be polled by the OS--yuck!).

miket

---

From: "Russ Nelson" <[email-masked]>,
Date: Tue, 11 Jul 2000 21:17:03 -0400 (EDT)

> approach because it adapts better to hypothetical delta-spewing hardware.

How are mice hypothetical?  You lose nothing by compressing your data
stream into "and I saw the same thing for N intervals until I saw
this".  You *do* avoid context switches and kernel/userspace copying,
which are relatively expensive operations.  Remember: every electron
has to get pushed around by your battery.

---

From: "Bradley D. LaRonde" <[email-masked]>
Date: Tue, 11 Jul 2000 21:48:06 -0400

----- Original Message -----
From: "Russ Nelson" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Tuesday, July 11, 2000 9:17 PM
Subject: Re: [Handhelds] Re: Touch Screen Driver Generic Interface for

> How are mice hypothetical?

I know mice are delta beasts.  I was talking about touch panels.

> You lose nothing by compressing your data

I agree with you in principle, but in practice, a touch panel data stream
fluctuates enough so that this simple compression method doesn't buy you
much at all except more electrons running around trying to figure out if
they should (de)compress or not using that lonely extra code we've chucked
into both the kernel and userland side, but practically always getting
disappointed.

And I suppose someone will say "then put some hysteresis and/or noise
filtering in the kernel driver".  So now whenever the user holds his pen
perfectly still on the touch panel, all our extra code gets to do it's
dance.  :-)

Regards,
Brad

---

From: Paul Koning <[email-masked]>
Date: Wed, 12 Jul 2000 10:12:26 -0400 (EDT)

>> Some people are assuming that the digitizer is spitting out points
 >> at a constant interval.  Others are assuming that the digitizer is
 >> only spitting out deltas.

 Bradley> Yup, I'm a constant interval assumer.  :-)

 Bradley> To all: is that safe to assume?  Is there touch panel
 Bradley> hardware out there that won't do this?

I think so.

Furthermore, passing only non-zero deltas across the kernel/user
boundary is more efficient.  Those boundary crossings are very
efficient and doing one every millisecond or so is not particularly
desirable.

	paul

---

From: "Bradley D. LaRonde" <[email-masked]>
Date: Wed, 12 Jul 2000 10:29:53 -0400

----- Original Message -----
From: "Paul Koning" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Wednesday, July 12, 2000 10:12 AM
Subject: Re: [Handhelds] Re: Touch Screen Driver Generic Interface for
allLinux SA11x0 platforms.

<snip>
> efficient and doing one every millisecond or so is not particularly

As I mentioned in a previous email, I agree in principle, but in practice
non-zero deltas in raw touch panel data are too rare to bother with.

Also, who says you have to get touch panel data one reading at a time?  The
kernel driver can buffer the readings.

Regards,
Brad

---

From: [email-masked] (Jim Gettys)
Date: Wed, 12 Jul 2000 10:24:14 -0700 (PDT)

> recognition, particularly for Asian languages.

I agree...

> specific screen resolution.

Yup.  Not just nice, but essential for some applications.  This implies
the driver interface(s) should be in device coordinates to me, rather than
X coordinate systems.

There are two interfaces in X that have to be built: one in which the touch
screen is being used as the primary pointer, and then some other way to
deal with it in all its glory, almost certainly via the X Input extension.

(Un)fortunately, the X Input extension is something I haven't ever dealt
with, so I'll have to spend some time figuring things out.  This was going
on about the same time as I was last working on X related topics (the XSync
extension).

Keith Packard knows quite a bit about the input extension (he and Bob 
Scheifler ripped it apart and put it back together again some years ago), 
and we're talking to each other about how in general we need X input to 
get redone (note that while touchscreen is burning for handhelds, that 
the widespread deployment of USB over the next year is going to require 
this issue to get visited in a general sense for X; Keith is also interested 
in handheld computing).  Some work needs to be done to X in general in 
this area, as the input extension does not have the concept of devices 
coming and going (plug and play kinds of hardware weren't on the drawing 
board in the early '90's).  So not all the cultural history has been lost.
If we need to add an extension to make this all work, we can.

So we'll probably have to do a bit of work to X in general and while we're
at it, should ensure there be some way to get both screen coordinates from
the X server, and higher resolution coordinates for applications that need
them.
			- Jim

--
Jim Gettys
Technology and Corporate Development
Compaq Computer Corporation
[email-masked]

---

From: Keith Packard <[email-masked]>
Date: Wed, 12 Jul 2000 11:05:44 -0700

> deal with it in all its glory, almost certainly via the X Input extension.

I've been thinking more about input recently, and it's less than clear 
that the input extension is sufficient for pen-based devices.  Because the 
input device is so limited, I believe that a significant amount of policy 
will be required to distinguish between gestures intended as text input 
and gestures intended for pointer input.

In addition, we need support for a digital ink "overlay". One of the
important HWR lessons I learned from the Itsy was that graffiti with
feedback is much more reliable than without.

It's almost as if a separate app should be reading the touch screen and 
selectively synthesizing pointer and keyboard events; drawing digital 
ink on the screen to help make HWR usable.  Perhaps a portion of this app 
could be done within the X server using a grab/queuing mechanism similar 
to the core grabs.

Here's an idea -- have pen-down events cause raw input to be directed at
the external agent and simultaneously queued within the server.  The agent
could then monitor the gesture and at some point decide whether to echo
with digital ink, and finally decide whether to forward the entire queued
event stream on to the X pointer input queue or send it along for HWR. The
server could echo the ink itself or we could let the agent generate X
protocol for that.

[email-masked]		XFree86 Core Team	SuSE, Inc.

---

From: [email-masked] (Jim Gettys)
Date: Wed, 12 Jul 2000 11:15:57 -0700 (PDT)

> Sender: [email-masked]
> From: Mike Touloumtzis <[email-masked]>
> Date: Tue, 11 Jul 2000 10:57:08 -0700
> To: Charlie Flynn <[email-masked]>
> Cc: Mike Touloumtzis <[email-masked]>, [email-masked],
>         [email-masked]
> -----

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.  

> 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...

> -- Timestamps are important because they allow pen velocity to be

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.
>    at read a bunch of data sheets before trying to settle on a canonical

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...
 
>    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...

>    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

---

From: Steve Hill <[email-masked]>
Date: Wed, 12 Jul 2000 13:39:46 -0500

> resolution, though the hardware might make claims to be that high...
Actually, from experience with digitizing tablets for CAD which use
similar technology, the resolution is near that.

> The second question is how large do tablets get?
I used tablets that were 12"x12" and 36"x24", but I have seen them as
large as 48"x36".

-Steve

-- 
 Steven J. Hill - Embedded SW Engineer
 Public Key: 'finger [email-masked]'
 FPR1: E124 6E1C AF8E 7802 A815
 FPR2: 7D72 829C 3386 4C4A E17D

---

From: Paul Koning <[email-masked]>
Date: Wed, 12 Jul 2000 15:02:15 -0400 (EDT)

>>>>> "Steve" == Steve Hill <[email-masked]> writes:

 Steve> Jim Gettys wrote:
 >>  > 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).
 >> 
 Steve> Actually, from experience with digitizing tablets for CAD
 Steve> which use similar technology, the resolution is near that.

Of course accuracy isn't anywhere near that, but so long as the device
is monotonic, having the extra bits is potentially useful.

 >> The second question is how large do tablets get?
 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.

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.

 Jim> I'm a bit skeptical about pen color: are there devices that can
 Jim> change colors of pens dynamically?  Can they change pen types
 Jim> dynamically?  If yes, then I suppose the data might be packed
 Jim> into each event, and if no, just via an interface to determine
 Jim> once...

Pen type -- definitely.  Consider the Wacom tablet, popular among
graphic artists on PCs and Macs.  They come with several pen types
(pen, puck, airbrush).  Also, the pen has an "erasers" on the other
end, so you can flip it over to erase.  That's a property seen across
the API.

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).

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.

    paul

   paul

---

From: Steve Hill <[email-masked]>
Date: Wed, 12 Jul 2000 14:18:19 -0500

> is monotonic, having the extra bits is potentially useful.
I would agree.

> dimension, perhaps even more.
Whoops, I forgot about the mapping agencies too.

> 32 bits is clearly the safer answer.
You've got my vote for it.

> that each sample would consist of five analog values (x, y, z, air,
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.

> 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

---

From: Warner Losh <[email-masked]>
Date: Wed, 12 Jul 2000 13:33:16 -0600

In message <[email-masked]> Paul Koning writes:
:  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.

Back in school in the late 1980's, one of my jobs was to get a
digitizer table working.  While it didn't use a pen stylus, it was
6'x4' and had a resolution of about .001".  Its coordinate space was
something like 75000x50000.  There were larger tables at the time (on
the order of 12'x8') that were talked about in the manual that had an
even better resolution, but they were mondo expensive so we didn't
have one :-)

Warner

---

From: [email-masked] (Jim Gettys)
Date: Wed, 12 Jul 2000 12:38:22 -0700 (PDT)

So what you are saying is that something like xscribble becomes central
to input in general on handheld devices: it takes relatively raw input
and then tells X what to do when it needs to.  Building it into the
core X server seems wrong to me: by definition, we won't get it right:
I think we should regard it as though it were a window manager: a separate
application providing some of the UI.

The issue I see is how to arbitrate among more than one application that
might want/need the high resolution digitizer device...  We'll certainly
be running something like scribble continuously, but other apps may need
more than what the X core protocol gives them.  If the Xinput stuff can
adaquately handle this situation (other applications in addition to
the scribble app), then we have a rational course of action.

I guess it is time to go look at the Input extension and see if it can 
deal with digitizers adequately in the general case and whether it has 
any grab/replay notion.  My book is at home, I'll try to remember to get 
a copy and stare at it some tomorrow.

					- Jim

> From: Keith Packard <[email-masked]>
> Date: Wed, 12 Jul 2000 11:05:44 -0700
> To: [email-masked] (Jim Gettys)
> Cc: Mike Touloumtzis <[email-masked]>, Charlie Flynn <[email-masked]>,
>         [email-masked], [email-masked]
> _______________________________________________
> Handhelds mailing list
> [email-masked]
> http://handhelds.org/mailman/listinfo/handhelds

---

From: "Bradley D. LaRonde" <[email-masked]>
Date: Wed, 12 Jul 2000 15:46:48 -0400

----- Original Message -----
From: "Jim Gettys" <[email-masked]>
To: "Mike Touloumtzis" <[email-masked]>
Cc: "Charlie Flynn" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Wednesday, July 12, 2000 2:15 PM
Subject: Re: [Handhelds] Re: Touch Screen Driver Generic Interface for all
Linux SA11x0 platforms.

> updated with correct values if the user recalibrates the device).

/etc/pointercal

> practical impact is large.  Saving the information between processes is

echo ... > /etc/pointercal

Regards,
Brad

---

From: Keith Packard <[email-masked]>
Date: Wed, 12 Jul 2000 12:51:00 -0700

> application providing some of the UI.

With help from the server for queuing and resending events.  One tricky 
part will be to get it to work in the presence of server grabs...

> might want/need the high resolution digitizer device...

That's separate from input management, lets see if that can be made to use 
the X input extension.

---

From: Warner Losh <[email-masked]>
Date: Wed, 12 Jul 2000 13:54:56 -0600

In message <[email-masked]> Jim Gettys writes:
: So what you are saying is that something like xscribble becomes central
: to input in general on handheld devices: it takes relatively raw input
: and then tells X what to do when it needs to.  Building it into the
: core X server seems wrong to me: by definition, we won't get it right:
: I think we should regard it as though it were a window manager: a separate
: application providing some of the UI.
: 
: The issue I see is how to arbitrate among more than one application that
: might want/need the high resolution digitizer device...  We'll certainly
: be running something like scribble continuously, but other apps may need
: more than what the X core protocol gives them.  If the Xinput stuff can
: adaquately handle this situation (other applications in addition to
: the scribble app), then we have a rational course of action.
: 
: I guess it is time to go look at the Input extension and see if it can 
: deal with digitizers adequately in the general case and whether it has 
: any grab/replay notion.  My book is at home, I'll try to remember to get 
: a copy and stare at it some tomorrow.

For what is worth....

I have a program that will read the newton keyboard input stream and
feed it to the X server via the XInput extention.  It deals well with
all key events that I throw at it, as well as dealing fairly well with
the kludge mouse events that I had in it for a while (I ripped them
out because I could more easily do mouselike things with the keyboard
via window manager mappings, etc).  This stuff is much lower
resolution than the digitizer input that you're talking about, but it
does show that at least investigation down this path might be
warranted.

This works well.  It certaily is entertaining to have two different
keyboards that both do the right thing.  I'm even able to use the
serial keyboard on machine X to control the X server on machine Y.  It
is very flexible, at least for keyboard input.

I'd imagine that scribble would recognize the drawn letters and conver
them to key press key release events.  I'd also imagine that a virtual
keyboard would do the same sort of thing.

Warner

---

From: [email-masked] (Jim Gettys)
Date: Wed, 12 Jul 2000 13:00:51 -0700 (PDT)

> keyboard would do the same sort of thing.

This is exactly how xscribble works: the source is in the handhelds.org 
CVS repository.  So you don't need to imagine: you need to compile and
run it instead....

xscribble synthesizes input sends it back to the X server to go to the right
application. xscribble is the name of the application that does this that
we've demoed on Itsy, and which is now on the iPAQ (and feel free to port
it elsewhere). 

We haven't done a virtual keyboard (yet).  Any volunteers?

					- Jim

---

From: "Vadim Lebedev" <[email-masked]>
Date: Thu, 13 Jul 2000 11:03:52 +0200

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-masked]
[mailto:[email-masked]]On Behalf Of Steve Hill
Sent: mercredi 12 juillet 2000 21:18
To: Paul Koning
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [Handhelds] Re: Touch Screen Driver Generic Interface for
all Linux SA11x0 platforms.

I would agree.

> that each sample would consist of five analog values (x, y, z, air,
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.

-Steve

unsubscribe: body of `unsubscribe linux-arm' to [email-masked]
++        Please use [email-masked] for
++
++                        kernel-related discussions.
++

---

From: Mike Touloumtzis <[email-masked]>
Date: Tue, 18 Jul 2000 13:43:29 -0700

> the others to suffer for their own sins of bad hardware...

(sorry for the delay; I'm pretty burst with mailing list mail)

I don't know with how much hardware an affine transform will work;
I'm not really a digitizer expert, I've just worked with a number
of specific components.  It certainly seems reasonable to say "the
kernel driver will normalize the coordinates if it's easy to do so,
otherwise it'll somehow convey the device type to userspace, and
it's the job of userspace to deal with weirdo hardware."

miket