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: AW: AltGr key mostly fires an additional CONTROL key

[Jon TURNEY]

>> 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
>>
> no problem - here we go:
> The logs are attached.
>
> This is what I did:
>
> 1. /bin/startxwin -- XWin.20110801-git-2d9f9305cb559907.exe -emulate3buttons 100 -logverbose 3
> 2. It took me more attempts than usual to reproduce it, therefore the interesting part will be at the end of the log.
> 3. I manually killed the X-Server and took the log.
> 4. XWin.0.log is the full log of the session.
> 5. xev.txt: I have taken only the "interesting" part.
>
> My session in detail:
>
> I pressed several times AltGr and Q, nothing special, I get "@" (it doesn't happen always - just then and when).
> I hold down AltGr for 2 seconds ... I play around.
> Then I get into the bug:
> I press AltGr and Q, then release both keys: I get CHAR 00.
> I just hit key A and instead of "a" I get CHAR 01 = CONTROL-A.
> I just hit key C and instead of "c" I get CHAR 03 = CONTROL-C.
> Then I (first time) hit the real CONTROL key to unlock that situation. In the xev-log you see only(!) a ReleaseEvent at that point.
> Then I press AltGr and Q again and I get CHAR HEX 40 = letter "@".
> I hit key A and get "a".

Thanks for the logs, that was very useful.

I still can't reproduce this (although holding AltGr down to make it 
autorepeat seems the best way to try to do that).  It is a timing issue with 
the keypress/release messages so it might be sensitive to CPU speed, or 
perhaps you have some software installed which looks at keypress/release 
messages and changes the timing?

I've had a go at fixing it.  Can you please try the build I've uploaded at [1] 
and see if it still shows the problem for you?

[1] ftp://cygwin.com/pub/cygwinx/XWin.20110803-git-a493c0465e56ce0b.exe.bz2

--
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/