rdesktop works bad with several keyboard layouts

This bug was fixed in the package rdesktop - 1.6.0-1ubuntu1

---------------
rdesktop (1.6.0-1ubuntu1) intrepid; urgency=low

  * Merge from Debian unstable
  * Remaining Ubuntu changes:
    - Replace x-dev with libx11-dev in Build-Depends.
    - Build with ALSA support.
    - Add viewport patch.
  * Add patch from Alt Linux that adds support for raw keyboard.
    (LP: #251709)

rdesktop (1.6.0-1) unstable; urgency=low

  * New stable upstream release (closes: #484071).

 -- Steve Kowalik <email address hidden> Mon, 28 Jul 2008 12:49:31 +1000

The patch is causing following regression:

 https://bugs.launchpad.net/ubuntu/+source/rdesktop/+bug/270997

This is also going to break tsclient with "Enable window Manager's Key Bindings" enabled.

This is causing regression with -K option

While this bug was fixed in Hardy, the fix stopped working in Intrepid, probably because of update of Xorg.
See bug 304044.

Removing regression-2.6.27 tag since this is not a bug due to the linux kernel 2.6.26->2.6.27 transition.

I can confirm the regression. I became a showstopper for myself due to StumpWM.

Here's a patch _to the patch itself_ that fixes -K by never (re)grabbing if grabbing is disabled. Please merge.

Typo: "It became", not me :-D

So, how do we get your Patch applied to the release build of rdesktop Simo?

I don't know, I haven't heard anything from this bug until now and I'm not sure how the Ubuntu bug tracking process goes. This bug doesn't seem to be assigned to anyone, however the nomination info on top points to ktp420.

However, I would like to see the changes in the release, too. I have since installed one new Ubuntu system and I just compiled rdesktop from apt-get source and applied my patch manually. And then put my custom rdesktop deb on hold to prevent an "upgrade" from the standard distribution :-)

He seemed to merged the original patch so maybe he can merge the patch which fixes the regression...hopefully in 9.04

Unfortunately, this bug still exists in 9.04 Jaunty, causing the small "v" being interpreted as an at-sign (@) and small "e" as an euro-sign (€) - just like with AltGr pressed - using czech keyboard layout. Pressing AltGr with these two letters produces them normally (v, e), so it's simply reversed behavior.

I can handle with this without any problems, but I can't imagine forcing regular users in our company to use rdesktop in this state of things.

I tested different combinations:

- Intrepid i386: affected
- Jaunty i386: affected
- Karmic amd64: affected

Using -y makes CAPS LOCK work with a US layout, but unfortunately:
- altgr presses ENTER
- arrowup doesn't work
- arrowdown launches the start menu
- arrowleft is alt
- arrowright doesn't work
- pgup presses slash
- pgdn doesn't work
- home doesn't work
- end doesn't work
- keypad enter presses arrowdown

Removing the 02_raw_keyboard_support.dpatch patches solves all problems. I tested every single key combination of the layouts I know.

Here are some links that refer to this bug:
http://ubuntuforums.org/showthread.php?t=975449
http://ubuntuforums.org/showthread.php?p=7075739#post7075739
http://ubuntuforums.org/showthread.php?t=977663

The raw keyboard patch is really broken, it modifies #define's so there is no clean way to have -y without breaking the regular behavior.

Besides, there is a large thread on the rdesktop mailing list:
http://sourceforge.net/mailarchive/forum.php?thread_name=a905f5230904142325g2e4d575bp35412af4a77fd4eb%40mail.gmail.com&forum_name=rdesktop-devel

I quote Peter Åstrand here:
"For a normal application, looking at the "keycode" is simply a big no-no.
Using the "keysyms" is the preferred approach; works on all platforms."

now if someone would just remove this bad patch I can use rdesktop normally again.

 Thank you for bringing this bug to our attention. Unfortunately a paper cut should be a small usability issue that affects many people and is quick and easy to fix. I'm afraid this bug can't be addressed as part of this project.

Since there is no simple/quick fix , this is NOT a papercut.

 A paper cut is a minor usability annoyance that an average user would encounter on his/her first day of using a new installation of Ubuntu 9.10.

 For further info about papercuts criteria , pls read > https://wiki.ubuntu.com/PaperCut

 Don't worry though, This bug has been marked as "invalid" ONLY in the papercuts project.

Without knowing the details, I'm a little surprised this isn't a simple/quick fix. Since this a regression, can't we simply revert to the old way of doing things? Judging by the number of bugs duped to this one it seems to me like the negative impact of this regression far outweighs any positive impact from the code which introduced the regression (that we would be reverting in the "simple" fix).

@sirianni:

The bug is still active ,it is ONLY not a part of papercuts project...
For further info about papercuts criteria , pls read > https://wiki.ubuntu.com/PaperCut

As workaround, since no one want to remove the bad patch, I have found that GTK+/Gnome Remote Desktop Client (GRDC) is great replacement for tsclient and vnc client/server. With GRDC I have not ran into any issues with keys with VNC or RDC and it even as way more features. Karmic as updated grdc package but it is really old in Jaunty. You can get the latest deb for following:

http://grdc.sourceforge.net/downloads.html

@ktp420: Original bug title says: "rdesktop works bad with several
keyboard layouts".

ktp420, can you please tell us what exactly keyboard layouts do you use?
And does your problem actually has something to do with typing letters
in several keyboard layouts, or you complain about something
different? If you complaints are about window manager key bindings,
what exactly works wrong -- i.e. what steps do you take, what do you
expect to get and what do you get instead?

I would appreciate your comments very much, since we are working now
on the solution.
And I also have to note that GRDC doesn't solve the original problem
of working with several keyboard layouts.
It works as bad as rdesktop does.

@Michael Lazarev: in my separate bug report, which was then marked as a duplicate of this bug, I described some symptoms with the fi keymap under VNC:

  https://bugs.launchpad.net/ubuntu/+source/rdesktop/+bug/381567

though they may not be the same or similar ones that ktp420 is concerned about.

@Juha Aatrokoski: I am aware of your bug report, but I was completely
confused after I read it, especially with "0=}" things.

Do I undestand correctly that you connect with VNC to some computer,
and then run there rdesktop?
Can you reproduce this bug if you run rdesktop locally, without VNC?
Do you run rdesktop with -y key, or without it?

And about the part which I don't understand completely: when you press
zero, shouldn't it send zero keycode to windows remote desktop? You
say that with a finnish keymap the '0' key should produce "0=}". What
do you mean?

Also, do I understand correctly that you have two keyboard layouts,
Finnish and English on the machine you work physically, the same
layouts on the machine you connect to with VNC, and the same two on
the Windows machine you work on with rdesktop? If so, you should have
8 combinations of layouts (En -> En -> En, Fi -> En -> En, En -> Fi ->
En, Fi -> Fi -> En, and so on). Does this bug reproduce on each
combination, or only on several ones?

rdesktop is run inside a VNC session, i.e. connect from desktop with vncviewer to a server running vncserver, and start rdesktop there. There was no problem running rdesktop locally (without -y, I did not try with -y as it worked without it).

I reported the effects of keypresses, perhaps in a confusingly compact form. The part "with itself/shift/altgr" meant that the '0' key should produce '0' when pressed alone, '=' with shift key pressed, and '}' with AltGr key pressed. Instead it produces '0' by itself (correctly), '0' with shift ("ignored modifier") and nothing with AltGr. For the key to the right of it the corresponding expected and actual results are "+?\" and "??\" ("assumed modifier").

All the servers and desktops, Linux and Windows, have finnish keymaps.

@Michael

Following is the original bug I had created and found out it was this patch that introduced since using deb without this patch everything worked correctly.

https://bugs.launchpad.net/ubuntu/+source/rdesktop/+bug/270997

I am using standard En keyboard layout. The issue I have seen is this patch basically broke all the non-asci keys, i.e. the arrow keys, home, insert, end, page up/down, ... were not working. If I remember correctly, even opening Notepad in remoted system and using arrow keys to navigate would do "weird" things.

@Juha Aatrokoski: now all is clear, thanks.
Stupid me, of course there is one layout, Finnish don't need to switch
to English one.
It's Russian layout which we must frequently change to English and
backwards. It gives many combinations, and even more weird effects. We
are onto some solution for users with several keyboard layouts, when
it will be ready, maybe it will solve VNC problem too.

I just little more testing with the latest rdesktop package for Jaunty.

The root issue I was talking about with the -K option not working still remains. The non-asci keys not working only applies to -y option and might not be a bug (I really don't know what -y does internally).

To reproduce:

launch rdesktop with -K or tsclient with Enable window Manager's Key Bindings" checked in Performance tab. I also had fullscreen but doesn't work either way.
Type inside the remote session, like typing your password at the login screen.
use the ctrl+alt+arrow keys to switch desktops

This is working correctly in Hardy or when you downgrade to 1.6.0-0ubuntu2 version of rdesktop...so it is a regression.

@ktp420: so, you have only one keyboard layout: English, right?

Yes, -y option introduced by this patch made keyboard work absolutely
correctly in Hardy.
Then, starting from Intrepid, running rdesktop with -y caused arrow
keys and alike to stop working. Without -y option, keyboard in Russian
layout made weird things, but arrows were working. So, if you have
English layout only, and didn't use -y option, it must be that this
patch didn't affect you in that sense.

You might not reproduce the text from the Bug 270997, it was read
thoroughly several times, I know it by heart.
When you run rdesktop with -K option in windowed mode, ctrl+alt+arrow
really should switch desktops.
Also, did you manage before to switch desktops in full-screen mode?
I mean, desktops could be switched, but you still don't see them
behind the full-screen rdesktop window.

@Michael, Yes I am only using English.

I thought this patch introduced -y. There was no -y before this patch. That is why downgrading to rdesktop_1.6.0-0ubuntu2_amd64.deb, just before this patch was merged in Intrepid, everything works.

Before this patch, I was able to switch desktops in full-screen mode. You had to use ctrl+alt+Enter to make it stick to one face of the cube. If you didn't use ctrl+alt+Enter, then you can see the desktop switch but full-screen rdesktop window would be on all the workspaces.

But after this patch, running rdesktop with -K option (without the -y option) Window Manager's Key Bindings do not work in either full-screen or windowed mode, If you run rdesktop with -K and -y, then Window Manager's Key Bindings work but non-asci keys don't work.

Found a solution that will at least temporarily allow using rdesktop with this patch per http://ubuntuforums.org/showthread.php?t=977663&page=2 shamelessly (ripped from Xires' post). Modifying as specified below will at least allow users to work around this bug (or at least I haven't hit an issue yet). The latest Debian unstable package is another option...

--- /usr/share/rdesktop/keymaps/common.orig 2009-01-15 12:32:10.000000000 -0600
+++ /usr/share/rdesktop/keymaps/common 2009-01-15 12:00:40.000000000 -0600
@@ -225,5 +225,6 @@
#
# Inhibited keys
#
-Caps_Lock 0x0 inhibit
+#Caps_Lock 0x0 inhibit
+Caps_Lock 0x3a capslock
Multi_key 0x0 inhibit

With a small modification to 02_raw_keyboard_support.dpatch, this problem goes away for me. If g_grab_keyboard is checked before doing a XGrabKeyboard or XUngrabKeyboard, everything works correctly. Someone using an international keyboard setup should verify as I only use QWERTY English.

315c315
< + if ( g_focused && g_grab_keyboard && g_modeswitch_down ) XUngrabKeyboard(g_display, CurrentTime);
---
> + if ( g_focused && g_modeswitch_down ) XUngrabKeyboard(g_display, CurrentTime);
327c327
< + if ( g_focused && g_grab_keyboard && !g_modeswitch_down ) XGrabKeyboard(g_display, g_wnd, True, GrabModeAsync, GrabModeAsync, CurrentTime);
---
> + if ( g_focused && !g_modeswitch_down ) XGrabKeyboard(g_display, g_wnd, True, GrabModeAsync, GrabModeAsync, CurrentTime);

This problem is still present in Jaunty and Karmic RC (whatever US or French keyboard).

I'm going to try Michael's patch above.

Here is PPA for Karmic package with the patch if anyone wants to use it since this bug is not going to be fix for two releases now...let see it is going to be three in six/seven more months.

https://launchpad.net/~ddumont/+archive/ppa/

The patch didn't seem to fix the problem :(

On Fri, Oct 23, 2009 at 7:19 PM, ktp420 <email address hidden> wrote:

> Here is PPA for Karmic package with the patch if anyone wants to use it
> since this bug is not going to be fix for two releases now...let see it
> is going to be three in six/seven more months.
>
> https://launchpad.net/~ddumont/+archive/ppa/
>
> --
> rdesktop works bad with several keyboard layouts
> https://bugs.launchpad.net/bugs/251709
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in NULL Project: Invalid
> Status in “rdesktop” package in Ubuntu: Confirmed
>
> Bug description:
> Binary package hint: rdesktop
>
> Many people have many errors while working with rdesktop on a remote host
> having two or more keyboard layouts.
> For example, russian letter 'Б' sometimes are recognized as if it was
> pressed with Alt.
> Sometimes it works fine, sometimes symbols "." and "," do not work
> properly.
>
> One man founded a solution (raw keyboard support), it deskribed here:
> http://habrahabr.ru/blog/ubuntu/45595.html
>
> Alt Linux maintainers added patch to rdesktop, it's located here:
> http://sisyphus.ru/srpm/Sisyphus/rdesktop/patches
>
> After patch is applied, it is possible to use option '-y' to use raw
> keyboards. After that all problems with two or more keyboard layouts go
> away.
>
> Please include this patch while building this package.
>

Ok.

After some wide investigations (checking raw keyboard scan codes with "showkey", checking Xorg key codes with "xev", checking GNOME keyboard selection, checking/removing SCIM/iBus keyboard alteration in the way, checking console keyboard choice in "/etc/default/console-setup") and after trying to tune rdesktop keyboard files, some friend and I found that the problem in our case can be separated in two parts:
- rdesktop's capslock problem, easily solved using the solution given in comment #29
- xorg's numeric keypad decimal separator problem, easily solved with the following Xmodmap entry:
  keycode 91 = KP_Delete KP_Decimal KP_Delete KP_Decimal KP_Delete KP_Decimal

I can't understand why this solution to the capslock problem has not been integrated since Intrepid... There is only people telling it works, nobody complaining about regression after that, so what?!?

About the numeric keypad decimal problem, in our case it's specific to the French keyboard (no problem with the US keyboard) which defines it this way:
  keycode 91 = KP_Delete period KP_Delete period comma U202F comma U202F KP_Delete period

The French keyboard I'm talking about is this one (from "/etc/default/console-setup") :
  XKBMODEL="pc105"
  XKBLAYOUT="fr"
  XKBVARIANT="oss"
  XKBOPTIONS=""

This hasn't been fixed due to a simple lack of time on my part. If you want to make it easier to get it fixed, prepare a debdiff, attach it to this bug, and then subscribe ubuntu-universe-sponsors. If you do it within the next two weeks, I'm sure it would land very easily in Lucid.

Thanks for the directions. Starting to learn how to use debdiff...

This package is in main (at least for karmic). So you should subscribe ubuntu-main-sponsors instead.

It appears _there actually is_ some wrong/bad consequences when activating capslock, especially when going in/out the rdesktop window. It then sometimes makes the capslock modifier apparently stuck (permanently active) in the GNOME environment which alter a lot of keyboard and mouse actions.

It's all suppositions (for now) because I didn't experienced that myself (it was some colleagues reporting it). So I will investigate more (since we badly need it at work) before posting a debdiff.

When working on this bug, we come to conclusion, that keyboard
handling in rdesktop is done in a conceptually wrong way. I attach two
executables we got so far, and they work in our office. We run them as
"rdesktop -y ..." That -y switch is essential. If you can try it and
it works for you, please report this. We worked on handling all the
keys in a proper way in the first place. Desktop switching and window
manager keys handling is another story, and we didn't change anything
in this part yet.

I am sorry for such extravagant way of proposing a solution for
testing, when I'll get that .deb infrastructure myself, or somebody
will point me how to publish a patch in a proper way, I'll do that.

Your feedback is much anticipated.

I'm test your rdesktop-9.10 -y, russian and english keyboard layouts works perfect (i mean rus/eng in system and rus/eng in rdp session) thanks. -K still broken, but it is another bug and i do not understand, why it marked as dublicate of this.

About proper way of .deb pathing:

~$ mkdir rdesktop-deb
~$ cd rdesktop-deb
~$ apt-get source rdesktop
~$ cd rdesktop-1.6.0/debian/patches
~$ ls
~$ cat 00list
~$man dpatch

you can add you own patch or replace current 02_raw_keyboard_support.dpatch by yours.

I don't know why the other bug, -K bug, was closed as dup of this but it is proven that this patch or bug fix caused the -K regression. So I would hope whatever fix that is provided fixes the -K regression also.

This solution may not work for everyone. To get caps lock to work, I used the rdesktop client. I specified 'none' as the keyboard layout i.e...

rdesktop -k none remoteserver.com

I have no idea why it worked, but since this bug can be a dealbreaker for mass deployment of Ubuntu in a business environment, I have to throw this "workaround" out there. Mileage may vary since there's no telling how the particular server may respond to being told there's no keyboard layout.

Thanks people, but in my case (Notebook US Keyboard, French Windows server) neither "-y" nor "-k none" is acceptable. In both case capslock works but the arrow keys stop working.

@Jean Christophe André:

Even with binaries I provided here
(https://bugs.launchpad.net/ubuntu/+source/rdesktop/+bug/251709/comments/39)
?

@Michael: since we use rdesktop to access our accounting system, I can't stand to test binary only files. Could you provide a .diff against Ubuntu rdesktop sources please?

Of course!
If I did everything correctly, here it is.
By no means, it is a production code, and I disclaim any warranties. :)

@Michael: I've just tested binary you attached in post #39 and noticed that it works much better then the original one in 9.10. The only bug in russian layout i found is that the slash key in numeric keypad puts a dot (or comma if shifted). A command line is the following: rdesktop -a15 -u Admin -y -k en-us -N -f 192.168.110.110

@Michael: could you re attach that diff with the arguments: diff -Naur I am working on updating the latest version for lucid and would like to test your patch to see if it will be included.

@Manny Vindiola:

Here it is. I made a diff of original rdesktop-1.6.0 package with two
(01_paging, 02_raw_keyboard_support) dpatches applied, and our
version.

@valerykk:
thanks for such kind words.
As for the bug with numeric slash, we know about it, and know what
exactly causes it.
We still need some time to figure out the sane way to fix it.

@Michael
Thanks for the patch. I have been testing it and it is definitely a big improvement over the current version. I have not found any problems when -y is enabled, but I only have a US layout so I am not the best person to test this. There is one bug that still remains rdesktop -K host does not work correctly. I incorporated the patch listed here by Michael Ryan and that fixed the prooblem but it introduced a new one CAPS lock no longer works. Since you see to have the best understanding here of how the code all fits together do you have any insight as to why this might be?

I think I might have a fix for this. I would like to include this in Lucid but obviously it is going to need some testing before hand. The way it currently stands is obviously not acceptable for a LTS version. I would appreciate if people would try this version out and give me feedback.

Apparently there is still an open bug in the russian layout. I dont use multiple keyboard layouts so I cannot test this. @Michael you seem to know how this can be fixed, is that correct?

You can find the package on my ppa: deb http://ppa.launchpad.net/serialorder/ppa/ubuntu karmic main

 or here http://ppa.launchpad.net/serialorder/ubuntu/pool/main/r/rdesktop/

@Manny:

Yesterday I downloaded rdesktop_1.6.0.orig.tar.gz and
rdesktop_1.6.0-3ubuntu1~ppa1.diff.gz from your PPA, and tried to
analyze it thoroughly. I must admit that you did a great work of
taking all these patches together!

Today I tested rdesktop from your PPA in our office.

First, I have to say I *always* use -y switch, because without it
rdesktop uses *very* unreliable, in soft words, algorithm. From the
code I have read it seems that its developers are smart people, and I
still can't believe how could they choose such way of handling
keyboard!

With -y switch, TAB works properly, and I only encounter two bugs
related to key handling: 1) numeric slash behaves like "/" key near
right shift; 2) Break/Pause key does nothing. We know what caused both
bugs, and working on solution now.

