altGR key problem with windows XP

[Andreas Schessner]

Hello Alain and Harold,

sorry, I had a lot of work last month's and today I just returned out 
from vacation.

Harold L Hunt II wrote:

 >Alain,
 >
 >The problem with Andreas Schessner's patch was that it modified functions
 >that were not being compiled in the default build. I asked him where the
 >missing parts of the patch were, but he never responded. I don't know 
if he
 >just gave up or if he realized that his patch maybe didn't have the effect
 >that he thought it did. In any case, we no longer have a valid report of
 >that problem... if you can contact Andreas Schessner and ask him for the
 >rest of his patch, then perhaps we can get somewhere. Until then, I can
 >only assume that he made some sort of mistake and decided to keep quiet
 >about it :) Seriously, what else can I think when someone stops helping
 >to get their patch committed?
 >
 >Harold
 
Harold, that's not true.
I sent you all the modified sources and the patch worked fine for me and 
some of my friends.

Ok. Back to our AltGr problem:

First of all: I've found the reason why some "non-US-keyboards" are 
misbehaving.

The problem is due to the Microsoft PowerToys for XP (and the 
"Alt-Tab-Taskswitch")
The PowerToys are manipulating the Windows-Event-Queue.
I think they need to do this for their extended 
"Alt-Tab-Taskswitch"-Feature.
Probably they globaly catch some keyboard-events (specially the Ctrl and 
Alt events) before these are "resend" to the window with the current 
focus (with modified/actual timestamp).
So if the Ctrl and Alt events don't have the same timestamp (because the 
PowerToys manipulated/delayed these events) your current algorithm isn't 
able to detect an AltGr event.

The simpliest way to solve the problem is to deinstall the PowerToys.
(this worked for me and some other people, which contacted me directly 
after my posting in the cgwin-xfree mailing list)

If you want to keep the PowerToys or if you are using some other tool 
wich is also manipulationg your event-queue in the described manner, 
then you will have to change the AltGr-detection-algorithm.

I had a suggestion, about how it could be implemented.
The core idea of my suggestion was the implementation of an FSM (finite 
state machine) keeping track of the current state of Alt_R and Control_L.
I gave all the modified sources (win.h,  winkeybd.c, winwndproc.c) to 
Harold.
I thought he could run a diff over these files in order to to see what 
I've done and to build a patch.
I'm sorry, but I'm not (yet) familiar with open source projects.
I thought Harold didn't like my modifications because I made some more 
changes than really nescessary (I just wanted to keep it a little bit 
more modular).

So if you are really interested in my patch, contact me.
I will get the lastest sources, put in my modifications and send you the 
modified sources (and a diff ;-).
Unfortunally this will take some days, because I'm out of office till 
next week and I'm using Windows XP only on computers at work.

Andreas


Remark (out of my mail from 5.Nov.2002):
[If you use the alternate AltGr-detection]  The output of a "Control_L 
press" is delayed.
This seems to be the only weakness (IMHO) of the algorithm.
But it's not so bad as it's looking at the first sight. Normally a 
"Control_L press" key is mostly followed by another key press, which
will end the delay. In worst case another "Control_L press" caused by 
the automatic repeat capability of your keyboard will end the delay.
So the maximum delay for a "Control_L press" (for example if your are 
just holding down your left Control key) is the typmatic delay.
In all other cases (a "Control_L press" followed by any other key press 
or release) the following key breaks the delay.