Hi Felipe and Jonathan.

Sorry but it's really hard for me to understand Jonathan's email and iio 
driver. [ I'm not the native speaker of English :) ]
Before asking Jonathan a few questions about his comments and iio, I 
want to reply this mail first.

Felipe Balbi wrote:

On Mon, May 18, 2009 at 09:45:55AM +0200, ext Kim Kyuwon wrote:

quoted

Hi All,

It's very nice of Felipe to make an issue of accelerometers in Linux
kernel again.
Before further discussions, we'd better see previous threads about
accelerometer.

http://lkml.org/lkml/2008/5/20/135
http://lkml.org/lkml/2008/12/1/156
--

I have considered how I can add my accelerometer driver into the Linux
kernel nicely for a few months.

As Trilok said, there are many accelerometer drivers under
drivers/hwmon. So I first tried to add my driver as hwmon, but Jean
Delvare didn't agree this idea. Please refer to the following URL:
http://lists.lm-sensors.org/pipermail/lm-sensors/2009-April/025686.html

And from the next URL, Dmitry don't think it is great idea to add
accelerometer as Input system.
http://lkml.org/lkml/2008/5/27/283

Good links, I'll read them all :-)

Thanks

quoted

On Sat, May 16, 2009 at 5:02 AM, Felipe Balbi [off-list ref] wrote:

quoted

Hi all,


On Fri, May 15, 2009 at 09:30:41PM +0200, ext Mohamed Ikbel Boulabiar wrote:

quoted

I am really interested about that.

But I want to know more about the device, its type, name, ...
The device isn't HID (Human Interface Device) ? If so, we should
rethink adding such thing but modify/use hid-input instead.

Because, I have an accelerometer phidget device and it is HID.
Handling should be the same.

Yeah, let's try to define the best way to expose accelerometers with
linux kernel and avoid a sysfs hell. Better sooner than later.

Felipe,
Can I ask why did you say "avoid a sysfs hell"?. I have thought Kernel
developers prefer sysfs to IOCTL lately.

For sure sysfs is prefered, but I meant that without a proper
abstraction or definition of how to export the device, each device
driver write will export sysfs nodes as they want and that's really bad
since we create the 'userland interface'. If it's messed up from the
beginning, it's gonna be like that for ages.

Agreed. Thank you for your explanation.

quoted

quoted

quoted

On Fri, May 15, 2009 at 7:06 PM, Trilok Soni [off-list ref] wrote:

quoted

Hi Felipe,

Adding linux-input and Jonathan, so not deleting any lines from this e-mail.

On Fri, May 15, 2009 at 6:46 PM, Felipe Balbi [off-list ref] wrote:

quoted

Hi all,

the following patch is just an idea to see how the community feels about
it. Considering accelerometer devices, you might have different use
cases for it while running different applications. You could be using it
for screen rotation in one case but when opening a game, you could use
it as a game controller by turning the device side-by-side.

There was one proposal from Jonathan called Industrial IO patchset
which tried to address these sensor devices. Please grep in your
linux-kernel archieve. I believe there are accelerometer drivers under
drivers/hwmon.

The problem is that it doesn't really seem to me that all accelerometers
will be doing hw monitoring. The ones used in laptops, for sure, trying
to prevent the hd from drying during a fall. But imagine the
accelerometers used in, say, wii-mote, or cellphones, or such stuff ?

Say we wanna use the accelerometer for both screen rotation and gaming,
that device isn't doing hw monitoring and still we _do_ want to set
different thresholds and irq requests/types for different use cases,
right ?

Yes, I agree that accelerometer needs new interface. However setting
parameters of accelerometer is very different from devices and device
specific. Until now, I met two accelerometer, SMB380 from
bosch-sensortec and KXSD9 from Kionix. As far as I know, these two
accelerometers are quite different from each other and existing
accelerometer drivers located /driver/hwmon/ in current Linux kernel.
Thus I think sysfs interface (including hwmon-sysfs) is the best
solution for setting various parameters of accelerometer..

what if you wanna use the accelerometer as joystick for gaming ? Imagine
a portable device...

So I said that accelerometer driver can use input_register_device, 
input_register_polled_device functions.

quoted

On the other hand, accelerometers are mostly used as Input device in
these days. Most APIs(input_allocate_device,
input_allocate_polled_device, ...) and macros(ABS_X,  ABS_Y, ...)of
Input subsystem are useful to accelerometer too. If we create another
APIs and Macros for accelerometers, I think It's another duplicate
work and result.

for sure

quoted

It seems like Dmitry concerns input_dev becomes too big with hundreds
of sensors.(right?) However, Market trend makes us consider
accelerometer as an input device now. I'm sure there is a good way to
add accelerometer input system without enlarging input_dev much.

In conclusion,
We need the inheritance concept in the object-oriented programming.
Accelerometer device sometimes can be hwmon device, sometimes input
device. So let accelerometer drivers use both APIs of hwmon and input
subsystems(hwmon_device_register, input_register_device,
input_register_polled_device). Acutally this is what many
accelerometer drivers in current Linux kernel are doing, so we don't
have to do much.

Let's
1) Introduce a new maintainer of accelerometer (Felipe?).
2) Move accelerometer drivers in current Linux kernel to /driver/accelerometer.
3) If we find the common functions of accelerometer or have idea about
new API or Macro, let's make at driver/accelerometer/acccelerometer.c,
input/linux/acccelerometer.h file or modify input.h little.
4) Add every new accelerometer into /driver/accelerometer.

How about extending these to several kinds of sensors ?? Why not having
a sensor framework that abstracts the creating of the input_dev for
accelerometer ? 

Good point. We should consider the extensibility. I agree a sensor 
framework that abstracts input_dev. However we should discuss with Jean 
Delvare about the boundary between lm-sensors and input(?)-sensors

* However we should first confirm and review that Jonathan's iio can be 
the solution for input(?)-sensors *

 > But then comes another question: what to do with

magnetometers, gyroscopes, etc etc ??

If we make a extensible sensor driver, I think we can add these new etc 
sensors in the future. step by step.

Regards,
Kyuwon