From mint-bounce@lists.fishpool.fi  Fri Apr  1 04:27:52 2005
X-Original-To: fnaumann@mail.boerde.de
Delivered-To: fnaumann@mail.boerde.de
Subject: Re: [MiNT] New AES keyboard messages
From: "Evan K. Langlois" <Evan@CoolRunningConcepts.com>
To: Henk Robbers <h.robbers@chello.nl>
Cc: mint@fishpool.com
In-Reply-To: <200503312340.27237.h.robbers@chello.nl>
References: <1111344400.12169.50.camel@taro.coolrunningconcepts.com>
	 <424B0943.3000706@gabo.pl>  <200503312340.27237.h.robbers@chello.nl>
Content-Type: multipart/alternative; boundary="=-X1DQYiPAQPlASCviFKEe"
Organization: Cool Running Concepts
Date: Thu, 31 Mar 2005 20:24:56 -0600
Message-Id: <1112322296.24071.63.camel@taro.coolrunningconcepts.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.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 - [47 12] / [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.9 tagged_above=-50.5 required=7.0 tests=AWL,
 BAYES_00, HTML_MESSAGE
X-Spam-Level: 


--=-X1DQYiPAQPlASCviFKEe
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

On Thu, 2005-03-31 at 23:40 +0200, Henk Robbers wrote:


> I reserved event MU_DYNAMIC_KEYBD for it, nothing more.
> Didnt spent further thoughts about it at the time.
> Presumely it was my intention to send the event when either a key was pressed
> or released. A bit in kstate could be spent.
> 


Looks about what I just proposed, except I didn't have a nice MU_ name
for it.   Good to know I wasn't completely bonkers.


> As for detection of single press of CTRL, ALT, SHIFT:
> This requires facilitating in low level keyboard driver (IKBD).
> Normally these states are only supplied in combination with
> scancode generating keys.



I wasn't aware that those keys were handled that differently, but
changing the keyboard driver to give the information doesn't sound like
a bad idea.


> I did implement the use of NKCC by XaAES via event MU_NORMKEYBD.
> In stead of scancodes you get normalized ASCII character values.
> This might be a good place to look into.


I thought that when the AES returned a keyboard value, it returned both
the scancode and the ASCII value, and that the ASCII value was the same
as the one you would get by indexing the scancode into Keytbl().   Is
this incorrect?   What additional benefits does NKCC give you?

-- Evan

--=-X1DQYiPAQPlASCviFKEe
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/3.2.4">
</HEAD>
<BODY>
On Thu, 2005-03-31 at 23:40 +0200, Henk Robbers wrote:<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">I reserved event MU_DYNAMIC_KEYBD for it, nothing more.</FONT>
<FONT COLOR="#000000">Didnt spent further thoughts about it at the time.</FONT>
<FONT COLOR="#000000">Presumely it was my intention to send the event when either a key was pressed</FONT>
<FONT COLOR="#000000">or released. A bit in kstate could be spent.</FONT>

</PRE>
</BLOCKQUOTE>
<BR>
Looks about what I just proposed, except I didn't have a nice MU_ name for it.&nbsp;&nbsp; Good to know I wasn't completely bonkers.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">As for detection of single press of CTRL, ALT, SHIFT:</FONT>
<FONT COLOR="#000000">This requires facilitating in low level keyboard driver (IKBD).</FONT>
<FONT COLOR="#000000">Normally these states are only supplied in combination with</FONT>
<FONT COLOR="#000000">scancode generating keys.</FONT>
</PRE>
</BLOCKQUOTE>
<PRE>

</PRE>
I wasn't aware that those keys were handled that differently, but changing the keyboard driver to give the information doesn't sound like a bad idea.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">I did implement the use of NKCC by XaAES via event MU_NORMKEYBD.</FONT>
<FONT COLOR="#000000">In stead of scancodes you get normalized ASCII character values.</FONT>
<FONT COLOR="#000000">This might be a good place to look into.</FONT>
</PRE>
</BLOCKQUOTE>
<BR>
I thought that when the AES returned a keyboard value, it returned both the scancode and the ASCII value, and that the ASCII value was the same as the one you would get by indexing the scancode into Keytbl().&nbsp;&nbsp; Is this incorrect?&nbsp;&nbsp; What additional benefits does NKCC give you?<BR>
<BR>
-- Evan
</BODY>
</HTML>

--=-X1DQYiPAQPlASCviFKEe--


