Message-id: <4A121C54.2040205@samsung.com>
Date:	Tue, 19 May 2009 11:41:24 +0900
From:	Kim Kyuwon <q1.kim@...sung.com>
To:	felipe.balbi@...ia.com
Cc:	ext Kim Kyuwon <chammoru@...il.com>,
	ext Mohamed Ikbel Boulabiar <boulabiar@...il.com>,
	Trilok Soni <soni.trilok@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	"linux-input@...r.kernel.org" <linux-input@...r.kernel.org>,
	Jonathan Cameron <jic23@....ac.uk>,
	Kyungmin Park <kyungmin.park@...sung.com>,
	Jean Delvare <khali@...ux-fr.org>
Subject: Re: [RFC] Add Input IOCTL for accelerometer devices

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:
>> 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
> 
>> On Sat, May 16, 2009 at 5:02 AM, Felipe Balbi <felipe.balbi@...ia.com> wrote:
>>> Hi all,
>>>
>>>
>>> On Fri, May 15, 2009 at 09:30:41PM +0200, ext Mohamed Ikbel Boulabiar wrote:
>>>> 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.

>>>> On Fri, May 15, 2009 at 7:06 PM, Trilok Soni <soni.trilok@...il.com> wrote:
>>>>> 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 <felipe.balbi@...ia.com> wrote:
>>>>>> 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.

>> 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
> 
>> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists