Cygwin X + HP-UX 11.11 + italian keyboard = AltGr not working (solved/worked around)

Fri Jul 8 09:01:00 GMT 2011

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/