Second, regarding -K switch. I need some detailed explanations here. I
generally don't use it, but as I can tell, in rdesktop from your PPA,
and in original rdesktop from 8.04, it works similarly. I can't find
any bugs here. Except when not using -y, you get broken TAB key, but
we just didn't notice it here, because of bigger problem: not using -y
results in a mess instead of Russian layout.

Also, I don't get several things about -K. Do you use Alt+F4?
Actually, it's window manager key binding, so you must expect that
whole rdesktop window will close. So it does. Is it OK? As for me,
that was unpleasant surprise. What about PrintScreen? With -K switch,
must it take a screenshot in Windows, or in Ubuntu? For now, it does
this in Ubuntu, and screenshot dialog is invisible until rdesktop
window is minimized, because it is below that window. I find this
wrong, and believe that when rdesktop window is active, PrintScreen
must take a screenshot inside Windows. Only if rdesktop window is
inactive, it must take a screenshot in Ububntu. Do I get right that
actually only CTRL+ALT+LEFT_ARROW and CTRL+ALT+RIGHT_ARROW are the key
bindings users want to pass to Window Manager?

Maybe there must be some config file so that a user could set up
particular keys which must be handled by Window Manager. All other
keys will be sent to remote Windows desktop.

Our sales department kindly agreed to test starting from tomorrow the
version you provided, so there will be a followup.

