headers
Henrique de Moraes Holschuh | 1 Aug 2007 17:36
Picon
Favicon

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
(Continue reading)

Permalink | Reply | 8 comments |
headers
Henrique de Moraes Holschuh | 1 Aug 2007 17:47
Picon
Favicon

Re: 2.6.21-rc1: T60 ACPI issues

(CC changed from Borislav to ibm-acpi-devel).

On Wed, 01 Aug 2007, Michael S. Tsirkin wrote:
> > > 2. Pressing Fn/F4 does not trigger suspend to ram
> > >    This normally triigers ACPI event which triggers suspend to RAM on Ubuntu
> > >    (echo mem > /sys/power/state works)
> > 
> > I'll bet this is your CONFIG_THINKPAD_ACPI_INPUT_ENABLED=y.
> > I got the same, see my "THINKPAD_ACPI_INPUT_ENABLED seems regressive"
> > mail to Henrique and lkml an hour ago.

[...]

> > > 3. After suspend to RAM, system wakes up but laptop's screen is blank,
> > >    switching VTs etc does not help.
> > >    External screen wakes up OK though.
> > >    dmesg output from boot attached.
> > 
> > (I've not had that.)
> 
> Bingo.
> sudo rmmod thinkpad_acpi cures both 2 and 3.
> Thanks for pointing this out.

I can see how it would help with (2), as that prompty tells the firmware to
issue its default ACPI events for Fn+F4 upon removal.  But I have *NO* idea
what thinkpad_acpi might be doing that is causing issues with the wake up
after a resume.

Please open a bug in bugzilla.kernel.org about it, and attach the full debug
(Continue reading)

Permalink | Reply | 2 comments |
headers
Michael S. Tsirkin | 1 Aug 2007 17:55
Picon

Re: 2.6.21-rc1: T60 ACPI issues

> Quoting Henrique de Moraes Holschuh <hmh <at> hmh.eng.br>:
> Subject: Re: 2.6.21-rc1: T60 ACPI issues
> 
> (CC changed from Borislav to ibm-acpi-devel).
> 
> On Wed, 01 Aug 2007, Michael S. Tsirkin wrote:
> > > > 2. Pressing Fn/F4 does not trigger suspend to ram
> > > >    This normally triigers ACPI event which triggers suspend to RAM on Ubuntu
> > > >    (echo mem > /sys/power/state works)
> > > 
> > > I'll bet this is your CONFIG_THINKPAD_ACPI_INPUT_ENABLED=y.
> > > I got the same, see my "THINKPAD_ACPI_INPUT_ENABLED seems regressive"
> > > mail to Henrique and lkml an hour ago.
> 
> [...]
> 
> > > > 3. After suspend to RAM, system wakes up but laptop's screen is blank,
> > > >    switching VTs etc does not help.
> > > >    External screen wakes up OK though.
> > > >    dmesg output from boot attached.
> > > 
> > > (I've not had that.)
> > 
> > Bingo.
> > sudo rmmod thinkpad_acpi cures both 2 and 3.
> > Thanks for pointing this out.
> 
> I can see how it would help with (2), as that prompty tells the firmware to
> issue its default ACPI events for Fn+F4 upon removal.  But I have *NO* idea
> what thinkpad_acpi might be doing that is causing issues with the wake up
(Continue reading)

Permalink | Reply | 1 comment |
headers
Michael S. Tsirkin | 1 Aug 2007 18:08
Picon

Re: THINKPAD_ACPI_INPUT_ENABLED seems regressive

> Quoting Henrique de Moraes Holschuh <hmh <at> hmh.eng.br>:
> 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.
>
(Continue reading)

Permalink | Reply | 6 comments |
headers
Henrique de Moraes Holschuh | 1 Aug 2007 18:18
Picon
Favicon

Re: 2.6.21-rc1: T60 ACPI issues

On Wed, 01 Aug 2007, Michael S. Tsirkin wrote:
> My guess is that upon resume, I normally get some other acpi event
> which gets blocked with CONFIG_THINKPAD_ACPI_INPUT_ENABLED.

*Nothing* should be using any such events like that (that is an bug by
itself), but let's find out if that's what happening first.

acpid logs can probably tell you that.

> > Please open a bug in bugzilla.kernel.org about it, and attach the full debug
> > output of a suspend+resume cycle with and without thinkpad-acpi loaded.
> > 
> > Also, please try the same with thinkpad-acpi loaded, but
> > CONFIG_THINKPAD_ACPI_INPUT_ENABLED set to N.  If the problem goes away,
> > please retest, but set hotkey_enable to 1 and do an "cat
> > /sys/bus/platform/devices/thinkpad_acpi/hotkey_recommended_mask >
> > /sys/bus/platform/devices/thinkpad_acpi/hotkey_mask" before the sleep.
> 
> what's hotkey_enable?

/sys/bus/platform/devices/thinkpad_acpi/hotkey_enable.

Please read the full thinkpad-acpi documentation (it is in
Documentation/thinkpad-acpi.txt in the kernel tree).

--

-- 
  "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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Henrique de Moraes Holschuh | 1 Aug 2007 18:24
Picon
Favicon

Re: THINKPAD_ACPI_INPUT_ENABLED seems regressive

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

-------------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 4 comments |
headers
Hugh Dickins | 1 Aug 2007 19:03

Re: THINKPAD_ACPI_INPUT_ENABLED seems regressive

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.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Henrique de Moraes Holschuh | 1 Aug 2007 19:52
Picon
Favicon

Re: Thinkpad ACPI "hwmon" driver needs libsensors support

On Sun, 29 Jul 2007, Hans de Goede wrote:
> I just received this bug report:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=250013
>
> This is caused because the thinkpad_acpi driver now exports its sensors 
> through the standard hwmon interface, while libsensors does not know how to 
> handle them  (for now).

Yeah.  I had to choose between adding support for current libsensors, and
improving hot key support a great deal in thinkpad-acpi.  Since AFAIK the
forthcoming new libsensors already knows how to deal with generic hwmon
interfaces, I decided to priorize work on the hot key support.

> As already said in various posts I'll be away on vacation for 6 days, after 
> that I will start writing libsensors support for the thinkpad_acpi "chip" 
> to resolve this issue. If anyone starts work on this, or has already 
> started please let me know ASAP to stop us from doing double work.

Feel free to add support to libsensors 2.x for thinkpad-acpi, I don't
believe anyone else is working on it.  At least, nobody told me about it,
yet.  If 3.x needs some thinkpad-acpi specific stuff, feel free to do it as
well.

You can probably do it better than I do, I don't know lm-sensors that well.

And if you have any doubts about something in thinkpad-acpi, or if you find
any bugs in the thinkpad-acpi side, drop me a note and I will be on it as
soon as possible.

> Also a word to the person implementing these changes in the thinkpad_acpi
(Continue reading)

Permalink | Reply | 0 comments |
headers
Henrique de Moraes Holschuh | 1 Aug 2007 20:01
Picon
Favicon

Re: THINKPAD_ACPI_INPUT_ENABLED seems regressive

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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeremy Jackson | 2 Aug 2007 18:38

T30 bluetooth regression 2.6.20 -> 2.6.22

Hi,

I just tried a kernel from Ubuntu's Gutsy distro based on 2.6.22, and
compared to the Feisty kernel 2.6.20, I've lost the use of my Bluetooth
module. 

I have a T30 Thinkpad, and the Bluetooth isn't supported by the BIOS, it
complains at each bootup, but was working under 2.6.20 with

# echo enable > /proc/acpi/ibm/bluetooth

I checked thinkpad_acpi.c from 2.6.22.y branch of git.kernel.org and it
seems the new code detects the presence of the bluetooth modules solely
by the ACPI info.

Would it be possible or is there already a way to force
detection/enabling of bluetooth in 2.6.22?

Regards,

Jeremy

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
Permalink | Reply | 4 comments |

Gmane