From mboxrd@z Thu Jan  1 00:00:00 1970
From: jmk@plan9.bell-labs.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Targus keyboard for iPAQ?
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Message-Id: <20010519170750.9E2D1199C1@mail.cse.psu.edu>
Date: Sat, 19 May 2001 13:07:48 -0400
Topicbox-Message-UUID: a22dc390-eac9-11e9-9e20-41e7f4b1d025

Earlier this week I made the first stab at rationalising the kernel
serial console code in the 9P2000 kernel when I changed the PC uart code
to use devuart.c. While doing it I toyed with the idea of allowing the
serial console device to be enabled/disabled/assigned by writing to the
ctl file, all the hooks are now there I think.

I'll bear this in mind as I work through the remaining issues in tidying
up the twisty little maze the serial console code has become. Presotto did
us all a great service by ripping the code apart to produce devuart.c

--jim

On Sat May 19 12:44:25 EDT 2001, cross@math.psu.edu wrote:
> In article <3B059E18.4F03E587@gsyc.escet.urjc.es> you write:
> >I use the stylus.
> 
> Ahh!
> 
> >my local reseller told me that such keyboard was not yet
> >available for the ipaq, so I didnt even bothered to look for it
> >on the web. Does such beast exist?
> 
> Indeed it does!  The pointers that others have proffered are quite
> handy.
> 
> Following up to my own question, I now understand the issue a little
> better.  As it turns out, the keyboard is really just a serial device
> (!!).  echo -n b9600 > /dev/eia0ctl and a subsequent cat /dev/eia0 spit
> out all sorts of neat things.  This is promising; one might potentially
> be able to implement a keyboard ``driver'' completely in user space,
> without mucking with the kernel at all.  (I was confused earlier about
> device drivers because the Linux people have a kernel abstraction for
> ``serial input devices'' which mimic a `standard' keyboard, and there
> is a stowaway driver for fitting into that framework.  Also, there is a
> terminal line discipline in the kernel for driving the stowaway
> keyboard.  It's not clear that the two are relate.  Ugh.  The general
> method [things in the kernel] is, as near as I can gather, because they
> don't have the concept of /dev/kbdin, which would allow them to pull
> this garbage out of the kernel.)
> 
> So anyway, a pure user-space implementation should be possible.
> Unfortunately, there's a catch in the bitsy kernel....
> 
> By default, main() calls sa1100_uartsetup(1) (sorry if this is
> incorrect, I'm doing this from memory and don't have the kernel sources
> in front of me at the moment).  sa1100_uartsetup interprets the
> argument literal 1 as a flag indicating that it should set up the first
> serial port as a console device via a call to uartspecial().  The first
> time a process reads /dev/eia0, input taken from a serial port is
> automagically sent to /dev/kbdin, resulting in the active window taking
> data from the serial port as input to the process in that shell.  Well,
> this is *really cool* if the serial port is connected to a window
> running con on the other end, but really not cool if the input consists
> of scancodes read from a keyboard!  (I was pretty confused for a few
> minutes about why, after I had killed cat, it was still reading data
> from the keyboard; and sending it to the shell no less!  Duh.)
> 
> Anyway, a minimal solution seems obvious: call sa1100_uartsetup(0);
> from main(), and then write a user level program to do scancode
> translation on data taken from /dev/eia0, sending the results on to
> kbdin.  However, this removes the ability to use the serial port as a
> console from a con session, which seems a shame.  I can't think of a
> good way to multiplex between the two, though; perhaps try to figure
> out if a keyboard is attached to the serial port, and if so, don't make
> the call to uartspecial().  Another thing would be to never call
> uartspecial(), and instead use cat to get data from the serial port and
> send it to kbdin, after the machine had booted.  This makes it hard to
> change the root (eg, at the ``root is from [sac]'' prompt), but the
> same applies if the keyboard is hooked up to the bitsy instead of the
> console serial port.  I suppose the most complete solution would be
> attempting to detect the keyboard, and if present, doing the keycode
> translation logic in the kernel, if not present, installing the serial
> handler as per normal.  This wouldn't be that hard (I think there's a
> way to try and detect the keyboard), but seems kinda icky nonetheless.
> 
> What do others think?  Is it worth the gyrations to have the more
> general solution?
> 
> 	- Dan C.
>