This is the mail archive of the cygwin-xfree mailing list for the Cygwin XFree86 project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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 è?

>     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

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


> At the moment I'm using Xming 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:
> If I set XKB_DISABLED=1, I get, instead:
> If I try xev on Xming with XKB_DISABLED=1 (where I have no problem at all), I
> get:

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

Volunteer Cygwin/X X Server maintainer

Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]