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. > 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. > 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). > 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) 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. _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
