"Vincent DEDIEU" <[EMAIL PROTECTED]> writes:
> Tristan
>
> I tested the xmodmap command to set an Xvnc French keyboard mapping... And
> it doesn't work.
>
> It's like the VNC server is not able to change dynamicaly it's default
> keyboard map (i.e. hardcoded keyboard map).
>
> For example, on a French keyboard the row above "AZERTYU..." is different
> than an US keyboard. So I created the following "kb.FR" file:
> keycode 17 = twosuperior
> keycode 18 = ampersand 1
> keycode 19 = eacute 2
> keycode 20 = quotedbl 3
> keycode 21 = apostrophe 4
> keycode 22 = parenleft 5
> keycode 23 = minus 6
> keycode 24 = egrave 7
> keycode 25 = underscore 8
> keycode 26 = ccedilla 9
> keycode 27 = agrave 0
>
> And I invoked the following command to set these keys:
> xmodmap kb.FR
>
> ...And the row above AZERTY is broken. (If I press <&> I get <7>).
>
> I experienced these problems few months ago and that's why a modified the
> VNC source code.
>
> Maybe I don't use correctly xmodmap command. Is there a command to force the
> VNC server to reset its keyboard table ?
>
> Do you have an idea ?
>
Yes, sorry I wasn't very clear. You shouldn't need to do any xmodmap at
all, unless the X application is broken.
For example, when you press the "eacute" key on the VNC client, it sends
the "eacute" keysym to Xvnc which looks in its keyboard mapping and doesn't
find it. So it allocates the next available keycode (starting from 89) and
maps it to the "eacute" keysym, then generate an X event with that keycode.
The X application looks up that keycode in the mapping, finds that it maps
to "eacute", and is happy. Subsequently when you press "eacute" on the VNC
client, Xvnc finds it in its mapping and sends the same keycode as before
in the X event.
Now there are two ways in which an X application can be broken:
1) it can read the keyboard mapping only at the start of its connection to
the X server, in which case Xvnc's method of dynamically adding keys as
it finds them won't work, because the X application won't notice that
the keyboard mapping has changed.
2) it can totally ignore the keyboard mapping and assume a single
particular physical layout of the keyboard (i.e. using keycodes directly
rather than looking them up to keysyms).
Case (1) can be dealt with by adding keys with xmodmap before you start the
application. Note that you should add keys starting, say, at keycode 100
(anything above 88), because Xvnc's predefined keys from 8 to 88 are
treated specially.
For case (2) you currently have to recompile Xvnc with a particular
keyboard layout in it, as you did. However, the only reason for this is
that Xvnc treats keycodes 8 to 88 specially, in that it attempts to allow
them to be remapped using xmodmap. This can easily be disabled by
commenting out the code which does this (see the patch below), then your
kb.FR file ought to work.
Hope this helps
Cheers
Tristan
---------------------------------------------------------------------------
Tristan Richardson [EMAIL PROTECTED] www.uk.research.att.com/~tjr
---------------------------------------------------------------------------
AT&T Laboratories Cambridge, 24a Trumpington Street, Cambridge, CB2 1QA, UK
Tel: +44 1223 343000 Fax: +44 1223 313542 www.uk.research.att.com
---------------------------------------------------------------------------
*** kbdptr.c Wed Sep 20 10:38:56 2000
--- kbdptr.c.new Mon Apr 23 11:28:55 2001
***************
*** 300,305 ****
--- 300,306 ----
event. We don't attempt to do this for keycodes which we make up on the
fly because it's too hard... */
+ #if 0
for (i = 0; i < N_PREDEFINED_KEYS * GLYPHS_PER_KEY; i++) {
if (keySym == kbdMap[i]) {
keyCode = MIN_KEY_CODE + i / GLYPHS_PER_KEY;
***************
*** 317,322 ****
--- 318,324 ----
break;
}
}
+ #endif
if (!keyCode) {
---------------------------------------------------------------------
To unsubscribe, send a message with the line: unsubscribe vnc-list
to [EMAIL PROTECTED]
See also: http://www.uk.research.att.com/vnc/intouch.html
---------------------------------------------------------------------
