Joe, thanks a lot for taking the time to investigate the subject in depth. At the moment, given all the problems you mention, and given the fact that I would have to install a kernel of the 2.2 generation (meaning a change in quite a lot of other things, including, but not restricted to, pcmcia scripts, which I have changed at a lot of places), I have to judge on a cost/usefulness basis: pressing a few function keys from time to time is definetely negligible compared to the headaches I would run into by trying to use the perfect software solution in an imperfect world. It is just too costly (cost being measured in lost sleep hours ;-)) for me to try your way. But I really feel indepted to you for this effort of yours. Regards Chris [EMAIL PROTECTED] wrote: > > 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 <[EMAIL PROTECTED]> > cc: [EMAIL PROTECTED], [EMAIL PROTECTED] > 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 <[EMAIL PROTECTED]> on 01/15/99 08:32:00 AM > > To: Joe Pranevich/Lycos > cc: [EMAIL PROTECTED] > Subject: Re: (UPDATE) Re: ISSUE: Keyboard ScrollLock on after APM suspend > /restore > > [EMAIL PROTECTED] 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 > > --------------------------------------------------------------- > > Name: pic27327.pcx > Part 1.2 Type: unspecified type (application/octet-stream) > Encoding: base64 > > Name: apm_console.diff > Part 1.3 Type: unspecified type (application/octet-stream) > Encoding: base64
