Re: AltGr key mostly fires an additional CONTROL key

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/

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/

AW: AW: AltGr key mostly fires an additional CONTROL key

[Paul Maier]

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

> 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


Hi Jon,

works fine for me. I Played around quite a while, but the CONTROL-locking didn't occur any more. Yippie!
Is it ok, if I leave the hotfix file permanently in on my PC (I mean, did you base it on a recent XWin released version with just my
bug fix in - or is there other experimental stuff inside?), then I'll use it automatically during work and I can let you know in
case of problems.

I wouldn't have started a thread with the following, but since we have already started looking at this keyboard, maybe you are
interested in some of these:

Tilde sign (~) should be a normal (not a blind) key.
  In Windows I hit AltGr+"+" to get ~, in XWin I need to type AltGr+"+" then space to get a ~.
  See attachment for the initial XWin xmodmap -pke table.
  Possible xmodmap correction (works fine):
  keycode  35 = plus asterisk plus asterisk asciitilde

Euro Currency sign doesn't work.
  I know - it's not a latin1 character, but together with CP1252 this xmodmap correction works like Windows:
  keycode  26 = e E e E 0x0080

ALT+Space produces a NBSP character (HEX A0) in Windows, but not in XWin.
  xmodmap correction is unfortunately not possible, because the xmodmap setting on ISO_Level3_Shift+Space is just thrown away:
  Something like
  keycode  65 = space NoSymbol space NoSymbol nobreakspace
  or
  keycode  65 = space space space space nobreakspace
  doesn't work: it's discarded and the setting is not shown on a "xmodmap -pke".
  So I put nobreakspace to the fifth place of another key - there it works.
  That would be good if key 65 (space key) would accept above xmodmap setting or have it initially.

Number block is not working.
  See attachment for the initial XWin xmodmap -pke table (all these KP_* settings look good at the first sight, but the keys don't
produce numbers).
  Possible xmodmap correction (works fine):
  keycode  63 = asterisk asterisk
  keycode  79 = 7 7
  keycode  80 = 8 8
  keycode  81 = 9 9
  keycode  82 = minus minus
  keycode  83 = 4 4
  keycode  84 = 5 5
  keycode  85 = 6 6
  keycode  86 = plus plus
  keycode  87 = 1 1
  keycode  88 = 2 2
  keycode  89 = 3 3
  keycode  90 = 0 0
  keycode  91 = period period
  keycode 108 = Return Return
  keycode 112 = slash slash

Regards,
  Paul


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

