Cygwin X + HP-UX 11.11 + italian keyboard = AltGr not working

Cygwin X + HP-UX 11.11 + italian keyboard = AltGr not working

[Danilo Turina]

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

Hello,
	having recently replaced my old keyboard (that had a US layout) with an 
italian one, I'm having a problem with Cygwin X when running HP-UX 
clients: AltGr does not work and this prevents me to use characters like 
"[" "{" "}" "]", etc.

I'm up to date with Cygwin and Cygwin X at the moment ("1.7.9(0.237/5/3) 
2011-03-29 10:10 i686 Cygwin" for Cygwin and "1.10.2.0" for XWin).

These are the steps to reproduce the problem:

	1) start Cygwin X
	2) disable access control ("xhost +")
	3) access via telnet/ssh a HP-UX machine
	4) open an xterm from the HP-UX machine in Cygwin X
	5) in the newly opened xterm try to use AltGr (AltGr + "è" (i.e. the 
key at the right of "P"), should produce "{", while AltGr + Shift + "è" 
should produce "{")
	6) fall on the floor crying in desperation

Notice that when using a client from a Linux machine all works properly.

A googled a lot and found a lot of information but only few of it 
applied (=helped) to my specific case. I tried to mess with xmodmap and 
kbd config files and also with other stuff, but nothing seemed to solve 
the problem.

At the moment I'm using Xming 6.9.0.31 that doesn't seem affected by the 
problem IF I set XKB_DISABLE=1 on the client machine (i.e. HP-UX).

Trying to troubleshoot the problem, I used xev on the HP-UX machine to 
see if the keys were properly recognized and, in effect, they are.
This are xev results for Cygwin X, when I press (and release) AltGr+è 
(thus by trying to get "[") with XKB_DISABLED not set:

KeyPress event, serial 19, synthetic NO, window 0x400001,
     root 0x101, subw 0x0, time 697269421, (167,-13), root:(345,181),
     state 0x0, keycode 113 (keysym 0xfe03, ISO_Level3_Shift), 
same_screen YES,
     XLookupString gives 0 bytes:
     XFilterEvent returns: False

KeyPress event, serial 22, synthetic NO, window 0x400001,
     root 0x101, subw 0x0, time 697269703, (167,-13), root:(345,181),
     state 0x80, keycode 34 (keysym 0x5b, bracketleft), same_screen YES,
     XKeysymToKeycode returns keycode: 17
     XLookupString gives 1 bytes: (5b) "["
     XFilterEvent returns: False

KeyRelease event, serial 22, synthetic NO, window 0x400001,
     root 0x101, subw 0x0, time 697269750, (167,-13), root:(345,181),
     state 0x80, keycode 34 (keysym 0x5b, bracketleft), same_screen YES,
     XKeysymToKeycode returns keycode: 17
     XLookupString gives 1 bytes: (5b) "["
     XFilterEvent returns: False

KeyRelease event, serial 22, synthetic NO, window 0x400001,
     root 0x101, subw 0x0, time 697269890, (167,-13), root:(345,181),
     state 0x80, keycode 113 (keysym 0xfe03, ISO_Level3_Shift), 
same_screen YES,
     XLookupString gives 0 bytes:
     XFilterEvent returns: False


If I set XKB_DISABLED=1, I get, instead:


KeyPress event, serial 18, synthetic NO, window 0xc00001,
     root 0x101, subw 0x0, time 697070562, (170,-9), root:(216,53),
     state 0x0, keycode 113 (keysym 0xfe03, ISO_Level3_Shift), 
same_screen YES,
     XLookupString gives 0 bytes:
     XFilterEvent returns: False

KeyPress event, serial 18, synthetic NO, window 0xc00001,
     root 0x101, subw 0x0, time 697071250, (170,-9), root:(216,53),
     state 0x80, keycode 34 (keysym 0xe8, egrave), same_screen YES,
     XLookupString gives 1 bytes: (e8) "è"
     XFilterEvent returns: False

KeyRelease event, serial 18, synthetic NO, window 0xc00001,
     root 0x101, subw 0x0, time 697071312, (170,-9), root:(216,53),
     state 0x80, keycode 34 (keysym 0xe8, egrave), same_screen YES,
     XLookupString gives 1 bytes: (e8) "è"
     XFilterEvent returns: False

