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: <20071016165623.GA13643@khazad-dum.debian.net>
Date:	Tue, 16 Oct 2007 14:56:23 -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:31:24PM -0200, Henrique de Moraes Holschuh wrote:
> > On Tue, 16 Oct 2007, Matthew Garrett wrote:
> > > Yes, the firmware acts upon it.
> > 
> > So, I'd have to say it doesn't belong on the input layer AFAIK.

> They're keys that generate scancodes through the keyboard controller. 

The fact is that we were not used to anything using the keyboard controller
as a message-passing device, but nowadays that is (unfortunately) happening.

It still doesn't mean it belongs inside the stream of data for the keyboard,
maskerading as a key press.

> Not having them go through the input layer requires actively forcing 
> them into some other route, which seems excessive.

I don't think it is excessive at all, actually.  But I am known to take the
longer and harder road if I think the end result will be neater and more
organized.

> > > 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.
> 
> There's no advantage in having to implement multiple solutions. If we're 
> stuck with one of them, we might as well just use it for the other cases 
> as well.

IMO we might as well go to the clean road, deploy a generic interface that
CAN do it properly (might as well be input, but Dmitry has some good reasons
not to want it there), and move to it.

> > > 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.
> 
> No, these aren't ACPI keys and the machines don't provide backlight 
> control through ACPI. It's not a problem with more recent Dells, but 
> machines before mid-2006 or so have this issue.

Am I the only one seeing the irony on that comment over the idea of sending
such events through the input layer?  ACPI is not just a way to talk to AML
crap in the BIOS.  Is a (somewhat obtuse, very limited) generic interface to
model the hardware.  But for backlight, it certianly is powerful enough.

If you want an even more generic interface, I am fine with it too (just make
sure to move ACPI over to that interface as well).

-- 
  "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/