Messages in this thread | | | From | jpranevich@lycos ... | Date | Fri, 15 Jan 1999 17:56:12 -0500 | Subject | ISSUE: Keyboard / APM Problems (was (PATCH) Re: (UPDATE) Re: ISSUE: Keyboard ScrollLock on after APM suspend /restore) |
| |
Hello,
Firstly, I just wanted to say that I neglected to include a bit of my last patch. You need to change vt.c to not ignore the spacial case when you are switching consoles to the foreground console.
Secondly, the issue is larger than I thought and it appears as if the patch only works in certain cases. It appears now as if what I assumed was keyboard garbage and a scroll-lock problem was in fact somewhat different. It appears that there are some interactions between the APM BIOS and the keyboard driver that results in odd things happening. What I interpreted as garbage appears to be the same as if the control-key is being held down. Additionally, it appears as if the keyboard buffer (or whatever) is corrupted as the first things that happen is that a number of keypresses make it through the kernel.
Now, the patch that I submitted would refresh the keyboard bits immediately after an APM resume message was recieved. But, it does not appear as if that had any affect. (at least part of the time; it may be a timing issue) However, if I wait a moment and then press Alt-F1 (which would do the same as the code that I added), the terminal becomes fine. (Thus, I assume that the keyboard driver is not aware of the problem.)
Could someone that knows more about this than I do take a gander at this problem? In my opinion, we probably need to set ups something that ignores the first keypresses immediately after a resume. Once those go through, we need to refersh the keyboard state. At that point, evenything should be fine.
Comments / Suggestions / Patches?
Joe
Joe Pranevich 01/15/99 04:17 PM (Embedded image moved to file: pic27327.pcx)
To: Chris Karakas <karakas@t-online.de> cc: linux-laptop@vger.rutgers.edu, linux-kernel@vger.rutgers.edu Subject: (PATCH) Re: (UPDATE) Re: ISSUE: Keyboard ScrollLock on after APM suspend /restore (Document link not converted)
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
[unhandled content-type:application/octet-stream][unhandled content-type:application/octet-stream] | |