UPDATE(June/24/2012): Ignore the patch in this thread.

^[1] <- UPDATE(June/23/2012)#2 yet another update, also including additional primitives dependency for modified ex_keyboard_events in respective makelist file and also clearing the state on switching back in now to address an issue in wine

UPDATE(June/23/2012) new patch also addressing 'switch away, keys stuck in state' issue now as discussed in this thread

The attached files contain a refactoring for the Windows version of al_get_keyboard_state.

The only difference to the old version here is that in this new version the function always attempts to get the actual current keyboard state rather than returning a state which might not be up to date because it was filled/maintained asynchronously by windows system events.

Disclaimer: I haven't tested whether this new version is just as fast as the old one.
It's probably a bit slower, because it needs to convert the keyboard state from the Windows format to the internal Allegro format.

I have also attached a modified ex_keyboard_events.c which will display white lines based on synchronously read keyboard states in the main window.

credits to elias and zap0 who were most helpful while I hacked this up.

The original motivation for this patch was that ALLEGRO_KEY_PAUSE state differences could not be detected between two different states acquired by al_get_keyboard_state.

It turned out they still can't be detected because not even Windows can correctly read the keystate of that key (it generates a down and an immediate up event and no repeated down events even if it is kept depressed... so in other words it is impossible to determine whether it is currently being held down at a specific moment).

1. will check, thought the ALLEGRO_KEYBOARD_STATE did not have a field for modifier keys...at least I could not find one
2. elias and I agreed not to touch the_state because it is being used elsewhere as well and that patch was only supposed to improve behavior of programs using al_get_keyboard_state directly without affecting the current event system behavior (which seems to use the_state anytime to make updates based on windows system events)
3. ok

EDIT:
In addition to 2.) the windows api call to update the state can fail, so the_state is used as a fallback return value in case it's not possible to read the real most current state.

I just tested yesterdays compiled version of my modified ex_keyboard_events again and found that all modifier keys and also extended keys like the arrow keys and numpad enter are correctly detected (you can tell by the white lines that blip up for each key which is correctly detected in a state).

I'll check if giving that key special treatment with GetAsyncKeyState or GetKeyState will allow for correct state detection.

edit:
Reading one of the other threads, I now know what you're talking about with the switch out/switch in problem and yes that could be easily fixed by clearing the state on switch out/switch in.

edit2:
Alright, I tested and debugged special GetKeystate and GetAsyncKeyState for the BREAK key. Neither is able to correctly detect the keystate.

I noticed though that Allegro treats that keypress as a so called 'dead key' and that on the windows system level, the window always gets a WM_KEYDOWN and an immediate following WM_KEYUP message for that key, regardless of its' actual physical state.

So yeah, can't ever detect that ones' state properly.

edit3:
Attached is a new patch which gets rid of the duplicate internal state and also clears the state when the window becomes inactive/loses input focus. That effectively prevents keys from getting 'stuck' in the state on switching away. see updated main post

Not an ideal solution. I does the extra work every time al_get_keyboard_state is called, once every switch in would have gotten you the same result. And just clearing the state on switch out would have done so too, for all practical uses.

Yes, if it wasn't for the fact that Allegro already maintains the keyboard state perfectly reliably in the_state. The only time it breaks is on switch in/out. I tested this for hours a few months back.

Basically, I would have replaced the whole patch with a single memset.

EDIT: Okay, and a call to update_toggle_modifiers().

EDIT2:
Also, updating the state on switch in is fine, instead of just clearing it. But doesn't need to happen more often than that. It's already taken care of.

EDIT3:

I don't think it's actually working. Does it differentiate between the two Enter keys, or are they just both mapped to ALLEGRO_KEY_ENTER? Things like that won't work, because you need more one than just the single byte to distinguish between them. And the numpad keys should map to the same ALLEGRO_KEY code independently of the state of Num Lock.

Hm, so should I revert it? I only tried it in Wine (which turned out to be pointless since Wine has an X11 bug where it messes up keyboard state itself ).

So anyway, if there's a better patch, I'll apply that instead.

I can make a new patch if you could just once more sum up a list of bullet points of what it should do.

Numpad Enter does work and sets the state flag for both the normal Enter and the Numpad Enter whereas the normal Enter only sets the state for the normal Enter and not the Numpad Enter, so if you test the state flag for Numpad Enter you can be sure that's what was pressed.

I noticed however that the number pad key states 1 to 9 do not get set if Numlock is off. The other extended key states (cursors, modifiers, etc do work).

EDIT:
As this thread is getting messy and there seem to have been a few communication problems and misunderstandings towards what the original patch was supposed to do, I made a new thread and a new patch (against latest SVN 5.1 where the other patch (rightly so) has already been reverted).
http://www.allegro.cc/forums/thread/610504

Here in X11 the pause key is just a normal key with a pressed event, then repeat events and a release event. Nothing special at all.

But since I can't test it in Windows this either means that I have a keyboard which did away with the special hardware for pause - or that only Windows adds all the special handling.