linuxconsole-dev

Re: [Linux-fbdev-devel] Supporting various depth

[James S. <jsi...@tr...>]

> This won't exactly work - there are some ways to access the vga
> registers - io (might be remapped from 0x3c0-03df to other address),
> memory mapped (at any address) or other (nvidia uses other). Also the
> memory in the linear aperture is organized differently (at least on the
> nvidia) then the memory at 0xa0000-0xc0000. The solution is probably for
> the chipset drivers to supply functions (incrtc, outcrtc, etc.)

So basically I need a vga_ops struct that defines functions to access the
vga_region. Have any ideas what is needed? How is the linear aperture
arranged differently?

Re: [Linux-fbdev-devel] Supporting various depth

[Matan Ziv-Av <ma...@sv...>]

On Thu, 14 Jun 2001, James Simmons wrote:

> > I guess it is more limited by the software, isn't it ? Is it
> > possible to have vgacon and fbcon active at the same time with 2.4.+ kernels ?
> 
>  Not with 2.4.X :-( The console system uses a gloal struct consw
> (conswitchp). You really have to hack up the console system to get it to
> work. For me I just rewrote the whole thing.
>  For ruby it is possible but I haven't done it yet. The biggest problem
> right now is the current vgacon I have. Lots of global variables. I like
> to be able to pass the register region and the text memory region to
> vgacon. By default they would be 0x3C0 for the registers and A000 for the
> text memory region. Well something like that. These regions are different
> on different platforms. Now you could write a small wrapper that passes in
> the pci regions. This is what I plan to do for the NVIDIA text mode
> driver I have. It pretty much is vgacon except it uses the pci regions
> instead. I also plan to vgacon firmware independent as well.

This won't exactly work - there are some ways to access the vga
registers - io (might be remapped from 0x3c0-03df to other address),
memory mapped (at any address) or other (nvidia uses other). Also the
memory in the linear aperture is organized differently (at least on the
nvidia) then the memory at 0xa0000-0xc0000. The solution is probably for
the chipset drivers to supply functions (incrtc, outcrtc, etc.)



-- 
Matan Ziv-Av.                         ma...@sv...

Re: X-server config / serial mouse ??

[James S. <jsi...@tr...>]

> can somebody give me information on the Xserver configuration file
> (comparable to /etc/X11/XF86config, ...-4 on x86 systems) for the iPAQ?
> Does it support serial mice additionally or alternatively to the
> touchscreen input?

Good question. Does the tiny X server support PS/2 mice? If it does then
your in luck.

To do this compile the kernel for the ipaq with:

In the driver/input directory

Input core support
Mouse support
Horizontal screen resolution '320'
Vertical screen resolution '240'

In drivers/char enable:

Joystick support
Serial port input line discipline

Compile the attached serial mouse driver.

Then do a if compiled all as modules. Otherwise if they are all built in
just run inputattach. 

insmod input.o
insmod serio.o
insmod serport.o
insmod sermouse.o
insmod mousedev.o

inputattach -bare /dev/ttySA0 &


Now if make sure you have a /dev/input/mice device. If not just do a

cd /dev
mkdir input
mknod input/mice c 13 63

Now for your XFree86 4.0 server config file have the following:

Section "InputDevice"
  Driver        "mouse"
  Identifier    "Mouse[1]"
  Option        "Device"        "/dev/input/mice"
  Option        "Emulate3Buttons"       "on"
  Option        "Name"          "AutoDetected"
  Option        "Protocol"      "imps/2"
  Option        "Vendor"        "AutoDetected"
EndSection

Now you should be ready to go.

Re: Patching, video and input

[James S. <jsi...@tr...>]

> At present I am using a patched version of 2.4.5 (includes a number of
> ac patches) Can I apply the LCP code without any nasty surprises being
> likely?

I haven't tried it with the ac patches. Their could be surprises. I hope
to in the coming weeks have it work again other trees (the mips and arm)
as well as Linus tree.  

> Can I simply compile the sunkbd driver on its own? 

Yes. You don't need to apply the LCP patches to get your sun keyboard
working. What you do need is in the standard tree:

Enable input support.

Select Keyboard support
Select Joystick support
Select Event interface support

Then in the Joystick directory in character devices

Select Serial port input line discipline

Build everything and then build your sunkbd.o driver.

Do a if built all modular:

insmod input.o
insmod serio.o
insmod serport.o
insmod keybdev.o
insmod evdev.o
insmod sunkbd.o

Then run inputattach which is in our ruby/utils directory.

To test the device use evtest which is also in the directory.

If you need anything else just post to the list.

X-server config / serial mouse ??

[Ralf A. <ra...@sh...>]

Hello,

can somebody give me information on the Xserver configuration file
(comparable to /etc/X11/XF86config, ...-4 on x86 systems) for the iPAQ?
Does it support serial mice additionally or alternatively to the
touchscreen input?

i'm currently working on an adapter (microcontroler based) and the Linux
input modules to interface both a PS/2 keyboard and PS/2 mouse (that's
what e.g. the Twiddler2 chording keyboard provides) to just 1 serial port
(the 2 data streams will be interleaved and decomposed at the "host"
side).

Information on the components
 - the already working PS/2 => serial adapter with Linux input interface
   support
	http://www.iptel-now.de/HOWTO/PS2SER/ps2ser.html
 - PS/2 mouse to serial conversion (this is a bit more tricky because
   you need to send to the mouse as well to make it start sending data)
	http://www.iptel-now.de/HOWTO/PS2SER/ps2ser.html (enhancement
	section)
 - interfacing serial mice via the Linux input interface
	http://www.iptel-now.de/HOWTO/SUN_SERIAL_KBD/sun_serial_kbd.html

