Re: [AD] Keyboard handling

[Elias Pschernig <elias.pschernig@xxxxxxxxxx>]

On Sun, 2009-02-08 at 10:26 +0000, Colin Ward wrote:
> Hi all.
> 
> I have just been fleshing out my keyboard handling after I found that my
> driver had to do more than I expected.  There are certain things like
> capitalisation and handling of the alt and caps lock keys that a driver has
> to do that I would have thought could have been done by Allegro.
> 
> Anyway, everything is working now, except one thing.  In the allegro.txt
> documentation it gives the following example:
> 
> int val = readkey();
> 
> if ((val & 0xff) == 3)       /* ctrl+letter */
>    allegro_message("You pressed Control+C\n");
> 
> This doesn't work for me and I can't see what the driver can do to make it
> work.  Is this a problem on other platforms?  KEY_C is already 3 and
> _key_shifts has been updated with KB_CTRL_FLAG when the control key was
> pressed.  I noticed that when calling _handle_key_press() to report a key
> when alt is pressed I have to report 0 as being pressed (strange! see first
> paragraph) - is there something similar that needs to be done for control? 
> I didn't see anything obvious in the Linux source.

The value returned by readkey() & 0xff is not KEY_C, but an ascii code
of 3. A press of the "c" key is returned as ('c' + (KEY_C * 256)). If
the shift key is pressed, it would be ('C' + (KEY_C * 256)). With the
control key it would be (3 + (KEY_C * 256)).

Under Windows and Linux, pressing Ctrl+C already produces an unicode
code of 3, just as pressing Shift+C produces 'C', so those drivers don't
do anything special for it. The OSX driver does this:

      if (modifiers & NSAlternateKeyMask)
         _handle_key_press(0, scancode);
      else {
         if ((modifiers & NSControlKeyMask) && (isalpha(character)))
            _handle_key_press(tolower(character) - 'a' + 1, scancode);
	 else
            _handle_key_press(character, scancode);
      }

So, yes, for Alt+key, Allegro expects ASCII 0, for Control+a..z it
expects 1..26, and else just the ASCII code.

> Also, the examples/exkeys.c is horribly broken!  It uses the
> keyboard_lowlevel_callback function callback, the documentation for which
> explicitly says:
> 
> "This routine executes in an interrupt context"
> 
> Now I know that we don't use interrupts any more in "modern" ports, but it
> can be expected that some ports use a different thread for keyboard
> handling, which means that the same rules apply as for interrupts.  Namely,
> do as little as possible and don't call Allegro functions for drawing to
> the screen!  I spent quite a time tracking down the "bug" in my graphics
> routines, to finally realise that it was exkeys.c, not me.  I might look at
> making a patch for this.

Well, see this comment in exkeys.c:

/* Keyboard callback. We are very evil and draw to the screen from within
 * the callback. Don't do this in your own programs ;)
 */

However, Allegro's mouse cursor is updated in the same way, so there's
likely no need to 'fix' it. If exkeys breaks, then all examples using a
mouse cursor break as well.

> Multithreading on Allegro 4 is a hazy subject;

Indeed. The original DOS release used no threads, and there was a Linux
port which used signals instead of threads for a long time.

>   has there been thought put
> into making it a bit more robust in Allegro 5?
> 

Not just a bit. A5 has a threading API (with examples), uses events
instead of callbacks, uses thread local state extensively, and all A5
functions can be called from multiple threads at the same time.

-- 
Elias Pschernig <elias@xxxxxxxxxx>