On Sun, Mar 7, 2010 at 4:42 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
quoted text
> 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
subsystem.

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
driver.

-- 
Jon Smirl
jonsmirl@gmail.com
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/