This is the mail archive of the cygwin-xfree@cygwin.com mailing list for the Cygwin XFree86 project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: AltGR problems with Windows XP


Hi Harold,

the FSM is doing something like a "lookahead". This "lookahead" is only
done when the first "Control_L press" is detected.

Normally the FSM stays in the initial state "0" and passes all input
through. So there is no real transformation.

But if the FSM detects a "Control_L press" it keeps this symbol (no
output) and memorizes this event in the state "1"

If the following input symbol is anything else but a "AltGr press", the
memorized Control_L will be prepended to the actual input symbol.
The output would be "Control_L press", "<not-a-AltGr-key> press" or
"Control_L press", "<not-a-AltGr-key> release"
The state would return to the initial state "0" (or stay in state "1" if
the following symbol was another Control_L)

Remark:
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.
The best way to prove the behaviour of the algorithm is to open the
"xev" and look at the received events.

Now, if we are in state "1", corresponding to a memorized "Control_L
press" and the following input symbol is an "AltGr press" we discard the
"Control_L press" by  sending only the "AltGr press" to the output.
The following state would be "2", memorizing that we have also to
discrard the final "Control_l release"

If we are in state "2", we are waiting for the final "Control_L
release". Getting this input symbol, we discard the "Control_L release"
and return to the initial state (0).

The state transition table shows one more state (state "3") . This state
is obsolete and can be reduced (leftover from my tests).
I will recode the FSM later.

Resulting state transition table:
input           \ state | 0 (start) | 1          |  2        |
--------------------------------------------------------------
KeyPressed-CtrlL  (PCL) |  1  -     | 1  PCL     |  2  PCL   |
KeyReleased-CtrlL (RCL) |  0  RCL   | 0  PCL,RCL |  0  -     |
KeyPressed-AltR   (PAR) |  0  PAR   | 2  PAR     |  2  PAR   |
KeyReleased-AltR  (RAR) |  0  RAR   | 0  PCL,RAR |  1  RAR   |
any other key     (*)   |  0  *     | 0  PCL,*   |  2  *     |


Andreas






JPEG image


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]