is available and has been tested.

Once i have the information on whether/how the iPAQ x-server handles
serial mice - i'll post the info on hardware and drivers that combine all
these components.

That will enable the Twiddler2 as an universal input device for the iPAQ
(or other handhelds with just a serial input interface).

regards
 ralf


--
Best regards,
 Ralf Ackermann

Re: [Linux-fbdev-devel] Supporting various depth

[James S. <jsi...@tr...>]

> huh ???
> 
> What special hardware support is needed there. The card is just a multi
> function agp board, with both pm# having their own mmio and fb space, as well
> as the (unused by fbdev) gamma bridge.

This is what I mean. The card has to have two fully functional framebuffers, 
mmio regions and seperate accel engines if used. In a nut shell the hardware
has to have two independent states.

> It is just like a dual card setup. Is there a hardware reason you cannot keep
> vgacon on the first head, and have fbcon setting up a new console on the
> second head ? 

If the card can support being in a vga text state and a graphics state at
the same time then I see no problem. 

> I guess it is more limited by the software, isn't it ? Is it
> possible to have vgacon and fbcon active at the same time with 2.4.+ kernels ?

   Not with 2.4.X :-( The console system uses a gloal struct consw
(conswitchp). You really have to hack up the console system to get it to
work. For me I just rewrote the whole thing. 
   For ruby it is possible but I haven't done it yet. The biggest problem
right now is the current vgacon I have. Lots of global variables. I like
to be able to pass the register region and the text memory region to
vgacon. By default they would be 0x3C0 for the registers and A000 for the
text memory region. Well something like that. These regions are different
on different platforms. Now you could write a small wrapper that passes in
the pci regions. This is what I plan to do for the NVIDIA text mode
driver I have. It pretty much is vgacon except it uses the pci regions
instead. I also plan to vgacon firmware independent as well. 
   As for your case it would be a matter of coordinating both pm3con and
pm3fb together. They have to have the same initialization function to
ensure the correct regions go to the correct console display drivers.  	

> > then. Does the pm2 card have such a feature?
> 
> mmm, don't think so, will have to check it. But the problem is, i think, that
> thec chip don't really knows that something is going wrong.


Some cards can tell if something does go wrong. A example is the ATI
cards. They send out a irq when the accel engine goes bonkers. It is
really for debugging but I can see its use otherwise. Imagine a X server
ontop of ati fbdev and if the X server does something foolish then the
kernel driver would correct itself. This would be a really nice feature.
Plus you get the bonus info in syslog if you use printk to let you know
something went wrong.

Patching, video and input

[Chris <ch...@st...>]

Hi,

     I recently obtained a Sun Type 4 keyboard and built a serial
interface for it. I started developing my own driver for it before
discovering this project. I've had a number of years userspace 
development, but I'm a complete newbie at kernel hacking so my
apologies for the dumb questions..

At present I am using a patched version of 2.4.5 (includes a number of
ac patches) Can I apply the LCP code without any nasty surprises being
likely?

Poking through the code, I've notices a number of video drivers. I'm
only really interested in getting my sun keyboard to work at the moment,
and not too keen on patching my nice stable kernel with more alpha code
that I absolutely need. Can I simply compile the sunkbd driver on its
own? I've noticed that a number of 2.4.5 drivers have been written by
the author of the sunkbd driver, and a quick look through the
appropriate sources doesn't seem to turn up too many obvious
differences. Do I actually need to apply the complete source patch just
to get that one driver to work?

Thanks for any feedback,

Chris

Re: [Linux-fbdev-devel] DMA/IRQ based hardware support.

[James S. <jsi...@tr...>]

> > The ruby tree has finished the moved away from using spinlocks to a
> > sempahore for the console lock.
> 
> Has this issue been discussed on this list?

Yes. Especially with the i810 fbdev driver. It can only work as a DMA/irq
based device. The console spinlock was preventing this. Turning off IRQs
prevented the hardware from working.

> The sempahore gives better support for threads/tasks?

?? Do you from a userland prespective?
 
> When/why would you want to use DMA? Do all the drawing on CPU memory and
> then DMA
> the block to graphics memory? It seems that approach would get in the
> way of acceleration.

Because one this is the only way some devices work. Second DMA often gives
better performance and it usually is much easier to program. For most
hardware you can send accel commands threw the DMA engine to draw things.
 
> Using DMA inside the acceleration routines? It seems on average you
> would spend more time making the tests to decide to use DMA and
> programming the DMA then it would be to write the pixels directly.

No. Fbcon needs only one DMA buffer. Allocate a chunck of memory and mark
it for DMA use. Then feed data into it. We do have to make sure that we
don't flood the DMA engine with to many commands. This can be controled
by the size of the buffer and with some conditional scheduling code. We do
the same thing for FIFOs and we also do a busy loop polling the accel
engine to see if it is busy. Often with DMA hardware you can feed it data
while the accel engine is busy and it gets processed as soon as the accel
engine is done with the previous command. 
 
> It seems most operations on fb would involve "small" rectangles that do
> not use large contigous blocks of memory. Console scrolling would be
> able to take advantage of it...

Correct. The new fbdev api is based around this idea.

Re: [Linux-fbdev-devel] DMA/IRQ based hardware support.

[Scott A M. <sam...@co...>]

James Simmons wrote:
> 
> The ruby tree has finished the moved away from using spinlocks to a
> sempahore for the console lock.

Has this issue been discussed on this list?

The sempahore gives better support for threads/tasks?


> This means we can now have fbdev drivers
> that use DMA :-) We can now write fbdev drivers using DMA. Thank you.