KeyRelease event, serial 18, synthetic NO, window 0xc00001,
     root 0x101, subw 0x0, time 697071390, (170,-9), root:(216,53),
     state 0x80, keycode 113 (keysym 0xfe03, ISO_Level3_Shift), 
same_screen YES,
     XLookupString gives 0 bytes:
     XFilterEvent returns: False


If I try xev on Xming with XKB_DISABLED=1 (where I have no problem at 
all), I get:

KeyPress event, serial 16, synthetic NO, window 0xa00001,
     root 0x5a, subw 0x0, time 696970906, (79,-9), root:(213,144),
     state 0x0, keycode 113 (keysym 0xfe03, ISO_Level3_Shift), 
same_screen YES,
     XLookupString gives 0 bytes:
     XFilterEvent returns: False

KeyPress event, serial 18, synthetic NO, window 0xa00001,
     root 0x5a, subw 0x0, time 696971078, (79,-9), root:(213,144),
     state 0x80, keycode 34 (keysym 0x5b, bracketleft), same_screen YES,
     XKeysymToKeycode returns keycode: 17
     XLookupString gives 1 bytes: (5b) "["
     XFilterEvent returns: False

KeyRelease event, serial 18, synthetic NO, window 0xa00001,
     root 0x5a, subw 0x0, time 696971140, (79,-9), root:(213,144),
     state 0x80, keycode 34 (keysym 0x5b, bracketleft), same_screen YES,
     XKeysymToKeycode returns keycode: 17
     XLookupString gives 1 bytes: (5b) "["
     XFilterEvent returns: False

KeyRelease event, serial 18, synthetic NO, window 0xa00001,
     root 0x5a, subw 0x0, time 696971250, (79,-9), root:(213,144),
     state 0x80, keycode 113 (keysym 0xfe03, ISO_Level3_Shift), 
same_screen YES,
     XLookupString gives 0 bytes:
     XFilterEvent returns: False

One strange thing that I noticed is that if I start Cygwin X by using 
"startxwin" from the Cygwin's command line, I get the following warning 
on screen:

(--) 3 mouse buttons found
(--) Setting autorepeat to delay=500, rate=31
(--) Windows keyboard layout: "00000410" (00000410) "Italian", type 4
(--) Found matching XKB configuration "Italian"
(--) Model = "pc105" Layout = "it" Variant = "none" Options = "none"
Rules = "base" Model = "pc105" Layout = "it" Variant = "none" Options = 
"none"
The XKEYBOARD keymap compiler (xkbcomp) reports:
 > Warning:          Type "ONE_LEVEL" has 1 levels, but <RALT> has 2 symbols
 >                   Ignoring extra symbols

But that warning is not present in XWin.0.log (attached).

Any suggestion about this problem or about any procedure to diagnose it 
properly?

Thank you,
	Danilo Turina

-- 
DANILO TURINA
ALCATEL-LUCENT
Software Analyst
NM System Team
Network-Optics
Rieti (Italy)
Phone: +39 0746 600332

10 anni 2 mesi 26 giorni 23 ore 59 minuti 7 secondi