keycode   8 =
keycode   9 = Escape NoSymbol Escape
keycode  10 = 1 exclam 1 exclam onesuperior exclamdown onesuperior
keycode  11 = 2 quotedbl 2 quotedbl twosuperior oneeighth twosuperior
keycode  12 = 3 section 3 section threesuperior sterling threesuperior
keycode  13 = 4 dollar 4 dollar onequarter currency onequarter
keycode  14 = 5 percent 5 percent onehalf threeeighths onehalf
keycode  15 = 6 ampersand 6 ampersand notsign fiveeighths notsign
keycode  16 = 7 slash 7 slash braceleft seveneighths braceleft
keycode  17 = 8 parenleft 8 parenleft bracketleft trademark bracketleft
keycode  18 = 9 parenright 9 parenright bracketright plusminus bracketright
keycode  19 = 0 equal 0 equal braceright degree braceright
keycode  20 = ssharp question ssharp question backslash questiondown U1E9E
keycode  21 = dead_acute dead_grave dead_acute dead_grave dead_cedilla dead_ogonek dead_cedilla
keycode  22 = BackSpace NoSymbol BackSpace
keycode  23 = Tab ISO_Left_Tab Tab ISO_Left_Tab
keycode  24 = q Q q Q at Greek_OMEGA at
keycode  25 = w W w W lstroke Lstroke lstroke
keycode  26 = e E e E EuroSign EuroSign EuroSign
keycode  27 = r R r R paragraph registered paragraph
keycode  28 = t T t T tslash Tslash tslash
keycode  29 = z Z z Z leftarrow yen leftarrow
keycode  30 = u U u U downarrow uparrow downarrow
keycode  31 = i I i I rightarrow idotless rightarrow
keycode  32 = o O o O oslash Oslash oslash
keycode  33 = p P p P thorn THORN thorn
keycode  34 = udiaeresis Udiaeresis udiaeresis Udiaeresis dead_diaeresis dead_abovering dead_diaeresis
keycode  35 = plus asterisk plus asterisk dead_tilde dead_macron dead_tilde
keycode  36 = Return NoSymbol Return
keycode  37 = Control_L NoSymbol Control_L
keycode  38 = a A a A ae AE ae
keycode  39 = s S s S U017F U1E9E U017F
keycode  40 = d D d D eth ETH eth
keycode  41 = f F f F dstroke ordfeminine dstroke
keycode  42 = g G g G eng ENG eng
keycode  43 = h H h H hstroke Hstroke hstroke
keycode  44 = j J j J dead_belowdot dead_abovedot dead_belowdot
keycode  45 = k K k K kra ampersand kra
keycode  46 = l L l L lstroke Lstroke lstroke
keycode  47 = odiaeresis Odiaeresis odiaeresis Odiaeresis dead_doubleacute dead_belowdot dead_doubleacute
keycode  48 = adiaeresis Adiaeresis adiaeresis Adiaeresis dead_circumflex dead_caron dead_circumflex
keycode  49 = dead_circumflex degree dead_circumflex degree U2032 U2033 U2032
keycode  50 = Shift_L NoSymbol Shift_L
keycode  51 = numbersign apostrophe numbersign apostrophe rightsinglequotemark dead_breve rightsinglequotemark
keycode  52 = y Y y Y guillemotright U203A guillemotright
keycode  53 = x X x X guillemotleft U2039 guillemotleft
keycode  54 = c C c C cent copyright cent
keycode  55 = v V v V doublelowquotemark singlelowquotemark doublelowquotemark
keycode  56 = b B b B leftdoublequotemark leftsinglequotemark leftdoublequotemark
keycode  57 = n N n N rightdoublequotemark rightsinglequotemark rightdoublequotemark
keycode  58 = m M m M mu masculine mu
keycode  59 = comma semicolon comma semicolon periodcentered multiply periodcentered
keycode  60 = period colon period colon U2026 division U2026
keycode  61 = minus underscore minus underscore endash emdash endash
keycode  62 = Shift_R NoSymbol Shift_R
keycode  63 = KP_Multiply XF86_ClearGrab KP_Multiply XF86_ClearGrab
keycode  64 = Alt_L Meta_L Alt_L Meta_L
keycode  65 = space NoSymbol space
keycode  66 = Caps_Lock NoSymbol Caps_Lock
keycode  67 = F1 XF86_Switch_VT_1 F1 XF86_Switch_VT_1
keycode  68 = F2 XF86_Switch_VT_2 F2 XF86_Switch_VT_2
keycode  69 = F3 XF86_Switch_VT_3 F3 XF86_Switch_VT_3
keycode  70 = F4 XF86_Switch_VT_4 F4 XF86_Switch_VT_4
keycode  71 = F5 XF86_Switch_VT_5 F5 XF86_Switch_VT_5
keycode  72 = F6 XF86_Switch_VT_6 F6 XF86_Switch_VT_6
keycode  73 = F7 XF86_Switch_VT_7 F7 XF86_Switch_VT_7
keycode  74 = F8 XF86_Switch_VT_8 F8 XF86_Switch_VT_8
keycode  75 = F9 XF86_Switch_VT_9 F9 XF86_Switch_VT_9
keycode  76 = F10 XF86_Switch_VT_10 F10 XF86_Switch_VT_10
keycode  77 = Num_Lock Pointer_EnableKeys Num_Lock Pointer_EnableKeys
keycode  78 = Scroll_Lock NoSymbol Scroll_Lock
keycode  79 = KP_Home KP_7 KP_Home KP_7
keycode  80 = KP_Up KP_8 KP_Up KP_8
keycode  81 = KP_Prior KP_9 KP_Prior KP_9
keycode  82 = KP_Subtract XF86_Prev_VMode KP_Subtract XF86_Prev_VMode
keycode  83 = KP_Left KP_4 KP_Left KP_4
keycode  84 = KP_Begin KP_5 KP_Begin KP_5
keycode  85 = KP_Right KP_6 KP_Right KP_6
keycode  86 = KP_Add XF86_Next_VMode KP_Add XF86_Next_VMode
keycode  87 = KP_End KP_1 KP_End KP_1
keycode  88 = KP_Down KP_2 KP_Down KP_2
keycode  89 = KP_Next KP_3 KP_Next KP_3
keycode  90 = KP_Insert KP_0 KP_Insert KP_0
keycode  91 = KP_Delete KP_Separator KP_Delete KP_Separator
keycode  92 =
keycode  93 = Mode_switch NoSymbol Mode_switch
keycode  94 = less greater less greater bar brokenbar bar
keycode  95 = F11 XF86_Switch_VT_11 F11 XF86_Switch_VT_11
keycode  96 = F12 XF86_Switch_VT_12 F12 XF86_Switch_VT_12
keycode  97 = Home NoSymbol Home
keycode  98 = Up NoSymbol Up
keycode  99 = Prior NoSymbol Prior
keycode 100 = Left NoSymbol Left
keycode 101 =
keycode 102 = Right NoSymbol Right
keycode 103 = End NoSymbol End
keycode 104 = Down NoSymbol Down
keycode 105 = Next NoSymbol Next
keycode 106 = Insert NoSymbol Insert
keycode 107 = Delete NoSymbol Delete
keycode 108 = KP_Enter NoSymbol KP_Enter
keycode 109 = Control_R NoSymbol Control_R
keycode 110 = Pause Break Pause Break
keycode 111 = Print Sys_Req Print Sys_Req
keycode 112 = KP_Divide XF86_Ungrab KP_Divide XF86_Ungrab
keycode 113 = ISO_Level3_Shift NoSymbol ISO_Level3_Shift
keycode 114 =
keycode 115 = Super_L NoSymbol Super_L
keycode 116 = Super_R NoSymbol Super_R
keycode 117 = Menu NoSymbol Menu
keycode 118 =
keycode 119 =
keycode 120 =
keycode 121 =
keycode 122 =
keycode 123 =
keycode 124 = ISO_Level3_Shift NoSymbol ISO_Level3_Shift
keycode 125 = NoSymbol Alt_L NoSymbol Alt_L
keycode 126 = KP_Equal NoSymbol KP_Equal
keycode 127 = NoSymbol Super_L NoSymbol Super_L
keycode 128 = NoSymbol Hyper_L NoSymbol Hyper_L
keycode 129 = XF86AudioMedia NoSymbol XF86AudioMedia
keycode 130 =
keycode 131 =
keycode 132 =
keycode 133 =
keycode 134 =
keycode 135 =
keycode 136 =
keycode 137 =
keycode 138 =
keycode 139 =
keycode 140 =
keycode 141 =
keycode 142 =
keycode 143 =
keycode 144 = XF86AudioPrev NoSymbol XF86AudioPrev
keycode 145 =
keycode 146 =
keycode 147 =
keycode 148 =
keycode 149 =
keycode 150 = XF86Sleep NoSymbol XF86Sleep
keycode 151 =
keycode 152 =
keycode 153 = XF86AudioNext NoSymbol XF86AudioNext
keycode 154 =
keycode 155 =
keycode 156 = NoSymbol Meta_L NoSymbol Meta_L
keycode 157 =
keycode 158 =
keycode 159 =
keycode 160 = XF86AudioMute NoSymbol XF86AudioMute
keycode 161 = XF86Calculator NoSymbol XF86Calculator
keycode 162 = XF86AudioPlay XF86AudioPause XF86AudioPlay XF86AudioPause
keycode 163 =
keycode 164 = XF86AudioStop XF86Eject XF86AudioStop XF86Eject
keycode 165 =
keycode 166 =
keycode 167 =
keycode 168 =
keycode 169 =
keycode 170 = XF86Eject NoSymbol XF86Eject
keycode 171 =
keycode 172 =
keycode 173 =
keycode 174 = XF86AudioLowerVolume NoSymbol XF86AudioLowerVolume
keycode 175 =
keycode 176 = XF86AudioRaiseVolume NoSymbol XF86AudioRaiseVolume
keycode 177 =
keycode 178 = XF86WWW NoSymbol XF86WWW
keycode 179 =
keycode 180 =
keycode 181 =
keycode 182 =
keycode 183 =
keycode 184 =
keycode 185 =
keycode 186 =
keycode 187 =
keycode 188 =
keycode 189 =
keycode 190 =
keycode 191 =
keycode 192 =
keycode 193 =
keycode 194 =
keycode 195 =
keycode 196 =
keycode 197 =
keycode 198 =
keycode 199 =
keycode 200 =
keycode 201 =
keycode 202 =
keycode 203 =
keycode 204 = XF86Eject NoSymbol XF86Eject
keycode 205 =
keycode 206 =
keycode 207 =
keycode 208 =
keycode 209 =
keycode 210 =
keycode 211 =
keycode 212 =
keycode 213 =
keycode 214 = XF86Display NoSymbol XF86Display
keycode 215 = XF86KbdLightOnOff NoSymbol XF86KbdLightOnOff
keycode 216 = XF86KbdBrightnessDown NoSymbol XF86KbdBrightnessDown
keycode 217 = XF86KbdBrightnessUp NoSymbol XF86KbdBrightnessUp
keycode 218 =
keycode 219 =
keycode 220 =
keycode 221 =
keycode 222 = XF86PowerOff NoSymbol XF86PowerOff
keycode 223 = XF86Standby NoSymbol XF86Standby
keycode 224 =
keycode 225 =
keycode 226 =
keycode 227 = XF86WakeUp NoSymbol XF86WakeUp
keycode 228 =
keycode 229 = XF86Search NoSymbol XF86Search
keycode 230 = XF86Favorites NoSymbol XF86Favorites
keycode 231 = XF86Reload NoSymbol XF86Reload
keycode 232 = XF86Stop NoSymbol XF86Stop
keycode 233 = XF86Forward NoSymbol XF86Forward
keycode 234 = XF86Back NoSymbol XF86Back
keycode 235 = XF86MyComputer NoSymbol XF86MyComputer
keycode 236 = XF86Mail NoSymbol XF86Mail
keycode 237 = XF86AudioMedia NoSymbol XF86AudioMedia
keycode 238 =
keycode 239 =
keycode 240 =
keycode 241 =
keycode 242 =
keycode 243 =
keycode 244 = XF86Battery NoSymbol XF86Battery
keycode 245 =
keycode 246 = XF86WLAN NoSymbol XF86WLAN
keycode 247 =
keycode 248 =
keycode 249 =
keycode 250 =
keycode 251 =
keycode 252 =
keycode 253 =
keycode 254 =
keycode 255 =


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

