> From: Russell King - ARM Linux <[EMAIL PROTECTED]> > Date: Wed, 23 Jan 2002 19:24:02 +0000 > To: Jim Gettys <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], > [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] > Subject: Re: Touchscreen driver, Xinput extension, input device interface, > etc.... > ----- > On Wed, Jan 23, 2002 at 10:55:07AM -0800, Jim Gettys wrote: > > 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. > > Indeed it has. > > We now have a generic library that allows applications of any type to > interface via a standard API with any kernel interface, and be configured > to perform any scaling, filtering or whatever else you can think of > without even being re-linked. This is actively being used by several > people in the ARM community. > > > The line drawn in the sand is that we must avoid continuing the current > > Linux input interface disaster. > > I'm not completely happy that you suddenly took this coarse of action > leaving your previous discussions hanging in mid-air on this list. It > was only thorough rumour that we learnt your intentions. However, I'm > glad that a reasonable consensus has been reached that is now acceptable > to all parties.
The previous discussions were not moving to consensus well, and we realized that it was a generic problem, not specific to ARM. An ARM solution by itself was not going to make it. And the holidays intervened on available time. > > > 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. > > I'm especially glad that we now see eye to eye on this issue. > > > 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). > > This is fine. > > > 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. > > tslib already handles screen rotation, and the scaling of data. > tslib doesn't yet provide a method for handling the calibration data, > but that is on my to do list. You may well find that tslib provides > you a lot of your requirements in the user space side. Fine. A pointer would be useful, as due to personal reasons the last year has been to crazy for me to keep up with everything I'd like to. For it to be useful to the X distribution, it needs to be MIT licensed; lgpl won't hack it, and I'll write from scratch if need be. > > > 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 :-). > > Where will this data be stored? Assuming its in some non-volatile device, > do we really want a touchscreen driver combined with a MTD driver in a big > huge mass inside the kernel? (I personally think not). Left to the implementation. I expect most people will have a user space calibration program, which stores the information in a file. But we did not want to preclude implementations that do not depend on a read/write file system, not available on some embedded implementations. > > > 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. > > > > 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 hope you won't ignore this community while you work on this. 8) Nope. That is why it went to both lists: I'm a member of both communities. And once I have something running on the desktop and Andy has done the driver work, we'll bring it up on the iPAQ. > > tslib - see http://www.arm.linux.org.uk/cvs/ > > tslib is a clean, easily extendable design, and I'm hoping it can stay > that way. Tslib is only the tip of the iceburg from the perspective of the X server, which has to deal with a very wide range of input devices (mice, keyboard, touchscreens, joysticks, dial boxes, etc, etc.). Keith and I have been worrying about the general XFree86 problem, of which the iPAQ touchscreen is the least (but most immediate) of the problem. As I said, I'm always happy to use reuse code when possible. - Jim -- Jim Gettys Cambridge Research Laboratory Compaq Computer Corporation [EMAIL PROTECTED] _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