[-- Attachment #2: XWin.0.log --]
[-- Type: text/plain, Size: 3997 bytes --]

Welcome to the XWin X Server
Vendor: The Cygwin/X Project
Release: 1.10.2.0
OS: Windows XP Service Pack 3 [Windows NT 5.1 build 2600] (Win32)
Package: version 1.10.2-1 built 2011-06-28

XWin was started with the following command line:

X :0 -multiwindow 

ddxProcessArgument - Initializing default screens
winInitializeScreenDefaults - primary monitor w 1280 h 1024
winInitializeDefaultScreens - native DPI x 96 y 96
_XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6
_XSERVTransOpen: transport open failed for inet6/MYMACHINE:0
_XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6
[697886.250] (II) xorg.conf is not supported
[697886.250] (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information
[697886.250] LoadPreferences: Loading /home/dturina/.XWinrc
[697886.250] LoadPreferences: Done parsing the configuration file...
[697886.250] winDetectSupportedEngines - DirectDraw installed, allowing ShadowDD
[697886.250] winDetectSupportedEngines - Windows NT, allowing PrimaryDD
[697886.250] winDetectSupportedEngines - DirectDraw4 installed, allowing ShadowDDNL
[697886.250] winDetectSupportedEngines - Returning, supported engines 0000001f
[697886.250] winSetEngine - Multi Window or Rootless => ShadowGDI
[697886.250] winScreenInit - Using Windows display depth of 32 bits per pixel
[697886.265] winAllocateFBShadowGDI - Creating DIB with width: 1280 height: 1024 depth: 32
[697886.265] winFinishScreenInitFB - Masks: 00ff0000 0000ff00 000000ff
[697886.265] winInitVisualsShadowGDI - Masks 00ff0000 0000ff00 000000ff BPRGB 8 d 24 bpp 32
[697886.265] winInitMultiWindowWM - Calling pthread_mutex_lock ()
[697886.265] winMultiWindowXMsgProc - Calling pthread_mutex_lock ()
[697886.265] Screen 0 added at virtual desktop coordinate (0,0).
[697886.281] MIT-SHM extension disabled due to lack of kernel support
[697886.296] XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in the kernel
[697886.593] (II) AIGLX: Loaded and initialized /usr/lib/dri/swrast_dri.so
[697886.593] (II) GLX: Initialized DRISWRAST GL provider for screen 0
[697887.500] winPointerWarpCursor - Discarding first warp: 640 512
[697887.500] (--) 3 mouse buttons found
[697887.500] (--) Setting autorepeat to delay=500, rate=31
[697887.500] (--) Windows keyboard layout: "00000410" (00000410) "Italian", type 4
[697887.500] (--) Found matching XKB configuration "Italian"
[697887.500] (--) Model = "pc105" Layout = "it" Variant = "none" Options = "none"
[697887.500] Rules = "base" Model = "pc105" Layout = "it" Variant = "none" Options = "none"
[697888.234] winBlockHandler - pthread_mutex_unlock()
[697888.234] winInitMultiWindowWM - pthread_mutex_lock () returned.
[697888.234] winInitMultiWindowWM - pthread_mutex_unlock () returned.
[697888.234] winMultiWindowXMsgProc - pthread_mutex_lock () returned.
[697888.234] winInitMultiWindowWM - DISPLAY=:0.0
[697888.234] winMultiWindowXMsgProc - pthread_mutex_unlock () returned.
[697888.265] winProcEstablishConnection - winInitClipboard returned.
[697888.265] winMultiWindowXMsgProc - DISPLAY=:0.0
[697888.265] winClipboardProc - DISPLAY=:0.0
[697888.265] winInitMultiWindowWM - XOpenDisplay () returned and successfully opened the display.
[697888.281] winClipboardProc - XOpenDisplay () returned and successfully opened the display.
[697888.375] winMultiWindowXMsgProc - XOpenDisplay () returned and successfully opened the display.
[697917.046] winDeinitMultiWindowWM - Noting shutdown in progress
[697917.046] winClipboardProc - winClipboardFlushWindowsMessageQueue trapped WM_QUIT message, exiting main loop.
[697917.046] winClipboardProc - XDestroyWindow succeeded.
[697917.046] winClipboardProc - Clipboard disabled  - Exit from server 
[697917.046] winClipboardIOErrorHandler!

[697917.046] winMultiWindowXMsgProcIOErrorHandler!

[697917.046] winInitMultiWindowXMsgProc - Caught IO Error.  Exiting.
[697917.078] winDeinitMultiWindowWM - Noting shutdown in progress


[-- 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: Cygwin X + HP-UX 11.11 + italian keyboard = AltGr not working

[Jon TURNEY]

On 06/07/2011 09:15, Danilo Turina wrote:
>     having recently replaced my old keyboard (that had a US layout) with an
> italian one, I'm having a problem with Cygwin X when running HP-UX clients:
> AltGr does not work and this prevents me to use characters like "[" "{" "}"
> "]", etc.
> 
> I'm up to date with Cygwin and Cygwin X at the moment ("1.7.9(0.237/5/3)
> 2011-03-29 10:10 i686 Cygwin" for Cygwin and "1.10.2.0" for XWin).
> 
> These are the steps to reproduce the problem:
> 
>     1) start Cygwin X
>     2) disable access control ("xhost +")
>     3) access via telnet/ssh a HP-UX machine
>     4) open an xterm from the HP-UX machine in Cygwin X
>     5) in the newly opened xterm try to use AltGr (AltGr + "è" (i.e. the key
> at the right of "P"), should produce "{", while AltGr + Shift + "è" should
> produce "{")

I'm missing here what is actually produced.  Nothing? or the unmodified è?