'de' keyboard layout issues (Re: AW: AW: AltGr key mostly fires an additional CONTROL key)

[Jon TURNEY]

On 04/08/2011 03:21, Paul Maier wrote:
>> 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
>
>
> Hi Jon,
>
> works fine for me. I Played around quite a while, but the CONTROL-locking didn't occur any more. Yippie!
> Is it ok, if I leave the hotfix file permanently in on my PC (I mean, did you base it on a recent XWin released version with just my
> bug fix in - or is there other experimental stuff inside?), then I'll use it automatically during work and I can let you know in
> case of problems.

That particular build is 1.10.3-1 plus the patch for your issue.

> I wouldn't have started a thread with the following, but since we have already started looking at this keyboard, maybe you are
> interested in some of these:

A new thread would have been fine :-)

I am assuming you are using the 'de' keyboard layout:

> [ 29391,484] (--) Windows keyboard layout: "00000407" (00000407) "Deutsch", type 4
> [ 29391,484] (--) Found matching XKB configuration "German (Germany)"
> [ 29391,484] (--) Model = "pc105" Layout = "de" Variant = "none" Options = "none"
> [ 29391,484] Rules = "base" Model = "pc105" Layout = "de" Variant = "none" Options = "none"

> Tilde sign (~) should be a normal (not a blind) key.
>    In Windows I hit AltGr+"+" to get ~, in XWin I need to type AltGr+"+" then space to get a ~.
>    See attachment for the initial XWin xmodmap -pke table.
>    Possible xmodmap correction (works fine):
>    keycode  35 = plus asterisk plus asterisk asciitilde

This is a can of worms I don't want to open :-)

At the moment, in the 'de' layout, the tilde deadkey will add a macron 
diacritic, e.g. AltGr + "+" + a = ã.

I really lack the expertise to determine if this is a bug in xkeyboard-config 
(if this german keyboard behavior is something no german keyboard user would 
ever expect or want)

The xkb configurations we use come from the xkeyboard-config project, and 
aren't trying to be identical to Windows, but to conform to the appropriate 
national standards and user expectations.

However, I can see in the case of XWin this is problematic, as it will be 
confusing to switch between X and normal Windows windows which have different 
keyboard behavior.

As a workaround, you might find specifying -xkbvariant nodeadkeys, 
deadgraveacute or deadacute helpful.

> Euro Currency sign doesn't work.
>    I know - it's not a latin1 character, but together with CP1252 this xmodmap correction works like Windows:
>    keycode  26 = e E e E 0x0080

I guess this is another symptom of Xlib not understanding the de_DE.CP1252 locale.

This works fine in the de_DE.UTF-8 locale.

I suppose I could patch Xlib to fix this, but I'd rather encourage people to 
use UTF-8 locales.

> ALT+Space produces a NBSP character (HEX A0) in Windows, but not in XWin.
>    xmodmap correction is unfortunately not possible, because the xmodmap setting on ISO_Level3_Shift+Space is just thrown away:
>    Something like
>    keycode  65 = space NoSymbol space NoSymbol nobreakspace
>    or
>    keycode  65 = space space space space nobreakspace
>    doesn't work: it's discarded and the setting is not shown on a "xmodmap -pke".
>    So I put nobreakspace to the fifth place of another key - there it works.
>    That would be good if key 65 (space key) would accept above xmodmap setting or have it initially.

Reading [1], this looks like an (undocumented) Windows-ism

http://en.wikipedia.org/wiki/Non-breaking_space#Keyboard_entry_methods

> Number block is not working.
>    See attachment for the initial XWin xmodmap -pke table (all these KP_* settings look good at the first sight, but the keys don't
> produce numbers).
>    Possible xmodmap correction (works fine):
>    keycode  63 = asterisk asterisk
>    keycode  79 = 7 7
>    keycode  80 = 8 8
>    keycode  81 = 9 9
>    keycode  82 = minus minus
>    keycode  83 = 4 4
>    keycode  84 = 5 5
>    keycode  85 = 6 6
>    keycode  86 = plus plus
>    keycode  87 = 1 1
>    keycode  88 = 2 2
>    keycode  89 = 3 3
>    keycode  90 = 0 0
>    keycode  91 = period period
>    keycode 108 = Return Return
>    keycode 112 = slash slash

