From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S267163AbUBMS5T (ORCPT ); Fri, 13 Feb 2004 13:57:19 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S267165AbUBMS5T (ORCPT ); Fri, 13 Feb 2004 13:57:19 -0500 Received: from twilight.ucw.cz ([81.30.235.3]:43398 "EHLO midnight.ucw.cz") by vger.kernel.org with ESMTP id S267163AbUBMS5P (ORCPT ); Fri, 13 Feb 2004 13:57:15 -0500 Date: Fri, 13 Feb 2004 19:57:44 +0100 From: Vojtech Pavlik To: Dmitry Torokhov Cc: linux-kernel@vger.kernel.org, Meelis Roos Subject: Re: Strange atkbd messages with missing keyboard Message-ID: <20040213185744.GA1371@ucw.cz> References: <200402131327.46543.dtor_core@ameritech.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200402131327.46543.dtor_core@ameritech.net> User-Agent: Mutt/1.4.1i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 13, 2004 at 01:27:46PM -0500, Dmitry Torokhov wrote: > On Friday 13 February 2004 08:12 am, Meelis Roos wrote: > > > Meelis, can you please enable DEBUG in i8042.c, so that I can check > > > where these unexpected NAKs come from? > > > > Here is full dmesg (though probably only the serio and atkbd lines are > > interesting). > > > > > drivers/input/serio/i8042.c: d4 -> i8042 (command) [3] > > drivers/input/serio/i8042.c: f2 -> i8042 (parameter) [3] > > drivers/input/serio/i8042.c: d4 -> i8042 (command) [109] > > drivers/input/serio/i8042.c: ed -> i8042 (parameter) [109] > > drivers/input/serio/i8042.c: fe <- i8042 (interrupt, aux, 12, timeout) [122] > > drivers/input/serio/i8042.c: 60 -> i8042 (command) [122] > > drivers/input/serio/i8042.c: 54 -> i8042 (parameter) [122] > > drivers/input/serio/i8042.c: fe <- i8042 (interrupt, aux, 12, timeout) [240] > > atkbd.c: Unknown key pressed (raw set 0, code 0x17e on isa0060/serio1). > > atkbd.c: Use 'setkeycodes 7e ' to make it known. > > I see that we are not getting a NAK when querying ID but getting it while > setting LEDs (or even writing to the control register later). It seems > like controller's timeout is longer than our internal one so we getting > timeout signal from keyboard (which we convert to a NAK) too late. We don't convert it to a NAK, it comes as a NAK byte from the controller (generated by the controller), and with the timeout flag set. > I wonder if changing timeout in atkbd_sendbyte to 400 or 500 ms will > cure the problem. It probably would, but it also would slow down the detection. I think we can simply ignore bytes with the timeout flag set in the atkbd_interrupt function when we're not expecting an ACK/NAK. -- Vojtech Pavlik SuSE Labs, SuSE CR