Re: AltGr key mostly fires an additional CONTROL key

Re: AltGr key mostly fires an additional CONTROL key

[Oliver Schmidt]

[-- Attachment #1: Type: text/plain, Size: 839 bytes --]

Hi,

I also had problems with the AltGr key. These could reliably 
be reproduced by holding the AltGr for some seconds (causing 
Windows generating auto repeat events).

Unfortunately the test version at 

  ftp://cygwin.com/pub/cygwinx/XWin.20110801-git-2d9f9305cb559907.exe.bz2

doesn't fix this problem for me.

I discovered that the mechanism in winkeybd.c function
winIsFakeCtrl_L had a problem if PeekMessage cannot obtain 
the next Alt_R message because it is not there.

I prepared a patch that remembers the last Ctrl_L event and 
reacts on a later following Alt_R. It was also necessary to 
alter the order in winWindowProc in winwndproc.c: the invocation 
of winIsFakeCtrl_L had to be done before discarding auto-repeated
key presses.

The attached patch is against the sources of xserver-cygwin-1.10.3-1.

Best regards,
Oliver

[-- Attachment #2: diff2.txt --]
[-- Type: text/plain, Size: 3879 bytes --]

diff --git a/hw/xwin/winkeybd.c b/hw/xwin/winkeybd.c
index e807fc5..460c9d6 100644
--- a/hw/xwin/winkeybd.c
+++ b/hw/xwin/winkeybd.c
@@ -356,6 +356,12 @@ winIsFakeCtrl_L (UINT message, WPARAM wParam, LPARAM lParam)
   MSG		msgNext;
   LONG		lTime;
   Bool		fReturn;
+  
+  static Bool   hasLastControlL = FALSE;
+  static UINT   lastMessage;
+  static WPARAM lastWparam;
+  static LPARAM lastLparam;
+  static LONG   lastTime;
 
   /*
    * Fake Ctrl_L presses will be followed by an Alt_R keypress
@@ -389,9 +395,22 @@ winIsFakeCtrl_L (UINT message, WPARAM wParam, LPARAM lParam)
 				 WM_KEYDOWN, WM_SYSKEYDOWN,
 				 PM_NOREMOVE);
 	}
-      if (msgNext.message != WM_KEYDOWN && msgNext.message != WM_SYSKEYDOWN)
+      if (fReturn && msgNext.message != WM_KEYDOWN && msgNext.message != WM_SYSKEYDOWN)
           fReturn = 0;
 
+      if (!fReturn)
+        {
+          hasLastControlL = TRUE;
+          lastMessage = message;
+          lastWparam  = wParam;
+          lastLparam  = lParam;
+          lastTime    = lTime;
+        } 
+      else
+        {
+          hasLastControlL = FALSE;
+        }
+
       /* Is next press an Alt_R with the same timestamp? */
       if (fReturn && msgNext.wParam == VK_MENU
 	  && msgNext.time == lTime
@@ -406,11 +425,33 @@ winIsFakeCtrl_L (UINT message, WPARAM wParam, LPARAM lParam)
 	}
     }
 
+  /*
+   * Check for Alt_R keypress, that was not ready when the
+   * last Ctrl_L appeared.
+   */
+  else if ((message == WM_KEYDOWN || message == WM_SYSKEYDOWN)
+      && wParam == VK_MENU
+      && (HIWORD (lParam) & KF_EXTENDED))
+    {
+      if (hasLastControlL)
+        {
+          lTime = GetMessageTime ();
+          
+          if ((lastMessage == WM_KEYDOWN || lastMessage == WM_SYSKEYDOWN)
+              && lastTime == lTime)
+            {
+                /* take back the fake ctrl_L key */
+                winSendKeyEvent (KEY_LCtrl, FALSE);
+            }
+          hasLastControlL = FALSE;
+        }
+    }
+
   /* 
    * Fake Ctrl_L releases will be followed by an Alt_R release
    * with the same timestamp as the Ctrl_L release.
    */
-  if ((message == WM_KEYUP || message == WM_SYSKEYUP)
+  else if ((message == WM_KEYUP || message == WM_SYSKEYUP)
       && wParam == VK_CONTROL
       && (HIWORD (lParam) & KF_EXTENDED) == 0)
     {
@@ -439,9 +480,11 @@ winIsFakeCtrl_L (UINT message, WPARAM wParam, LPARAM lParam)
 				 PM_NOREMOVE);
 	}
 
-      if (msgNext.message != WM_KEYUP && msgNext.message != WM_SYSKEYUP)
+      if (fReturn && msgNext.message != WM_KEYUP && msgNext.message != WM_SYSKEYUP)
           fReturn = 0;
       
+    hasLastControlL = FALSE;
+
       /* Is next press an Alt_R with the same timestamp? */
       if (fReturn
 	  && (msgNext.message == WM_KEYUP
@@ -458,6 +501,10 @@ winIsFakeCtrl_L (UINT message, WPARAM wParam, LPARAM lParam)
 	  return TRUE;
 	}
     }
+  else
+    {
+      hasLastControlL = FALSE;
+    }
   
   /* Not a fake control left press/release */
   return FALSE;
diff --git a/hw/xwin/winwndproc.c b/hw/xwin/winwndproc.c
index 316cf08..7de5a5d 100644
--- a/hw/xwin/winwndproc.c
+++ b/hw/xwin/winwndproc.c
@@ -1060,6 +1060,10 @@ winWindowProc (HWND hwnd, UINT message,
       if ((wParam == VK_LWIN || wParam == VK_RWIN) && !g_fKeyboardHookLL)
 	break;
 
+      /* Discard fake Ctrl_L presses that precede AltGR on non-US keyboards */
+      if (winIsFakeCtrl_L (message, wParam, lParam))
+	return 0;
+      
       /* 
        * Discard presses generated from Windows auto-repeat
        */
@@ -1080,10 +1084,6 @@ winWindowProc (HWND hwnd, UINT message,
         }
       } 
       
-      /* Discard fake Ctrl_L presses that precede AltGR on non-US keyboards */
-      if (winIsFakeCtrl_L (message, wParam, lParam))
-	return 0;
-      
       /* Translate Windows key code to X scan code */
       winTranslateKey (wParam, lParam, &iScanCode);
 


[-- Attachment #3: Type: text/plain, Size: 223 bytes --]

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/

AW: AltGr key mostly fires an additional CONTROL key

[Paul Maier]

> Hi,
> 
> I also had problems with the AltGr key. These could reliably
> be reproduced by holding the AltGr for some seconds (causing
> Windows generating auto repeat events).
> 
> Unfortunately the test version at
> 
>   ftp://cygwin.com/pub/cygwinx/XWin.20110801-git-2d9f9305cb559907.exe.bz2
> 
> doesn't fix this problem for me.
> 
> I discovered that the mechanism in winkeybd.c function
> winIsFakeCtrl_L had a problem if PeekMessage cannot obtain
> the next Alt_R message because it is not there.
> 
> I prepared a patch that remembers the last Ctrl_L event and
> reacts on a later following Alt_R. It was also necessary to
> alter the order in winWindowProc in winwndproc.c: the invocation
> of winIsFakeCtrl_L had to be done before discarding auto-repeated
> key presses.
> 
> The attached patch is against the sources of xserver-cygwin-1.10.3-1.
> 
> Best regards,
> Oliver


Hi Oliver,

the ftp://.....exe.bz2 that you mention wasn't intended to contain any fix;
it only produces additional debug statements.

This is the one, that contains Jon's fix (works fine for me):
ftp://cygwin.com/pub/cygwinx/XWin.20110803-git-a493c0465e56ce0b.exe.bz2

Paul.



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/

Re: AltGr key mostly fires an additional CONTROL key

[Oliver Schmidt]

Hi Paul,

On 8/15/2011 7:13 PM, Paul Maier wrote:
> the ftp://.....exe.bz2 that you mention wasn't intended to contain any fix;
> it only produces additional debug statements.

sorry, for pasting the wrong link.

> This is the one, that contains Jon's fix (works fine for me):
> ftp://cygwin.com/pub/cygwinx/XWin.20110803-git-a493c0465e56ce0b.exe.bz2

to be sure I downloaded and tested this version again and it still 
doesn't fix the AltGr problem reliably.

I tested also on my older notebook which has Windows XP and only one 
core with the current official Cygwin release: no problems with AltGr at 
all. My newer notebook has Windows 7 and quadcore.

So it seems that this is a timing problem or race condition that has 
something to do with newer Windows versions and/or multi core architecture.

Best regards,
Oliver

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/

Re: AltGr key mostly fires an additional CONTROL key

[Jon TURNEY]

On 15/08/2011 13:53, Oliver Schmidt wrote:
> I also had problems with the AltGr key. These could reliably
> be reproduced by holding the AltGr for some seconds (causing
> Windows generating auto repeat events).
>
> Unfortunately the test version at
>
>    ftp://cygwin.com/pub/cygwinx/XWin.20110801-git-2d9f9305cb559907.exe.bz2
>
> doesn't fix this problem for me.
>
> I discovered that the mechanism in winkeybd.c function
> winIsFakeCtrl_L had a problem if PeekMessage cannot obtain
> the next Alt_R message because it is not there.
>
> I prepared a patch that remembers the last Ctrl_L event and
> reacts on a later following Alt_R. It was also necessary to
> alter the order in winWindowProc in winwndproc.c: the invocation
> of winIsFakeCtrl_L had to be done before discarding auto-repeated
> key presses.
>
> The attached patch is against the sources of xserver-cygwin-1.10.3-1.

Thanks for the patch.  The approach of remembering if the last keyevent was a 
Ctrl-L and reversing it if it was fake because it's followed by a AltGr is a 
good one, which hadn't occurred to me, and it clearly better than assuming the 
AltGr keyevent message will be available some fixed time after the Ctrl-L one.

(I had considered buffering the Ctrl-L keyevent until we could determine a 
AltGr wasn't going to be coming after it, but that would be more complex to 
implement)

A few comments on the patch follow.  It could also do with some better 
comments, as what this code is trying to do is slightly obscure, and I assume 
that the old comments about TweakUI being the cause of this are just wrong (as 
you don't mention that you have it installed)

> diff --git a/hw/xwin/winkeybd.c b/hw/xwin/winkeybd.c
> index e807fc5..460c9d6 100644
> --- a/hw/xwin/winkeybd.c
> +++ b/hw/xwin/winkeybd.c
> @@ -356,6 +356,12 @@ winIsFakeCtrl_L (UINT message, WPARAM wParam, LPARAM lParam)
>    MSG		msgNext;
>    LONG		lTime;
>    Bool		fReturn;
> +
> +  static Bool   hasLastControlL = FALSE;
> +  static UINT   lastMessage;
> +  static WPARAM lastWparam;
> +  static LPARAM lastLparam;
> +  static LONG   lastTime;

I was going to suggest using static  MSG lastMsg, but then I noticed that 
lastWparam, lastLparam are completely unused...

>    /*
>     * Fake Ctrl_L presses will be followed by an Alt_R keypress
> @@ -389,9 +395,22 @@ winIsFakeCtrl_L (UINT message, WPARAM wParam, LPARAM lParam)
>  				 WM_KEYDOWN, WM_SYSKEYDOWN,
>  				 PM_NOREMOVE);
>  	}
> -      if (msgNext.message != WM_KEYDOWN && msgNext.message != WM_SYSKEYDOWN)
> +      if (fReturn && msgNext.message != WM_KEYDOWN && msgNext.message != WM_SYSKEYDOWN)
>            fReturn = 0;
> +      if (!fReturn)
> +        {
> +          hasLastControlL = TRUE;
> +          lastMessage = message;
> +          lastWparam  = wParam;
> +          lastLparam  = lParam;
> +          lastTime    = lTime;
> +        }
> +      else
> +        {
> +          hasLastControlL = FALSE;
> +        }
> +
>        /* Is next press an Alt_R with the same timestamp? */
>        if (fReturn && msgNext.wParam == VK_MENU
>  	  && msgNext.time == lTime
> @@ -406,11 +425,33 @@ winIsFakeCtrl_L (UINT message, WPARAM wParam, LPARAM lParam)
>  	}
>      }
>
> +  /*
> +   * Check for Alt_R keypress, that was not ready when the
> +   * last Ctrl_L appeared.
> +   */
> +  else if ((message == WM_KEYDOWN || message == WM_SYSKEYDOWN)
> +      && wParam == VK_MENU
> +      && (HIWORD (lParam) & KF_EXTENDED))
> +    {
> +      if (hasLastControlL)
> +        {
> +          lTime = GetMessageTime ();
> +
> +          if ((lastMessage == WM_KEYDOWN || lastMessage == WM_SYSKEYDOWN)
> +              && lastTime == lTime)

Why is it necessary to check that the last message was WM_(SYS)KEYDOWN here? 
hasLastControlL can't get set unless it was?

> +            {
> +                /* take back the fake ctrl_L key */
> +                winSendKeyEvent (KEY_LCtrl, FALSE);
> +            }
> +          hasLastControlL = FALSE;
> +        }
> +    }
> +
>    /*
>     * Fake Ctrl_L releases will be followed by an Alt_R release
>     * with the same timestamp as the Ctrl_L release.
>     */
> -  if ((message == WM_KEYUP || message == WM_SYSKEYUP)
> +  else if ((message == WM_KEYUP || message == WM_SYSKEYUP)
>        && wParam == VK_CONTROL
>        && (HIWORD (lParam) & KF_EXTENDED) == 0)
>      {
> @@ -439,9 +480,11 @@ winIsFakeCtrl_L (UINT message, WPARAM wParam, LPARAM lParam)
>  				 PM_NOREMOVE);
>  	}
>
> -      if (msgNext.message != WM_KEYUP && msgNext.message != WM_SYSKEYUP)
> +      if (fReturn && msgNext.message != WM_KEYUP && msgNext.message != WM_SYSKEYUP)
>            fReturn = 0;
>
> +    hasLastControlL = FALSE;
> +
>        /* Is next press an Alt_R with the same timestamp? */
>        if (fReturn
>  	  && (msgNext.message == WM_KEYUP
> @@ -458,6 +501,10 @@ winIsFakeCtrl_L (UINT message, WPARAM wParam, LPARAM lParam)
>  	  return TRUE;
>  	}
>      }
> +  else
> +    {
> +      hasLastControlL = FALSE;
> +    }
>
>    /* Not a fake control left press/release */
>    return FALSE;
> diff --git a/hw/xwin/winwndproc.c b/hw/xwin/winwndproc.c
> index 316cf08..7de5a5d 100644
> --- a/hw/xwin/winwndproc.c
> +++ b/hw/xwin/winwndproc.c
> @@ -1060,6 +1060,10 @@ winWindowProc (HWND hwnd, UINT message,
>        if ((wParam == VK_LWIN || wParam == VK_RWIN) && !g_fKeyboardHookLL)
>  	break;
>
> +      /* Discard fake Ctrl_L presses that precede AltGR on non-US keyboards */
> +      if (winIsFakeCtrl_L (message, wParam, lParam))
> +	return 0;
> +
>        /*
>         * Discard presses generated from Windows auto-repeat
>         */
> @@ -1080,10 +1084,6 @@ winWindowProc (HWND hwnd, UINT message,
>          }
>        }
>
> -      /* Discard fake Ctrl_L presses that precede AltGR on non-US keyboards */
> -      if (winIsFakeCtrl_L (message, wParam, lParam))
> -	return 0;
> -

Can you say why it's necessary to change the order here and why this is the 
correct ordering?  A comment here might be a good idea :-)

>        /* Translate Windows key code to X scan code */
>        winTranslateKey (wParam, lParam, &iScanCode);
>
>

-- 
Jon TURNEY
Volunteer Cygwin/X X Server maintainer

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/

Re: AltGr key mostly fires an additional CONTROL key

[Oliver Schmidt]

Hi Jon,

On 9/5/2011 3:35 PM, Jon TURNEY wrote:
> comments, as what this code is trying to do is slightly obscure, and I
> assume that the old comments about TweakUI being the cause of this are
> just wrong (as you don't mention that you have it installed)

Yes I didn't test it with Tweak UI and I ignored the comments on Tweak
UI. I also think that the old "sleep(0)" workaround for Tweak UI is now
not necessary with the new patch. But I kept the changes as minimal as
possible and tried to keep existing code as much as it is.

>> diff --git a/hw/xwin/winkeybd.c b/hw/xwin/winkeybd.c
>> +  static Bool   hasLastControlL = FALSE;
>> +  static UINT   lastMessage;
>> +  static WPARAM lastWparam;
>> +  static LPARAM lastLparam;
>> +  static LONG   lastTime;
> 
> I was going to suggest using static  MSG lastMsg, but then I noticed
> that lastWparam, lastLparam are completely unused...

yes, they are now unused editing relicts from my testing phase...

>> +
>> +          if ((lastMessage == WM_KEYDOWN || lastMessage ==
>> WM_SYSKEYDOWN)
>> +              && lastTime == lTime)
> 
> Why is it necessary to check that the last message was WM_(SYS)KEYDOWN
> here? hasLastControlL can't get set unless it was?

yes you are right: the if condition here is a little over-determined ;-)


>> diff --git a/hw/xwin/winwndproc.c b/hw/xwin/winwndproc.c
>> +      /* Discard fake Ctrl_L presses that precede AltGR on non-US
>> keyboards */
>> +      if (winIsFakeCtrl_L (message, wParam, lParam))
>> +    return 0;
>> +
>> -      /* Discard fake Ctrl_L presses that precede AltGR on non-US
>> keyboards */
>> -      if (winIsFakeCtrl_L (message, wParam, lParam))
>> -    return 0;
>> -
> 
> Can you say why it's necessary to change the order here and why this is
> the correct ordering?  A comment here might be a good idea :-)

