Subject: Re: Touch Screen Drivers

From: Charlie Flynn <[email-masked]>
Date: Tue, 01 Aug 2000 09:00:57 +1000

Hi Scott,

>
> The kernel used by the iPAQ had three touch screens:
>

Actually there may be three touch screen files but the iPAQ uses only the h3650_ts.c. The
other two drivers are for other platforms and interface to different touch screen hardware.

There is a move under foot to make all touch screendrivers have a generic interface ( as
far as X is concerned ) you can find the current (draft) spec at:

http://handhelds.org/projects/ts_spec.html

>
> h3650_ts.c  sa1100_ts.c  ucb1200_ts.c (the last two being nearly the
> same.) I was not able to determin how the init code was called for
> h365_ts.c.

I am not exactly sure what you mean. There is a function in h3650_ts called init_module()
which initialises the driver. If you mean what inits the iPAQ touch screen hardware then
the iPAQ driver doesn't talk to a touch screen device directly but to a microcontroller
which ( in turn ) talks to the touch screen device.

Hope this helps
-Charlie

unsubscribe: body of `unsubscribe linux-arm-kernel' to [email-masked]

---

From: Tak-Shing Chan <[email-masked]>
Date: Tue, 1 Aug 2000 10:08:54 +0800 (CST)

Is there already someone working on the generic touchscreen driver
for the Assabet?

Tak-Shing Chan

---

From: Charlie Flynn <[email-masked]>
Date: Tue, 01 Aug 2000 13:39:37 +1000

> Is there already someone working on the generic touchscreen driver

We are still in the draft spec phase. When it is finalised individual driver writers will be
able to modify their interfaces.

---

From: S A McConnell <[email-masked]>
Date: Wed, 02 Aug 2000 09:23:12 -0500

Charlie Flynn wrote: 
> >
> > - Where in the kernel should the device driver reside? (/drivers/char?)
> 
> There are different classes of devices
> character
> block
> sound
> network
> Each is kept in it's own class directory
> /drivers/char
> /drivers/block
> /drivers/sound
> /drivers/net
> 

There appears to be a sub class to /drivers/char called "misc_device"
Mouse/pointing devices appear to be located (See /drivers/char/misc.c
and /include/linux/miscdevice.h) They have a different mechanism for
registering the file ops. The MIPS folks used this "API?" over the "char
API".

misc_register(&vr41xx_tpanel); -vs-
register_chrdev(0,"sa1100-ts",&sa1100_ts_fops);

Has that interface been replaced?

I think we need to ask what is a touch screen?
-It appears to me to be a pointing device closely related to mice. As
such shouldn't we use the misc_device approach? (This is where you find
major 10 devices.)

If it does not matter shouldn't we stop using one of them to gain more
common set of device driver API's?

BTW, do not forget about the hidden API/grammer in the Read/Write
routines.
When we read the device the data it returns has some meaning. The
meaning of that data
needs to be well specified. (The API appears to be doing that)

                 Applications (X, Microwindows,...)
             ==================================================

              Module/non-Module) API | File Ops API | ioctl API
             ---------------------------------------------------
                     Serial Interface Bus
             --------------------------------------
                UCB1200 (Touch Screen controller)

                                      | File ops API
Touch Screen | Touch Screen filtering | ------------
                                      | ioctl API

Touch Screen:
-Knows how to read an write the registers and knows how to initialize
the hardware.

Touch Screen Filtering:
-Knows how to apply filtering algorithms, has an API to provide the
cooked data,
 might have an API that allows the parameters used by the filtering
algorithm to
 be changed.

File Ops API:
- How applications get access to the data.

ioctl API:      (I may not have a valid understanding of this)
-Methods to control the settings of the filters and hardware

We should try to hammer out the layers then move fuctionality up and
down those layers until we reach some level of agreement ;-). For
instance, if we find most applications are performing the same
fuctionality that implies an additional layer.

Scott