From owner-freebsd-mobile Sat Jan 4 23:57:36 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id XAA19408 for mobile-outgoing; Sat, 4 Jan 1997 23:57:36 -0800 (PST) Received: from nasu.utsunomiya-u.ac.jp (nasu.utsunomiya-u.ac.jp [160.12.128.3]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id XAA19403 for ; Sat, 4 Jan 1997 23:57:32 -0800 (PST) Received: by nasu.utsunomiya-u.ac.jp (5.57/ULTRIX-940302) id AA06095; Sun, 5 Jan 97 16:56:11 +0900 Received: by outmail.utsunomiya-u.ac.jp (5.57/ULTRIX-940909) id AA03228; Sun, 5 Jan 97 16:56:10 +0900 Received: from zodiac.mech.utsunomiya-u.ac.jp (zenith.mech.utsunomiya-u.ac.jp [160.12.33.60]) by zodiac.mech.utsunomiya-u.ac.jp (8.7.6+2.6Wbeta7/3.4W/zodiac-May96) with ESMTP id QAA24361; Sun, 5 Jan 1997 16:59:36 +0900 (JST) Message-Id: <199701050759.QAA24361@zodiac.mech.utsunomiya-u.ac.jp> To: Brian Beattie Cc: mobile@freebsd.org, Nate Williams , yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: Re: Tecra 730 Date: Sun, 05 Jan 1997 16:59:35 +0900 From: Kazutaka YOKOTA Sender: owner-mobile@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello, this is Kazu. Nate CC'd me the exchange between you and him on your keyboard/mouse problem. >> The saga of my Terca 730. I installed 2.1.6 + XF8632 + PAO. I had >> some problems with this, I don't remember exactally what now but >> since I needed XF8632 for my video chipset I decided to try 2.2-BETA. >> >> I installed 2.2-BETA + XF8632. This almost worked but while running >> X + fvwm1.24r the keybord stopped working. The mouse continued to >> work and the window manager continued to work but the keyboard did >> not. I decided to try to apply the PAO patches PAO-961215. > >They don't affect the keyboard. I think there can be two possible reasons why the keyboard looks locked up while the mouse continues to work: The first possibility is that this is real lock up; the keyboard and the keyboard controller cannot communicate properly. Communication MAY be restored by instructing the keyboard controller to test the keyboard port. This can be done from the console driver, but in practice it would be difficult for the driver to decide when it should do it. The second possible explanation is that due to a lost keyboard interrupt, shift, ctrl, alt, num lock, or whatever shift/lock state change is not seen by the console driver or the X server and a key stroke is not interpreted properly, thus, the keyboard looks locked up despite that key scan codes are received by the console driver. You may be able to recover from this by tapping these shift/lock keys several times. The interrupt problem existed before, and we have been hoping to eliminate it with the new syscons/psm/kbdio drivers, but... >> The keyboard still locks up under X + fvwm-1.24r, restarting the X >> server brings the keyboard back. > >*sigh* I suspect you could switch to another virtual terminal and do the >same thing, but w/out a keyboard it's kinda hard. :( Well, it appears that the second explanation above is more likely to be the case, as I don't think resetting the X server affect the state of the data line between the keyboard and the keyboard controller in any way.