[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100307204933.GC17727@core.coreip.homeip.net>
Date: Sun, 7 Mar 2010 12:49:34 -0800
From: Dmitry Torokhov <dmitry.torokhov@...il.com>
To: Dima Zavin <dmitriyz@...gle.com>
Cc: Jean Delvare <khali@...ux-fr.org>,
Jonathan Cameron <kernel@...23.retrosnub.co.uk>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Jonathan Cameron <jic23@....ac.uk>,
LKML <linux-kernel@...r.kernel.org>,
Zhang Rui <rui.zhang@...el.com>,
Amit Kucheria <amit.kucheria@...durent.com>
Subject: Re: [GIT PULL] Ambient Light Sensors subsystem
On Wed, Mar 03, 2010 at 03:08:29PM -0800, Dima Zavin wrote:
>
> As it came up earlier in the thread, adding an ABS_AMBIENT_LIGHT_LEVEL
> or equivalent is much simpler and provides a clean, concise, and
> useful interface to userspace.
>
> Note that for many applications, you actually get configurable
> threshold levels, and the hardware triggers an interrupt when the
> light level crosses those thresholds. This makes using an input device
> very useful, and that is in fact how we use ALS devices today. I have
> several pieces of hardware that do this, and I don't see how this new
> als subsystem helps me handle that problem. With the suggested API,
> I'll have to poll the sysfs files manually to see if they've changed
> (which is suboptimal), or still add a non-standard input device to do
> what I want.
>
OK, so from what you are saying it looks you just like the _interface_,
or transport, that input subsystem provides, not the fact that you
considering the device to be a HID-type device. If this is the case then
this indicates that we need to take another look at the proposed
interface and make sure that it allows proper poll() support.
--
Dmitry
--
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