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]

Date:	Tue, 16 Oct 2007 01:49:54 -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 1:36 am Henrique de Moraes Holschuh wrote:
> > No, on Lenovo (and in general actually) the firmware should *not*
> > touch the backlight.  Otherwise if another driver touches it the
> > driver and
>
> This is not an option on IBM ThinkPads, unless you patch the DSDT on
> non-ancient ACPI-based models, and unless you patch the BIOS (and
> maybe even the EC control program) itself on the really ancient
> models.  It is that simple.
>

Yeah, unfortunately, "should not" doesn't mean "does not" in this case.  
In cases where we can't control the firmware, we have to use it to 
control the backlight exclusively, or we'll definitely get into 
trouble.

> 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...

> Good luck, and please interface it properly to the backlight class
> while at it.  There's no reason to make the waters mudier :-)

Yeah, the backlight class needs some changes:  the backlight dirs should 
somehow identify the display they control and only *one* backlight 
driver should be registered for a given display.  Unfortunately we 
don't have enough info in the kernel to identify displays, so those 
changes may have to wait until the DRM grows such knowledge.

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/