From mint-bounce@lists.fishpool.fi Thu Mar 31 23:08:25 2005 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Message-ID: <424C65AA.9070900@gabo.pl> Date: Thu, 31 Mar 2005 23:03:38 +0200 From: =?ISO-8859-2?Q?Adam_K=B3obukowski?= User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: pl, en-us, en MIME-Version: 1.0 To: "Evan K. Langlois" Cc: mint@fishpool.com Subject: Re: [MiNT] New AES keyboard messages 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> In-Reply-To: <1112294969.24071.20.camel@taro.coolrunningconcepts.com> Content-Type: text/plain; charset=ISO-8859-2; format=flowed X-AV-Checked: Gabo - system antywirusowy X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-To: mint-bounce@lists.fishpool.fi X-original-sender: atari@gabo.pl 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=-1.0 tagged_above=-50.5 required=7.0 tests=BAYES_00 X-Spam-Level: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by wh58-508.st.uni-magdeburg.de id j2VL8P9P005663 Evan K. Langlois napisał(a): > On Thu, 2005-03-31 at 07:48 +0200, Adam Kłobukowski wrote: >>That is the basic idea, but note that I wish that Shift, Control, Alt to >>be reported like other keys, so application could know that Shift, Alt, >>Control are pressed alone. > > Oh yeah. In the proposed hack^h^h^h^h "interface modification", the > KEYSTATE event would report the status of the "modifier" keys as well. > You wouldn't get the ascii equivalent, but you'd get the scancode in the > key portion and the status of the keys in the usual place, when they go > up or down. Why do you call that solution a hack? Is there anything unclean here? > For example, when CONTROL goes down, you'd get the scancode for the > control key in the upper 8 bits of the keyboard key, nothing in the > lower 8 bits since there is no ascii value and 0x04 for the keyboard > state. For Control going up, you'd get the same scancode for the key > value, but the keyboard state variable would be blank. This would > either require a couple of #define's for the scancodes of the modifier > keys to check there, or if you want to allow multiple keys at once, the > programmer might want to keep track of the previous state of the > keyboard modifier keys so you can see what transitioned. The basic idea is, that on lowest level, all keys on Atari keyboard are the same (maybe with exception of Caps Lock, but I'm unsure of that), ie, on lov level there is no difference wether we push SHIFT or R or F1 or UNDO. 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. The solution with aditional bits for modifer keyes and sending "emty" messages with modifier keys has some drawbacks: 1. It needs different handling for different group of keys, so all routines must be more complicated and more CPU time hungry. 2. If we ever would want to add support for non-atari keyboards, we could run out of options 3. btw. is there an asci code for Help or Undo? 4. With your solution we would have up to 256 keys and 8 modifiers... with my solution he have up to 65536 keys but no modifiers, what is better? 5. You can still get ascii codes with usual (present) keyboard handling. > This is basically what I used to do for mouse buttons anyway (if I > remember this correctly - its been 10 or 11 years, but its coming > back!). Instead of waiting for a specific button, toss in the last > button state, OR clicks with 0x0100 to wait for the buttons to NOT be in > that state. Then compare the returned button state with the previous > one to see which button(s) were pressed. Double and triple clicks are > returned, although hopefully only 1 button transitioned if you get more > than 1 click. This way you can get mouse click, mouse down, and mouse > up, and for all mouse buttons, basically what you want for keyboard > keys. Then before calling evnt_multi again, set the previous mouse > button state to the one that was just returned. You'd basically be > doing the same with the keyboard. This involves constant poling for events, and eats CPU time. I know that keyboard drivers do not eat much CPU, but we should always care. -- Semper Fidelis Adam Klobukowski atari@gabo.pl