Please pardon my ignorance...

When/why would you want to use DMA? Do all the drawing on CPU memory and
then DMA
the block to graphics memory? It seems that approach would get in the
way of acceleration.

Using DMA inside the acceleration routines? It seems on average you
would spend more time making the tests to decide to use DMA and
programming the DMA then it would be to write the pixels directly.

It seems most operations on fb would involve "small" rectangles that do
not use large contigous blocks of memory. Console scrolling would be
able to take advantage of it...

Thanks for any comments.


-- 
Scott A. McConnell

Re: [driver] New life for Serial mice

[James S. <jsi...@tr...>]

> > I ported it over to my tree. I will have to figure out how to incorporate
> > the input serial stuff without breaking all the input drivers we have. In
> > CVS we have alot of them. This will make life so much easier since all I
> > will have to do is change one file for changes I make to the tty layer. I
> > have improved andrew mortons console patch to work with multiple consoles
> > and for different types of console devices. Instead of altering all the 
> > console drivers I'm planning on intergrating the locking into the tty
> > layer. That patch is needed for serial devices as well as video terminals.
> > Your work might help speed up devleopement.
> 
> Sounds cute. Where do I find the result of your work?

For Russell's work I placed it in the ruby tree under linux/drivers/serial. No
changes have happened to it. Well at least not yet. What I like to see is:

