Re: Sensors and the input layer (was Re: [RFC] [PATCH V2 1/2] input: CMA3000 Accelerometer driver)

[Pavel Machek <pavel@ucw.cz>]

Hi!

> > >> (or GPS device, for that matter) really be?
> > >
> > > But why GPS should be input device? It has nothing to do with user
> > > input.
> > 
> > What? OF COURSE it is an input driver. It's the user moving the device
> > around. It's EXACTLY the same thing as an accelerometer in that
> > respect. Sure, it's a bit less precise and measures movement wrt some
> > external frame, but technically they are almost exactly the same.
> > 
> > If you se doing a navigation app, the accelerometer, the compass and
> > the GPS are all equally (but differently) important.
> > 
> > Again - it's not a user touching buttons. But it IS a user moving around.
> 
> Right, but do you expect that movement to cause an immediate action?
> When you press a key - something happens; when you swing a Wii
> controller - the device reacts. And really you can swap joysticks,
> motion controllers, Sony's 6-axis and so forth and the application would
> be hard pressed to tell the difference. I am unsure how you would play a
> game with GPS as an input device.

Well, there's cross between geocaching and game called 'whereigo'; I
played it once, it is quite fun...

"You bought a horse. Check if horse was fast enough by running to the
trees you see north of you". And so you run. "Your horse is too
slow. Try again".

OTOH, for the GPS... I guess it is more complex because you have
important and non-trivial metadata, such as precisions, fix type,
#sats used and their positions. So NMEA might be right interface for
that...

...unless there are more chips like nokia n900 one that talk strange
protocols. Or should we just translate them at kernel level?

Anyway it would be good to have gps hardware abstraction one day.
       	  	   	   	    	     		     Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html