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, 16 Oct 2007 13:32:21 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
cc:	Matthew Garrett <mjg59@...f.ucam.org>,
	Henrique de Moraes Holschuh <hmh@....eng.br>,
	Jeremy Katz <katzj@...hat.com>, linux-kernel@...r.kernel.org,
	davej@...hat.com
Subject: Re: [PATCH] Map volume and brightness events on thinkpads



On Tue, 16 Oct 2007, Dmitry Torokhov wrote:
> 
> I agree that these are 2 different events. My argument is that
> "VOLUME_UP_NOTIFY" event is similar to "BATTERY_OUT_NOTIFY",
> "DOCK_UNDOCK_NOTIFY", etc, etc and should be sent not through input
> layer but through a generic (yet to be designed) notification
> mechanism. Something lighter than input. Something like uevents over
> netlink.

Well, I'd argue that:

 - it's going to be the same entity that cares in both cases (ie anybody 
   who is ready to accept VOLUME_UP keypresses is also the exact same 
   party that also wants to know if VOLUME_UP happened *independently*)

   Ergo: making it a separate "generic" notification is actually totally 
   counterproductive, because it just adds complexity.

 - it really is a keypress. Yes, it's a keypress with side effects, but 
   it still tends to have a distinct source, and as such it is interesting 
   *as* a keypress. 

   IOW: it should have all the same "incidental" side effects as any other 
   keypress. Example: I think it's reasonable to consider it an event as 
   far as the screen saver is concerned. In other words, it's not *just* a 
   "volume was raised" event. It's a "volume was raised, and the user 
   actually pressed a key to do so".

So I do think they are keypresses, although I also suspect that like many 
other magical keys, the "NOTIFY" version is often also totally hidden by 
hardware/firmware interactions (ie I'm pretty sure that many of those 
special keys will never be visible at all to the OS, because the firmware 
hides the fact that they were pressed entirely!)

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