Cc'ing Input list and maintainer. > > On Tue, 2 Mar 2010, Dima Zavin wrote: >> >> I definitely see the need for what you guys are trying to accomplish. >> For example, currently, we use an input device for reporting events, >> and a separate misc device node for control >> (enable/disable/configure). It's definitely suboptimal, but there >> currently isn't anything there would let us do things cleanly. > > I have to say, I personally don't see why something like an ambient light > sensor _isn't_ just an input device. > > What's the difference between a physical "increase screen brightness" key, > and a "ambient light sensor"? Absolutely none as far as I can tell. > > And for something like an X server, it sounds a lot more natural to just > have another input device than to have yet abother event reporting > interface. > > And quite frankly, the "explanations" I see in this thread for why it > needs to be a subsystem of its own don't actually explain anything or make > sense. They seem to boil down to "we just did it this way" without > actually answering any of the issues brought up. > > Linus > -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
