Ctrl_R or Alt_R Key Can Not Be Released

[xu3stones]

Is there anyone can give me some information? I would be very grateful.

I have met several times that the right ctrl key or right alt key is in a pressed status and never released.
I use noVNC as my vnc client to connect my virtual machine. What confused me is that, noVNC client seems automatically convert the right ctrl/alt to the left ctrl/alt which means noVNC will not be possible to send right ctrl/alt key to Qemu vnc sever. What's more, I have never pressed any ctrl or alt key. This may happen even as soon as I use vnc to connect my VM which is now in the login interface.

The phenomenon is described as below:
1. When I press 'a', the vnc client outputs '^A', and 'b' is '^B'... Then I try
virsh qemu-monitor-command --hmp VM1 sendkey 0x9d ---> 0x9d is left ctrl up scancode
it does not work.
but if I try
virsh qemu-monitor-command --hmp VM1 sendkey 0xe0-0x9d ---->0xe0-0x9d is Ctrl_R up scancode keyboard works right!
So I'm sure this phenomenon is caused because right ctrl key is in a pressed status.
*2. * Other several times, when I press '1', vnc outputs noting, '2' is '@', '7' is '{', '8' is '['...
It is obviously that my third function key (right alt/altgr) is in pressed.
Then I try virsh qemu-monitor-command --hmp VM1 sendkey 0xe0-0xb8
0xe0-0xb8 is Alt_R up scancode keyboard works again.
The keymap of vnc, qemu and guestOS are all en-us.

Is this a bug of noVNC?

noVNC version: 0.4

[samhed]

I can't recall seeing the behavior with ctrl or alt being stuck.

However, the right ctrl/alt being sent as their left counterparts I did know. For a list of keyboard problems with noVNC, see this bug (ThinLinc uses noVNC for the HTML5 client).

[samhed]

To further explain: First, it's not noVNC that converts keys such as right Alt and Ctrl to the left versions. This is behavior comes from the browsers themselves. There is nothing we can do here except trying to convince the browser vendors to fix this for us. However, there are very few web applications that use this part of the keyboard events in the browsers.

Secondly, with regards to the actual information that is sent over the RFB protocol; Most VNC servers expect keysym values on keyboard input. These values, as the name suggests, represent symbols and not hardware keys. This does in turn of course have it's own advantages and drawbacks which we don't have to dive in to for now. But the way VNC works today means that you can not always expect to generate the same keypresses on the server as what the user pressed on their physical keyboard. I can give an example of an effect of what the above means, to explain that this can indeed be confusing:

If the user on the client side uses a Swedish layout and inputs the letter 'ö', this symbol is sent to the server and, if the server layout is US_int, the server will simulate keypresses for 'AltGr' and 'p'.

However, there is hope! The RFB protocol has an extension from QEMU that allows the VNC client to, in addition to the keysym, send a keycode.

The advantage of providing the keycode is that it enables the server to interpret the key event independantly of the clients' locale specific keymap. This can be important for virtual desktops whose key input device requires scancodes

Support for this extension has recently been added to noVNC. But it's very important to remember that keycodes are not standardized which means that there are some incompatibilities. In general you should be much better of using QEMU with noVNC now-a-days.

[bill-mcgonigle]

This is probably as close to the right bug report as I can find ...

I just spent a few hours trying to figure out why control was stuck on a qemu host that I usually access with NoVNC. I eventually was able to switch the provider's VNC setting to a standard VNC port, fire up TigerVNC and based on the info here tap the right control key on my keyboard which fixed everything right away.

I wonder if NoVNC can do anything to keep the key map clean or offer a way to reset it if things foul up? Since I have always accessed that console with NoVNC exclusively I'm not sure how right control got stuck on in the first place.

[CendioOssman]

I'm afraid this is likely not the correct bug. The keyboard code has gotten lots of fixes since this issue.

Please file a new issue and make sure to fill out all the entries in the issue template. Then we can have a look.