Hello,
Now that I know that you are having the same problem, I thought that I
should solve it. And I did. The patch that I have here
is so obvious that it almost has to be the "right thing" There is probably
a way to fix this by calling a lower-level tty function
directly, but I think that we are better off keeping it this way.
I have tested this and it appears to solve the problems on my machine. This
makes me very happy.
Please test this and let me know how it works for you. The patch is against
2.2.0-pre6. If this works for enough people, even those without APM
enabled, I'll sumbit it someplace for includion in the kernel.
Joe
(See attached file: apm_console.diff)
Chris Karakas <karakas@t-online.de> on 01/15/99 08:32:00 AM
To: Joe Pranevich/Lycos
cc: linux-laptop@vger.rutgers.edu
Subject: Re: (UPDATE) Re: ISSUE: Keyboard ScrollLock on after APM suspend
/restore
jpranevich@lycos.com wrote:
>
> Hello,
>
> Apologies for the format of the quoted message, I don't like my mailer
> either.
>
> Update:
>
> A couple trials indicated that there is even more weirdness going on here
> than I previously thought. Firstly, it does not appear to be a problem
> restoring when you are in X, just at the console. Secondly, the results
are
> not always the same but generally the same symptoms appear in some
fasion.
> Thirdly, switching virtual consoles (which still works when the keyboard
is
> muffed up) appears to fix the problems.
>
> This morning when I restored my machine, it appeared initially as if my
> keyboard had be somehow remapped. Keys were not returning what they
should
> have. The enter key, for instance, worked. But several of the home row
keys
> either did nothing or beeped. I hit the 'f' key and I was loogged out of
> the shell. (What kind of escape sequence does *that*?)
>
> I know next to nothing about Linux's keyboard implementation. But it
> appears as if the APM BIOS is stepping on some data structure that
handles
> keyboard controls, maybe the keyboard buffer itself. (Is there a real
> hardware buffer or is that a feature that is only relevant when
programming
> DOS applications?) But whatever it is, Linux apparantly already knows how
> to fix the problem when it changes consoles so *maybe* it could be fixed
by
> doing that immediately aftert an APM restore is detected. Or, I could be
> off-base.
I have a similar "non-critical" problem: sometimes, when I resume from
"Suspend to disk" (which on my Olivetti ECHOS P90M with Phoenix NoteBIOS
seems to be what we call "hibernation" in this list) the keyboard does
not respond at all. The best way to cope with this is to stay cool (too
much accustomed to using the middle finger to reset the mashine ;-)) and
NOT power off, just play with the function keys a little: switch from X
to the text console(s), or try to switch to the extenal monitor, even if
there isn't one, then back to LCD again. So using FN-F4 or Ctrl-Alt-Fx
(x=1,...6) will revive the keyboard for me ;-). By now, I have come to
consider it "normal", since it happens only on a small percentage of
"hibernations". By the way, "Suspend to disk" works worderfully on this
laptop - of course I have to (soft) eject any PCMCIA cards that happen
to be inserted before I try it, otherwise the next tme I will have to
stop and restart the /etc/rc.d/pcmcia script, after cs gives me a
"received bogus resume event" message to remind me...
Chris
--0__=2BNlhGULRhVxnhwBR4ZGqbCcKWKlswv0Z4bQr3L6rCHP6hcFuNRGqAcL
Content-type: application/octet-stream;
name="apm_console.diff"
Content-Disposition: attachment; filename="apm_console.diff"
Content-transfer-encoding: base64
LS0tIGxpbnV4L2FyY2gvaTM4Ni9rZXJuZWwvYXBtLmMJRnJpIEphbiAxNSAxNjowMjozMSAxOTk5
CisrKyBsaW51eC1hcG0vYXJjaC9pMzg2L2tlcm5lbC9hcG0uYwlGcmkgSmFuIDE1IDE1OjM4OjU4
IDE5OTkKQEAgLTExNiw2ICsxMTYsNyBAQAogI2luY2x1ZGUgPGxpbnV4L21pc2NkZXZpY2UuaD4K
ICNpbmNsdWRlIDxsaW51eC9hcG1fYmlvcy5oPgogI2luY2x1ZGUgPGxpbnV4L2luaXQuaD4KKyNp
bmNsdWRlIDxsaW51eC90dHkuaD4KIAogI2luY2x1ZGUgPGFzbS9zeXN0ZW0uaD4KICNpbmNsdWRl
IDxhc20vdWFjY2Vzcy5oPgpAQCAtODkwLDYgKzg5MSw3IEBACiAJCQlpZ25vcmVfYm91bmNlID0g
MTsKICNlbmRpZgogCQkJc2V0X3RpbWUoKTsKKyAgICAgICAgICAgICAgICAgICAgICAgIGNoYW5n
ZV9jb25zb2xlKGZnX2NvbnNvbGUpOwogCQkJc2VuZF9ldmVudChldmVudCwgMCwgTlVMTCk7CiAJ
CQlicmVhazsKIAo=
--0__=2BNlhGULRhVxnhwBR4ZGqbCcKWKlswv0Z4bQr3L6rCHP6hcFuNRGqAcL--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/