From Sat May 19 10:44:26 2001
Received: from ( []) by (8.11.3/8.8.5) with ESMTP id f4JGiQp38002; Sat, 19 May 2001 10:44:26
-0600 (MDT)
Received: from ( [])
	by (8.10.1/8.10.1/(cic-5, 6/12/00)) with ESMTP id
	Sat, 19 May 2001 10:44:26 -0600
Received: from ( [])
	by (8.10.1/8.10.1/(ccn-5)) with ESMTP id f4JGiPj03365;
	Sat, 19 May 2001 10:44:25 -0600
Received: from ( [])
	by (CSE Mail Server) with ESMTP
	id 4E4E1199FC; Sat, 19 May 2001 12:44:13 -0400 (EDT)
Received: from ( [])
	by (CSE Mail Server) with ESMTP id 8DB56199C1
	for <>; Sat, 19 May 2001 12:43:23 -0400 (EDT)
Received: from ( [])
	by (8.9.3/8.9.3) with ESMTP id MAA27343
	for <>; Sat, 19 May 2001 12:43:22 -0400 (EDT)
From: Dan Cross <>
Received: (from cross@localhost)
	by (8.9.3+Sun/8.9.3) id MAA13310;
	Sat, 19 May 2001 12:43:22 -0400 (EDT)
Message-Id: <>
Subject: Re: [9fans] Targus keyboard for iPAQ?
Newsgroups: comp.os.plan9
In-Reply-To: <>
References: <>
Organization: Mememememememmeme
X-Mailman-Version: 2.0.1
Precedence: bulk
List-Id: Fans of the OS Plan 9 from Bell Labs <>
List-Archive: <>
Date: Sat, 19 May 2001 12:43:22 -0400 (EDT)
Status: RO

In article <> you write:
>I use the stylus.


>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

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.