public inbox for cygwin-xfree@sourceware.org help / color / mirror / Atom feed
* Re: AltGr key mostly fires an additional CONTROL key @ 2011-08-15 12:53 Oliver Schmidt 2011-08-15 17:14 ` AW: " Paul Maier 2011-09-05 13:35 ` Jon TURNEY 0 siblings, 2 replies; 7+ messages in thread From: Oliver Schmidt @ 2011-08-15 12:53 UTC (permalink / raw) To: cygwin-xfree [-- 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/ ^ permalink raw reply [flat|nested] 7+ messages in thread
* AW: AltGr key mostly fires an additional CONTROL key 2011-08-15 12:53 AltGr key mostly fires an additional CONTROL key Oliver Schmidt @ 2011-08-15 17:14 ` Paul Maier 2011-08-15 17:37 ` Oliver Schmidt 2011-09-05 13:35 ` Jon TURNEY 1 sibling, 1 reply; 7+ messages in thread From: Paul Maier @ 2011-08-15 17:14 UTC (permalink / raw) To: cygwin-xfree > 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/ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: AltGr key mostly fires an additional CONTROL key 2011-08-15 17:14 ` AW: " Paul Maier @ 2011-08-15 17:37 ` Oliver Schmidt 0 siblings, 0 replies; 7+ messages in thread From: Oliver Schmidt @ 2011-08-15 17:37 UTC (permalink / raw) To: cygwin-xfree 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/ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: AltGr key mostly fires an additional CONTROL key 2011-08-15 12:53 AltGr key mostly fires an additional CONTROL key Oliver Schmidt 2011-08-15 17:14 ` AW: " Paul Maier @ 2011-09-05 13:35 ` Jon TURNEY 2011-09-06 7:45 ` Oliver Schmidt 1 sibling, 1 reply; 7+ messages in thread From: Jon TURNEY @ 2011-09-05 13:35 UTC (permalink / raw) To: cygwin-xfree; +Cc: oschmidt-mailinglists 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/ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: AltGr key mostly fires an additional CONTROL key 2011-09-05 13:35 ` Jon TURNEY @ 2011-09-06 7:45 ` Oliver Schmidt 2011-10-13 12:42 ` Jon TURNEY 0 siblings, 1 reply; 7+ messages in thread From: Oliver Schmidt @ 2011-09-06 7:45 UTC (permalink / raw) To: cygwin-xfree 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/ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: AltGr key mostly fires an additional CONTROL key 2011-09-06 7:45 ` Oliver Schmidt @ 2011-10-13 12:42 ` Jon TURNEY 0 siblings, 0 replies; 7+ messages in thread From: Jon TURNEY @ 2011-10-13 12:42 UTC (permalink / raw) To: cygwin-xfree; +Cc: oschmidt-mailinglists 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/ ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <006301cc4fb3$2696d060$73c47120$@de>]
* Re: AltGr key mostly fires an additional CONTROL key [not found] <006301cc4fb3$2696d060$73c47120$@de> @ 2011-08-01 14:57 ` Jon TURNEY [not found] ` <000001cc5085$6b711fb0$42535f10$@de> 0 siblings, 1 reply; 7+ messages in thread From: Jon TURNEY @ 2011-08-01 14:57 UTC (permalink / raw) To: cygwin-xfree 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/ ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <000001cc5085$6b711fb0$42535f10$@de>]
* Re: AW: AltGr key mostly fires an additional CONTROL key [not found] ` <000001cc5085$6b711fb0$42535f10$@de> @ 2011-08-03 13:15 ` Jon TURNEY 0 siblings, 0 replies; 7+ messages in thread From: Jon TURNEY @ 2011-08-03 13:15 UTC (permalink / raw) To: 'cygwin-xfree'; +Cc: Paul Maier >> 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/ ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2011-10-13 12:42 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-08-15 12:53 AltGr key mostly fires an additional CONTROL key Oliver Schmidt 2011-08-15 17:14 ` AW: " Paul Maier 2011-08-15 17:37 ` Oliver Schmidt 2011-09-05 13:35 ` Jon TURNEY 2011-09-06 7:45 ` Oliver Schmidt 2011-10-13 12:42 ` Jon TURNEY [not found] <006301cc4fb3$2696d060$73c47120$@de> 2011-08-01 14:57 ` Jon TURNEY [not found] ` <000001cc5085$6b711fb0$42535f10$@de> 2011-08-03 13:15 ` AW: " Jon TURNEY
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).