I can't reproduce this problem.

I wonder if this is a problem with handling numpad overlaid onto normal keys 
on a laptop keypad?  Again, -logverbose 3 output together with xev output 
would be helpful.

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

AW: 'de' keyboard layout issues (Re: AW: AW: AltGr key mostly fires an additional CONTROL key)

[Paul Maier]

Hi Jon,


1. Tilde sign
-------------

> > Tilde sign (~) should be a normal (not a blind) key.
> >    In Windows I hit AltGr+"+" to get ~, in XWin I need to type AltGr+"+" then space to
> get a ~.
> >    See attachment for the initial XWin xmodmap -pke table.
> >    Possible xmodmap correction (works fine):
> >    keycode  35 = plus asterisk plus asterisk asciitilde
> 
> This is a can of worms I don't want to open :-)
> 
> At the moment, in the 'de' layout, the tilde deadkey will add a macron
> diacritic, e.g. AltGr + "+" + a = ã.
> 
> I really lack the expertise to determine if this is a bug in xkeyboard-config
> (if this german keyboard behavior is something no german keyboard user would
> ever expect or want)
> 
> The xkb configurations we use come from the xkeyboard-config project, and
> aren't trying to be identical to Windows, but to conform to the appropriate
> national standards and user expectations.
> 
> However, I can see in the case of XWin this is problematic, as it will be
> confusing to switch between X and normal Windows windows which have different
> keyboard behavior.

I did some research: German computer keyboard layout is defined in DIN 2137-2.
And to my surprise I found, that tilde is a dead key there.
That means, that the xkeyboard-config project perfectly matches the DIN norm,
while Windows (where the key is not dead) does not match it.
So I understand, that you may want to stick to the DIN norm.
A workaround for guys like me, who want the XWin keyboard work the same like Windows,
is possible with xmodmap, so yeah ... let's close this point.


2. Euro currency sign
---------------------

> > Euro Currency sign doesn't work.
> >    I know - it's not a latin1 character, but together with CP1252 this xmodmap
> correction works like Windows:
> >    keycode  26 = e E e E 0x0080
> 
> I guess this is another symptom of Xlib not understanding the de_DE.CP1252 locale.
> This works fine in the de_DE.UTF-8 locale.

I agree to concentrate on more important stuff.


3. Non breaking space (NBSP) on ALT+space
-----------------------------------------

> > ALT+Space produces a NBSP character (HEX A0) in Windows, but not in XWin.
> >    xmodmap correction is unfortunately not possible, because the xmodmap setting on
> ISO_Level3_Shift+Space is just thrown away:
> >    Something like
> >    keycode  65 = space NoSymbol space NoSymbol nobreakspace
> >    or
> >    keycode  65 = space space space space nobreakspace
> >    doesn't work: it's discarded and the setting is not shown on a "xmodmap -pke".
> >    So I put nobreakspace to the fifth place of another key - there it works.
> >    That would be good if key 65 (space key) would accept above xmodmap setting or have
> it initially.
> 
> Reading [1], this looks like an (undocumented) Windows-ism
> 
> http://en.wikipedia.org/wiki/Non-breaking_space#Keyboard_entry_methods

I found out, that DIN 2137-2:2003-09 defines two different keyboard layouts, the one having ALT+space
undefinied (the common layout with an extra "<"/">" key left to the y key; see page 27 of that DIN norm), 
the other one defining ALT+space as NBSP (see page 9 of that DIN norm, table 2, line 1).

So it's fine, that ALT+space is undefined by default. But it wouldn't harm anybody, if
ALT+space were xmodmap redefinable, so that those guys, who got used to using ALT+space
in Windows, have a chance to xmodmap it themselves.

And: for all other keys you can xmodmap what you like on ALT+key, so why not for ALT+space?
I can easily xmodmap the NBSP onto another key, but if you try to do the same with the space key,
XWin doesn't take it:

Try xmodmapping
  keycode  65 = space NoSymbol space NoSymbol nobreakspace
    or
  keycode  65 = space space space space nobreakspace
then issue a "xmodmap -pke" ... and the NBSP is not on the space key.


4. Number block
---------------

> I can't reproduce this problem.
> 
> I wonder if this is a problem with handling numpad overlaid onto normal keys
> on a laptop keypad?  Again, -logverbose 3 output together with xev output
> would be helpful.

That was referring to plugging an external (USB) keyboard to the Laptop.
I got a new external keyboard recently.
The number block was not working with my old external keyboard, but with
the new one I can't reproduce the problem, with other words, it is working there.
Unfortunately I don't have the old keyboard any more, so I can't help you
debugging this issue. Maybe somebody else calls.


Regards,
  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: AW: 'de' keyboard layout issues (Re: AW: AW: AltGr key mostly fires an additional CONTROL key)

[Jon TURNEY]

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

On 09/08/2011 00:17, Paul Maier wrote:
> 1. Tilde sign
> -------------
>
>>> Tilde sign (~) should be a normal (not a blind) key.
>>>     In Windows I hit AltGr+"+" to get ~, in XWin I need to type AltGr+"+" then space to
>> get a ~.
>>>     See attachment for the initial XWin xmodmap -pke table.
>>>     Possible xmodmap correction (works fine):
>>>     keycode  35 = plus asterisk plus asterisk asciitilde
>>
>> This is a can of worms I don't want to open :-)

In case it wasn't clear, the can of worms here is ensuring that XWin selects a 
keyboard layout which matches the Windows one in all cases.

>> At the moment, in the 'de' layout, the tilde deadkey will add a macron
>> diacritic, e.g. AltGr + "+" + a = ã.

Obviously I meant to write 'tilde diacritic' here :-)

>> I really lack the expertise to determine if this is a bug in xkeyboard-config
>> (if this german keyboard behavior is something no german keyboard user would
>> ever expect or want)
>>
>> The xkb configurations we use come from the xkeyboard-config project, and
>> aren't trying to be identical to Windows, but to conform to the appropriate
>> national standards and user expectations.
>>
>> However, I can see in the case of XWin this is problematic, as it will be
>> confusing to switch between X and normal Windows windows which have different
>> keyboard behavior.
>
> I did some research: German computer keyboard layout is defined in DIN 2137-2.
> And to my surprise I found, that tilde is a dead key there.
> That means, that the xkeyboard-config project perfectly matches the DIN norm,
> while Windows (where the key is not dead) does not match it.
> So I understand, that you may want to stick to the DIN norm.

