From mint-bounce@lists.fishpool.fi Sat Apr 2 13:31:10 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" To: Petr Stehlik Cc: Adam =?iso-8859-2?Q?K=B3obukowski?= , MiNT In-Reply-To: <1112433659.6687.2.camel@joy.home> References: <1111344400.12169.50.camel@taro.coolrunningconcepts.com> <424B0943.3000706@gabo.pl> <1112242300.10960.20.camel@taro.coolrunningconcepts.com> <424B8F47.7040803@gabo.pl> <1112294969.24071.20.camel@taro.coolrunningconcepts.com> <424C65AA.9070900@gabo.pl> <1112344790.25198.39.camel@joy.sophics> <1112394317.28763.13.camel@taro.coolrunningconcepts.com> <1112433659.6687.2.camel@joy.home> Content-Type: multipart/alternative; boundary="=-uH4vLSdmXLdqlpl4E8Kt" Organization: Cool Running Concepts Date: Sat, 02 Apr 2005 05:09:29 -0600 Message-Id: <1112440170.28763.84.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: List-unsubscribe: List-Id: X-List-ID: 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: --=-uH4vLSdmXLdqlpl4E8Kt Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable Hi Peter, By "intelligent scancodes" - I assume you mean simply changing whatever the keyboard driver returns into the english keyboard equivalent for better compatibility? I can see a couple variations on that: If, for example, the Z key generates a different scancode on the German keyboard than on a US keyboard, should the Z key scancode be translated? If so, should the existing keyboard events, and not just the new event for Key-Up/Key-Down, have this translated as well (currently there is no translation), and will that break any compatibility with either existing apps, or having different events return differnt scan-codes? Personally, I don't think it will be a problem to translate, as long as the new event for key-up/key-down is consistent with the returned scan-codes for all AES calls. The real question was if a move to 16 bit scan-codes is a good idea. I don't see the point if its not consistent with the existing AES calls. Currently the AES returns the key pressed in a 16 bit word with the scan-code in the upper 8 bits and the ascii code in the lower 8 bits. The ascii code is translated through the keyboard translation tables (can be queried or changed through Keytbl() and is dependent on modifier keys and keyboard language) but the scan-code is raw. The ascii value will be 0 if there is no ascii value for that key, and the programmer can then look at the scancode to determine which function key or undo/help/home or whatever was pressed. A few people are calling me idiots for being against a 16 bit scan-code, but I don't know where the extra 8 bits are going to be returned without breaking something, nor do I ever see a keyboard with more than 255 keys - I wouldn't buy one! No one has yet told me where this extra 8 bits is going to come from, or why a 16 bit scan-code is a good idea. With that logic, I could argue that we make scancodes a full 32 bits, and the ascii values as well. We can make the low 16 bits of the ascii portion UNICODE compatible, and the rest is in case we move to a full 32 bit character set. And the VDI (NDC) coordinate system ... 32Kx32K won't cut it for long .. maybe 64 bit floats so it scales accurately to new resolutions and very high resolution displays. Displays will hit resolutions of more than 32767 pixels across before you see a keyboard with more than 255 keys, IMHO. On Sat, 2005-04-02 at 11:20 +0200, Petr Stehlik wrote: > Evan K. Langlois p=ED=B9e v P=E1 01. 04. 2005 v 16:25 -0600: > > > > My idea is to return rather scancodes then ascii codes. Not raw=20 > > > > scancodes - it should be inteligent enough to send the same code fo= r=20 > > > > (for example) Z key, no matter what keyboard (German, UK, US) is us= ed. > > >=20 > > > This doesn't sound like a good idea to me. You'll want to stick with > > > pure scancodes and to provide a function for conversion from scancode= to > > > ASCII code... > >=20 > > The AES normally returns both. >=20 > I haven't followed the proposed extension in detail so I don't know if > it was supposed to return ASCII value as well. My main point was that > there is nothing like "intelligent scancodes" that would take the > keyboard layout into account. >=20 > Petr >=20 >=20 >=20 >=20 >=20 --=-uH4vLSdmXLdqlpl4E8Kt Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hi Peter,

By "intelligent scancodes" - I assume you mean simply changing whatever the keyboard driver returns into the english keyboard equivalent for better compatibility?   I can see a couple variations on that:

If, for example, the Z key generates a different scancode on the German keyboard than on a US keyboard, should the Z key scancode be translated?   If so, should the existing keyboard events, and not just the new event for Key-Up/Key-Down, have this translated as well (currently there is no translation), and will that break any compatibility with either existing apps, or having different events return differnt scan-codes?  Personally, I don't think it will be a problem to translate, as long as the new event for key-up/key-down is consistent with the returned scan-codes for all AES calls.

The real question was if a move to 16 bit scan-codes is a good idea.  I don't see the point if its not consistent with the existing AES calls.  Currently the AES returns the key pressed in a 16 bit word with the scan-code in the upper 8 bits and the ascii code in the lower 8 bits.  The ascii code is translated through the keyboard translation tables (can be queried or changed through Keytbl()
and is dependent on modifier keys and keyboard language) but the scan-code is raw.  The ascii value will be 0 if there is no ascii value for that key, and the programmer can then look at the scancode to determine which function key or undo/help/home or whatever was pressed.

A few people are calling me idiots for being against a 16 bit scan-code, but I don't know where the extra 8 bits are going to be returned without breaking something, nor do I ever see a keyboard with more than 255 keys - I wouldn't buy one!  No one has yet told me where this extra 8 bits is going to come from, or why a 16 bit scan-code is a good idea.

With that logic, I could argue that we make scancodes a full 32 bits, and the ascii values as well.  We can make the low 16 bits of the ascii portion UNICODE compatible, and the rest is in case we move to a full 32 bit character set.  And the VDI (NDC) coordinate system ... 32Kx32K won't cut it for long .. maybe 64 bit floats so it scales accurately to new resolutions and very high resolution displays.   Displays will hit resolutions of more than 32767 pixels across before you see a keyboard with more than 255 keys, IMHO.

On Sat, 2005-04-02 at 11:20 +0200, Petr Stehlik wrote: 
Evan K. Langlois píše v Pá 01. 04. 2005 v 16:25 -0600:
> > > My idea is to return rather scancodes then ascii codes. Not raw 
> > > scancodes - it should be inteligent enough to send the same code for 
> > > (for example) Z key, no matter what keyboard (German, UK, US) is used.
> > 
> > This doesn't sound like a good idea to me.  You'll want to stick with
> > pure scancodes and to provide a function for conversion from scancode to
> > ASCII code...
> 
> The AES normally returns both.

I haven't followed the proposed extension in detail so I don't know if
it was supposed to return ASCII value as well. My main point was that
there is nothing like "intelligent scancodes" that would take the
keyboard layout into account.

Petr
--=-uH4vLSdmXLdqlpl4E8Kt--