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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20071016143124.GB3237@khazad-dum.debian.net>
Date:	Tue, 16 Oct 2007 12:31:24 -0200
From:	Henrique de Moraes Holschuh <hmh@....eng.br>
To:	Matthew Garrett <mjg59@...f.ucam.org>
Cc:	Jeremy Katz <katzj@...hat.com>, linux-kernel@...r.kernel.org,
	torvalds@...ux-foundation.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: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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/