Thread (42 messages) 42 messages, 12 authors, 2010-09-24

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

From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date: 2010-08-30 17:21:51
Also in: linux-omap, lkml

On Mon, Aug 30, 2010 at 12:10:41PM -0500, Felipe Balbi wrote:
Hi,

On Mon, 30 Aug 2010 09:28:56 -0700, Dmitry Torokhov
[off-list ref] wrote:
quoted
quoted
When we tried to push N900's accelerometer driver as an
input device you commented you didn't want sensors such
as accelerometers, magnetometers, proximity, etc on the
input layer because "they are not user input", although
I didn't fully agree with you, we had to modify the drivers
and, I believe, one of them is sitting in staging under
the industrial i/o subsystem.

Are you now accepting sensor drivers on the input layer ?
that will make our life a lot easier but we need some
definition to avoid having to re-work drivers when we
want to push them to mainline.
I got persuaded that 3-axis accelerometers are most often indended to be
used as input devices so I decided I should take these in (adxl134x is
there). I still think that sensor devices in general are better suited
to IIO subsystem and I hope it will get out of staging soon.

Once it is out of staging we may think about creating a IIO-to-input
bridge (copuld be either in kernel or a userspace solution based on
uinput) to route sensors that are indeed used as HIDs.

Hope this makes sense.
It kinda does, but such sensors will be more and more used as
input devices, specially for gaming on mobile devices.

For example a proximity sensor might be used as the trigger
button on a first person shooting game; accelerometers will
be used to walk through the map and a magnetometer might be
used to look behind you and a gyroscope to turn around your
own axis.

In the end, the user is the one moving the device around and
generating such events, so why not avoiding yet another
subsystem if we will have to resort to solutions such as
iio-to-input bridge, which smells like a hackish solution
to get input events from sensors anyway.

I really hope I could convince you that, on mobile at least,
sensors will be mostly used as HID devices and will give
app developers new ways for them to allow users to interact
with their app.

Take a look at how a gyroscope is used on iphone, for
instance [1].

[1] http://www.youtube.com/watch?v=ORcu-c-qnjg
My response to this - are gyroscopes will _only_ be used to turn around
in a game? Are proximity sensor is _only_ usable as a trigger in FPS?
Won't we ever see such chips controlling technological processes?

I do hope that answerrs are no, no and yes.

-- 
Dmitry
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help