[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] New AES keyboard messages
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.
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.
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.
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.
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.
3. btw. is there an asci code for Help or Undo?
There is no ASCII code for either. The AES reports scan code of 0x62 for HELP and 0x61 for UNDO. In my proposed modification of a new KEYSTATE event, pressing HELP, you'd get the KEYSTATE event returned with 0x6200 in the key of evnt_multi, as normal, and 0x10 as the keyboard state modifier, which is currently unused. When the key was released, you'd get the same event with a 0 for the modifier.
4. With your solution we would have up to 256 keys and 8 modifiers...
More importantly - it follows the existing conventions as closely as possible, and uses 1 of the unused bits that normally shows the keyboard state of "special" keys to instead determine if the new event is a "Down" or "Up" event.
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()
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
> 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.
What?!? No it doesn't. You only get events when something changes. I never poll! Why do you think this is polling?
I know that keyboard drivers do not eat much CPU, but we should always care.
I don't understand what you are reffering to.