>     6) fall on the floor crying in desperation

This is perfectly normal for people having to deal with XKB :-)

> Notice that when using a client from a Linux machine all works properly.
> 
> A googled a lot and found a lot of information but only few of it applied
> (=helped) to my specific case. I tried to mess with xmodmap and kbd config
> files and also with other stuff, but nothing seemed to solve the problem.

I think a solution is contained in this old mailing list post [1], use
XKB_DISABLE=1 and adjust the keyboard map so that AltGr is Mode_switch and the
keys have the expected mapping in group 2, activated via Mode_switch.

Note that just reassigning AltGr to Mode_switch is not enough, you'll need to
remap appropriately the keys which generate different characters with AltGr
e.g. something like:

xmodmap -e "clear mod5"
xmodmap -e "clear mod3"
xmodmap -e "keycode 113 = Mode_switch Multi_key"
xmodmap -e "add mod3 = Mode_switch"
xmodmap -e "keycode 34 = egrave eacute bracketleft braceleft"
(and so on for the other keys which need to generate different characters with
AltGr)

I can't test this, because I don't have access to a HP-UX machine.

[1] http://cygwin.com/ml/cygwin-xfree/2004-03/msg00454.html

> At the moment I'm using Xming 6.9.0.31 that doesn't seem affected by the
> problem IF I set XKB_DISABLE=1 on the client machine (i.e. HP-UX).
> 
> Trying to troubleshoot the problem, I used xev on the HP-UX machine to see if
> the keys were properly recognized and, in effect, they are.
> This are xev results for Cygwin X, when I press (and release) AltGr+è (thus by
> trying to get "[") with XKB_DISABLED not set:
> 
[snip]
> 
> If I set XKB_DISABLED=1, I get, instead:
> 
[snip]
> 
> If I try xev on Xming with XKB_DISABLED=1 (where I have no problem at all), I
> get:
> 
[snip]

It's kind of hard to know how to interpret these results since I don't know
what XKB_DISABLED=1 actually does.


> One strange thing that I noticed is that if I start Cygwin X by using
> "startxwin" from the Cygwin's command line, I get the following warning on
> screen:
[snip]
> The XKEYBOARD keymap compiler (xkbcomp) reports:
>> Warning:          Type "ONE_LEVEL" has 1 levels, but <RALT> has 2 symbols
>>                   Ignoring extra symbols
> 
> But that warning is not present in XWin.0.log (attached).

I think this is normal, if a little odd.  Warnings from xkbocmp are written to
stdout, but not written to the log.

-- 
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: Cygwin X + HP-UX 11.11 + italian keyboard = AltGr not working

[Danilo Turina]

On 06/07/2011 16.02, Jon TURNEY wrote:
> On 06/07/2011 09:15, Danilo Turina wrote:
>>      having recently replaced my old keyboard (that had a US layout) with an
>> italian one, I'm having a problem with Cygwin X when running HP-UX clients:
>> AltGr does not work and this prevents me to use characters like "[" "{" "}"
>> "]", etc.
>>
>> I'm up to date with Cygwin and Cygwin X at the moment ("1.7.9(0.237/5/3)
>> 2011-03-29 10:10 i686 Cygwin" for Cygwin and "1.10.2.0" for XWin).
>>
>> These are the steps to reproduce the problem:
>>
>>      1) start Cygwin X
>>      2) disable access control ("xhost +")
>>      3) access via telnet/ssh a HP-UX machine
>>      4) open an xterm from the HP-UX machine in Cygwin X
>>      5) in the newly opened xterm try to use AltGr (AltGr + "è" (i.e. the key
>> at the right of "P"), should produce "{", while AltGr + Shift + "è" should
>> produce "{")
>
> I'm missing here what is actually produced.  Nothing? or the unmodified è?

