linux-kernel - Re: [PATCH] Map volume and brightness events on thinkpads

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 for Android: free password hash cracker in your pocket

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

Date:	Tue, 16 Oct 2007 18:02:07 -0200
From:	Henrique de Moraes Holschuh <hmh@....eng.br>
To:	Matthew Garrett <mjg59@...f.ucam.org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Jeremy Katz <katzj@...hat.com>, linux-kernel@...r.kernel.org,
	davej@...hat.com, Dmitry Torokhov <dmitry.torokhov@...il.com>
Subject: Re: [PATCH] Map volume and brightness events on thinkpads

On Tue, 16 Oct 2007, Matthew Garrett wrote:
> On Tue, Oct 16, 2007 at 12:14:32PM -0700, Linus Torvalds wrote:
> > IOW, I think the thinkpad issue (and others like it) should be fixed by 
> > splitting up the KEY_VOLUMEUP "key" into separate KEY_VOLUMEUP and 
> > KEY_VOLUMEUP_NOTIFY key events, so that downstream user mode (and the 
> > kernel itself, for that matter) can know whether it's a informational 
> > message or whether it should be acted upon.
> 
> In principle I agree, but userspace already handles it. While it's 
> certainly more correct, I'm not sure it provides any other real 
> advantage.

Let's put it in another way:

I'd go with Linus suggestion, as it is not icky (although it is a lot more
limited in scope than adding a flag to EV_* that could be use for any event,
etc).

I am not going with the current icky hackery that makes every consumer of
EV_* need to know when they are real events, or "notification" events using
outside information.  It is not "userspace already handles it", even.  it is
"HAL already handles it", BTW.

And unless Dmitry agrees with Linus' suggestion (maybe as a temporary
stopgap while something better gets written?), we are not going anywhere,
anyway.  

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
-
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/