When updating this IBM ThinkPad T43p from 2.6.22 to 2.6.23-rc1
using make oldconfig, the text and default Y of
config THINKPAD_ACPI_INPUT_ENABLED
bool "Enable input layer support by default"
depends on THINKPAD_ACPI
default y
---help---
Enables hot key handling over the input layer by default. If unset,
the driver does not enable any hot key handling by default, and also
starts up with a mostly empty keymap.
If you are not sure, say Y here. Say N to retain the deprecated
behavior of ibm-acpi, and thinkpad-acpi for kernels up to 2.6.21.
made it sound like a good thing, so I configured it Y. But its only
effect seems to be to disable the key I use most, Fn+F4 to suspend to
RAM. It also disables Fn+F3 to blank the screen, though I don't use
that one; but does not disable the brightness and ThinkLight keys,
presumably because they just get mapped to KEY_RESERVED.
The same remains true with latest kernel git. Perhaps there's some
other config option without which this option is useless, which I
don't have set? My .config for latest git attached.
I get along fine now with THINKPAD_ACPI_INPUT_ENABLED disabled; but
suggest that its text is misleading, and default Y questionable.
Or perhaps there's a bug, and I can help try patches.
Thanks,
Hugh
Cc's added.
On Wed, 01 Aug 2007, Hugh Dickins wrote:
> When updating this IBM ThinkPad T43p from 2.6.22 to 2.6.23-rc1
> using make oldconfig, the text and default Y of
>
> config THINKPAD_ACPI_INPUT_ENABLED
> bool "Enable input layer support by default"
> depends on THINKPAD_ACPI
> default y
> ---help---
> Enables hot key handling over the input layer by default. If unset,
> the driver does not enable any hot key handling by default, and also
> starts up with a mostly empty keymap.
>
> If you are not sure, say Y here. Say N to retain the deprecated
> behavior of ibm-acpi, and thinkpad-acpi for kernels up to 2.6.21.
>
> made it sound like a good thing, so I configured it Y. But its only
> effect seems to be to disable the key I use most, Fn+F4 to suspend to
> RAM. It also disables Fn+F3 to blank the screen, though I don't use
> that one; but does not disable the brightness and ThinkLight keys,
> presumably because they just get mapped to KEY_RESERVED.
Actually, it doesn't disable the keys, but it routes them differently, so it
will work well only if you have very up-to-date HAL, etc.
Richard, Matthew, would the HAL crowd be unhappy if I switch that default?
Distros with new enough userland would be expected to compile the kernel
with THINKPAD_ACPI_INPUT_ENABLED, though.
> I get along fine now with THINKPAD_ACPI_INPUT_ENABLED disabled; but
> suggest that its text is misleading, and default Y questionable.
> Or perhaps there's a bug, and I can help try patches.
No bug in he code. The help text should clearly be improved, and the
default could be switched to N. I will send in a patch, after I get a few
comments.
--
"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
> Quoting Henrique de Moraes Holschuh <[email protected]>:
> Subject: Re: THINKPAD_ACPI_INPUT_ENABLED seems regressive
>
> Cc's added.
>
> On Wed, 01 Aug 2007, Hugh Dickins wrote:
> > When updating this IBM ThinkPad T43p from 2.6.22 to 2.6.23-rc1
> > using make oldconfig, the text and default Y of
> >
> > config THINKPAD_ACPI_INPUT_ENABLED
> > bool "Enable input layer support by default"
> > depends on THINKPAD_ACPI
> > default y
> > ---help---
> > Enables hot key handling over the input layer by default. If unset,
> > the driver does not enable any hot key handling by default, and also
> > starts up with a mostly empty keymap.
> >
> > If you are not sure, say Y here. Say N to retain the deprecated
> > behavior of ibm-acpi, and thinkpad-acpi for kernels up to 2.6.21.
> >
> > made it sound like a good thing, so I configured it Y. But its only
> > effect seems to be to disable the key I use most, Fn+F4 to suspend to
> > RAM. It also disables Fn+F3 to blank the screen, though I don't use
> > that one; but does not disable the brightness and ThinkLight keys,
> > presumably because they just get mapped to KEY_RESERVED.
>
> Actually, it doesn't disable the keys, but it routes them differently, so it
> will work well only if you have very up-to-date HAL, etc.
>
> Richard, Matthew, would the HAL crowd be unhappy if I switch that default?
>
> Distros with new enough userland would be expected to compile the kernel
> with THINKPAD_ACPI_INPUT_ENABLED, though.
>
> > I get along fine now with THINKPAD_ACPI_INPUT_ENABLED disabled; but
> > suggest that its text is misleading, and default Y questionable.
> > Or perhaps there's a bug, and I can help try patches.
>
> No bug in he code. The help text should clearly be improved, and the
> default could be switched to N. I will send in a patch, after I get a few
> comments.
Forcing the selection at compile-time isn't such a great idea IMHO.
Isn't there a way to support both old and new userspace?
--
MST
On Wed, 01 Aug 2007, Michael S. Tsirkin wrote:
> Forcing the selection at compile-time isn't such a great idea IMHO.
> Isn't there a way to support both old and new userspace?
It only afects the *defaults* of various driver knobs that can be freely
modified at runtime:
without THINKPAD_ACPI_INPUT_ENABLED:
hotkey_enable = 0
hotkey_mask unchanged from whatever is already set
hot keys from ibm-acpi 0.14 are mapped to KEY_UNKNOWN, and thus will
generate ACPI events if hotkey_enabled is set to 1.
with THINKPAD_ACPI_INPUT_ENABLED:
hotkey_enable = 1
hotkey_mask = hotkey_recommended_mask
most hot keys are mapped to something other than KEY_UNKNOWN, and
thus will not generate ACPI events but rather input layer events.
You should select whichever works better with your userspace.
--
"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
On Wed, 1 Aug 2007, Henrique de Moraes Holschuh wrote:
> On Wed, 01 Aug 2007, Michael S. Tsirkin wrote:
> > Forcing the selection at compile-time isn't such a great idea IMHO.
> > Isn't there a way to support both old and new userspace?
>
> It only afects the *defaults* of various driver knobs that can be freely
> modified at runtime:
>
> without THINKPAD_ACPI_INPUT_ENABLED:
> hotkey_enable = 0
> hotkey_mask unchanged from whatever is already set
>
> hot keys from ibm-acpi 0.14 are mapped to KEY_UNKNOWN, and thus will
> generate ACPI events if hotkey_enabled is set to 1.
>
> with THINKPAD_ACPI_INPUT_ENABLED:
> hotkey_enable = 1
> hotkey_mask = hotkey_recommended_mask
>
> most hot keys are mapped to something other than KEY_UNKNOWN, and
> thus will not generate ACPI events but rather input layer events.
>
> You should select whichever works better with your userspace.
That reminds me of something else odd that I noticed.
While I had CONFIG_THINKPAD_ACPI_INPUT_ENABLED=y and was trying
to get Fn+F4 to give me Suspend to RAM somehow, I did try setting
/sys/blah/blah/blah/hotkey_enable to 0.
That caused the Fn+F4 key to become active, except that it wanted
to do Hibernation to Disk instead: a window popped up to tell me
(IIRC) that my kernel command line didn't have a good resume=
Hugh
On Wed, 01 Aug 2007, Hugh Dickins wrote:
> While I had CONFIG_THINKPAD_ACPI_INPUT_ENABLED=y and was trying
> to get Fn+F4 to give me Suspend to RAM somehow, I did try setting
> /sys/blah/blah/blah/hotkey_enable to 0.
That immediately tells the firmware to process hot keys at it would see fit.
You could call it "enter DOS mode for hot keys" if you want.
In that mode, it can and will do some stuff by itself, and Fn+F4 may
generate a sleep button event, for example.
The firmware can also report the hot key anyway, in which case
ibm-acpi/thinkpad-acpi lets it through. I can probably filter off some, but
it would be unsafe to filter out the whole lot.
> That caused the Fn+F4 key to become active, except that it wanted
> to do Hibernation to Disk instead: a window popped up to tell me
> (IIRC) that my kernel command line didn't have a good resume=
Something in your user space reacted to the ACPI event the firmware
generates by default for FN+F4, and tried to do sleep-to-disk.
--
"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