Re: Laptop keyboard unusable when ACPI is active

Re: Laptop keyboard unusable when ACPI is active

[Mats Johannesson]

Many responsible CCs added.

On 2007-10-20 18:33:09 Pavel Machek responded to Daniele C.:
> > > Try disabling acpi embedded controller.
> > >
> > How can I accomplish this? Are you referring to the i8042?
>
> rmmod acpi_ec or how is it called. But I'm not sure how easy this is.

Designed to be 'hard' because it in effect breaks several functions.
See "config ACPI_EC" in drivers/acpi/Kconfig which one must edit
manually, as well as arch/*/configs/*_defconfig

Either way, the result is exactly as not loading modularized battery
and ac (thermal module still worked on my system).

But this whole issue is getting ridiculous. INPUT subsystem is addled
more and more by ACPI (in real laptop life) while the maintainers,
from a user view, seem stumped.

The bad interaction between ACPI controlled EC (embedded controller)
and the i8042 interrupt handler is theorized about in detail at OLPCs
http://dev.laptop.org/ticket/2401 - almost at the end of that page.
Thanks to Daniele C for the link.

And the bug scenario has been present for many _years_ now. From my own
experience it is only getting worse. Here's the current relations in
2.6.24-rc3-git1

_EC-reading ACPI modules unloaded_

Notebook keyboard and Synaptics touchpad operations all perfectly OK.
Nothing related show up in the logs.


_EC-reading ACPI modules loaded_

Keyboard keys get stuck when EC is accessed for battery, temperature
etc.

Touchpad (mouse pointer) gets stuck for up to ca 5 seconds if I eg move
a window while EC data is read.

The logs are spammed when EC screws over i8042:
psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 4
psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio4/input0 - driver resynched.
psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
psmouse.c: issuing reconnect request
[etc]

Messages about an unknown key show up (possibly in relation to a stuck
key). I don't have this on disk, so I'll copy the message from the bug
http://bugzilla.kernel.org/show_bug.cgi?id=9147
atkbd.c: Unknown key released (translated set 2, code 0xe0 on
isa0060/serio0).
atkbd.c: Use 'setkeycodes e060 <keycode>' to make it known.


_EC-reading ACPI modules loaded. Command line option i8042.nomux used_

Keyboard keys _can_ get stuck when EC is accessed for battery,
temperature etc. Much less frequent than without i8042.nomux though.

Synaptics touchpad operations OK. Nothing related show up in the logs.


I know that some kind of US holiday is in effect presently, but please
make an effort to take a coordinated look at this afterwards. The
issues are so old and widespread that even the angels cry (I'm told).

PS. No, Dmitry. Lowering the report rate, eg psmouse.rate=40 does not
fix anything, as I tried on your suggestion already in August 2006.

Re: Laptop keyboard unusable when ACPI is active

[Len Brown]

On Friday 23 November 2007 02:44, Mats Johannesson wrote:

> The bad interaction between ACPI controlled EC (embedded controller)
> and the i8042 interrupt handler is theorized about in detail at OLPCs
> http://dev.laptop.org/ticket/2401 - almost at the end of that page.
> Thanks to Daniele C for the link.

huh?

I believe that the OLPC XO1 does not run in ACPI mode
and thus does not use the ACPI EC driver to talk to
the EC on their board.

Presumably they use some native embedded controller driver to
talk to their platform specific embedded controller.

I don't know why they call their interrupt an SCI.
Per above, it can't be an ACPI SCI.  Presumably they
call it that b/c their chipset documentation calls it
that too, on the (invalid) assumption that an ACPI-enabled
OS and firmware would be running on the hardware.

Please let me know if I'm wrong.

-Len