On 09/24/10 14:02, Pavel Machek wrote: > Hi! > >>> 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. > > That's very similar to analog joysticks, no? Yes, but typically much slower. Maybe a couple of times a second at most. Some of them do support events. The original proposal didn't include these as no driver at the time supported them. drivers/staging/iio/light/tsl2563.c does now though. Given the low rates, we did discuss doing this via select on sysfs attributes (driven off underlying hardware interrupts). > >>> 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 > > I'd not put GPS into input; yes, they do present 'x,y,z' in meters, > but that's not what users want. 'lat,lon,alt' is better, but it is > actually 'lat,lon,herror,alt,verror,time' and a lot of other > metadata... > > Also, we already have driver for GPSes, its called gpsd. I'd leave > GPSes out of input. > >> Also, GPS, liek ALS, would probably be polling, no? > > Normally, GPS just sends you position info once a second. -- 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
