Re: ACPI: thinkpad-acpi: react to Lenovo ThinkPad differences in hot key

[Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org>]

Hi Matthew!

On Sun, 15 Jul 2007, Matthew Garrett wrote:

> On Sun, Jul 15, 2007 at 02:59:22PM -0300, Henrique de Moraes Holschuh wrote:
> > On Sat, 14 Jul 2007, Matthew Garrett wrote:
> > 
> > > On Sat, Jul 14, 2007 at 11:12:09AM -0300, Henrique de Moraes Holschuh wrote:
> > > 
> > > Ah, I see this one fixes some of my comments. However:
> > > 
> > > > +		KEY_RESERVED,	/* 0x0F: FN+HOME (brightness up) */
> > > > +		/* Scan codes 0x10 to 0x1F: Extended ACPI HKEY hot keys */
> > > > +		KEY_RESERVED,	/* 0x10: FN+END (brightness down) */
> > > 
> > > > +		KEY_BRIGHTNESSUP,	/* 0x0F: FN+HOME (brightness up) */
> > > > +		/* Scan codes 0x10 to 0x1F: Extended ACPI HKEY hot keys */
> > > > +		KEY_BRIGHTNESSDOWN,	/* 0x10: FN+END (brightness down) */
> > > 
> > > Why this difference?
> > 
> > Brightness events are handled in firmware (and no, you cannot make the
> > firmware NOT handle it) in IBM thinkpads.  Lenovo thinkpads seem to be
> > moving it to userspace, so you have to generate the events and actively
> > handle them in the ACPI OSI or in userspace.
> 
> I believe that this is dependent on the BIOS version, not whether the 
> distinction is Lenovo/IBM.

Let's just say that IBM kept a certain behaviour consistent for all BIOS
versions, and Lenovo is not following that behaviour.

It might be considered a BIOS version thing, where all IBM-release BIOSES
behave in one way, and most Lenovo ones behave in another way.

But unless someone will start tracking the required information for me in
thinkwiki or somesuch, I will only support the latest versions of a ThinkPad
BIOS as a rule.  IBM and Lenovo BIOS updates fix a damn big lot of problems
quite often.  It is not a good idea to use outdated ones, especially the EC
firmware, anyway.

> > Regardless, userspace *will* have to take some action to enable the hotkeys
> > that are to only be used for passive monitoring.  Right now this means
> > enabling them in the mask, and remapping the key map.  If this is that a big
> > problem, I can add extra driver filtering, and make it only "enable it in
> > the mask".
> 
> HAL already has a flag indicating whether applications should respond to 
> brightness keys actively or passively. Life would be significantly 
> easier if they're mapped by default, since the alternative is that 
> everyone will just map them anyway.

Life would be significantly easier if I could convey that information in the
kernel.  Since I cannot, I effectively consider these keys to be "defective"
as far as the regular input device events are supposed to mean, and I don't
generate events for them.

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

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/