lkml.org 
[lkml]   [1999]   [Jan]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectISSUE: 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]
\
 
 \ /
  Last update: 2005-03-22 13:49    [W:0.039 / U:0.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site