From mint-bounce@lists.fishpool.fi  Thu Jan 26 20:45:33 2006
X-Original-To: fnaumann@mail.boerde.de
Delivered-To: fnaumann@mail.boerde.de
Message-ID: <20060126123954.tpapp6bbec80csok@coolrunningconcepts.com>
Date: Thu, 26 Jan 2006 12:39:54 -0700
From: evan@coolrunningconcepts.com
To: Patrice Mandin <mandin.patrice@wanadoo.fr>
Cc: Mint list <mint@fishpool.com>
Subject: Re: [MiNT] [Q] About /dev/mouse usage
References: <20060125211820.42e71135.mandin.patrice@wanadoo.fr>
	<Pine.NEB.4.64.0601260830480.14676@wh58-508.st.uni-magdeburg.de>
	<20060126191901.19a7b4cd.mandin.patrice@wanadoo.fr>
In-Reply-To: <20060126191901.19a7b4cd.mandin.patrice@wanadoo.fr>
MIME-Version: 1.0
Content-Type: text/plain;
	charset=ISO-8859-1;
	format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) H3 (4.0.3)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - esc14.midphase.com
X-AntiAbuse: Original Domain - fishpool.com
X-AntiAbuse: Originator/Caller UID/GID - [32001 32001] / [47 12]
X-AntiAbuse: Sender Address Domain - coolrunningconcepts.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-ecartis-version: Ecartis v1.0.0
Sender: mint-bounce@lists.fishpool.fi
Errors-To: mint-bounce@lists.fishpool.fi
X-original-sender: evan@coolrunningconcepts.com
Precedence: bulk
List-help: <mailto:ecartis@lists.fishpool.fi?Subject=help>
List-unsubscribe: <mailto:mint-request@lists.fishpool.fi?Subject=unsubscribe>
List-Id: <mint.lists.fishpool.fi>
X-List-ID: <mint.lists.fishpool.fi>
X-Virus-Scanned: by amavisd-new at relay.boerde.de
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on relay.boerde.de
X-Spam-Status: No, hits=0.2 tagged_above=-50.5 required=7.0 tests=AWL,
 BAYES_00, NO_REAL_NAME
X-Spam-Level: 

Quoting Patrice Mandin <mandin.patrice@wanadoo.fr>:

> I dig into the mouse device source, and read that it uses XBIOS
> Initmous() function. It redirects the mouse vector to its routine. I
> wonder if it would be possible to call the old handler when the
> device is used, so that AES still got mouse events.

In most sane environments there is a layered approach.  Could someone please
tell me what logic has been used in the mouse handling design of XaAES?

Example ... the AES can (should) open the mouse device like anyone 
else, and the
OS can then determine if its policy is to make the mouse device a mutually
exclusive device, or send events to every process that opens it.

So .. why has the common layered approach been scrapped in favor of confusion?