> Do I get right that actually only CTRL+ALT+LEFT_ARROW and
> CTRL+ALT+RIGHT_ARROW are the key bindings users want to pass to
> Window Manager?

I'd regard that as a bug. It should not intercept any key that the window manager has bound. I for instance have bound F1-F5 (without modifiers) to switch to designated work spaces. I know fully well that they override same keys in the rdesktop session, but I find the workspace switching more useful than whatever they might do on the remote side.

C.f. bug #270997, which may or may not be a duplicate of this one, but is marked as a duplicate nevertheless.

This bug #251709 (keyboard layout) is really getting confused with #270997 (window manager keystrokes). It concerns me unless these are split up as separate bugs, #251709 will get fixed but #270997 will be forgotten.

I agree with Martin - every window manager has a different set of key strokes to change windows. Under ratpoison for example, anything prefixed with ctrl-t is intended for ratpoison. As latest versions of rdesktop swallow this keystroke, it makes it impossible to change windows (as ratpoison does not have any other mechanism to change windows). It isn't rdesktop's job to second guess what window manager I have installed or what keystrokes it uses.

I could imagine a need to pass every keystroke to rdesktop in some situations, however please make it possible to override this behavour and/or change the default.

Brian May

@Martin Stjernholm and @Brian May and everyone else who is concerned with the -K switch. I am sorry I was not clear last time. The version I posted on my ppa has incorporated both the fix to support -y correctly (in most cases so far) and a seperate fix to make -K behave correctly.

