All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Dima Zavin <dmitriyz@google.com>,
	Jonathan Cameron <jic23@cam.ac.uk>,
	LKML <linux-kernel@vger.kernel.org>,
	Zhang Rui <rui.zhang@intel.com>,
	Amit Kucheria <amit.kucheria@verdurent.com>,
	Jean Delvare <khali@linux-fr.org>
Subject: Re: [GIT PULL] Ambient Light Sensors subsystem
Date: Wed, 3 Mar 2010 10:52:43 -0800 (PST)	[thread overview]
Message-ID: <alpine.LFD.2.00.1003031045390.3599@localhost.localdomain> (raw)
In-Reply-To: <20100303184132.GA11471@core.coreip.homeip.net>



On Wed, 3 Mar 2010, Dmitry Torokhov wrote:

> On Wed, Mar 03, 2010 at 09:03:16AM -0800, Linus Torvalds wrote:
> > 
> > What's the difference between a physical "increase screen brightness" key, 
> > and a "ambient light sensor"? Absolutely none as far as I can tell.
> 
> Because in general ambient light sensor may have nothing to do with the
> screen brightness. The fact that all current uses are tied to
> controlling screen brightness is coincidential. You could use it as well
> to turn on the lights in the kitchen if it is getting too dark...

But my point is, it acts pretty much like a key on a keyboard 
_regardless_. 

Sure, you migth use it to turn up the lights too. But how is that 
different from having a switch to do the same? Again, it doesn't sound 
that different from a key to me. 

> Yes, it is easier, but it is not necessarily the right interface. I
> still believe in using input layer for human iteraction events, and not
> as generic transport a-la netlink or uevent. Voltage measurements,
> network cable presence notifications, ambient light/temperature sensors,
> and so forth do not belong here.

The thing is, if the choice is about a whole new subsystem just for some 
silly light sensor logic, I'd _much_ rather see the much simpler - and 
more useful - approach of just considering it an input event.

It happens in the same kind of situations, it has the same kinds of timing 
issues (ie we're not talking streaming megabytes of data), and it has the 
same kind of users (ie a lightsensor really would be used along with 
something that cares about input).

I agree that that's not true in many other situations. A cable insertion 
event is about the networking, not about some independent input. The kind 
of application that cares about network cable presense is _not_ the kind 
of app that would care about keyboard input. Same goes for voltage.

That said, I'm not married to the whole "it has to be input layer". But I 
_do_ think that it's crazy to start doing new subsystems for every little 
thing. That way lies madness. 

		Linus

  reply	other threads:[~2010-03-03 18:53 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-01 19:41 [GIT PULL] Ambient Light Sensors subsystem Jonathan Cameron
2010-03-03  6:13 ` Dima Zavin
2010-03-03  9:34   ` Jean Delvare
2010-03-03 10:29     ` Dima Zavin
2010-03-03 11:02       ` Jean Delvare
2010-03-03 11:10       ` Jonathan Cameron
2010-03-03 13:07       ` Linus Walleij
2010-03-03 10:30   ` Linus Walleij
2010-03-03 11:19     ` Jonathan Cameron
2010-03-03 17:03   ` Linus Torvalds
2010-03-03 17:51     ` Jonathan Cameron
2010-03-03 18:41     ` Dmitry Torokhov
2010-03-03 18:52       ` Linus Torvalds [this message]
2010-03-03 19:07         ` Dmitry Torokhov
2010-03-03 19:33           ` Jonathan Cameron
2010-03-03 20:08             ` Jonathan Cameron
2010-03-03 22:02             ` Jean Delvare
2010-03-03 23:08               ` Dima Zavin
2010-03-04  9:22                 ` Jean Delvare
2010-03-07 20:49                 ` Dmitry Torokhov
2010-03-08  6:29                   ` Dima Zavin
2010-03-05  7:38             ` Amit Kucheria
2010-03-05 10:58               ` Jonathan Cameron
2010-03-03 21:38           ` Dima Zavin
2010-03-03 21:51             ` Linus Torvalds
2010-03-04 11:19               ` Jonathan Cameron
2010-03-07 12:34                 ` Jean Delvare
2010-03-07 12:57                   ` J.I. Cameron
2010-03-08  9:58                 ` Dima Zavin
2010-03-08 10:24                   ` Jonathan Cameron
2010-03-07 20:42               ` Dmitry Torokhov
2010-03-08 10:00                 ` Jonathan Cameron
2010-03-18 14:34                 ` Jon Smirl
2010-03-03 21:56             ` Mike Chan
2010-03-03 22:05               ` Jean Delvare
2010-03-10 20:46           ` Pavel Machek
2010-03-22  0:13           ` Jan Engelhardt
2010-03-22  4:27             ` Dmitry Torokhov
2010-03-03 19:20         ` Jonathan Cameron
2010-03-03 19:29           ` Manu Abraham
2010-03-03 19:45             ` Jonathan Cameron
2010-03-03 20:08               ` Manu Abraham
2010-03-03 20:37                 ` Jonathan Cameron

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.2.00.1003031045390.3599@localhost.localdomain \
    --to=torvalds@linux-foundation.org \
    --cc=amit.kucheria@verdurent.com \
    --cc=dmitriyz@google.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=jic23@cam.ac.uk \
    --cc=khali@linux-fr.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rui.zhang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.