Date: Tue, 16 Oct 2007 12:31:24 -0200
From: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
To: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Jeremy Katz <katzj@redhat.com>, linux-kernel@vger.kernel.org,
       torvalds@linux-foundation.org, davej@redhat.com,
       Dmitry Torokhov <dmitry.torokhov@gmail.com>
Subject: Re: [PATCH] Map volume and brightness events on thinkpads
Message-ID: <20071016143124.GB3237@khazad-dum.debian.net>
References: <1192481110-9299-1-git-send-email-katzj@redhat.com> <20071015210737.GA15293@khazad-dum.debian.net> <20071016130053.GA20010@srcf.ucam.org> <20071016141153.GA3237@khazad-dum.debian.net> <20071016142121.GA21431@srcf.ucam.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20071016142121.GA21431@srcf.ucam.org>
User-Agent: Mutt/1.5.16 (2007-06-11)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2393
Lines: 50

On Tue, 16 Oct 2007, Matthew Garrett wrote:
> On Tue, Oct 16, 2007 at 12:11:53PM -0200, Henrique de Moraes Holschuh wrote:
> > On Tue, 16 Oct 2007, Matthew Garrett wrote:
> > > are sent via the keyboard controller, such as the wireless and touchpad 
> > > disable keys on my HP. There are Dells that do the same for brightness 
> > 
> > It is not clear to me if they are notifications or not.  Does the firmware
> > act on the keys by itself? If it does, then they are notifications.  If it
> > does not, then they are regular hot keys and there is no controversy whether
> > they belong on the input layer or not (they do).
> 
> Yes, the firmware acts upon it.

So, I'd have to say it doesn't belong on the input layer AFAIK.

As I said, I am not against using the input layer for this, but currently
AFAIK it is not to be used for it.

> > 2. I am against sending notification events through input **that look
> > exactly the same as regular events**.  That is not a wise design choice IMO,
> > it is a very dirty hack.
> 
> Userspace is going to have to deal with this case anyway. Some vendors 
> simply don't let us distinguish.

But many do, and the less mud in the water, the better.

> > 3. We have a backlight class, a LED class, a rf-kill class and ALSA mixers.
> > Is there a real reason to pester Dmitry about the issue, if we can use these
> > alternate paths (that are indeed more generic and more suited for the job)?
> 
> It's not always going to be possible to tie notifications into a class 
> device - in the Dell case, for instance, interacting with the backlight 
> requires you to use a 200Kb library so has to be done in userspace.

Perhaps.  But for that Dell case, there is already a proper notification
system in place as well: ACPI backlight events.  You might have to get
userspace to tell the ACPI video driver that it will handle the events
(something X.org already needs, anyway), but that's about it.

-- 
  "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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/