Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1764752AbXJQP5a (ORCPT ); Wed, 17 Oct 2007 11:57:30 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757561AbXJQP5V (ORCPT ); Wed, 17 Oct 2007 11:57:21 -0400 Received: from wr-out-0506.google.com ([64.233.184.229]:25362 "EHLO wr-out-0506.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756124AbXJQP5U (ORCPT ); Wed, 17 Oct 2007 11:57:20 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ZKEEtG3OFWs6E2556Y/w4Eh4EaeA8d9XTyAvRdfrUy5VyOVwRTpXLgnTSs2/nfanmOKCVUlg74CI65RIjIn/5rO6z44KeGMjtd+mfRTQBmTYiM1dDaz63F2PntBykMhu504VqDFDiDta6d49h8y3lL5hrDAnF6BCkeWMbq4aCLw= Message-ID: Date: Wed, 17 Oct 2007 11:57:18 -0400 From: "Dmitry Torokhov" To: "Linus Torvalds" Subject: Re: [PATCH] Map volume and brightness events on thinkpads Cc: "Matthew Garrett" , "Henrique de Moraes Holschuh" , "Jeremy Katz" , linux-kernel@vger.kernel.org, davej@redhat.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1192481110-9299-1-git-send-email-katzj@redhat.com> <20071016141153.GA3237@khazad-dum.debian.net> <20071016142121.GA21431@srcf.ucam.org> <20071016143124.GB3237@khazad-dum.debian.net> <20071016144016.GA21749@srcf.ucam.org> <20071016165623.GA13643@khazad-dum.debian.net> <20071016184606.GB25181@srcf.ucam.org> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3032 Lines: 75 On 10/16/07, Linus Torvalds wrote: > > 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. That is a good argument. If there are no other users for this other transport then I agree, inventing it just for keypress notifications is bad idea. > - 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". > This is a good argument for having 2 separate types of events but not for which transport shoudl be used to deliver it. > 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!) > Yes, on my old Inspiron brightness is completely handled by firmware. There is no ACPI, nor keyboard events generated whatsoever. OK, I guess I would like to hear once again from userspace guys - DBUS/HAL/etc. Do they see a need for a generic interface that can be used for all kinds of events, not only related to keypresses. If they say that they only care about notifications arising from keypresses then I will add EV_NOTIFY type of events to input layer. What events would we need? I can imagine: KEY_BRIGHTNESSUP_NOTIFY KEY_BRIGHTNESSDOWN_NOTIFY KEY_BRIGHTNESSMIN_NOTIFY KEY_BRIGHTNESSMAX_NOTIFY KEY_VOLUMEUP_NOTIFY KEY_VOLUMEDOWN_NOTIFY KEY_MUTE_NOTIFY KEY_DISPLAYSWITCH_NOTIFY KEY_WIFI_NOTIFY What else? And it better have "key" in its name, BATTERY_OUT_NOTIFY won't fly ;) -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/