From 9fans-admin@cse.psu.edu Sat May 19 10:44:26 2001 Received: from mailhost.lanl.gov (mailhost.lanl.gov [128.165.3.12]) by acl.lanl.gov (8.11.3/8.8.5) with ESMTP id f4JGiQp38002; Sat, 19 May 2001 10:44:26 -0600 (MDT) Received: from mailproxy1.lanl.gov (mailproxy1.lanl.gov [128.165.0.26]) by mailhost.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) with ESMTP id f4JGiQV18873; Sat, 19 May 2001 10:44:26 -0600 Received: from mail.cse.psu.edu (psuvax1.cse.psu.edu [130.203.4.6]) by mailproxy1.lanl.gov (8.10.1/8.10.1/(ccn-5)) with ESMTP id f4JGiPj03365; Sat, 19 May 2001 10:44:25 -0600 Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.8.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 4E4E1199FC; Sat, 19 May 2001 12:44:13 -0400 (EDT) Received: from math.psu.edu (leibniz.math.psu.edu [146.186.130.2]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 8DB56199C1 for <9fans@cse.psu.edu>; Sat, 19 May 2001 12:43:23 -0400 (EDT) Received: from augusta.math.psu.edu (augusta.math.psu.edu [146.186.132.2]) by math.psu.edu (8.9.3/8.9.3) with ESMTP id MAA27343 for <9fans@cse.psu.edu>; Sat, 19 May 2001 12:43:22 -0400 (EDT) From: Dan Cross Received: (from cross@localhost) by augusta.math.psu.edu (8.9.3+Sun/8.9.3) id MAA13310; Sat, 19 May 2001 12:43:22 -0400 (EDT) Message-Id: <200105191643.MAA13310@augusta.math.psu.edu> To: 9fans@cse.psu.edu Subject: Re: [9fans] Targus keyboard for iPAQ? Newsgroups: comp.os.plan9 In-Reply-To: <3B059E18.4F03E587@gsyc.escet.urjc.es> References: <200105181910.PAA11299@math.psu.edu> Organization: Mememememememmeme Cc: Sender: 9fans-admin@cse.psu.edu Errors-To: 9fans-admin@cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.0.1 Precedence: bulk Reply-To: 9fans@cse.psu.edu List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Archive: Date: Sat, 19 May 2001 12:43:22 -0400 (EDT) Status: RO X-Status: 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.