linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Felipe Balbi <felipe.balbi@nokia.com>
To: ext Kim Kyuwon <chammoru@gmail.com>
Cc: "Balbi Felipe (Nokia-D/Helsinki)" <felipe.balbi@nokia.com>,
	ext Mohamed Ikbel Boulabiar <boulabiar@gmail.com>,
	Trilok Soni <soni.trilok@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	"linux-input@vger.kernel.org" <linux-input@vger.kernel.org>,
	Jonathan Cameron <jic23@cam.ac.uk>,
	Kim Kyuwon <q1.kim@samsung.com>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	Jean Delvare <khali@linux-fr.org>
Subject: Re: [RFC] Add Input IOCTL for accelerometer devices
Date: Mon, 18 May 2009 12:12:36 +0300	[thread overview]
Message-ID: <20090518091236.GH4443@nokia.com> (raw)
In-Reply-To: <4d34a0a70905180045u6619773dt1563fe38b13d46fb@mail.gmail.com>

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@nokia.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.

> >> On Fri, May 15, 2009 at 7:06 PM, Trilok Soni <soni.trilok@gmail.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@nokia.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...

> 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 ? But then comes another question: what to do with
magnetometers, gyroscopes, etc etc ??

-- 
balbi

  reply	other threads:[~2009-05-18  9:24 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20090515131636.GE4443@nokia.com>
2009-05-15 18:06 ` [RFC] Add Input IOCTL for accelerometer devices Trilok Soni
2009-05-15 19:30   ` Mohamed Ikbel Boulabiar
2009-05-15 20:02     ` Felipe Balbi
2009-05-16  4:19       ` Mohamed Ikbel Boulabiar
2009-05-16 12:50         ` Felipe Balbi
2009-05-18  7:45       ` Kim Kyuwon
2009-05-18  9:12         ` Felipe Balbi [this message]
2009-05-18 10:11           ` Jonathan Cameron
2009-05-18 10:31             ` Felipe Balbi
2009-05-18 11:37               ` Jonathan Cameron
2009-05-19  6:32             ` Kim Kyuwon
2009-05-21 11:42               ` Jonathan Cameron
2009-05-22  8:21                 ` Kim Kyuwon
2009-05-22 13:35                   ` Jonathan Cameron
2009-05-25  8:15                     ` Kim Kyuwon
2009-05-25  8:52                       ` Mohamed Ikbel Boulabiar
2009-05-25 11:07                       ` Jonathan Cameron
2009-05-19  2:41           ` Kim Kyuwon
2009-05-19 10:42             ` Felipe Balbi
2009-05-19 12:34               ` Mohamed Ikbel Boulabiar
2009-05-21 10:21                 ` Jonathan Cameron

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090518091236.GH4443@nokia.com \
    --to=felipe.balbi@nokia.com \
    --cc=boulabiar@gmail.com \
    --cc=chammoru@gmail.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=jic23@cam.ac.uk \
    --cc=khali@linux-fr.org \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=q1.kim@samsung.com \
    --cc=soni.trilok@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).