From mint-bounce@lists.fishpool.fi Fri Apr 1 08:06:39 2005 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Message-ID: <424CE414.3080409@gabo.pl> Date: Fri, 01 Apr 2005 08:03:00 +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> <424C65AA.907 In-Reply-To: <1112305473.24071.53.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 j3166csX023234 Evan K. Langlois napisał(a): > On Thu, 2005-03-31 at 23:03 +0200, Adam Kłobukowski wrote: >>Why do you call that solution a hack? Is there anything unclean here? > > No, I was joking. Ok, sorry, I was answering to your post in late evening when my snese of humor was already sleeping ;) >>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. > > I was trying to find a solution that would require the minimum of > modification to current API. My suggestion was a method to return the > information you requested without breaking existing programs or changing > how evnt_multi() was presented to the user. New proposed events do not fit into the old scheme. W keep the old API the same, to not brake the old clients, and we are defining a new one for our new messages. New clients can benefit of that - and, no, in my opinion we do not ned, moreover, we should not follow the old API in every possible aspect. It should be rendered extensible. Well, yes, I think that for consistency we should use event_multi, for a consistency - and it does not limit us that much. >>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. > > Actually, the scan codes are based on key position if I remember > correctly, so Z is actually one of the ones that would be different on > different keyboards. My suggestion preserved both, exactly like the > existing API. As I already said - we should not follow the old API in every aspect. >>1. It needs different handling for different group of keys, so all >>routines must be more complicated and more CPU time hungry. > > How does it require different handling? The only ones that are treated > even slightly different is the existing control, alt, and shift keys > since they already have their own bits in the field I suggested to > overload for representing whether a key was being reported as being > pressed down or released. You need aditional condition, and fiddling with bits and stuff. With returning scancodes we do exactly the same thing, no matter what key was pressed. >>2. If we ever would want to add support for non-atari keyboards, we >>could run out of options > > If you have a keyboard with more than 256 keys, its going to break the > existing evnt_multi() and evnt_keybd() as well. Well, more thatn 256 keys on a single keyboard is hard to find, I agree. But most modern keyboards these days has some multimedia keys, or just power on/off keys, and that do not fit very well into ascii. >>with my solution he have up to 65536 keys but no modifiers, what is better? > > I've not seen your solution or how you are going to implement it and fit > it into evnt_multi() Well, this solution is still a theory - that is the reason for this discussion. >>5. You can still get ascii codes with usual (present) keyboard handling. > > Getting them both at once can be useful - use the ascii code if present, > else use the scan code As a ompromise we could return dwo words: a scancode in first, ascci + modifiers in 2nd, how do that sound? >>This involves constant poling for events, and eats CPU time. > > What?!? No it doesn't. You only get events when something changes. I > never poll! Why do you think this is polling? Ok, my mess, sorry. >>I know that keyboard drivers do not eat much CPU, but we should always care. > > I don't understand what you are reffering to. I'm trying to design it as powerfull, as extendable and as less CPU hungry as possible. -- Semper Fidelis Adam Klobukowski atari@gabo.pl