[lkml]   [2010]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [GIT PULL] Ambient Light Sensors subsystem
On Sun, Mar 7, 2010 at 4:42 PM, Dmitry Torokhov
<> wrote:
> On Wed, Mar 03, 2010 at 01:51:07PM -0800, Linus Torvalds wrote:
>> On Wed, 3 Mar 2010, Dima Zavin wrote:
>> >
>> > Actually, accelerometers fit into that model fine. They have some
>> > variable number of absolute axes (3, 6, etc.).
>> In fact, they obviouslya also do end up being used exactly like joysticks
>> in real life, and joysticks are commonly starting to have accelerometers
>> in them (ie any modern game console controller).
>> So treating an accelerometer like a joystick - regardless of whether it
>> happens to be internal to the device or happens to be external in a
>> separate controller - is not all that far-fetched anyway.
> But the point is that not every accelerometer is a joystick. We have
> hdaps and friends that have accelerometers inside but that is not their
> main purpose (they do export a secondary joystick-like interface and
> that is fine), and I am pretty sure that there are other users of
> accelerometers in various systems.
> I am pretty sure that once we settle on the proper interface for such
> sensors we should be able to write a bridge to input layer so they can
> be easily used as [human] input devices in cases whether it is desired.

Sorry for the late reply, but this is a recurring theme. Remote
controls (IR and radio) have the same problem and this was the core of
my objection to their drivers being merged. Input devices need to
communicate their human oriented events to user space using the input
subsystem period. If you don't do this things like the xserver/apps
have to implement custom drivers for every new user event interface
that is dreamed up and that destroys backwards compatibility.

Drivers can always be split into two modules. A core module could
provide a sysfs or kernel internal interface. An add-on module can
optionally redirect events from the core module into the input

I'm also not a fan of having a custom interface on the sensor/input
devices that reports device specific events to user space. Then those
events are massaged by a tiny user space app and reinjected into the
input subsystem. That does work but it leads to the kernel requiring
external apps in order to function. I believe converting device
specific events to a common device protocol is the work of the device

Jon Smirl

 \ /
  Last update: 2010-03-18 15:37    [W:0.085 / U:1.572 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site