Usability comes before standards compliance :-)

> A workaround for guys like me, who want the XWin keyboard work the same like Windows,
> is possible with xmodmap, so yeah ... let's close this point.

Doing some more research, I found an upstream bug [1], which seems to make the 
opposite claim about DIN 2137-2(1998)

I also discovered that the nodeadkeys variant of the de layout was at one 
stage the default used by XWin when a German Windows keyboard layout was 
reported [2]

Maybe the 'correct' solution is possibly to create a 'nodeadtilde' variant of 
the de layout in xkeyboard-config, and then to arrange for that to be the 
default used by XWin when Windows reports a German keyboard layout.

Perhaps you'd like to try the attached patch to /usr/share/X11/xkb/symbols/de, 
which adds a nodeadtilde variant, which you can then select with -xkbvariant 
nodeadtilde.

Or perhaps the correct solution is to use one of the existing deadgraveacute 
or deadacute variants as the XWin default when Windows reports a German 
keyboard layout?

[1] https://bugs.freedesktop.org/show_bug.cgi?id=9752
[2] http://cygwin.com/ml/cygwin-xfree/2003-05/msg00495.html


[-- Attachment #2: de.patch --]
[-- Type: text/plain, Size: 582 bytes --]

--- de.old	2011-08-09 20:17:57.406250000 +0100
+++ de	2011-08-09 20:26:52.156250000 +0100
@@ -96,6 +96,17 @@
 };
 
 partial alphanumeric_keys
+xkb_symbols "nodeadtilde" {
+    // modify the basic German layout to not have the tilde dead key
+
+    include "de(basic)"
+
+    name[Group1]="German (nodeadtilde)";
+
+    key <AD12>	{ [      plus,   asterisk,   asciitilde,       macron ]	};
+};
+
+partial alphanumeric_keys
 xkb_symbols "ro" {
     // add romanian-specific letters to the basic German layout.
     // Romanian symbols are accessible with combination of <AltGr> and



[-- 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: 'de' keyboard layout issues (Re: AW: AW: AltGr key mostly fires an additional CONTROL key)

[Paul Maier]

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

> > 1. Tilde sign
> > -------------
> >
> >>> Tilde sign (~) should be a normal (not a blind) key.
> >>>     In Windows I hit AltGr+"+" to get ~, in XWin I need to type AltGr+"+" then space
> to
> >> get a ~.
> >>>     See attachment for the initial XWin xmodmap -pke table.
> >>>     Possible xmodmap correction (works fine):
> >>>     keycode  35 = plus asterisk plus asterisk asciitilde
> >>
> >> This is a can of worms I don't want to open :-)
> 
> In case it wasn't clear, the can of worms here is ensuring that XWin selects a
> keyboard layout which matches the Windows one in all cases.
> 
> >> At the moment, in the 'de' layout, the tilde deadkey will add a macron
> >> diacritic, e.g. AltGr + "+" + a = ã.
> 
> Obviously I meant to write 'tilde diacritic' here :-)
> 
> >> I really lack the expertise to determine if this is a bug in xkeyboard-config
> >> (if this german keyboard behavior is something no german keyboard user would
> >> ever expect or want)
> >>
> >> The xkb configurations we use come from the xkeyboard-config project, and
> >> aren't trying to be identical to Windows, but to conform to the appropriate
> >> national standards and user expectations.
> >>
> >> However, I can see in the case of XWin this is problematic, as it will be
> >> confusing to switch between X and normal Windows windows which have different
> >> keyboard behavior.
> >
> > I did some research: German computer keyboard layout is defined in DIN 2137-2.
> > And to my surprise I found, that tilde is a dead key there.
> > That means, that the xkeyboard-config project perfectly matches the DIN norm,
> > while Windows (where the key is not dead) does not match it.
> > So I understand, that you may want to stick to the DIN norm.
> 
> Usability comes before standards compliance :-)
> 
> > A workaround for guys like me, who want the XWin keyboard work the same like Windows,
> > is possible with xmodmap, so yeah ... let's close this point.
> 
> Doing some more research, I found an upstream bug [1], which seems to make the
> opposite claim about DIN 2137-2(1998)
> 
> I also discovered that the nodeadkeys variant of the de layout was at one
> stage the default used by XWin when a German Windows keyboard layout was
> reported [2]
> 
> Maybe the 'correct' solution is possibly to create a 'nodeadtilde' variant of
> the de layout in xkeyboard-config, and then to arrange for that to be the
> default used by XWin when Windows reports a German keyboard layout.
> 
> Perhaps you'd like to try the attached patch to /usr/share/X11/xkb/symbols/de,
> which adds a nodeadtilde variant, which you can then select with -xkbvariant
> nodeadtilde.
> 
> Or perhaps the correct solution is to use one of the existing deadgraveacute
> or deadacute variants as the XWin default when Windows reports a German
> keyboard layout?
> 
> [1] https://bugs.freedesktop.org/show_bug.cgi?id=9752
> [2] http://cygwin.com/ml/cygwin-xfree/2003-05/msg00495.html


Hi Jon,

thanks for your work.
I myself have made 2 patches and include them in this mail:

- One patch for files /usr/share/x11/locale/iso8859-1/Compose and
  /usr/share/x11/locale/iso8859-15/Compose.

- My patch for the "de" file:
  de.patch.patch patches your patch, whereas de.patch is the same thing
  patching the original de file.

