Re: MiNT device drivers

[Juergen Lock <nox@jelal.north.de>]

In article <memo.42385@cix.compulink.co.uk> you write:
>I'm trying to write a device driver for my new external keyboard. This is
>a DEC LK201 which outputs key scan codes on a serial interface.
>
>What the driver basically has to do is:
>
>1) read and convert DEC key scans from the serial port and make them ready
>for reading.
>
>2) take characters written to it and echo them to the console.
>
>Anyway does that sound right? Alternatively is there an easier way to do
>it without having to go to the trouble of writing a complete driver?

 well you could just use a pty...  or, take the virtual consoles, hack
daemon.c to also select() the tty where the keyboard is connected and
read & convert its input so it gets processed like input from the `real'
console.  then you can type on both and get some fast terminals to boot...
and when you get it working send me the diffs. :)

>I have half written a driver for FCON: which is suposed to duplicate the
>standard CON: device. Its main problem is that it doesn't block if there
>are no characters waiting to be read. According to The Atari Compendium,
>returning 0L from select() should cause the process to block until
>characters are available.

 well it blocks the process that called select()...  if you want reads
to block as well do a sleep(IO_Q, &tag) and wake() them at the same
place where you also wakeselect().

> I also check for blocking in ioctl() which I
>suppose should help.

 sorry what do you mean?
>
>Another thing thats not clear is how I supposed to wake up processes once
>they have been blocked. I understand I need to call wakeselect(), but where
>from? I don't see how the device driver gets any CPU time if only one
>process is using it, and its blocked. BTW I had a quick look at Thierry
>Bousch's modm0dev. There the solution seems to be an interupt routine on
>the 200ms clock. This seems a bit complicated - is it the correct solution?

 the correct solution would be to do all this from the ports receiver
interrupt handler (wake reads+selects, send signals for ^c etc...)
if you cannot do that (like you don't want to write a `real' device
driver but still call TOS/BIOS :) or it should run on kernels < 1.11)
you need some kind of daemon, either thru addroottimeout or in some
timer interrupt (depending on how time-critical your stuff is), or
an extra process...
>
>Finally, although my driver accepts characters and echos them to the console
>it seems to do it in RAW mode.eg:
>
>ls -l > /dev/fcon
>
>produces output with LFs but no CRs. Howver doing the same on /dev/con works
>fine. Am I right in assuming I should be looking up the mode of the terminal
>and doing the correct conversions?

 oh CRMOD should be the kernels job...  did your open set f->flags |= O_TTY; ?

 anyway i would just hack the virtual consoles...
	Juergen