@Michael Lazarev
Thanks for the quick response and the deployment in your organization that will definitely help wrt testing. As people have mentioned when key-binding is enabled people generally want to preserve all the key bindings. Making this a more configurable option where it is possible to specify which key bindings to preserve and witch to ignore and propagate to the remote client is really a new feature and not a bug fix. Right now I would like focus specifically on the bug fix to get rdesktop to behave as it would if the -y switch were not present. When this is done and we are sure it works I will forward the changes upstream since clearly the application itself has problems with they way it handles keyboard input. If you are interested in adding the configurable key bindings that is something you should coordinate with the upstream developers.

Do you know if <TAB> not working with a Russian keyboard layout is introduced by our ubuntu specific changes? I.E. would it be present in the latest debian version as well which does not have raw keyboard support? If I understand you correctly you are saying that the russian layout just doesnt work very well at all without raw keyboard support is that correct?

if anyone is interested...there is a fork of rdesktop, which as one of the planned feature is to have "New keyboard input system, based on the XKB configuration database":

http://freerdp.sourceforge.net/

I tested rdesktop from PPA and found some problem with alt key:
When i press Alt+Shift (left Alt+Shift) layout must change (EN <-> RU) but nothing happen. But, it working with right Alt + right Shift !
With enabled debuging (--with-debug-kbd) when i press left Alt key i see in console:

