[9fans] Targus keyboard for iPAQ?

[9fans] Targus keyboard for iPAQ?

[Dan Cross]

To anyone whose using Plan 9 on the iPAQ; are you using the
Targus `stowaway' keyboard?  It appears to need a special device
driver, and I don't see code for it yet.  A linux driver exists,
however, so maybe it wouldn't be too hard.  Certainly, not as
hard as the stylus is being on my fingers.  :-)

	- Dan C.

Re: [9fans] Targus keyboard for iPAQ?

[Francisco J Ballesteros]

I use the stylus.
my local reseller told me that such keyboard was not yet
available for the ipaq, so I didn´t even bothered to look for it
on the web. Does such beast exist?

Dan Cross wrote:
> 
> To anyone whose using Plan 9 on the iPAQ; are you using the
> Targus `stowaway' keyboard?  It appears to need a special device
> driver, and I don't see code for it yet.  A linux driver exists,
> however, so maybe it wouldn't be too hard.  Certainly, not as
> hard as the stylus is being on my fingers.  :-)
> 
>         - Dan C.

RE: [9fans] Targus keyboard for iPAQ?

[Richard Elberger]

Yes, check it out at www.targus.com.  Model #PA840U. URL:
http://www.targus.com/default_product.asp?title=STOWAWAY+PORTABLE+KEYBOARD+F
OR+COMPAQ+IPAQ&sku=PA840U

-- rich

-----Original Message-----
From: 9fans-admin@cse.psu.edu [mailto:9fans-admin@cse.psu.edu]On Behalf
Of Francisco J Ballesteros
Sent: Saturday, 19 May 2001 10:12 a.m.
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Targus keyboard for iPAQ?


I use the stylus.
my local reseller told me that such keyboard was not yet
available for the ipaq, so I didn´t even bothered to look for it
on the web. Does such beast exist?

Dan Cross wrote:
>
> To anyone whose using Plan 9 on the iPAQ; are you using the
> Targus `stowaway' keyboard?  It appears to need a special device
> driver, and I don't see code for it yet.  A linux driver exists,
> however, so maybe it wouldn't be too hard.  Certainly, not as
> hard as the stylus is being on my fingers.  :-)
>
>         - Dan C.

RE: [9fans] Targus keyboard for iPAQ?

[Sam Ducksworth]

FYI, i contacted targus to see if they had an adapter so that
i could use the same keyboard for either my palm or my
iPAQ and she said no. you have to buy one for each.


On Sat, 19 May 2001, Richard Elberger wrote:

> Yes, check it out at www.targus.com.  Model #PA840U. URL:
> http://www.targus.com/default_product.asp?title=STOWAWAY+PORTABLE+KEYBOARD+F
> OR+COMPAQ+IPAQ&sku=PA840U
>
> -- rich
>
> -----Original Message-----
> From: 9fans-admin@cse.psu.edu [mailto:9fans-admin@cse.psu.edu]On Behalf
> Of Francisco J Ballesteros
> Sent: Saturday, 19 May 2001 10:12 a.m.
> To: 9fans@cse.psu.edu
> Subject: Re: [9fans] Targus keyboard for iPAQ?
>
--<snip>---<snip>---

--sam

Re: [9fans] Targus keyboard for iPAQ?

[Dan Cross]

In article <Pine.BSF.4.33.0105181619100.97125-100000@lucifer.ducksworth.com> you write:
>FYI, i contacted targus to see if they had an adapter so that
>i could use the same keyboard for either my palm or my
>iPAQ and she said no. you have to buy one for each.

The Linux people at http://www.handhelds.org/ figured out how to build
a dongle to connect the Palm stowaway to an iPAQ.  They have a pointer
to circuit schematics somewhere; I don't know if that's such a hot
idea, though; it might be better to just get two keyboards.

	- Dan C.

Re: [9fans] Targus keyboard for iPAQ?

[Dan Cross]

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.

Re: [9fans] Targus keyboard for iPAQ?

[jmk]

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.
>