Rdesktop and keymap vs kxkb interraction?

Hi all,

SHORT STORY:
We are trying to figure out a way to dissociate the interraction between "KDE keyboard switcher" vs "rdesktop using keymaps" to make sure that when we can fire-up a rdekstop using either a ca-fr or en-us keymap and that the keyboard will keep that mapping independently of any keyboard mapping switch in the KDE session.


LONG STORY:
We are having a scientific department with around 75 linux desktops.  Every user as a connetion to a terminal server to read it's emails and use the official office technology supported suite (a.k.a ms office).

People can either work in english or french which mean that they can easily configure their KDE session language and have keyboard switching available using kxkb.

Almost every single forecaster applications they use only handle US ASCII characters thus they mostly (if not only) use en_US keyboard mapping on thoses applications.  Although, on some other they might switch keyboard mapping (like for bloggin in firefox for instance).

They can also either connect to a english or french terminal server and thus use either an english of french keyboard mapping for it.

This is where the problem begins... Using linux only applications it's quite easy to switch language for one application to the other using kxkb global, per application or per window feature.  The problem is it's interraction with rdesktop.

Doing a lot of testing under Debian we found out that:

Without keymap and LC_ALL set to POSIX:
Version 1.5: The mapping of the keyboard in the windows terminal session is affected by kxkb (kde keyboard switcher) wich meands that, having set the keyboard in french in the terminal session and switching from us to ca or cae in KDE doubles the accentuated characters (for instance, é becomes ée) in the windows sesison.  It also generates errors on the prompt when we switch to another language then us in KDE:
WARNING: No translation for (keysym 0xfe51, dead_acute)
This results in:  if the keyboard in KDE is set in us then french accents works ok in TS.  If the keyboard in KDE is set to ca or cae then accentuated characters gets doubled (é becomming ée).

Version 1.4: The mapping of the keyboard is not affected by keyboard switching in KDE which means that a switch from us to ca or cae in KDE make no difference in the windows terminal session keyboard mapping.  Although, it does generate the same errors at the console than the 1.5 version.

In both cases (1.4 & 1.5 versions) the terminal session is started by default with an english keyboard mapping everytime and even if the user change its default keyboard preferences to french canadian it will be resetted at next logon.



With a ca-fr keymap or LC_ALL set to fr_CA / fr_CA.ISO-8859-1:
The terminal server session always get started with the proper keyboard mapping (this means that the blue windows keyboard icon is set to FR).  Although, the keyboard in KDE MUST be set to either ca or cae to allow french accentuated characters.  If the keyboard in KDE is set to us the keyboard will be mapped to US in TS although the keyboard layout icon is set to FR ???


Desired behaviour:
1- We hope we could easilly start a windows terminal session using rdesktop directly using the appropriate keymap (passing either en-us of fr-ca keymap thus resulting in having a EN or FR blue icon at login screen and proper keyboard set by default in the windows session.  This can already be done.
2- Making sure that rdesktop will keep typing the appropriate characters when I type which would mean that rdesktop wouln't be affected by any keyboard switching (that could lead to a new option a rdesktop startup ?).  To do so I'm presuming that if I start rdesktop using a french keyboard mapping that this mapping will stay that way in my TS independently of my KDE session.  That would mean a pseudo-equivalent of the version 1.4 behaviour as described previously.


Vincent Fortier
Informatique
Environnement Canada

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

_______________________________________________
rdesktop-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/rdesktop-users