The unmodified è (well, sort of, because when I press "è" on the 
keyboard I see on the terminal "I" (I think because of some other 
problem of the terminal with non-ASCII chars) and if I press AltGr+"è" I 
yet see "I", so it's just like pressing AltGr has no effect at all).

>
>>      6) fall on the floor crying in desperation
>
> This is perfectly normal for people having to deal with XKB :-)
>
>> Notice that when using a client from a Linux machine all works properly.
>>
>> A googled a lot and found a lot of information but only few of it applied
>> (=helped) to my specific case. I tried to mess with xmodmap and kbd config
>> files and also with other stuff, but nothing seemed to solve the problem.
>
> I think a solution is contained in this old mailing list post [1], use
> XKB_DISABLE=1 and adjust the keyboard map so that AltGr is Mode_switch and the
> keys have the expected mapping in group 2, activated via Mode_switch.
>
> Note that just reassigning AltGr to Mode_switch is not enough, you'll need to
> remap appropriately the keys which generate different characters with AltGr
> e.g. something like:
>
> xmodmap -e "clear mod5"
> xmodmap -e "clear mod3"
> xmodmap -e "keycode 113 = Mode_switch Multi_key"
> xmodmap -e "add mod3 = Mode_switch"
> xmodmap -e "keycode 34 = egrave eacute bracketleft braceleft"
> (and so on for the other keys which need to generate different characters with
> AltGr)

I already encountered some like that while searching the internet but 
didn't work.
I tried what you wrote here but didn't work either...

Is there anything that I can do to go deeper into the analysis of this 
problem? xev seems not of any help, since it returns the same results 
both for Xming where all works and Cygwin X where I have the problem.

Ciao,
	Danilo

>
> I can't test this, because I don't have access to a HP-UX machine.
>
> [1] http://cygwin.com/ml/cygwin-xfree/2004-03/msg00454.html
>
>> At the moment I'm using Xming 6.9.0.31 that doesn't seem affected by the
>> problem IF I set XKB_DISABLE=1 on the client machine (i.e. HP-UX).
>>
>> Trying to troubleshoot the problem, I used xev on the HP-UX machine to see if
>> the keys were properly recognized and, in effect, they are.
>> This are xev results for Cygwin X, when I press (and release) AltGr+è (thus by
>> trying to get "[") with XKB_DISABLED not set:
>>
> [snip]
>>
>> If I set XKB_DISABLED=1, I get, instead:
>>
> [snip]
>>
>> If I try xev on Xming with XKB_DISABLED=1 (where I have no problem at all), I
>> get:
>>
> [snip]
>
> It's kind of hard to know how to interpret these results since I don't know
> what XKB_DISABLED=1 actually does.
>
>
>> One strange thing that I noticed is that if I start Cygwin X by using
>> "startxwin" from the Cygwin's command line, I get the following warning on
>> screen:
> [snip]
>> The XKEYBOARD keymap compiler (xkbcomp) reports:
>>> Warning:          Type "ONE_LEVEL" has 1 levels, but<RALT>  has 2 symbols
>>>                    Ignoring extra symbols
>>
>> But that warning is not present in XWin.0.log (attached).
>
> I think this is normal, if a little odd.  Warnings from xkbocmp are written to
> stdout, but not written to the log.
>

-- 
DANILO TURINA
ALCATEL-LUCENT
Software Analyst
NM System Team
Network-Optics
Rieti (Italy)
Phone: +39 0746 600332

10 anni 2 mesi 27 giorni 6 ore 42 minuti 8 secondi

--
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: Cygwin X + HP-UX 11.11 + italian keyboard = AltGr not working

[Jon TURNEY]

