Path: utzoo!attcan!uunet!mcsun!ukc!harrier.ukc.ac.uk!gos.ukc.ac.uk!tkb1
From: tkb1@ukc.ac.uk (T.K.Berge)
Newsgroups: comp.os.minix
Subject: MOUSE SYSTEM
Keywords: Description of my  mouse system
Message-ID: <2675@gos.ukc.ac.uk>
Date: 7 Dec 89 16:44:26 GMT
Reply-To: tkb1@ukc.ac.uk (Tor Kristjan Berge)
Organization: Computing Lab, University of Kent at Canterbury, UK.
Lines: 75


As  I  have posted previously, I am working on a mouse-driver, and this
is how I am going to implement a mouse driver. As I promisesed then,  I
will post a more detailed description of my mouse system. 

There  is two major aims of my mouse system: MS-DOS mouse-library com-
patibility and a hardware independent mouse system (i.e. as far as the
server processed and application program is concerned) . 

    +---------------------------+
    |                           |
    |  APPLICATION PROGRAM      |
    |                           |
    +---------------------------+
        |               A    A
        |               |    :
        |               |    :
        V               |    :
    +---------+       +---------+
    |         |       |         |
    | T T Y   |       |  MOUSE  |
    |         |       |         |
    +---------+       +---------+

Basic description:
When the mouse driver detects a change in  the  status  of  the  mouse
driver  (ie. the mouse has moved or a button is pressed / released), a
signal is sent to the application program. The application program now
reads the mouse driver and updates the internal data of the mouse.  If
neccesary, the mouse cursor is moved. 

The mouse cursor movement.
After  my point of view, the mouse cursor is a natural part of the TTY
driver. I could have implemented the mouse cursor controll as  a  part
of the IOCNT system call, but that might lead to compatability clashes
with  future  version of MINIX. Instead I have choosed to use the ANSI
escape code. The ANSI escape code supports a "private mode" set of es-
cape characters, and that is what I am using. While the  compatability
clashes  with  future  development  still  is  a problem, I regard the
problem to be far less important. 

The mouse driver.
There is three problem associated with the mouse driver:
1 - Collecting information from other device drivers.
2 - Detecting a change in the status of the mouse driver.
3 - Sending a signal to the application program.

Collecting information from other device drivers.
This might be seen as an odd problem, but if a mouse system has to  be
truly hardware independent, the mouse driver might need to collect in-
formation  fro  other  device  drivers.  e.g. on a multi user computer
where the mouse is a part of the console. 

Knowing the status of the mouse.
Since the application program need to be informed if there is a change
in  the  mouse  status,  the mouse driver has send a signal to the ap-
plication program when this change occur. Some hardware interrupts when
the mouse status has changed, and in this case, there is no problem in
detecting a change. However, not all hardware has the  ability  to  do
so.  The  only  way  around  this  problem  is  to  check the hardware
regularly, i.e. the clock driver has to send a message  every  x  clock
tick. 

Sending a signal to the application program.
To send a signal to the application program, the mouse driver needs to
know the process number of the application program. A solution  is  to
let the file system extend the OPEN and CLOSE system call to the mouse
driver.  Another  problem is that more than one process might open the
mouse driver at the same time. 

Tor Kristjan Berge
Electronic Engineering Laboratory
The University
Canterbury CT2 7NF
ENGLAND