Here is the explanation (I'm referring to the original pargraph numbering):

1. Tilde sign
-------------

Yes, file "de" patched with your de.patch and XWin invoked with "-xkbvariant nodeadtilde"
results in a German Windows keyboard (regarding the tilde).

I did just a renaming of the Group description there to match the pattern of the other
xkbvariants.

3. Non breaking space (NBSP) on ALT+space
-----------------------------------------

In my patch I provide a xkbvariant "windowscompatible", that puts nobreakspace onto Alt+Space,
like Windows has it.

Furthermore, I added a line to the default German layout.
It doesn't change the behaviour of the space key with shift, Alt, AltGr,
but (and that's the reason why I've put it there), it makes the space key
xmodmap redefinable in regard to the Alt key.
Without that patch the key definition has not enough numbers of layers,
resulting in that xmodmap discards a change of AltGr layer of space.

5. New dead acute issue
-----------------------

Sorry to say, I found another difference while testing.
This is, what the Compose.patch is for.

In Windows, all blind keys followed by a space result in that character.
Same in XWin, but with one exception:
dead-´ plus space gives ' instead of ´.

Please check out my patch for that.

Regards,
 Paul


[-- Attachment #2: Compose.patch --]
[-- Type: application/octet-stream, Size: 530 bytes --]

diff -u orig//Compose new//Compose
--- orig//Compose	2010-02-10 01:49:25.001000000 +0100
+++ new//Compose	2011-08-11 23:27:39.752691500 +0200
@@ -392,7 +392,7 @@
 <dead_grave> <space>			: "`"	grave
 <dead_grave> <dead_grave>		: "`"	grave
 # These are for us_intl, that does not have diaeresis, etc
-<dead_acute> <space>			: "'"	apostrophe
+<dead_acute> <space>			: "\264"	acute
 <dead_acute> <dead_acute>		: "\264"	acute
 <dead_diaeresis> <space>		: "\""	quotedbl
 <dead_diaeresis> <dead_diaeresis>	: "\250"	diaeresis

[-- Attachment #3: de.patch.patch --]
[-- Type: application/octet-stream, Size: 1241 bytes --]

diff -u 01-yourpatch//de 02-new//de
--- 01-yourpatch//de	2011-08-11 21:30:14.018725500 +0200
+++ 02-new//de	2011-08-12 07:41:24.551445700 +0200
@@ -51,6 +51,11 @@
     include "kpdl(comma)"
 
     include "level3(ralt_switch)"
+
+    // enable xmodmap to put a nobreakspace onto AltGr+space
+    // (Without the following line, the key <SPCE> definition is too short for xmodmap's AltGr level;
+    // for users, that don't use xmodmap, the following line is transparent.)
+    key <SPCE> { [ space, space, space, space ] };
 };
 
 partial alphanumeric_keys
@@ -105,12 +110,23 @@
 
     include "de(basic)"
 
-    name[Group1]="German (nodeadtilde)";
+    name[Group1]="Germany - nodeadtilde";
 
     key <AD12> { [      plus,   asterisk,   asciitilde,       macron ] };
 };
 
 partial alphanumeric_keys
+xkb_symbols "windowscompatible" {
+    // modify the basic German layout to match the Windows layout
+
+    include "de(nodeadtilde)"
+
+    name[Group1]="Germany - Windows";
+
+    include "nbsp(level3)"
+};
+
+partial alphanumeric_keys
 xkb_symbols "ro" {
     // add romanian-specific letters to the basic German layout.
     // Romanian symbols are accessible with combination of <AltGr> and

[-- Attachment #4: de.patch --]
[-- Type: application/octet-stream, Size: 1326 bytes --]

diff -u 00-orig//de 02-new//de
--- 00-orig//de	2010-08-03 02:28:12.001000000 +0200
+++ 02-new//de	2011-08-12 07:41:24.551445700 +0200
@@ -51,6 +51,11 @@
     include "kpdl(comma)"
 
     include "level3(ralt_switch)"
+
+    // enable xmodmap to put a nobreakspace onto AltGr+space
+    // (Without the following line, the key <SPCE> definition is too short for xmodmap's AltGr level;
+    // for users, that don't use xmodmap, the following line is transparent.)
+    key <SPCE> { [ space, space, space, space ] };
 };
 
 partial alphanumeric_keys
@@ -100,6 +105,28 @@
 };
 
 partial alphanumeric_keys
+xkb_symbols "nodeadtilde" {
+    // modify the basic German layout to not have the tilde dead key
+
+    include "de(basic)"
+
+    name[Group1]="Germany - nodeadtilde";
+
+    key <AD12> { [      plus,   asterisk,   asciitilde,       macron ] };
+};
+
+partial alphanumeric_keys
+xkb_symbols "windowscompatible" {
+    // modify the basic German layout to match the Windows layout
+
+    include "de(nodeadtilde)"
+
+    name[Group1]="Germany - Windows";
+
+    include "nbsp(level3)"
+};
+
+partial alphanumeric_keys
 xkb_symbols "ro" {
     // add romanian-specific letters to the basic German layout.
     // Romanian symbols are accessible with combination of <AltGr> and


[-- Attachment #5: 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/

Re: AW: 'de' keyboard layout issues (Re: AW: AW: AltGr key mostly fires an additional CONTROL key)

[Jon TURNEY]

On 12/08/2011 07:48, Paul Maier wrote:
>>> 1. Tilde sign
>>> -------------
>>>
>>>>> Tilde sign (~) should be a normal (not a blind) key.
>>>>>      In Windows I hit AltGr+"+" to get ~, in XWin I need to type AltGr+"+" then space
>> to
>>>> get a ~.
>>>>>      See attachment for the initial XWin xmodmap -pke table.
>>>>>      Possible xmodmap correction (works fine):
>>>>>      keycode  35 = plus asterisk plus asterisk asciitilde
>>>>
>>>> This is a can of worms I don't want to open :-)
>>
>> In case it wasn't clear, the can of worms here is ensuring that XWin selects a
>> keyboard layout which matches the Windows one in all cases.
>>
>>>> At the moment, in the 'de' layout, the tilde deadkey will add a macron
>>>> diacritic, e.g. AltGr + "+" + a = ã.
>>
>> Obviously I meant to write 'tilde diacritic' here :-)
>>
>>>> I really lack the expertise to determine if this is a bug in xkeyboard-config
>>>> (if this german keyboard behavior is something no german keyboard user would
>>>> ever expect or want)
>>>>
>>>> The xkb configurations we use come from the xkeyboard-config project, and
>>>> aren't trying to be identical to Windows, but to conform to the appropriate
>>>> national standards and user expectations.
>>>>
>>>> However, I can see in the case of XWin this is problematic, as it will be
>>>> confusing to switch between X and normal Windows windows which have different
>>>> keyboard behavior.
>>>
>>> I did some research: German computer keyboard layout is defined in DIN 2137-2.
>>> And to my surprise I found, that tilde is a dead key there.
>>> That means, that the xkeyboard-config project perfectly matches the DIN norm,
>>> while Windows (where the key is not dead) does not match it.
>>> So I understand, that you may want to stick to the DIN norm.
>>
>> Usability comes before standards compliance :-)
>>
>>> A workaround for guys like me, who want the XWin keyboard work the same like Windows,
>>> is possible with xmodmap, so yeah ... let's close this point.
>>
>> Doing some more research, I found an upstream bug [1], which seems to make the
>> opposite claim about DIN 2137-2(1998)
>>
>> I also discovered that the nodeadkeys variant of the de layout was at one
>> stage the default used by XWin when a German Windows keyboard layout was
>> reported [2]
>>
>> Maybe the 'correct' solution is possibly to create a 'nodeadtilde' variant of
>> the de layout in xkeyboard-config, and then to arrange for that to be the
>> default used by XWin when Windows reports a German keyboard layout.
>>
>> Perhaps you'd like to try the attached patch to /usr/share/X11/xkb/symbols/de,
>> which adds a nodeadtilde variant, which you can then select with -xkbvariant
>> nodeadtilde.
>>
>> Or perhaps the correct solution is to use one of the existing deadgraveacute
>> or deadacute variants as the XWin default when Windows reports a German
>> keyboard layout?
>>
>> [1] https://bugs.freedesktop.org/show_bug.cgi?id=9752
>> [2] http://cygwin.com/ml/cygwin-xfree/2003-05/msg00495.html
>
>
> Hi Jon,
>
> thanks for your work.
> I myself have made 2 patches and include them in this mail:
>
> - One patch for files /usr/share/x11/locale/iso8859-1/Compose and
>    /usr/share/x11/locale/iso8859-15/Compose.
>
> - My patch for the "de" file:
>    de.patch.patch patches your patch, whereas de.patch is the same thing
>    patching the original de file.
>
> Here is the explanation (I'm referring to the original pargraph numbering):
>
> 1. Tilde sign
> -------------
>
> Yes, file "de" patched with your de.patch and XWin invoked with "-xkbvariant nodeadtilde"
> results in a German Windows keyboard (regarding the tilde).
>
> I did just a renaming of the Group description there to match the pattern of the other
> xkbvariants.

I'd really appreciate it if you could re-open the upstream bug [1] for the 
tilde issue, ideally with a suitable patch and referencing this discussion.

I'd also suggest you send your other suggested changes to the xkb list [2], as 
I'm not really qualified to review them.

[1] https://bugs.freedesktop.org/show_bug.cgi?id=9752
[2] http://www.freedesktop.org/wiki/Software/XKeyboardConfig/Development

> 3. Non breaking space (NBSP) on ALT+space
> -----------------------------------------
>
> In my patch I provide a xkbvariant "windowscompatible", that puts nobreakspace onto Alt+Space,
> like Windows has it.
>
> Furthermore, I added a line to the default German layout.
> It doesn't change the behaviour of the space key with shift, Alt, AltGr,
> but (and that's the reason why I've put it there), it makes the space key
> xmodmap redefinable in regard to the Alt key.
> Without that patch the key definition has not enough numbers of layers,
> resulting in that xmodmap discards a change of AltGr layer of space.

It looks like the mysterious voodoo to achieve this is adding '-xkboptions 
nbsp:level3'

Perhaps that should be set by XWin by default if that is how Windows behaves 
for all keyboard layouts (so that we don't get different behavior between XWin 
windows and other Windows applications)

> 5. New dead acute issue
> -----------------------
>
> Sorry to say, I found another difference while testing.
> This is, what the Compose.patch is for.
>
> In Windows, all blind keys followed by a space result in that character.
> Same in XWin, but with one exception:
> dead-´ plus space gives ' instead of ´.
>
> Please check out my patch for that.

This patch makes sense to me, but doesn't seem to go far enough.  Since the 
compose sequences are selected by the locale, this fixes things if 
LANG=de_DE.iso8859-1 or LANG=de_DE.iso8859-15, but not if LANG=de_DE.UTF-8.

I'll try to take another look when I'm back from my holiday :-)

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

AW: AW: 'de' keyboard layout issues

[Paul Maier]

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


> > In Windows, all blind keys followed by a space result in that character.
> > Same in XWin, but with one exception:
> > dead-´ plus space gives ' instead of ´.
> >
> > Please check out my patch for that.
> [...] for files /usr/share/x11/locale/iso8859-1/Compose and
  /usr/share/x11/locale/iso8859-15/Compose.

> 
> This patch makes sense to me, but doesn't seem to go far enough.  Since the
> compose sequences are selected by the locale, this fixes things if
> LANG=de_DE.iso8859-1 or LANG=de_DE.iso8859-15, but not if LANG=de_DE.UTF-8.
> 
> I'll try to take another look when I'm back from my holiday :-)


