public inbox for
help / color / mirror / Atom feed
From: Danilo Turina <>
To: cygwin-xfree <>
Subject: Re: Cygwin X + HP-UX 11.11 + italian keyboard = AltGr not working (solved/worked around)
Date: Fri, 08 Jul 2011 09:01:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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

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

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 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 :-)

Software Analyst
NM System Team
Rieti (Italy)
Phone: +39 0746 600332

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

Unsubscribe info:
Problem reports:

  reply	other threads:[~2011-07-08  8:19 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-06 14:02 Cygwin X + HP-UX 11.11 + italian keyboard = AltGr not working Danilo Turina
2011-07-06 14:27 ` Jon TURNEY
2011-07-07  0:12   ` Danilo Turina
2011-07-07 13:34     ` Jon TURNEY
2011-07-08  9:01       ` Danilo Turina [this message]
2011-07-19 15:17         ` Cygwin X + HP-UX 11.11 + italian keyboard = AltGr not working (solved/worked around) Jon TURNEY

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).