On Wed, Jan 23, 2002 at 12:55:00PM -0800, James Simmons wrote: > > > 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). > > When I was talking about filtering I was talking about the simple noise > elimination. This is the reason I never give talks. I'm not the greatest > at words. As for the other values I knew they are not used. Especially > when I have used really off values. I would have never obtained any data > otherwise. I have to tell you tho the first time you look at data people > do get the impression that is what those feilds are for. Look at the > confussion on this list about this.
Yes, I should document this better somewhere. But you agree that what's done is the sane thing? > > 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. > > Hm. The issue with that is userland might pass in really off values. Then > any calibration is really screwed. Oh I guess if someone does something > that dumb oh wells. It doesn't bring the system down. Exactly. And there is always permissions on the device file, by which you can control who has access to both the event data and settings of the ranges. > > > 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. > > True. What I was purposing was to make it pre process. Of course this gets > more complex. How do you make LED state per process? I deem that impossible. -- Vojtech Pavlik SuSE Labs _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