vk_handle_key = 0x40 vk = 0x0
Before: vk_handle_key = 0x40 vk = 0x0

next, i found this code:
vk = vkscancode[ xkey->keycode];
DEBUG_KBD(( "vk_handle_key = 0x%x vk = 0x%x\n", xkey->keycode, vk));

as i understand vk = 0x0 because keycode 0x40 can not be found in vkscancodes[] array. Ok, looking on xkeymap_init(void) function:
vkscancode[XKeysymToKeycode(g_display, XK_Alt_L)] = SCANCODE_CHAR_LALT;

There we have XKeysymToKeycode(g_display, XK_Alt_L) function. It must return 0x40 keycode, but if we add next line at the end of xkeymap_init() function:
+ DEBUG_KBD(("Scancode1: 0x%x, scancode2=0x%x\n", XKeysymToKeycode(g_display, XK_Alt_L), SCANCODE_CHAR_LALT));

we will see:
Scancode1: 0xcc, scancode2=0x38

it return 0xCC , why?
Sorry if i don't understand something.

Problem fixed. It was my error, not a patch problem.
Some time before when i try configure rdesktop without raw mode, i comment one string in /usr/share/X11/xkb/symbols/altwin file:
    key <LALT> { [ Alt_L, Meta_L ] };

That was a reason for strange scancode in XKeysymToKeycode(g_display, XK_Alt_L)

