On Tue, 16 Oct 2007, Dmitry Torokhov wrote: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 -
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Linus Torvalds | Re: init's children list is long and slows reaping children. |
| Kohei KaiGai | [PATCH 0/3] exporting capability name/code pairs (final#2) |
git: | |
| Gerrit Renker | [PATCH 33/37] dccp: Initialisation framework for feature negotiation |
| Jarek Poplawski | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Arjan van de Ven | Re: [GIT]: Networking |
| Mark Ryden | Re: Linux Wireless Mini-Summit -- Ottawa -- July 22, 2008 |
