nanogui: Thread: Re: Touchscreen driver, Xinput extension, input device interface, etc....]

Forwarded from the linux-arm-kernel list...

-------- Original Message --------
Subject: Touchscreen driver, Xinput extension, input device interface, 
etc....
Date: Wed, 23 Jan 2002 10:55:07 -0800 (PST)
From: ####@####.#### (Jim Gettys)
To: ####@####.#### ####@####.####
CC: ####@####.#### ####@####.#### ####@####.####

Ok folks,

Since my statements about six weeks ago around touch screen interfaces,
(and that continuing to kludge the X server and/or current iPAQ touch
screen interface was just not going to happen), alot has happened.

The line drawn in the sand is that we must avoid continuing the current
Linux input interface disaster.  We will NOT go to a situation where both
X and OS kernels get kludged to support N different driver interfaces;
there lies the insanity we suffer with today.  This is a generic problem
to Linux; it is not a ARM problem at all (even if it generated a lot of
controversy on the ARM list).

Ideally, we'd see one such interface across all open source platforms,
but the enemy of the good is the perfect, and we'll settle for at most
one interface per operating system if need be, but not the cross product
of all possible driver interfaces and operating system platforms, which
is the dangerous situation we find ourselves in. The only savings grace
has been the commonality of RS232 across systems (with the insanity of
per manufacturer protocols).  But RS232 is rapidly becoming a thing of
the past.

Keith Packard and I have been in correspondence with Linus Torvalds and
Vojtech Pavlik (author of the new Linux input mechanism).  We recently
took a look at Vojtech's new input interface and found much there to
recommend it (including kernel timestamps, at last).

So here's our intent (and it will take some months to get there):

We're planning on using Vojtech's new input mechanism (most generally
fleshed out for USB devices, but it's always been intended for general
use) to deal with input devices in the future on Linux, and will be
retargeting the iPAQ's touch screen driver interface to this interface.

We plan to use the low level event interface provided, rather than the
more cooked (typically for backward compatibility) interfaces, as it looks
like it should greatly help with coming devices on desktop systems and
support of the X Input extension.  We should no longer have to teach X
about one device at a time, rather the kernel provides more abstract
interfaces for classes of devices we can leverage.

After a fair amount of discussion back and forth about how to handle
the touchscreen calibration data (file vs. kernel, whether the kernel
should rescale the data, etc., etc.), I believe we have a consensus
to use Pavel's input stuff as is, with a couple tweaks.

This implies a number of things:
	o We presume touchscreens are sane enough that they are at least
	linear devices: if you have non-linear devices, you'll need to
	build something to make it so (and possibly a user level process).
	o clients will have to rescale themselves (using the kernel's
	calibration data) rather than the scaling in the kernel the
	way the current iPAQ driver does.  This turns out to aid rather
	than hurt dealing with XInput, so we can get to the point where
	a calibration program is just a vanilla X client, and deal with
	screen rotation transparently (since the X server knows about
	rotation at any given instant).  Non X people will have to do
	their own rescaling of event data.
	o I'll keep backward compatibility to the H36xx driver interface for
	a while in TinyX, but it will be removed eventually, in favor
	of the event interface.
	o The input interface will be widened in two minor ways:
		1) user programs will be able to set the calibration data.
		(either make the EVIOCGABS ioctl RW or add a new ioctl).
		Pavel doesn't care which, but, of course, reserves the
		right to change it if it isn't what he wants :-).
		2) user programs (e.g. calibration programs) will signal
		to clients of the input interfaces the calibration has
		been changed by writing a reset event (the input stuff
		broadcasts this to all clients using the new input
		event mechanism).  Clients that care to respond to new
		calibration data will then read the calibration data and
		rescale.
	o new input devices will get signalled to the X server via
	the hotplug mechanism, precise details TBD.  It is there where
	policy will get set as to whether an input device gets handed
	to X or left alone to be used directly by other programs; we hope
	leveraging the work that is going on there on setting policy
	on how new devices get recognized/installed/configured.

I hope that this statement of direction will help people in making good
decisions on their driver work.

Keith and I have been thinking about whether we'll need a minor
rev to X input to allow hot plug of devices: it isn't quite clear yet
if we will or whether we can fit it into the current extension by
some conventions on its use.  We probably won't know for sure until we try
an implementation and see what, if anything gets badly contorted;
it may be possible to avoid any protocol changes at all, but this is not
quite clear (most likely from a quick look is we may want to add an event
informing clients of an hotplug operation).

The X development can/will be done on laptops and or/desktops,
and has nothing iPAQ or ARM specific; in fact, it is badly needed in 
general
to support input devices on the most common platform X runs on today.
I plan to start on part of this, prototyping using TinyX, with the intent
of moving it to the full XFree86 server when we've done it once.  If people
are interested in contributing to the larger effort of hotplug of input
devices (think of your favorite USB HID input toy) and the X input 
extension
on Linux using the new event interface, please let me know: there is plenty
of hacking to go around, and with USB support becoming ubiquitous in Linux,
the time is now.

				- Jim



--
Jim Gettys
Cambridge Research Laboratory
Compaq Computer Corporation
####@####.####


_______________________________________________
http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
Please visit the above address for information on this list.

-- 
------------ Alex Holden - http://www.linuxhacker.org ------------
If it doesn't work, you're not hitting it with a big enough hammer