Caps Lock still doesn't work in Lucid

2010/5/4 Alvin <email address hidden>:
> Caps Lock still doesn't work in Lucid
>
> --
> rdesktop works bad with several keyboard layouts
> https://bugs.launchpad.net/bugs/251709
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
idem

--
Atentamente

Andrés Genovez Tobar / Sistemas
Elastix ECE - Linux LPI-1 - Novell CLA - Apple ACMT
http://www.crice.org

Well with the -K not working it kind of locks up the client system. I was not able to click on the menu or switch to another desktop. As a result in order to get back to the client I have to interact with the server which may or may not go away nicely.

Not really functional for my uses. So the work around I have been employing is to fall back to a version that works for my use case.

https://launchpad.net/ubuntu/+source/rdesktop/1.6.0-0ubuntu2/+build/652180/+files/rdesktop_1.6.0-0ubuntu2_i386.deb

2010/5/14 Mike Power <email address hidden>:
> Well with the -K not working it kind of locks up the client system.  I
> was not able to click on the menu or switch to another desktop.  As a
> result in order to get back to the client I have to interact with the
> server which may or may not go away nicely.
>
> Not really functional for my uses.  So the work around I have been
> employing is to fall back to a version that works for my use case.
>
> https://launchpad.net/ubuntu/+source/rdesktop/1.6.0-0ubuntu2/+build/652180/+files/rdesktop_1.6.0-0ubuntu2_i386.deb

