Re: [MiNT] New AES keyboard messages

[Adam Kłobukowski <atari@gabo.pl>]

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?

<cut>
> > 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