serial_driver -> serial common code -----> serial tty 
				      |	
				      |--> serial input

For my one system I have for my only serial device a joystick. Do I really
need a serial terminal for this device. Termios changes to joystick, give
me a break. It just another layer of uneeded bloat. A nice clean design
like this would be really nice. The code is in CVS if you want to play
with it. 

As for the console lock it is already in CVS as well. Their are a few race
conditions dealing with printk and register_console to pound out but its
there and it works well. The basic changes I have made are the functions
acquire_console_sem and release_console_sem take a struct tty_driver
argument. This way we can flush one driver that was busy while printk was
running when the tty code finish doing what it was doing. Now when printk
gets called it attempts to write data to all the consoles if they already
not busy. This way it only locks out one console at a time. This way
serial console doesn't have to be locked waiting for fbcon to finish
printing to the console. A semaphore in struct tty_driver is shared with
struct console. The better news is now we can use IRQ/DMA based devices
for the console system. 

		

Re: [driver] New life for Serial mice

[Vojtech P. <vo...@su...>]

On Wed, Jun 06, 2001 at 03:39:04PM -0700, James Simmons wrote:

> > > It would be nice if we had 
> > > 
> > > 1) A seperate serial directory under drivers.
> > > 
> > > 2) A nice structure that input devices and the tty layer can use. It is
> > >    just a waste to go threw the tty layer for input devices. It would also
> > >    make serial driver writing easier if the api is designed right :-) 
> > 
> > I am planning some day (don't know when yet though) to convert the 16x50
> > driver over to the serial_core stuff.
> 
> I ported it over to my tree. I will have to figure out how to incorporate
> the input serial stuff without breaking all the input drivers we have. In
> CVS we have alot of them. This will make life so much easier since all I
> will have to do is change one file for changes I make to the tty layer. I
> have improved andrew mortons console patch to work with multiple consoles
> and for different types of console devices. Instead of altering all the 
> console drivers I'm planning on intergrating the locking into the tty
> layer. That patch is needed for serial devices as well as video terminals.
> Your work might help speed up devleopement.

Sounds cute. Where do I find the result of your work?

> > NB, Ted Tytso mentioned something at the 2.5 conference about integrating
> > some of the serial layer with the tty layer.
> 
> What does he have in mind? I like to keep my VT changes in sync with what
> he has in mind.

-- 
Vojtech Pavlik
SuSE Labs

Re: [driver] New life for Serial mice

[James S. <jsi...@tr...>]

> > It would be nice if we had 
> > 
> > 1) A seperate serial directory under drivers.
> > 
> > 2) A nice structure that input devices and the tty layer can use. It is
> >    just a waste to go threw the tty layer for input devices. It would also
> >    make serial driver writing easier if the api is designed right :-) 
> 
> I am planning some day (don't know when yet though) to convert the 16x50
> driver over to the serial_core stuff.

I ported it over to my tree. I will have to figure out how to incorporate
the input serial stuff without breaking all the input drivers we have. In
CVS we have alot of them. This will make life so much easier since all I
will have to do is change one file for changes I make to the tty layer. I
have improved andrew mortons console patch to work with multiple consoles
and for different types of console devices. Instead of altering all the 
console drivers I'm planning on intergrating the locking into the tty
layer. That patch is needed for serial devices as well as video terminals.
Your work might help speed up devleopement.

> NB, Ted Tytso mentioned something at the 2.5 conference about integrating
> some of the serial layer with the tty layer.

What does he have in mind? I like to keep my VT changes in sync with what
he has in mind.

Re: Out of disk space?

[Mike A. H. <mh...@op...>]

On Tue, 5 Jun 2001, James Simmons wrote:

>Date: Tue, 5 Jun 2001 20:46:56 -0700 (PDT)
>From: James Simmons <jsi...@tr...>
>To: Linux console project <lin...@li...>
>Content-Type: TEXT/PLAIN; charset=US-ASCII
>Subject: Out of disk space?
>
>
>It appears the CVS machine has run out of disk space :-( Has anyone had
>trouble commiting stuff?

Yep it does appear so. Same problem discussed on various other
lists as well.


----------------------------------------------------------------------
    Mike A. Harris  -  Linux advocate  -  Open Source advocate
       Opinions and viewpoints expressed are solely my own.
----------------------------------------------------------------------

Out of disk space?

[James S. <jsi...@tr...>]

It appears the CVS machine has run out of disk space :-( Has anyone had
trouble commiting stuff?

Compilation errors

[Johann D. <jo...@Do...>]

Hi !

My kernel is the version 2.4.5
I get a complaint about the use of "current" in include/asm/hw_irq.h
It gets fixed if I add an #include <linux/sched.h>

I could commit this change, but as it's not in one of the files I usually
work on, I would rather leave it to someone else.
This bug looks quite obvious to me. Didn't anyone else ever encounter it
? Is it specific to my own config ?

[some time passes]

Ouch, another error: vga_lock isn't defined anywhere (according to the
linker). Looking at driver/video/vga_con.c, I see:
extern spinlock_t vga_lock;
In driver/video/vga.c:
static spinlock_t vga_lock;
^^^^^^
Is that done on purpose ?


-- 
Johann Deneux
CS student at DoCS (www.docs.uu.se/~johannd) and
ESIL (www.esil.univ-mrs.fr/~jdeneux)

Re: [SYNC] synced with 2.4.5

[Johann D. <jo...@Do...>]

Hi!

If the cvs tree now compiles well, we should tag it. I think we agreed on
that on previous mails. The point was to avoid the compilation problems we
had with 2.4.4.
Tagging this correct version would allow people to use it if we run into
trouble trying to sync the cvs tree with 2.4.6, once it's out.

-- 
Johann Deneux
CS student at DoCS (www.docs.uu.se/~johannd) and
ESIL (www.esil.univ-mrs.fr/~jdeneux)

Re: keyboard hook?

[James S. <jsi...@tr...>]

> Input API looks nice. For now, I'll write a patch against pc_keyb.c to add a 
> hook for my qoder stuff, and a loadable module for the meat of the
> driver. 

Okay. 

> Then I'll port up to the input API. 

Just send me the code and I will place it into CVS.

>I have a Sparc here; does it have drivers you wish to have ported?

Alot of work has to be done their :-/ If you are up to it I would be happy
to work with you.

Re: keyboard hook?

[James S. <jsi...@tr...>]

> Thanks, I'm loking through your driver now. Does the input api 
> already/currently support ps2 keyboards?

With the current tree no. The work around is to make input api keyboards
behave as PS/2 keyboards. In 2.5.X ps2 keyboards will be input api based. 
As you can see we already have PS/2 input api driver (i8042.c and atkbd.c). 
I have been using it for several months now. It is just a matter of making
sure it works on other platforms besides intel. 

P.S
   I also need to port other keyboard drivers on other platforms over to
the input api and test these drivers. If anyone would like to help out
contact me.

Re: keyboard hook?

[Michael R. <rot...@in...>]

Input API looks nice. For now, I'll write a patch against pc_keyb.c to add a hook for my qoder stuff, and a loadable module for the meat of the driver. Then I'll port up to the input API. The Qoder is strictly ps/2 keyboard, as far as its interface goes, so I cannot use the input API for now. I have a Sparc here; does it have drivers you wish to have ported?

On Sun, Jun 03, 2001 at 09:02:18PM -0700, James Simmons wrote:
> 
> > Thanks, I'm loking through your driver now. Does the input api 
> > already/currently support ps2 keyboards?
> 
> With the current tree no. The work around is to make input api keyboards
> behave as PS/2 keyboards. In 2.5.X ps2 keyboards will be input api based. 
> As you can see we already have PS/2 input api driver (i8042.c and atkbd.c). 
> I have been using it for several months now. It is just a matter of making
> sure it works on other platforms besides intel. 
> 
> P.S
>    I also need to port other keyboard drivers on other platforms over to
> the input api and test these drivers. If anyone would like to help out
> contact me.

Re: keyboard hook?

[Michael R. <rot...@ho...>]

Thanks, I'm loking through your driver now. Does the input api already/currently support ps2 keyboards?

-M

On Sat, Jun 02, 2001 at 08:40:04PM -0700, James Simmons wrote:
> 
> Hi!
> 
>    Your best bet for a kernel driver is to use the linux input api like
> the usb keyboard do. The drivers are pretty simple to write and since all
> the keyboard drivers will be port over to this api it will save a lot of 
> work done the road. If you need help let me know. I will be glad to help.
> It sounds alot alike the p2 to serial driver just placed in our CVS. You
> can access our CVS by doing 
> 
> cvs -d:pserver:ano...@cv...:/cvsroot/linuxconsole login
> 
> cvs -z3 -d:pserver:ano...@cv...:/cvsroot/linuxconsole co ruby
> 
> The driver is in ruby/linux/drivers/input as ps2serkbd.c.
> 
> > I'm beginning the process of writing a driver for the "Qoder"
> > keyboard-fob barcode scanner made by InterMec. It communicates with the
> > host computer using the PS/2 port by way of a "dock" that sits in
> > between the keyboard and the computer.
>  
> > One of them is "turn
> > numlock light on," which I can do with an ioctl from userspace (as root,
> > anyway), but also caps lock, num lock and carriage-return scancodes.
> 
> EV_LED
> 
> > The CueCat driver written by Pierre Coupard also modifies the keyboard
> > driver. It would be nice if it was possible to load modules that hook
> > into keyboard processing without requiring a kernel patch. And perhaps
> > there is, but I haven't run across it yet.
> 
> input api :-)
>  