Hi Jon,

agreed, my patch is a partial solution.

Is there an issue tracker in use, where we can put my patch and the idea behind it?

Regards,
  Paul


[-- Attachment #2: Compose.patch --]
[-- Type: application/octet-stream, Size: 532 bytes --]

diff -u orig//Compose new//Compose
--- orig//Compose	2010-02-10 01:49:25.001000000 +0100
+++ new//Compose	2011-08-11 23:27:39.752691500 +0200
@@ -392,7 +392,7 @@
 <dead_grave> <space>			: "`"	grave
 <dead_grave> <dead_grave>		: "`"	grave
 # These are for us_intl, that does not have diaeresis, etc
-<dead_acute> <space>			: "'"	apostrophe
+<dead_acute> <space>			: "\264"	acute
 <dead_acute> <dead_acute>		: "\264"	acute
 <dead_diaeresis> <space>		: "\""	quotedbl
 <dead_diaeresis> <dead_diaeresis>	: "\250"	diaeresis


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

Re: AW: AW: 'de' keyboard layout issues

[Jon TURNEY]

On 03/10/2011 12:27, Paul Maier wrote:
>>> In Windows, all blind keys followed by a space result in that character.
>>> Same in XWin, but with one exception:
>>> dead-´ plus space gives ' instead of ´.
>>>
>>> Please check out my patch for that.
>> [...] for files /usr/share/x11/locale/iso8859-1/Compose and
>   /usr/share/x11/locale/iso8859-15/Compose.
> 
>>
>> This patch makes sense to me, but doesn't seem to go far enough.  Since the
>> compose sequences are selected by the locale, this fixes things if
>> LANG=de_DE.iso8859-1 or LANG=de_DE.iso8859-15, but not if LANG=de_DE.UTF-8.
>>
>> I'll try to take another look when I'm back from my holiday :-)

Sorry, I lost track of this issue.