in the old coding there is this check for generated Windows auto-repeat
key events and this check can cause the function to exit:

      /*
       * Discard presses generated from Windows auto-repeat
       */
      if (lParam & (1<<30))
      {
        switch (wParam)
        {
          /* ago: Pressing LControl while RControl is pressed is
           * Indicated as repeat. Fix this!
           */
          case VK_CONTROL:
          case VK_SHIFT:
            if (winCheckKeyPressed(wParam, lParam))
              return 0;
            break;
          default:
            return 0;
        }
      }

I didn't change this coding and I'm not sure what the funtion
winCheckKeyPressed exactly does. However the check winIsFakeCtrl_L must
be done before leaving the function because of auto-repeated key events.
Otherwise there will be problems with autorepeated AltGr-Keys. These
must also be tracked with winIsFakeCtrl_L otherwise autorepeated AltGr
keys could produce a "hanging" Control_L key (I had this effect when I
tested the patch).

So the order has to be changed, because the function winIsFakeCtrl_L now
has an internal state due to it's static variables and this state has to
be synchronized with the actuel key events.

Best regards,
Oliver

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/

Re: AltGr key mostly fires an additional CONTROL key

[Jon TURNEY]

On 06/09/2011 08:44, Oliver Schmidt wrote:
> On 9/5/2011 3:35 PM, Jon TURNEY wrote:
>> comments, as what this code is trying to do is slightly obscure, and I
>> assume that the old comments about TweakUI being the cause of this are
>> just wrong (as you don't mention that you have it installed)
>
> Yes I didn't test it with Tweak UI and I ignored the comments on Tweak
> UI. I also think that the old "sleep(0)" workaround for Tweak UI is now
> not necessary with the new patch. But I kept the changes as minimal as
> possible and tried to keep existing code as much as it is.
 > ...

Thanks for the clarifications.  I decided to be a bit braver, so I reworked 
your patch a bit, added a few more comments  and removed the "sleep(0)" 
voodoo. Change is included in Cygwin/X server 1.11.1-1, thanks very much for 
your help.

[1] 
http://cgit.freedesktop.org/~jturney/xserver/commit/?h=cygwin-release-1.11&id=111ba21046b700850c5d4106d0c302d19a30e8b3

-- 
Jon TURNEY
Volunteer Cygwin/X X Server maintainer

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/

Re: AltGr key mostly fires an additional CONTROL key

[Jon TURNEY]

On 31/07/2011 19:53, Paul Maier wrote:
> Hi Jon,
>
> another issue with the keyboard on a Lenovo T60 (Windows XP) and
> Lenovo T510 (Windows 7).
>
> The AltGr key mostly fires and locks (!) an additional CONTROL key press.
> This makes the AltGr key basically inusable (and a xmodmap workaround is not
> possible).
>
> The AltGr key is a modifier key e. g. needed to get the @ sign (AltGr + Q) on a
> German keyboard.
>
>
> This is, what I found out on this issue:
> ----------------------------------------
>
> This is the output of xev when that occured. I pressed AltGR+Q once and
> released it again.
> Then (without any other modifier key pressed) I hit once a normal A.
> As you can see, instead of a @ I get a CONTROL-@ (= control character 00) and
> instead of an a I get a CONTROL-A (= control character 01).
> xev logs out very clear that there is an additionally (unwanted) KeyPress for
> key 37 = CONTROL_L.
> There is no KeyRelease for the keycode 37 = CONTROL_L in the log:
>
>
> KeyPress event, serial 23, synthetic NO, window 0xa00001,
>      root 0x101, subw 0xa00002, time 32794468, (47,57), root:(73,99),
>      state 0x10, keycode 113 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES,
>      XLookupString gives 0 bytes:
>      XFilterEvent returns: False
>
> KeyPress event, serial 23, synthetic NO, window 0xa00001,
>      root 0x101, subw 0xa00002, time 32795046, (47,57), root:(73,99),
>      state 0x90, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
>      XLookupString gives 0 bytes:
>      XFilterEvent returns: False
>
> KeyPress event, serial 23, synthetic NO, window 0xa00001,
>      root 0x101, subw 0xa00002, time 32795531, (47,57), root:(73,99),
>      state 0x94, keycode 24 (keysym 0x40, at), same_screen YES,
>      XLookupString gives 1 bytes: (00) ""
>      XFilterEvent returns: False
>
> KeyRelease event, serial 23, synthetic NO, window 0xa00001,
>      root 0x101, subw 0xa00002, time 32795640, (47,57), root:(73,99),
>      state 0x94, keycode 24 (keysym 0x40, at), same_screen YES,
>      XLookupString gives 1 bytes: (00) ""
>      XFilterEvent returns: False
>
> KeyRelease event, serial 23, synthetic NO, window 0xa00001,
>      root 0x101, subw 0xa00002, time 32798390, (47,57), root:(73,99),
>      state 0x94, keycode 113 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES,
>      XLookupString gives 0 bytes:
>      XFilterEvent returns: False
>
> KeyPress event, serial 23, synthetic NO, window 0xa00001,
>      root 0x101, subw 0xa00002, time 32799890, (47,57), root:(73,99),
>      state 0x14, keycode 38 (keysym 0x61, a), same_screen YES,
>      XLookupString gives 1 bytes: (01) ""
>      XFilterEvent returns: False
>
> KeyRelease event, serial 23, synthetic NO, window 0xa00001,
>      root 0x101, subw 0xa00002, time 32800015, (47,57), root:(73,99),
>      state 0x14, keycode 38 (keysym 0x61, a), same_screen YES,
>      XLookupString gives 1 bytes: (01) ""
>      XFilterEvent returns: False
>
>
> The ISO_Level3_Shift without the additional Control_L (left control key) would
> be the expected behaviour.
> It happens quite often (but I couldn't find the rule behind), pressing the
> AltGr ONCE also LOCKS the Control_L key in a way that if you later press a
> normal letter, say: a normal c, you get a CONTROL-C into the application.
> The Control_L (left control key) stays locked until you press the real CONTROL
> key.

>
> Meanwhile XWin.0.log logs out this:
>
> [ 32804,781] winSendKeyEvent: dwKey: 105, fDown: 1, nEvents 2
> [ 32805,984] winTranslateKey: wParam 00000011 lParam e01d0001
> [ 32805,984] winSendKeyEvent: dwKey: 29, fDown: 0, nEvents 2
> [ 32805,984] winTranslateKey: wParam 00000012 lParam c1380001
> [ 32805,984] winSendKeyEvent: dwKey: 105, fDown: 0, nEvents 2
> [ 32809,859] winTranslateKey: wParam 00000041 lParam 001e0001
> [ 32809,859] winSendKeyEvent: dwKey: 30, fDown: 1, nEvents 2
> [ 32809,968] winTranslateKey: wParam 00000041 lParam c01e0001
> [ 32809,968] winSendKeyEvent: dwKey: 30, fDown: 0, nEvents 2
>
> Key 29 seems to be the stuck control key.
> To emphasize again, I didn't press the control key on my keyboard.
> I just pressed AltGr Q (in the intention to get a @), released it again, then I
> pressed "a".

Thanks for the detailed report.

The actual issue here is that Windows apparently inserts a fake Ctrl-L 
keypress/release when AltGr is pressed/released (except when the keyboard 
layout is US).  I have never found any documentation of this behavior, and 
I've no idea why it does this.

There is some code in the X server which attempts to detect and discard these 
fake keypress/release events, but it not working reliably for some people has 
been reported a few times, but I've never been able to reproduce the problem 
or get to the bottom of what causes it.

If you are willing to help, I've put together a test build with some extra 
debugging at [1].  If you could run that with '-logverbose 3' as before and 
attach the output, that would be helpful.

[1] ftp://cygwin.com/pub/cygwinx/XWin.20110801-git-2d9f9305cb559907.exe.bz2

-- 
Jon TURNEY
Volunteer Cygwin/X X Server maintainer

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/