Re: International support.

[James S. <jsi...@tr...>]

> keynames are a problem - there are loads missing. For example there are no
> codes for the numbers on telephone keypads. Now I know they looks like normal
> numeric keypads, but if you look closely, they are the wrong way up, so if
> you use them for navigation you need to know.

Hum. Never noticed until now. To a userland app it doesn't know direction
but it is true the user does. In this case a program is informing the user
for navigation so it have to tell the difference between what device is
being used. The app have to call EVIOCGNAME(len) to see if the type of
device is arranged this way. 

Re: keyboard hook?

[James S. <jsi...@tr...>]

Hi!

   Your best bet for a kernel driver is to use the linux input api like
the usb keyboard do. The drivers are pretty simple to write and since all
the keyboard drivers will be port over to this api it will save a lot of 
work done the road. If you need help let me know. I will be glad to help.
It sounds alot alike the p2 to serial driver just placed in our CVS. You
can access our CVS by doing 

cvs -d:pserver:ano...@cv...:/cvsroot/linuxconsole login

cvs -z3 -d:pserver:ano...@cv...:/cvsroot/linuxconsole co ruby

The driver is in ruby/linux/drivers/input as ps2serkbd.c.

> I'm beginning the process of writing a driver for the "Qoder"
> keyboard-fob barcode scanner made by InterMec. It communicates with the
> host computer using the PS/2 port by way of a "dock" that sits in
> between the keyboard and the computer.
 
