[Gta04-owner] Linux 3.2-rc3 on GTA04

[Dr. H. Nikolaus Schaller]

Am 28.11.2011 um 01:32 schrieb NeilBrown:

> On Sat, 26 Nov 2011 13:16:06 +0100 Christoph Mair <christoph.mair at gmail.com>
> wrote:
> 
>> On Sat, Nov 26, 2011 at 12:43 PM, NeilBrown <neilb at suse.de> wrote:
>>>  I have just updated
>>>    git://neil.brown.name/gta04#merge
>>> 
>>>  to 3.2-rc3.
>>> 
>>>  Also in this release:
>>> 
>>>  - Fixed the charging problem - I think [1]
>>>  - We now charge the backup-battery.
>>>  - Brand new driver for the LEDs (tca6507] [2]
>>>  - Backlight control with PWM - untested [3]
>> 
>> Thank you for all the efforts! Cloning now...
>> 
>>> Future plans:
>>>  - I want to look at the accelerometers as the next project.  Part of this is
>>>   understanding the "iio" subsystem which seems to be the appropriate home.
>> Or the input subsystem. There is already a bma150 driver in
>> input/misc. The GTA04 uses the BMA180. They may behave similar..
> 
> Or maybe both.
> 
> The BMA150 does seem very similar to the BMA180.  It has a different set of
> bandwidths and sensitivities but the important details are much the same.
> 
> However that driver doesn't do what I think is needed of an input driver at
> all.
> 
> For me, the stream of x/y/z values (which is what that driver provides) is
> largely uninteresting.
> What I want to know is 
>  when does the acceleration in any given direction change by more than Xg for
>  at least Ysecs.
> This allows the app to know when there has been a significant change in
> orientation.
> Also
>  when was the device 'tapped' from any of the 6 directions.
> which effectively provides 6 more hardware 'buttons'.
> 
> 
> All of this is provided by the BMA1X0 hardware (and the lis302 hardware in
> the freerunner) but the driver doesn't provide easy access to it.
> 
> So I imagine a driver that provides both an 'input' interface and an 'iio'
> interface.
> The 'input' interface that provides EV_KEY events of BTN_X BTN_Y BTN_Z on taps
> and EV_ABS events of ABS_X ABS_Y ABS_Z whenever that has been a "sufficiently
> large" change.
> 
> The 'iio' interface would provide the steam of x/y/z data and allow the
> different trigger thresholds to be set.
> The 'iio' interface can provide events somewhat similar to input but I don't
> see the point of doing that when 'input' is already well-understood.
> Thought maybe when I try I'll find out why...

Maybe we should keep the x/y/z data stream in one driver and recognizing
(primitive) gestures (sudden changes) within this data streams in another one.

My first idea is to compare it to GPIOs. There is a GPIO driver which can map
gpios to user space so we can check their state. Or, there is a gpio_keys input
driver which maps a gpio to a keyboard event. Which ones is defined by the
board file.

So that would be sort of drivers/input/keyboard/accelerometer.c And some
platform data to configure it.

Nikolaus