linux-kernel - Re: Sensors and the input layer (was Re: [RFC] [PATCH V2 1/2] input: CMA3000 Accelerometer driver)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 31 Aug 2010 14:18:47 -0400 (EDT)
From:	Daniel Barkalow <barkalow@...ervon.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
cc:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Felipe Balbi <me@...ipebalbi.com>, Hemanth V <hemanthv@...com>,
	"linux-input@...r.kernel.org" <linux-input@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
	"igor.stoppa@...ia.com" <igor.stoppa@...ia.com>,
	"kai.svahn@...ia.com" <kai.svahn@...ia.com>,
	"matthias.nyman@...ia.com" <matthias.nyman@...ia.com>
Subject: Re: Sensors and the input layer (was Re: [RFC] [PATCH V2 1/2] input:
 CMA3000 Accelerometer driver)

On Mon, 30 Aug 2010, Linus Torvalds wrote:

> On Monday, August 30, 2010, Dmitry Torokhov <dmitry.torokhov@...il.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
> > in-kernel or userspace over uinput)?
> 
> Umm... You've brought that up before as an objection, but what _is_
> that other model that you would convert from? IOW what *is* that XXX
> that you talk about?
> 
> So I think accelerometers etc should be seen as input devices for the
> simple reason that
> 
>  (a) They really *are* input devices in all the most common cases. If
> you have a phone with an accelerometer, it really is used as an input
> device quite like a joystick.

At least some of the time, an accelerometer is more like part of a 
joystick. You can have phones with accelerometers at both ends, where the 
input events produced depend on the combination of the readings, with each 
of the individual accelerometers being a device that is also available by 
itself. You can have phones which can be used in various orientations, 
where the logical "left" direction depends on the orientation. With a 
joystick, the device that the driver is for has the assignment of motions 
to inputs; for an accelerometer in a phone, the assignment is outside the 
scope of the chip, and it would make sense to have a second driver that 
takes non-chip-specific accelerometer output (per-accelerometer, per-axis) 
and maps it to input events based on how the user holds the box the chip 
is in.

It's like having a whole bunch of button devices; you want them to be 
exposed as a keyboard, and the sensor hardware reports press and release, 
but something else is needed to know which hardware button is which key. 
Similarly, you want to know about how the user is moving the device, and 
you may need to process various sorts of raw data to produce anything 
meaningful to applications.

	-Daniel
*This .sig left intentionally blank*
--
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/