On 06/07/2011 15:26, Danilo Turina wrote:
> On 06/07/2011 16.02, Jon TURNEY wrote:
>> On 06/07/2011 09:15, Danilo Turina wrote:
>>>      having recently replaced my old keyboard (that had a US layout) with an
>>> italian one, I'm having a problem with Cygwin X when running HP-UX clients:
>>> AltGr does not work and this prevents me to use characters like "[" "{" "}"
>>> "]", etc.
>>>
>>> I'm up to date with Cygwin and Cygwin X at the moment ("1.7.9(0.237/5/3)
>>> 2011-03-29 10:10 i686 Cygwin" for Cygwin and "1.10.2.0" for XWin).
>>>
>>> These are the steps to reproduce the problem:
>>>
>>>      1) start Cygwin X
>>>      2) disable access control ("xhost +")
>>>      3) access via telnet/ssh a HP-UX machine
>>>      4) open an xterm from the HP-UX machine in Cygwin X
>>>      5) in the newly opened xterm try to use AltGr (AltGr + "è" (i.e. the key
>>> at the right of "P"), should produce "{", while AltGr + Shift + "è" should
>>> produce "{")
>>
>> I'm missing here what is actually produced.  Nothing? or the unmodified è?
> 
> The unmodified è (well, sort of, because when I press "è" on the keyboard I
> see on the terminal "I" (I think because of some other problem of the terminal
> with non-ASCII chars) and if I press AltGr+"è" I yet see "I", so it's just
> like pressing AltGr has no effect at all).
> 
>>
>>>      6) fall on the floor crying in desperation
>>
>> This is perfectly normal for people having to deal with XKB :-)
>>
>>> Notice that when using a client from a Linux machine all works properly.
>>>
>>> A googled a lot and found a lot of information but only few of it applied
>>> (=helped) to my specific case. I tried to mess with xmodmap and kbd config
>>> files and also with other stuff, but nothing seemed to solve the problem.
>>
>> I think a solution is contained in this old mailing list post [1], use
>> XKB_DISABLE=1 and adjust the keyboard map so that AltGr is Mode_switch and the
>> keys have the expected mapping in group 2, activated via Mode_switch.
>>
>> Note that just reassigning AltGr to Mode_switch is not enough, you'll need to
>> remap appropriately the keys which generate different characters with AltGr
>> e.g. something like:
>>
>> xmodmap -e "clear mod5"
>> xmodmap -e "clear mod3"
>> xmodmap -e "keycode 113 = Mode_switch Multi_key"
>> xmodmap -e "add mod3 = Mode_switch"
>> xmodmap -e "keycode 34 = egrave eacute bracketleft braceleft"
>> (and so on for the other keys which need to generate different characters with
>> AltGr)
> 
> I already encountered some like that while searching the internet but didn't
> work.
> I tried what you wrote here but didn't work either...

Just to be clear, you probably have to do all this before you start the xterm
you are going to be working in.

Can I see the xev output when you try that setup?

> Is there anything that I can do to go deeper into the analysis of this
> problem? xev seems not of any help, since it returns the same results both for
> Xming where all works and Cygwin X where I have the problem.

Yes, that's rather mystifying.

You might consider using wireshark, xmon or xscope to examine the protocol
interactions between client and server (not sure if all of these can decode
XKB extension protocol) to see if there is any difference there.

It seems that XKB_DISABLE is checked for inside libX11 (at least since R6.6,
the oldest version in freedesktop.org git), so you might want to identify what
version is on your HP-UX host and try to understand how it behaves.  It might
also be worthwhile to look forward in the version history to see if there's
been a fix made for this behavior?

Lastly, I notice that HP-UX 11.11 is apparently still in support, so you might
actually ask HP to fix it :-)

-- 
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: Cygwin X + HP-UX 11.11 + italian keyboard = AltGr not working (solved/worked around)

[Danilo Turina]

On 07/07/2011 15.04, Jon TURNEY wrote:
> On 06/07/2011 15:26, Danilo Turina wrote:
>> On 06/07/2011 16.02, Jon TURNEY wrote:
>>> On 06/07/2011 09:15, Danilo Turina wrote:
>>>>       having recently replaced my old keyboard (that had a US layout) with an
>>>> italian one, I'm having a problem with Cygwin X when running HP-UX clients:
>>>> AltGr does not work and this prevents me to use characters like "[" "{" "}"
>>>> "]", etc.
>>>>
>>>> I'm up to date with Cygwin and Cygwin X at the moment ("1.7.9(0.237/5/3)
>>>> 2011-03-29 10:10 i686 Cygwin" for Cygwin and "1.10.2.0" for XWin).
>>>>
>>>> These are the steps to reproduce the problem:
>>>>
>>>>       1) start Cygwin X
>>>>       2) disable access control ("xhost +")
>>>>       3) access via telnet/ssh a HP-UX machine
>>>>       4) open an xterm from the HP-UX machine in Cygwin X
>>>>       5) in the newly opened xterm try to use AltGr (AltGr + "è" (i.e. the key
>>>> at the right of "P"), should produce "{", while AltGr + Shift + "è" should
>>>> produce "{")
>>>
>>> I'm missing here what is actually produced.  Nothing? or the unmodified è?
>>
>> The unmodified è (well, sort of, because when I press "è" on the keyboard I
>> see on the terminal "I" (I think because of some other problem of the terminal
>> with non-ASCII chars) and if I press AltGr+"è" I yet see "I", so it's just
>> like pressing AltGr has no effect at all).
>>
>>>
>>>>       6) fall on the floor crying in desperation
>>>
>>> This is perfectly normal for people having to deal with XKB :-)
>>>
>>>> Notice that when using a client from a Linux machine all works properly.
>>>>
>>>> A googled a lot and found a lot of information but only few of it applied
>>>> (=helped) to my specific case. I tried to mess with xmodmap and kbd config
>>>> files and also with other stuff, but nothing seemed to solve the problem.
>>>
>>> I think a solution is contained in this old mailing list post [1], use
>>> XKB_DISABLE=1 and adjust the keyboard map so that AltGr is Mode_switch and the
>>> keys have the expected mapping in group 2, activated via Mode_switch.
>>>
>>> Note that just reassigning AltGr to Mode_switch is not enough, you'll need to
>>> remap appropriately the keys which generate different characters with AltGr
>>> e.g. something like:
>>>
>>> xmodmap -e "clear mod5"
>>> xmodmap -e "clear mod3"
>>> xmodmap -e "keycode 113 = Mode_switch Multi_key"
>>> xmodmap -e "add mod3 = Mode_switch"
>>> xmodmap -e "keycode 34 = egrave eacute bracketleft braceleft"
>>> (and so on for the other keys which need to generate different characters with
>>> AltGr)
>>
>> I already encountered some like that while searching the internet but didn't
>> work.
>> I tried what you wrote here but didn't work either...
>
> Just to be clear, you probably have to do all this before you start the xterm
> you are going to be working in.
>
> Can I see the xev output when you try that setup?
>
>> Is there anything that I can do to go deeper into the analysis of this
>> problem? xev seems not of any help, since it returns the same results both for
>> Xming where all works and Cygwin X where I have the problem.
>
> Yes, that's rather mystifying.
>
> You might consider using wireshark, xmon or xscope to examine the protocol
> interactions between client and server (not sure if all of these can decode
> XKB extension protocol) to see if there is any difference there.

