On Tue, Aug 31, 2010 at 05:59:37PM +0100, Alan Cox wrote: > > > If non-input uses later need non-input interfaces they can switch to that > > > with an input bridge when there is one and when it happens, which > > > probably won't. > > > > Would there even be an argument which subsystem to use if IIO->input > > bridge existed today? Because if the answer is "no" then push into input > > is driven by convenience and not because it is the right solution. > > Probably because most of these devices have nothing to do with industrial > I/O at all. "Data acquisition devices" then? > > > If application does take something as an input it does not make it > > necessarily a human interface device. By this reasoning cameras should > > be represented as an input devices (why, some applications take input > > That's not what I asked. > > > I really believe that input should represent purely human interface > > devices, not arbitrary data acquisition devices. > > That tends to make little sense where the API is the same and > applications benefit enormously from consistency. I'd rather have an > input->IIO bridge because that is the real world today ! > > The question is what does the API make *sense* for. Not what can you use > the API for. Unix (and Linux) are enormously powerful because of the use > of common interfaces and APIs. > > So a voltmeter really makes no sense. It's not a set of keys and it > doesn't give X/Y/Z style readings. Nor does a camera. But a lot of things > do fit this to varying degrees. > > I'm actually more dubious than Linus about ALS - because ALS tends not > produce 'events' but to be sampled, and there are significant power > implications to unnecessary polling. > > See it as a curse of success - because you got the API right and made it > flexible people want to use it. I knew it! Its all Vojtech's fault. > And the more it's used the less special > code is needed in user or kernel space for PDAs and phones - instead they > just work. OK, so let's say we start moving some of the devices into input. Which ones we consider suitable for input? I guess some 3-digit accelerometers, what else? Also, what new event types would we need? Let's take GPS - I do not think that ABS_X and ABS_Y are the best events to be used for such devices: I am trying to allow applications being ignorant of what exact device they are talking to and rather concentrate on device capabilities (list of events supported). GPS is sufficiently different from a tablet/touchscreen; while some might want to use both as inputs to a game most applications would want to know which one which. Also, GPS, liek ALS, would probably be polling, no? -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
