Hi!
So a voltmeter really makes no sense. It's not a set of keys and it
doesn't give X/Y/Z style readings. Nor does a camera. But a lot of things
do fit this to varying degrees.
I'm actually more dubious than Linus about ALS - because ALS tends not
produce 'events' but to be sampled,
On 09/24/10 14:02, Pavel Machek wrote:
Hi!
So a voltmeter really makes no sense. It's not a set of keys and it
doesn't give X/Y/Z style readings. Nor does a camera. But a lot of things
do fit this to varying degrees.
I'm actually more dubious than Linus about ALS - because ALS tends not
Hi!
(or GPS device, for that matter) really be?
But why GPS should be input device? It has nothing to do with user
input.
What? OF COURSE it is an input driver. It's the user moving the device
around. It's EXACTLY the same thing as an accelerometer in that
respect. Sure, it's
Subject: Re: [RFC] [PATCH V2 1/2] input: CMA3000 Accelerometer driver
Hi Hemanth,
On Fri, May 21, 2010 at 12:22:57PM +0530, Hemanth V wrote:
From: Hemanth V heman...@ti.com
Date: Thu, 20 May 2010 20:18:17 +0530
Subject: [PATCH] input: CMA3000 Accelerometer Driver
This patch adds support
Hi Hemanth,
On Fri, Sep 03, 2010 at 04:02:11PM +0530, Hemanth V wrote:
Do not like repeated release of resources in main and error path... Can
we do it like:
...
disable_irq();
error = cma3000_set(data, CMA3000_CTRL, ctrl, ctrl);
if (!error) {
/* Settling time delay required after
1. Input transport via evdev is very convenient
2. There is no other standard alternative
Once there is standard interface for such sensors they will happily use
it and will not look back.
I think the fact that most of the interest in IIO is how do we make an
IIO/Input bridge speaks
IIO which is currently in staging.
Except we had ALS before that as a layer and Linus vetoed it. So there is
zero faith in IIO ever going anywhere.
Instead we now have about ten different light sensor APIs to the point
developers are writing a toolkit userspace plugin for *each* sensor.
--
To
My hope is that we can make use of a well known and uniform
API for all input devices in a device, be it a keypad,
touchscreen, accelerometer, magnetometer, gyro, or whatever.
If only we could agree what input devices are...
Is that the right test for some of these devices.
Surely
On 08/31/10 10:44, Alan Cox wrote:
1. Input transport via evdev is very convenient
2. There is no other standard alternative
Once there is standard interface for such sensors they will happily use
it and will not look back.
I think the fact that most of the interest in IIO is how do we
On 08/31/10 10:46, Alan Cox wrote:
IIO which is currently in staging.
Except we had ALS before that as a layer and Linus vetoed it. So there is
zero faith in IIO ever going anywhere.
I have more faith - those developing it have limited time, but we will get
there. (another plug for anyone
On Tue, Aug 31, 2010 at 10:44:46AM +0100, Alan Cox wrote:
1. Input transport via evdev is very convenient
2. There is no other standard alternative
Once there is standard interface for such sensors they will happily use
it and will not look back.
I think the fact that most of the
If non-input uses later need non-input interfaces they can switch to that
with an input bridge when there is one and when it happens, which
probably won't.
Would there even be an argument which subsystem to use if IIO-input
bridge existed today? Because if the answer is no then push into
On Tue, Aug 31, 2010 at 05:59:37PM +0100, Alan Cox wrote:
If non-input uses later need non-input interfaces they can switch to that
with an input bridge when there is one and when it happens, which
probably won't.
Would there even be an argument which subsystem to use if IIO-input
IMHO I think sensors no more can be considered as non-input-devices.
Things changed too much in recent years. Input sources have now a
very different use as before (smartphones, Tablets and handheld
devices...)
They all have much inputs that come mostly from sensors.
So the definition of an input
linux-iio cc'd for comments on the code dump at end of email..
On 08/31/10 17:59, Alan Cox wrote:
If non-input uses later need non-input interfaces they can switch to that
with an input bridge when there is one and when it happens, which
probably won't.
Would there even be an argument which
On 08/31/10 18:24, Mohamed Ikbel Boulabiar wrote:
IMHO I think sensors no more can be considered as non-input-devices.
Things changed too much in recent years. Input sources have now a
very different use as before (smartphones, Tablets and handheld
devices...)
They all have much inputs that
On Mon, 30 Aug 2010, Linus Torvalds wrote:
On Monday, August 30, 2010, Dmitry Torokhov dmitry.torok...@gmail.com wrote:
But do you believe that input should be the primary residence for the
devices when they are only _sometimes_ used as input devices? Or it
would make sense to employ a
snip
Anyhow, here is a code dump of a very nasty proof of concept for an IIO
to input bridge in userspace. If I'd known it would be this easy I'd
have done this ages ago. I'm away for next couple of days, so a more
general version won't occur until next week unless someone else picks it
OK, so let's say we start moving some of the devices into input. Which
ones we consider suitable for input? I guess some 3-digit
accelerometers, what else? Also, what new event types would we need?
Let's take GPS - I do not think that ABS_X and ABS_Y are the best events
to be used for such
Hi Dmitry,
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,
Hi Felipe,
On Mon, Aug 30, 2010 at 11:04:39AM -0500, Felipe Balbi wrote:
Hi Dmitry,
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
Hi,
On Mon, 30 Aug 2010 09:28:56 -0700, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
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
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
dmitry.torok...@gmail.com wrote:
When we tried to push N900's accelerometer driver as an
input device you commented you didn't want sensors such
as accelerometers,
On 08/30/10 18:10, Felipe Balbi wrote:
Hi,
On Mon, 30 Aug 2010 09:28:56 -0700, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
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
Hi,
On Mon, 30 Aug 2010 10:21:44 -0700, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
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
On Mon, 30 Aug 2010 11:04:39 -0500
Felipe Balbi m...@felipebalbi.com wrote:
Hi Dmitry,
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
On Mon, Aug 30, 2010 at 09:40:25PM +0100, Alan Cox wrote:
On Mon, 30 Aug 2010 11:04:39 -0500
Felipe Balbi m...@felipebalbi.com wrote:
Hi Dmitry,
When we tried to push N900's accelerometer driver as an
input device you commented you didn't want sensors such
as accelerometers,
On Mon, Aug 30, 2010 at 01:52:18PM -0500, Felipe Balbi wrote:
Hi,
On Mon, 30 Aug 2010 10:21:44 -0700, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
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
On Monday, August 30, 2010, Dmitry Torokhov dmitry.torok...@gmail.com wrote:
But do you believe that input should be the primary residence for the
devices when they are only _sometimes_ used as input devices? Or it
would make sense to employ a converter from XXX to input (either purely
On Mon, Aug 30, 2010 at 02:28:37PM -0700, Linus Torvalds wrote:
On Monday, August 30, 2010, Dmitry Torokhov dmitry.torok...@gmail.com wrote:
But do you believe that input should be the primary residence for the
devices when they are only _sometimes_ used as input devices? Or it
would make
On Monday, August 30, 2010, Dmitry Torokhov dmitry.torok...@gmail.com wrote:
That is why I started taking accelerometers in. But I am concerned that
taking accelerometers (which indeed are most often input devices) will
lead people to try and use the same for temperature, ALS and other
On Mon, Aug 30, 2010 at 03:05:32PM -0700, Linus Torvalds wrote:
On Monday, August 30, 2010, Dmitry Torokhov dmitry.torok...@gmail.com wrote:
That is why I started taking accelerometers in. But I am concerned that
taking accelerometers (which indeed are most often input devices) will
lead
Hi,
On Mon, 30 Aug 2010 15:43:52 -0700, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
On Mon, Aug 30, 2010 at 03:05:32PM -0700, Linus Torvalds wrote:
On Monday, August 30, 2010, Dmitry Torokhov dmitry.torok...@gmail.com
wrote:
That is why I started taking accelerometers in. But I am
On Fri, Aug 13, 2010 at 08:34:07AM -0500, Murphy, Dan wrote:
Hemanth
I have a few comments on this patch.
+static ssize_t cma3000_store_attr_mdfftmr(struct device *dev,
+ struct device_attribute *attr,
+ const char
Hi Hemanth,
On Fri, May 21, 2010 at 12:22:57PM +0530, Hemanth V wrote:
From: Hemanth V heman...@ti.com
Date: Thu, 20 May 2010 20:18:17 +0530
Subject: [PATCH] input: CMA3000 Accelerometer Driver
This patch adds support for CMA3000 Tri-axis accelerometer, which
supports Motion detect,
From: Murphy, Dan dmur...@ti.com
Hemanth
I have a few comments on this patch.
+static ssize_t cma3000_store_attr_mdfftmr(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+
] On Behalf Of V, Hemanth
Sent: Friday, August 13, 2010 7:47 AM
To: Jonathan Cameron; Andrew Morton
Cc: linux-in...@vger.kernel.org; linux-ker...@vger.kernel.org;
linux-omap@vger.kernel.org
Subject: Re: [RFC] [PATCH V2 1/2] input: CMA3000 Accelerometer driver
- Original Message -
From: Jonathan
From: Hemanth V heman...@ti.com
Date: Thu, 20 May 2010 20:18:17 +0530
Subject: [PATCH] input: CMA3000 Accelerometer Driver
This patch adds support for CMA3000 Tri-axis accelerometer, which
supports Motion detect, Measurement and Free fall modes.
CMA3000 supports both I2C/SPI bus for
- Original Message -
From: Jonathan Cameron ji...@cam.ac.uk
To: Hemanth V heman...@ti.com
Cc: linux-in...@vger.kernel.org; linux-ker...@vger.kernel.org;
linux-omap@vger.kernel.org
Sent: Friday, May 21, 2010 5:27 PM
Subject: Re: [RFC] [PATCH V2 1/2] input: CMA3000 Accelerometer driver
39 matches
Mail list logo
