On Wed, Jan 23, 2002 at 12:18:00PM -0800, James Simmons wrote: > > 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 :-). > > What? I think you misunderstood the use of EVIOCGABS. That returns the > range of values the hardware can generate. Those values are used > internally in the input system to filter out junk. Sometimes hardware can > give you errous data so those fields filter that.
I have to correct you here: They're *NOT* used internally to filter the data. They are informative only, for the userspace. The kernel doesn't dare to filter the data at all (except for simple noise elimination, which is needed because we don't want to flood the userspace with too much data). So it's more like: "Hey, app, expect the data in this range, if it'll overflow the range, filter it if you wish." When we get EVIOCSABS, it makes sense, because the kernels first guess at the 'reasonable range' of the device may not be 100% correct. So it is OK with me to use this for passing touchscreen calibration information. The kernel won't filter the data outside the range, but the app will know what the range covering the screen is. > > 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. > > Again are you dealing with hardware that would reprogram itself to change > the range of values it would produce for events? > > > 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. > > It shoudn't matter for read incoming events if a bunch of programs, X and > other things, would use the event interface at the same time. It is > writing that does matter. Then we get into a per process state that is > stored. Except for FF, which is one-writer-only (for obvious reasons), for all other devices (keyboard, etc) the state is shared, and all those who use the device are notified of eg. LED changes if one of them does that. -- Vojtech Pavlik SuSE Labs _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
