public inbox for cygwin-xfree@sourceware.org
help / color / mirror / Atom feed
* Cygwin X + HP-UX 11.11 + italian keyboard = AltGr not working
@ 2011-07-06 14:02 Danilo Turina
2011-07-06 14:27 ` Jon TURNEY
0 siblings, 1 reply; 6+ messages in thread
From: Danilo Turina @ 2011-07-06 14:02 UTC (permalink / raw)
To: cygwin-xfree
[-- 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/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Cygwin X + HP-UX 11.11 + italian keyboard = AltGr not working
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
0 siblings, 1 reply; 6+ messages in thread
From: Jon TURNEY @ 2011-07-06 14:27 UTC (permalink / raw)
To: cygwin-xfree; +Cc: danilo.turina
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/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Cygwin X + HP-UX 11.11 + italian keyboard = AltGr not working
2011-07-06 14:27 ` Jon TURNEY
@ 2011-07-07 0:12 ` Danilo Turina
2011-07-07 13:34 ` Jon TURNEY
0 siblings, 1 reply; 6+ messages in thread
From: Danilo Turina @ 2011-07-07 0:12 UTC (permalink / raw)
To: cygwin-xfree
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/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Cygwin X + HP-UX 11.11 + italian keyboard = AltGr not working
2011-07-07 0:12 ` Danilo Turina
@ 2011-07-07 13:34 ` Jon TURNEY
2011-07-08 9:01 ` Cygwin X + HP-UX 11.11 + italian keyboard = AltGr not working (solved/worked around) Danilo Turina
0 siblings, 1 reply; 6+ messages in thread
From: Jon TURNEY @ 2011-07-07 13:34 UTC (permalink / raw)
To: cygwin-xfree; +Cc: danilo.turina
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/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Cygwin X + HP-UX 11.11 + italian keyboard = AltGr not working (solved/worked around)
2011-07-07 13:34 ` Jon TURNEY
@ 2011-07-08 9:01 ` Danilo Turina
2011-07-19 15:17 ` Jon TURNEY
0 siblings, 1 reply; 6+ messages in thread
From: Danilo Turina @ 2011-07-08 9:01 UTC (permalink / raw)
To: cygwin-xfree
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/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Cygwin X + HP-UX 11.11 + italian keyboard = AltGr not working (solved/worked around)
2011-07-08 9:01 ` Cygwin X + HP-UX 11.11 + italian keyboard = AltGr not working (solved/worked around) Danilo Turina
@ 2011-07-19 15:17 ` Jon TURNEY
0 siblings, 0 replies; 6+ messages in thread
From: Jon TURNEY @ 2011-07-19 15:17 UTC (permalink / raw)
To: cygwin-xfree; +Cc: danilo.turina
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/
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-07-19 14:58 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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 ` Cygwin X + HP-UX 11.11 + italian keyboard = AltGr not working (solved/worked around) Danilo Turina
2011-07-19 15:17 ` Jon TURNEY
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).