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 devices: I am trying to allow applications being
ignorant of what exact device they are talking to and rather concentrate
on device capabilities (list of events supported). GPS is sufficiently
different from a tablet/touchscreen; while some might want to use both
as inputs to a game most applications would want to know which one
which. 

Also, GPS, liek ALS, would probably be polling, no?

-- 
Dmitry
--

Hello Dmitry,

Current-generation accelerometers typically have some functions built-in that provide an interrupt signal under certain conditions.  For instance, orientation and motion detection can be calculated at the hardware level to reduce the need for constant polling and software to handle the algorithms.  Some devices have built-in tap detection, which can require data at several hundred samples per second, something that is certainly not efficiently supported in software.

I have been using ABS_MISC to pack 4 bytes of interrupt status information, but it might be a good idea to consider having a separate field for:
Orientation (screen rotation)
Motion Detection (or sleep detection)
Tap Detection

Regards,
Chris Hudson