> One of them is "turn
> numlock light on," which I can do with an ioctl from userspace (as root,
> anyway), but also caps lock, num lock and carriage-return scancodes.

EV_LED

> The CueCat driver written by Pierre Coupard also modifies the keyboard
> driver. It would be nice if it was possible to load modules that hook
> into keyboard processing without requiring a kernel patch. And perhaps
> there is, but I haven't run across it yet.

input api :-)
 

DMA/IRQ based hardware support.

[James S. <jsi...@tr...>]

The ruby tree has finished the moved away from using spinlocks to a
sempahore for the console lock. This means we can now have fbdev drivers
that use DMA :-) We can now write fbdev drivers using DMA. Thank you.

International support.

[James S. <jsi...@tr...>]

Hi folks!!

    I know this was going to happen later but since I got my hands on a
japanese keyboard brought back for me from japan. I figured it was time to
bring up support for these types of devices and other types of languages.
This is the last major change that will affect the lower level console
system drivers, mainly the display ones. First I like to point out the
keyboard I have is also a PS/2 keyboard. I only seen USB before. 
    I also have to figure how to use this thing. Anyone know of links to
that? The user manual was only in japanese :-( First I'm going to give it
a try with the input system. See if we have international key support for
it. Which I have to figure out which keys are the international keys. Any
help from any here please. 
    The next thing to work on as well is the keymap handling code. Now
that keyboard will be migrating to the input api we can have a universal
keymap. Another issue to discuss the the issues of key names. At present
we have 255 possible key names that can be defined. I'm discovering
working with embedded equipment they all the keys they have are called
something that we don't have. So I like to work out a new scheme to deal
with this issue. Prehaps the best thing is to have different names for the
same key value.

    
    

PS/2 => serial keyboard (fwd)

[James S. <jsi...@tr...>]

This driver has been placed in CVS. Its pretty cool. You can attach a
ordinary PS/2 keyboard to a handheld ipaq. Thank you ralf for the really
driver and link to the hardware to do this. Please keep us posted with
your developements. 

P.S 
   The linux console project is a project to rewrite the console system.
With the new console system things like multi-desktop systems are
supported. We are in the process of converting all keyboard and mice to
the linux input api. We are also reworking the framebuffer layer to allow
framebuffer devices to work without using a visual console. This allows
for micro kernels on small handheld devices.

---------- Forwarded message ----------
Date: Sat, 26 May 2001 20:56:53 +0200 (CEST)
From: Ralf Ackermann <ra...@sh...>
To: ip...@ha...
Cc: James Simmons <jsi...@tr...>, ra...@ip...
Subject: PS/2 => serial keyboard (fwd)

Hello,

i've finished the work on the ATMEL microcontroller based PS/2 to serial
converter and the Linux keyboard input driver.
	http://www.iptel-now.de/HOWTO/PS2SER/ps2ser.html

It has been successfully tested with an ordinary PS/2 keyboard, a
Twiddler2 and a Wearable Halfkeyboard (thank you, i just got this
delivered from the Matias Corporation).
It works with both a PC as well as an iPAQ running linux.

All the schematics, microcontroller and Linux code are available via the
web page. I'll try to get the Linux code be taken into the official 2.4
kernel source tree.

PS: with just 2 Laipac RF modules it can also be used wireless - that's
why i used the 1200 baud. I will check precautions against multiple
RF-attached devices in an environment though, before i announce it to be
wireless.
	http://www.iptel-now.de/HOWTO/RF_COMMUNICATION/rf_communication.html

regards
 ralf

--
Best regards,
 Ralf Ackermann