Danish keymap i X/CDE

[Ole Hansen]

Hi,

We've bought some VXL Itona thin clients as a replacement for som old HP X-terminals.

These clients are configured using a Danish keymap, but when connecting to one of our two HP-UX 11i machines, the danish keymap is not set. When connecting to a Solaris or Linux machines, theres is no problem.

Any ideas why the keymap is not set correctly?

[T G Manikandan]

check your /etc/kbdlang file

you can do a

#itemap -L
OR
#itemap -iL

[Ole Hansen]

/etc/kbdlang say "Not_Applicable"

/sbin/itemap gives me nothing..

The problem is, I believe, is that somehow dtlogin mess up my keymap on the client..

[T G Manikandan]

Please edit the /etc/kbdlang and make an entry

USB_PS2_DIN_Danish_Euro

[T G Manikandan]

Please edit the /etc/kbdlang and make an entry

USB_PS2_DIN_Danish_Euro

and do a reboot

[Ole Hansen]

No way! :)

Seriously; reading the man-page for itemap, it tells me, that it is used for configuring the internal terminal emulator for the graphics console.. As is found in the workstations. My problem is ONLY when connecting remotely via X using these VXL-boxes. Using one of our old HP X-terminals the danish keymap works fine. When connecting to a Solaris- or Linux-box from the VXL it works.. Only when connecting to one of our HP-UX boxes, it does not work..

[Rick Beldin]

You are correct and were led down the wrong path. itemap is only for workstations. It will have nothing to do with the thin client.

I'm not familiar with this thin client, so I am not sure what kind of OS it runs, nor what kind of Xserver it supports.

I would suggest:

- login to CDE
- xmodmap -pm > /tmp/xmodmap-pm.log
- xmodmap -pk > /tmp/xmodmap-pk.log
- xdpyinfo > /tmp/xdpyinfo.log

So that we can see what the modifier mappings, the keyboard mappings, and some information about the Xserver on the thin client are.

It would be helpful to know a bit more about these clients and the host OS revision.

[Ole Hansen]

Ahh.. Now we're getting somewhere! :)

I opened a dtpad, and here I'm able to type all my danish keys - but my "Alt-Gr" key does not work.. That key I need for doing pipe-, dollar and at-signs - so it's pretty important :)

See the attached file for xmodmap-log.. I did not have the Xpdyinfo, but I did a "Xserver Information" from som CDE menu..

The VXL runs some sort of Linux using an XFree X-server.

[Ole Hansen]

... The host-OS is HP-UX 11i, with December 2003 bundle installed.

[Ole Hansen]

I found a workaround in this thread.. http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=34315

Still - I don't have danish keymap at login-time, but hey - it's okay.. :)

[Rick Beldin]

Great. Part of the reason for asking for the xdpyinfo is that would reveal whether your Xserver has the XKEYBOARD extension. It does:

number of extensions: 26
BIG-REQUESTS
DOUBLE-BUFFER
DPMS Extended-Visual-Information
FontCache
LBX
MIT-SCREEN-SAVER
MIT-SHM
MIT-SUNDRY-NONSTANDARD
RANDR
RENDER
SECURITY
SHAPE
SYNC
TOG-CUP
X-Resource
XC-APPGROUP
XC-MISC
XFree86-Bigfont
XFree86-DGA
XFree86-Misc
XFree86-VidModeExtension
XInputExtension
XKEYBOARD XTEST
XVideo

The XKB_DISABLE environment force HP's Xlib (libX11) to take an older path through the library that will get you working. None of HP's current Xservers have the XKEYBOARD extension and thus this has not been a big issue, nor has XKEYBOARD support been tested very widely or at all on HP-UX.

A typical symptom of the problem is that dtterm will not do a proper caps lock. The AltGR is a variant of that problem.

[Ole Hansen]

I found an explanation simililar to what you tells me.. Well, I can accept this solution - the only time, people will run into problems, is when logging in and they have password, that includes special-characters! :)

[Rick Beldin]

I've never tried this, but you might be able to get dtlogin to have XKB_DISABLE by editing the file /etc/dt/config/Xconfig. Look for the line with:

Dtlogin*environment:

and modify it to read something like:

Dtlogin*environment: XKB_DISABLE=1

I'm not sure if that is early enough in the startup, since what we have to get is the dtgreet process, who is a child of dtlogin.

It becomes a bit complex since dtlogin runs as a daemon and I'm not too sure about the set of environment variables he carries with him. dtlogin is formally started in /usr/dt/config/dtrc.d/90_dtlogin_st.