[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[MiNT] Keyboard and other IKBD handling drivers

Hi all!

I've crawled through the FreeMiNT 1.16 sources. Do it really use the ROM 
TOS Bconin() (and related functions) to get the keyboard status? I've 
found some obsolete /dev/mouse sources too.

What it that status of IKBD intercepting in FreeMiNT? What about 
/dev/keyboard, /dev/mouse and /dev/joystick?

Correct me if I'm wrong: All the device /dev/console and others is done 
via the bios_tdevice (bconout()/bconin() functions). If we create a new 
/dev/keyboard for the keyboard than e.g. the /dev/console can be rewritten 
to use it.

best regards


PS: Please read the enclosed conversation with Henk about what he would 
have like to have for XaAES. IMHO this would be a great thing for more 
than only for the XaAES. Many applications uses the NKCC and my idea was 
to write the /dev/nkcc or something similar.

Or... is there any better way to reach this?

---------- Forwarded message ----------
Date: Fri, 17 Jan 2003 23:46:10 +0100
From: Henk Robbers <h.robbers@chello.nl>
To: Standa Opichal <opichals@seznam.cz>
Subject: Re: Optional keyboard driver for XaAES
Resent-Date: Fri, 17 Jan 2003 23:51:58 +0100 (CET)
Resent-From: OpichalS@seznam.cz
Resent-To: stop@idoox.com

Standa Opichal wrote:
> Good. I just thought that it would be really good to have this in the
> system directly so that other applications might use this as well. So if I
> have some time I'll try to implement such a device (no promisses - I just
> think that it would be really worth it).

It is especially nice because it would be a real 'raw' console. Make sure you dont
do any interpretation (^C (SIGQUIT) and other disasters).

I suppose you must intercept the IKBD completely. (well, I think you must)
There is no danger; Even when XaAES crashes, MiNT will close the device cleanly.

> > Currently, to be able to supply the AES code at all, I must fselect on dev/console
> > and then issue Bconin in stead of fread. This works, but doesnt make me feel comfortable.
> Ehm, and what would be the workflow when you have the /dev/nkcc

If I fread() from device/console, I just get 1 ascii character.
Bconin() returns the keyboard status + the scancode + the ascii code in a long.
With a small rearrangement this is just what the AES needs.

snippet from XaAES

typedef union
  long bcon;    /* returned by Bconin */
    unsigned char
    state,      /* Ensure conterm bit 3 is set, so we get the keyboard status in here. */
    scan,       /* scancode */
    code;       /* ascii (if applicable */

typedef struct rawkey
  CONKEY raw;
  G_u aes,      /* AES keycode */
      norm;     /* mormalized keycode */
} KEY;

/* snippet from xaaes kernel.c */

input_channels |= 1L << C.KBD_dev; /* We are waiting on all these channels */
        (long *)&input_channels,
if (input_channels & (1L << C.KBD_dev))
{                           /* Did we get some keyboard input? */
  KEY key;
  key.raw.bcon = Bconin(2); /* Crawcin(); */
  key.aes = (key.raw.conin.scan<<8) | key.raw.conin.code; /* Translate the BIOS raw data into                                                              AES format */
  key.norm = 0;             /* filled out by nkc_tconv when needed */


What I would very much like to do in stead of Bconin:

Fread(C.KBD_dev, sizeof(KEY), &key);

if C.KBD_dev is dev/nkcc

and nothing more, so the device supplies key.norm.

Groeten; Regards.
Henk Robbers.    mailto:h.robbers@chello.nl
A free multitasking GEM for MiNT: XaAES   (heavily under construction);
Interactive disassembler:         TT-Digger;  http://digger.atari.org
A Home Cooked teXt editor:        AHCX
The free desktop:                 TERADESK