Did you use -y?

2010/5/15 Loafer <email address hidden>

> 2010/5/14 Mike Power <email address hidden>:
> > Well with the -K not working it kind of locks up the client system. I
> > was not able to click on the menu or switch to another desktop. As a
> > result in order to get back to the client I have to interact with the
> > server which may or may not go away nicely.
> >
> > Not really functional for my uses. So the work around I have been
> > employing is to fall back to a version that works for my use case.
> >
> >
> https://launchpad.net/ubuntu/+source/rdesktop/1.6.0-0ubuntu2/+build/652180/+files/rdesktop_1.6.0-0ubuntu2_i386.deb
>
>
> Did you use -y?
>
> --
> rdesktop works bad with several keyboard layouts
> https://bugs.launchpad.net/bugs/251709
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

Cps Lock don´t work on Lucid either :(

--
Atentamente

Andrés Genovez Tobar / Sistemas
Elastix ECE - Linux LPI-1 - Novell CLA - Apple ACMT
http://www.crice.org

I have problems with keys, for example with E. Error messages following a connection are enclosed.

By the way, I am using the latest version of Ubuntu, 10.04.

I have the same problem with czech layout in rdesktop1.6.0-2ubuntu3; e. g. "nekvasilj" becomes "n€kv@silj". Option -y (which isn't even mentioned in man page) fixes that for me.

re #67
-y option solves some problems but many of them persists.
I can't use Home, End, Page Up, Page Down, arrow keys, Numeric Enter etc. ;?(

re #68

Confirm such problem on karmic and lucid. Arrows acts like ALT+somekey or even more complex.

Thanks to Manny Vindiola, your package works.

Hi,

Why it is not in the mainstream?

2010/8/5 skygunner <email address hidden>

> Thanks to Manny Vindiola, your package works.
>
> --
> rdesktop works bad with several keyboard layouts
> https://bugs.launchpad.net/bugs/251709
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

--
Atentamente

Andrés Genovez Tobar / Sistemas
Elastix ECE - Linux LPI-1 - Novell CLA - Apple ACMT
http://www.cspmsa.com
<email address hidden>

Jabber: <email address hidden>
Comunidad: http://www.crice.org

re #71

Cause maintainers do not care about not-english users.
Another exammple is bug 36812:
https://bugs.launchpad.net/ubuntu/+source/control-center/+bug/36812

I've removed the raw keyboard patch from Maverick due to the number of reports that it breaks non-raw mode and the sourceforce/debian versions do not. I understand that without this patch some keyboard layouts may experience problems - in this case please try remmina (available in the software centre) as this uses an updated version of rdesktop that has improved keyboard support.

Robert,

All of the people who have tested it have said that my patch and build
in my ppa has fixed their problem. I also have not heard any reports
of causing any regressions for anyone. Perhaps it would be worth
incorporating that patch into maverick?

Manny

On Thu, Sep 9, 2010 at 10:49 PM, Robert Ancell
<email address hidden> wrote:
> I've removed the raw keyboard patch from Maverick due to the number of
> reports that it breaks non-raw mode and the sourceforce/debian versions
> do not. I understand that without this patch some keyboard layouts may
> experience problems - in this case please try remmina (available in the
> software centre) as this uses an updated version of rdesktop that has
> improved keyboard support.
>
> --
> rdesktop works bad with several keyboard layouts
> https://bugs.launchpad.net/bugs/251709
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in NULL Project: Invalid
> Status in "rdesktop" package in Ubuntu: Confirmed
>
> Bug description:
> Binary package hint: rdesktop
>
> Many people have many errors while working with rdesktop on a remote host having two or more keyboard layouts.
> For example, russian letter 'Б' sometimes are recognized as if it was pressed with Alt.
> Sometimes it works fine, sometimes symbols "." and "," do not work properly.
>
> One man founded a solution (raw keyboard support), it deskribed here:
> http://habrahabr.ru/blog/ubuntu/45595.html
>
> Alt Linux maintainers added patch to rdesktop, it's located here:
> http://sisyphus.ru/srpm/Sisyphus/rdesktop/patches
>
> After patch is applied, it is possible to use option '-y' to use raw keyboards. After that all problems with two or more keyboard layouts go away.
>
> Please include this patch while building this package.
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/null/+bug/251709/+subscribe
>

2 Robert Ancell:
Remmina does NOT use rdesktop (maybe therefore it is not so buggy...), it uses FreeRDP instead. As for me, i switched to remmina and now happy, it seems to be perfect - no sticky Alt, no desappearing slash and problems with num-pad, any layout switch works without surprises. Recommend to all!

Here are my tests done with:
Host: Ubuntu 9.10 32bit vmware vm Remote: windowsXP vm
Host: Ubuntu 10.04 64bit Remote: windowsXP vm
Italian language and keyboard

-y option gave me many trouble so I do not use it.

Remmina can lost the Caps-Lock sync status between the host and the remote pc:
if I exit from the Remmina window, enable the caps-lock and reenter in the Remmina window, then the caps-lock light will be on but I will write lowercase.
Seamless window is not supported by Remmina.
Other things are ok: key "è" write "è" and shift+è write "é" with caps-lock on or off

With rdesktop 1.6.0-2 (from Ubuntu repository)
caps-lock do not work but it is in sync between the host and the remote pc.
With caps-lock on, "è" will write "e" and shift+è will write "éE"

With rdesktop_1.6.0-3ubuntu1~ppa1 from Manny Vindiola:
Caps-lock can lost sync like with Remmina.
With caps-lock on, shift+è will write "ée"

With rdesktop 1.5.0-3
With caps-lock on, pressing shift+è do not write "é" but "éE". Idem with shift+ò.
Caps-lock status is always sync between host and remote pc.

In my case:
rdesktop 1.6.0-2 is unusable because I must press shift+a to write "A"
rdesktop_1.6.0-3ubuntu1~ppa1 is not good for me because I can lost the capslock sync.
Idem for Remmina.
Also, I need to launch the connection with a script and I do not know how to do with Remmina.
Seamless windows is really usefull too (especially for inexperienced users that do not understand why there are two close buttons...)

So, rdesktop 1.5.0-3 is still my choice for now.

Sorry for bad english.

Manny Vindiola's version solved my problem, but when using rdesktop with "-k fr" option caps-lock work but it is inverted (on = lower case letters, off = upper case letters). Removing that option, everything works well.

Sorry, I forgot something:
when I remove the "-k fr" option, my complete rdesktop command is:
rdesktop -K -N -P -z -x m -r clipboard:yes -T title [ip]
using only rdesktop [ip] it works like with the "-k fr" option (inverted caps-lock)

This bug has never been fixed, now in 2016 and it's still present!

@Francois, if you have message "Autoselected keyboard map ru", try to run rdesktop with *correct* value of "-k" key, for example "-k en-us".