Fiddling aroung with Wireshark I was able to understand what the problem 
was and I had the confirm thanks to xmodmap.

With Xming I had that keycode 34 ("è") is associated to

	egrave eacute bracketleft braceleft bracketleft braceleft

while with CygwinX the association is

	egrave eacute egrave eacute bracketleft braceleft

I don't know the exact meaning of each of the positions above, but with

xmodmap -e "keycode 34 = egrave eacute bracketleft braceleft bracketleft 
braceleft"

I solved the problem.
I then saw that that solves the problem even without setting XKB_DISABLE 
but only with some applications (e.g. with xterm works, with nedit you 
need XKB_DISABLE set).

So just executing the xmodmap above for keycode 34, also within the same 
xterm on which I had the problem, without setting XKB_DISABLE and 
without doing anything else (so not resetting of the modifiers with 
'xmodmap -e "clear mod5"', etc.), it works (but better setting 
XKB_DISABLE=1 in order to make all clients work).

In short:

export XKB_DISABLE=1
xmodmap -e "keycode 34 = egrave eacute bracketleft braceleft bracketleft 
braceleft"
xmodmap -e "keycode 35 = plus asterisk bracketright braceright 
bracketright braceright"
xmodmap -e "keycode 48 = agrave degree numbersign dead_abovering 
numbersign dead_abovering numbersign dead_abovering"
xmodmap -e "keycode 47 = ograve ccedilla at dead_cedilla at dead_cedilla 
at dead_cedilla ograve ccedilla at dead_cedilla"

does the job (with the above I just fix the four keys needed to get "[", 
"{", "]", "}", "@" and "#", probably others are missing, like AltGr+E 
for the Euro sign, but I don't use them within HP-UX so no problem for me).

WARNING WARNING WARNING: I wrote the above xmodmap statements by getting 
their values from "xmodmap -pk" and replacing the 3rd and 4th values 
with the 5th and 6th values, so I don't know whether they can cause 
problems in other contexts. I hope that somebody that better knows 
xmodmap (and the like) could confirm the correctness of the above (that 
anyway for me works, so I have no problems at all now).

I don't know whether this is a symptom of a wrong keymap on the Cygwin X 
side or is a problem on HP-UX, but I don't really care at this point.

Thank you very much for the support and the precious hints.
Ciao,
	Danilo

P.S. If I had looked more carefully at "xmodmap -pk" output at the 
beginning, I would have discovered the problem early and I would have 
avoided all of this researching and trying.

>
> It seems that XKB_DISABLE is checked for inside libX11 (at least since R6.6,
> the oldest version in freedesktop.org git), so you might want to identify what
> version is on your HP-UX host and try to understand how it behaves.  It might
> also be worthwhile to look forward in the version history to see if there's
> been a fix made for this behavior?
>
> Lastly, I notice that HP-UX 11.11 is apparently still in support, so you might
> actually ask HP to fix it :-)
>

