[
https://issues.apache.org/jira/browse/GUACAMOLE-349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17151438#comment-17151438
]
Nick Couchman commented on GUACAMOLE-349:
-----------------------------------------
[~sebastian.ohmsen]: Are you able to re-test in version 1.2.0? There were
significant keymap updates that may have resolved this...
> RDP keymap translation unnecessarily presses SHIFT_L when SHIFT_R is held
> -------------------------------------------------------------------------
>
> Key: GUACAMOLE-349
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-349
> Project: Guacamole
> Issue Type: Bug
> Components: RDP
> Reporter: Sebastian Ohmsen
> Priority: Minor
>
> We've come across a bug that is corrupting the user input for guacamole
> sessions over rdp. The problem only occurs when you open a RDP session inside
> the RDP session established by guacamole. Our use case is that we connect to
> a Hyper-V server and would open the console of a VM running on it. You can
> very well test that too with connecting to any RDP server from the connection
> established by guacamole.
> We've tested this extensively and we can observe the following: Whenever you
> press a key combination that produces another result by adding a modifier
> key, like "SHIFT_R + ."(dot) which should lead to an ">" sign, it's only a
> matter of time when this is mapped to a "."(dot) sign. This does not only
> occur when you hold both keys down, it also occurs occasionally when you
> press it the first time. This makes entering passwords super hard and seems
> to be a bug.
> We've traced it down to the corresponding C code and think the problem is
> here:
> https://github.com/apache/incubator-guacamole-server/blob/master/src/protocols/rdp/keyboard.c#L261
> In some cases of extra mapped keys, for example in the above case, it's
> sending more keys than expected. We can see that “SHIFT_L + .” results in
> following keysym updates:
>
> * 0xFFE1 (SHIFT_L) pressed
> * 0x003E (>) pressed
> * 0x003E (>) released
> * 0xFFE1 (SHIFT_L) released
> and works perfectly fine. In contrast “SHIFT_R + .” results in following
> events:
> * 0xFFE2 (SHIFT_R) pressed
> * 0xFFE1 (SHIFT_L) pressed
> * 0x003E (>) pressed
> * 0xFFE1 (SHIFT_L) released
> * 0xFFE1 (SHIFT_L) pressed
> * 0x003E (>) released
> * 0xFFE1 (SHIFT_L) released
> * 0xFFE2 (SHIFT_R) released
> which leads to the described behavior above.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
