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:	Mon, 30 Aug 2010 14:43:56 -0700
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	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, Aug 30, 2010 at 02:28:37PM -0700, 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?
> 

IIO which is currently in staging.

> 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.
> 
> The fact that there are specialized and rare cases where people may
> have some fancier accelerometer that isn't necessarily seen that way,
> and where it is used for some fancy scientific experiment or whatever
> doesn't change this in *any* way. The common case that almost
> everybody cares about - and that is getting more common - is the
> simple and obvious input case.
> 
> How is a Wii accelerometer in any way different from a joystick? How
> is a phone accelerometer any different from one? The answer is clear:
> they aren't different! So it makes 100% sense to expose them under the
> same subsystem.
> 
> (b) You cannot even name your XXX thing. It clearly makes sense (at

I can - see above.

> least within Tue context of a driver for some embedded phone chip) to
> see it as an input device. And nothing else comes to mind. You'd have
> to expose it as some random character device and then everybody would
> just have to make it emulate an input device in user space anyway.
> What's the point of that?
> 
> None. That's what the point is.
> 
> So I really don't understand why you're fighting the input device
> angle. It makes sense as an input device. It does NOT make sense as
> anything else.
> 
> Really - what else could a phone accelerometer

That is why I started taking accelerometers in. But I am concerned that
taking accelerometers (which indeed are most often input devices) will
lead people to try and use the same for temperature, ALS and other
sensors that are more often used in industrial process controls.

> (or GPS device, for that matter) really be?

But why GPS should be input device? It has nothing to do with user
input.

> It very much is about user input - even if it
> isn't a keyboard.

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