> agreed, my patch is a partial solution.
> 
> Is there an issue tracker in use, where we can put my patch and the idea behind it?

I would suggest you mail a patch to libX11 to the xorg-devel list [1],[2].

> agreed.
> But isn't a partial fix better than no fix?  8-)

I can't really evaluate if this change is correct or not, which is why I
suggest you take it to the xorg-devel list.

For example, after reading [3], I'm wondering if the reason for this behaviour
is that typists had the habit of pressing the acute key for an apostrophe.

On the one hand, it's been this way for at least 5 years, so people may be
used to this behaviour.  On the other hand, it's inconsistent with the rule
that <dead_foo> <space> produces <foo>, and inconsistent across locales what
this sequence produces:

jon@byron /jhbuild/checkout/xorg/lib/libX11/nls master
$ grep -r "^<dead_acute> <space>" *
el_GR.UTF-8/Compose.pre:<dead_acute> <space>                    : "΄"   U0384
en_US.UTF-8/Compose.pre:<dead_acute> <space>                    : "'"
apostrophe # APOSTROPHE
fi_FI.UTF-8/Compose.pre:<dead_acute> <space>                    : "´"   #
ACUTE ACCENT
iso8859-1/Compose.pre:<dead_acute> <space>                      : "'"   apostrophe
iso8859-14/Compose.pre:<dead_acute> <space>                     : "'"   apostrophe
iso8859-15/Compose.pre:<dead_acute> <space>                     : "'"   apostrophe
iso8859-2/Compose.pre:<dead_acute> <space>                      : "\264"
  acute
iso8859-3/Compose.pre:<dead_acute> <space>                      : "'"   apostrophe
iso8859-7/Compose.pre:<dead_acute> <space>                      : "\264"
  acute
iso8859-9/Compose.pre:<dead_acute> <space>                      : "'"   apostrophe
iso8859-9e/Compose.pre:<dead_acute> <space>                     : "'"   apostrophe
pt_BR.UTF-8/Compose.pre:<dead_acute> <space>                    : "'"   apostrophe
vi_VN.tcvn/Compose.pre:<dead_acute> <space>                     : "'"   apostrophe
vi_VN.viscii/Compose.pre:<dead_acute> <space>                   : "'"   apostrophe

[1] http://lists.x.org/mailman/listinfo/xorg-devel
[2] http://www.x.org/wiki/DeveloperStart
[3] http://www.cl.cam.ac.uk/~mgk25/ucs/apostrophe.html

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

AW: AW: 'de' keyboard layout issues

[Paul Maier]

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

> > > In Windows, all blind keys followed by a space result in that character.
> > > Same in XWin, but with one exception:
> > > dead-´ plus space gives ' instead of ´.
> > >
> > > Please check out my patch for that.
> > [...] for files /usr/share/x11/locale/iso8859-1/Compose and
>   /usr/share/x11/locale/iso8859-15/Compose.
> 
> >
> > This patch makes sense to me, but doesn't seem to go far enough.  Since the
> > compose sequences are selected by the locale, this fixes things if
> > LANG=de_DE.iso8859-1 or LANG=de_DE.iso8859-15, but not if LANG=de_DE.UTF-8.
> >
> > I'll try to take another look when I'm back from my holiday :-)
> 


 
Hi Jon,

agreed.
But isn't a partial fix better than no fix?  8-)

Regards,
  Paul


[-- Attachment #2: Compose.patch --]
[-- Type: application/octet-stream, Size: 532 bytes --]

diff -u orig//Compose new//Compose
--- orig//Compose	2010-02-10 01:49:25.001000000 +0100
+++ new//Compose	2011-08-11 23:27:39.752691500 +0200
@@ -392,7 +392,7 @@
 <dead_grave> <space>			: "`"	grave
 <dead_grave> <dead_grave>		: "`"	grave
 # These are for us_intl, that does not have diaeresis, etc
-<dead_acute> <space>			: "'"	apostrophe
+<dead_acute> <space>			: "\264"	acute
 <dead_acute> <dead_acute>		: "\264"	acute
 <dead_diaeresis> <space>		: "\""	quotedbl
 <dead_diaeresis> <dead_diaeresis>	: "\250"	diaeresis


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

Re: AW: 'de' keyboard layout issues (Re: AW: AW: AltGr key mostly fires an additional CONTROL key)

[Jon TURNEY]

On 16/08/2011 14:10, Jon TURNEY wrote:
> On 12/08/2011 07:48, Paul Maier wrote:
>> 1. Tilde sign
>> -------------
>>
>> Yes, file "de" patched with your de.patch and XWin invoked with "-xkbvariant
>> nodeadtilde"
>> results in a German Windows keyboard (regarding the tilde).
>>
>> I did just a renaming of the Group description there to match the pattern of
>> the other
>> xkbvariants.
> 
> I'd really appreciate it if you could re-open the upstream bug [1] for the
> tilde issue, ideally with a suitable patch and referencing this discussion.
> 
> I'd also suggest you send your other suggested changes to the xkb list [2], as
> I'm not really qualified to review them.
> 
> [1] https://bugs.freedesktop.org/show_bug.cgi?id=9752
> [2] http://www.freedesktop.org/wiki/Software/XKeyboardConfig/Development

xkeyboard-config bug #9752 [1] has been resolved with a change [2] to make the
tilde not a dead key in the german keyboard layout.

Perhaps you could try the lastest xkeyboard-config from git and confirm that
the change is correct :-)

If you have any other issues with the xkeyboard-config data for the german
keyboard layout, it might be more efficient to engage directly with the
xkeyboard-config maintainer, as he has a lot more expertise in this area than
I do.

[1] https://bugs.freedesktop.org/show_bug.cgi?id=9752
[2]
http://cgit.freedesktop.org/xkeyboard-config/commit/symbols/de?id=49129c6358eebd248f83457dfef4ec58ad8e584c

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

AW: AW: AltGr key mostly fires an additional CONTROL key

[Paul Maier]

> -----Ursprüngliche Nachricht-----
> > 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
> 
> 
> Hi Jon,
> 
> works fine for me. I Played around quite a while, but the CONTROL-locking didn't occur any
> more. Yippie!



Hi Jon,

regarding XWin.20110803-git-a493c0465e56ce0b.exe.bz2 on my PC fixes AltGr problem:

I wanted to ask, if that fix will be available with the next release?

Regards,
  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]

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