linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Vojtech Pavlik <vojtech@suse.cz>
Cc: Andries Brouwer <aebr@win.tue.nl>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Pete Zaitcev <zaitcev@redhat.com>,
	Chris Heath <chris@heathens.co.nz>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: i8042 problem
Date: Wed, 13 Aug 2003 15:44:10 +0200 (MET DST)	[thread overview]
Message-ID: <Pine.GSO.3.96.1030813152344.25530E-100000@delta.ds2.pg.gda.pl> (raw)
In-Reply-To: <20030812204625.GB23011@ucw.cz>

On Tue, 12 Aug 2003, Vojtech Pavlik wrote:

> >  Wrt polling vs IRQ-driven probing and setup: using IRQ is a natural
> > choice as you have to do keyboard detection in the IRQ handler anyway to
> > properly support hot plugging of a PC/AT or a PS/2 keyboard. 
> 
> The only problem there is that it results in a damn complex state
> machine. Look at the PS/2 mouse probing and imagine how the state
> machine would look.

 Well, I don't think a complex state machine is needed.  What's the
variable part of the initialization?  Essentially the keyboard type (two
options available) and the scancode mode selected (three options
available).  Everything else is constant.  So besides the current
initialization step, you only need to record these two variables.  And the
good news is the more complicated setup scenarios are simply a superset of
the simpler ones, so you do not have multiple paths in the initialization
-- there's only one, of which parts are skipped, depending on the
configuration.  Specifically, for a PC/AT keyboard you don't select a
scancode mode and for the PS/2 keyboard you don't set up key
up/down/repeat characteristics in modes #1 and #2.

 Still if you go beyond the standard PC/XT compatibility mode, you need to
handle run-time keyboard switching, i.e. if I boot with a PS/2 keyboard,
unplug it and later use a PC/AT one, it should just work.  I have a
similar problem with the LK201 keyboard driver (that's a standard DEC
keyboard implementation for a lot of their systems).  There are different
keyboards having the same interface as the LK201 -- programming them is
the same, but their features differ, including the interpretation of some
keys and LEDs (the number of LEDs varies from 2 to 4 and they may have
different labels).  For 2.4, the driver does a reasonable job of run-time
configuration, but it may still be improved (e.g. it doesn't yet do a
handshake I'm thinking of; unfortunately not all LK201 commands return an
ACK) and I'm planning to do that for 2.6.  While looking at it, I may look
at the PS/2 driver and see how it can be improved. 

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


  reply	other threads:[~2003-08-13 13:44 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-26  6:11 i8042 problem Pete Zaitcev
2003-07-26  9:36 ` Andries Brouwer
2003-07-27  1:41   ` Chris Heath
2003-07-27  6:06     ` Pete Zaitcev
2003-07-27 10:47       ` Andries Brouwer
2003-07-28  1:55         ` Pete Zaitcev
2003-07-28 11:25           ` Alan Cox
2003-07-28 11:59             ` Andries Brouwer
2003-07-28 14:01               ` Maciej W. Rozycki
2003-07-28 14:54                 ` Andries Brouwer
2003-07-28 15:43                   ` Maciej W. Rozycki
2003-07-28 15:51                     ` Andries Brouwer
2003-07-29 18:29                       ` Maciej W. Rozycki
2003-08-12 20:46                         ` Vojtech Pavlik
2003-08-13 13:44                           ` Maciej W. Rozycki [this message]
2003-07-28 16:07             ` Pete Zaitcev
2003-08-12 20:47               ` Vojtech Pavlik
2003-08-12 20:42         ` Vojtech Pavlik
2003-08-12 23:06           ` Andries Brouwer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.GSO.3.96.1030813152344.25530E-100000@delta.ds2.pg.gda.pl \
    --to=macro@ds2.pg.gda.pl \
    --cc=aebr@win.tue.nl \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=chris@heathens.co.nz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vojtech@suse.cz \
    --cc=zaitcev@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).