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: <200710161940.05785.jesse.barnes@intel.com>
Date:	Tue, 16 Oct 2007 19:40:05 -0700
From:	Jesse Barnes <jesse.barnes@...el.com>
To:	Henrique de Moraes Holschuh <hmh@....eng.br>
Cc:	Jeremy Katz <katzj@...hat.com>, linux-kernel@...r.kernel.org,
	torvalds@...ux-foundation.org, davej@...hat.com
Subject: Re: [PATCH] Map volume and brightness events on thinkpads

On Tuesday, October 16, 2007 2:18 am Henrique de Moraes Holschuh wrote:
> On Tue, 16 Oct 2007, Jesse Barnes wrote:
> > On Tuesday, October 16, 2007 1:36 am Henrique de Moraes Holschuh 
wrote:
> > > You want ACPI video to just pass the messages to userspace when
> > > X.org is driving the backlight?  Fine with me.  That *still*
> > > doesn't make it right to get these messages as hot key presses
> > > over the input layer through the thinkpad-acpi driver.  So the
> > > NAK stands.  Any changes should be done to the ACPI video driver
> > > in this case.
> >
> > So is this really the direction that input is going?  Last time I
> > talked with Dmitry, he seemed ok with adding input events for ACPI
> > and other firmware hotkeys...
>
> Last time the issue was brought up (and I do believe it was because
> of thinkpad-acpi :-) ), he made it clear that any events you are to
> act upon are fine in input, but events that are just notifications
> (i.e. the firmware already did the action) are not.

Ah yeah, I agree with that.  Regular events should be uevents or 
something, not input events.  Actual keyboard keys though (whether they 
generate firmware event messages or actual scancodes) should probably 
go through the input layer.  I thought that's what Jeremy's patch was 
doing, maybe I didn't look closely enough.

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