From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S267256AbUBMWqo (ORCPT ); Fri, 13 Feb 2004 17:46:44 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S267269AbUBMWql (ORCPT ); Fri, 13 Feb 2004 17:46:41 -0500 Received: from smtp806.mail.sc5.yahoo.com ([66.163.168.185]:33880 "HELO smtp806.mail.sc5.yahoo.com") by vger.kernel.org with SMTP id S267256AbUBMWqV (ORCPT ); Fri, 13 Feb 2004 17:46:21 -0500 From: Dmitry Torokhov To: Vojtech Pavlik Subject: Re: Strange atkbd messages with missing keyboard Date: Fri, 13 Feb 2004 17:46:15 -0500 User-Agent: KMail/1.6 Cc: linux-kernel@vger.kernel.org, Meelis Roos References: <200402131327.46543.dtor_core@ameritech.net> <20040213185744.GA1371@ucw.cz> In-Reply-To: <20040213185744.GA1371@ucw.cz> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200402131746.15884.dtor_core@ameritech.net> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Friday 13 February 2004 01:57 pm, Vojtech Pavlik wrote: > On Fri, Feb 13, 2004 at 01:27:46PM -0500, Dmitry Torokhov wrote: > > 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. Right, sorry I got confused with something else... > > > 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. > The problem with this approach is that if late NAK comes while we are actually waiting for result of some other command it will interfere and can cause misdetection. -- Dmitry