-- 
DANILO TURINA
ALCATEL-LUCENT
Software Analyst
NM System Team
Network-Optics
Rieti (Italy)
Phone: +39 0746 600332

10 anni 2 mesi 28 giorni 23 ore 57 minuti 8 secondi

--
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: Cygwin X + HP-UX 11.11 + italian keyboard = AltGr not working (solved/worked around)

[Jon TURNEY]

Thanks very much for posting your work around.

On 08/07/2011 09:18, Danilo Turina wrote:
> Fiddling aroung with Wireshark I was able to understand what the problem was
> and I had the confirm thanks to xmodmap.
> 
> With Xming I had that keycode 34 ("è") is associated to
> 
>     egrave eacute bracketleft braceleft bracketleft braceleft
> 
> while with CygwinX the association is
> 
>     egrave eacute egrave eacute bracketleft braceleft
> 
> I don't know the exact meaning of each of the positions above, but with

This is (sort of) explained in 'man xmodmap'

>                The  list of keysyms is assigned to the indicated keycode (which may be specified in decimal,
>                hex or octal and can be determined by running the xev program).  Up to eight keysyms  may  be
>                attached  to  a key, however the last four are not used in any major X server implementation.
>                The first keysym is used when no modifier key is pressed in conjunction with  this  key,  the
>                second  with  Shift,  the third when the Mode_switch key is used with this key and the fourth
>                when both the Mode_switch and Shift keys are used.

However, you have to remember that what you see with xmodmap isn't the real
XKB keymap, but a compatibility xmodmap invented by XKB for clients which
don't know about XKB.

> xmodmap -e "keycode 34 = egrave eacute bracketleft braceleft bracketleft
> braceleft"
> 
> I solved the problem.
> I then saw that that solves the problem even without setting XKB_DISABLE but
> only with some applications (e.g. with xterm works, with nedit you need
> XKB_DISABLE set).
> 
> So just executing the xmodmap above for keycode 34, also within the same xterm
> on which I had the problem, without setting XKB_DISABLE and without doing
> anything else (so not resetting of the modifiers with 'xmodmap -e "clear
> mod5"', etc.), it works (but better setting XKB_DISABLE=1 in order to make all
> clients work).
> 
> In short:
> 
> export XKB_DISABLE=1
> xmodmap -e "keycode 34 = egrave eacute bracketleft braceleft bracketleft
> braceleft"
> xmodmap -e "keycode 35 = plus asterisk bracketright braceright bracketright
> braceright"
> xmodmap -e "keycode 48 = agrave degree numbersign dead_abovering numbersign
> dead_abovering numbersign dead_abovering"
> xmodmap -e "keycode 47 = ograve ccedilla at dead_cedilla at dead_cedilla at
> dead_cedilla ograve ccedilla at dead_cedilla"
> 
> does the job (with the above I just fix the four keys needed to get "[", "{",
> "]", "}", "@" and "#", probably others are missing, like AltGr+E for the Euro
> sign, but I don't use them within HP-UX so no problem for me).
> 
> WARNING WARNING WARNING: I wrote the above xmodmap statements by getting their
> values from "xmodmap -pk" and replacing the 3rd and 4th values with the 5th
> and 6th values, so I don't know whether they can cause problems in other
> contexts. I hope that somebody that better knows xmodmap (and the like) could
> confirm the correctness of the above (that anyway for me works, so I have no
> problems at all now).
> 
> I don't know whether this is a symptom of a wrong keymap on the Cygwin X side
> or is a problem on HP-UX, but I don't really care at this point.

Fair enough.  I wish I understood what was going on here better so I could
improve what Cygwin/X FAQ 5.1.8 [1] says.

[1] http://x.cygwin.com/docs/faq/cygwin-x-faq.html#alt-gr-with-old-x

> 
> Thank you very much for the support and the precious hints.
> Ciao,
>     Danilo
> 
> P.S. If I had looked more carefully at "xmodmap -pk" output at the beginning,
> I would have discovered the problem early and I would have avoided all of this
> researching and trying.

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