Non-US keyboard layouts

ditron commented 14 years ago

A nice feature for me and all others with non-US keyboards is to add a keyboard layout option list and/or trying to auto detect locale settings from the browser.

clnperez commented 9 years ago

Thanks. That seems to work now. I'm having trouble reproducing the issues I'm hearing about without a non-US keyboard, so I'll have to come back to this when I can be of more help.

clnperez commented 9 years ago

I now have a German keyboard and can get back to this.

Right now using noVNC and a Ubuntu guest I´m seeing a popup when I press ö, ä, or ß. The popup says, "No map for [key]."

Using the input.html, ö gives 1: raw key event keydown (key: 0, char: 0, which: 0) 2: raw key event keypress (key: 0, char: 246, which: 246) 3: RFB keypress down keysym: 246 key name: 246 4: raw key event keyup (key: 0, char: 0, which: 0) 5: RFB keypress up keysym: 246 key name: 246

and I have no idea if that's correct or not. :)

Also, nothing shows up on the canvas, so, that probably needs to be fixed as well.

DirectXMan12 commented 9 years ago

@clnperez : the canvas is just there to act as a focus for the input events

When you get a popup, do you mean the VNC target gives you a popup, or the browser gives you a popup?

clnperez commented 9 years ago

@DirectXMan12 The VNC target gives the popup.

danielhb commented 9 years ago

I am experiencing these issues using a Brazilian ABNT2 keyboard (it is similar to the en_us layout but with the cedilla 'ç' key and a couple changes in the accent keys). When trying to get accents such as 'ã', 'à', 'á' or 'â' (which are the combination of ~. `, ' and ^ keys plus 'a') nothing is displayed in Chrome (latest) and Firefox (36.0). The cedilla key, however, works.

Input.html output shows that for all the above dead keys noVNC provides no mapping:

0: Display initialized 1: raw key event keyup (key: 219, char: 0, which: 219) 2: raw key event keyup (key: 222, char: 0, which: 222) 3: raw key event keyup (key: 219, char: 0, which: 219) 4: raw key event keyup (key: 222, char: 0, which: 222)

Only raw key events are displayed.

This is the mapping for the working cedilla key:

19: raw key event keydown (key: 186, char: 0, which: 186) 20: raw key event keypress (key: 231, char: 231, which: 231) 21: RFB keypress down keysym: 231 key name: 231 22: raw key event keyup (key: 186, char: 0, which: 186) 23: RFB keypress up keysym: 231 key name: 231

I am trying to solve the problem by looking in keyboard.js but so far no luck. Any tips?

jalfd commented 9 years ago

@clnperez that output looks correct. noVNC is sending an ö to the VNC server. I suspect the problem is on the server side then.

@danielhb which OS are you using?

There is a known big in Firefox on Linux (https://github.com/kanaka/noVNC/issues/350) that prevents dead keys from working.

The reason ç works for you, but other accented characters don't is that on a Brazilian keyboard, ç is a separate key, while stuff like ã are composed using a dead key.

0: Display initialized 1: raw key event keyup (key: 219, char: 0, which: 219) 2: raw key event keyup (key: 222, char: 0, which: 222) 3: raw key event keyup (key: 219, char: 0, which: 219) 4: raw key event keyup (key: 222, char: 0, which: 222)

Looks like you're only getting keyup events from the browser. If you never get keydown/keypress events, there's not much noVNC can do. Do you get this output in both Firefox and Chrome? That seems weird.

danielhb commented 9 years ago

OS: Fedora 21 x86_64

Just did the test again with Chrome (Version 41.0.2272.118 (64-bit) ) and Firefox (37.0.1). This time I pressed the same dead key (key " ' ") multiple times:

Results in Chrome:

0: Display initialized 1: raw key event keyup (key: 219, char: 0, which: 219) 2: raw key event keydown (key: 229, char: 0, which: 229) 3: raw key event keyup (key: 219, char: 0, which: 219) 4: raw key event keyup (key: 219, char: 0, which: 219) 5: raw key event keydown (key: 229, char: 0, which: 229) 6: raw key event keyup (key: 219, char: 0, which: 219) 7: raw key event keyup (key: 219, char: 0, which: 219) 8: raw key event keydown (key: 229, char: 0, which: 229) 9: raw key event keyup (key: 219, char: 0, which: 219)

In Chrome I can say that I can only get a keydown after the second time I press the same dead key. If I press 2 dead keys alternately (" ' " and " ~ " for example) I get only keyup events:

0: Display initialized 1: raw key event keyup (key: 219, char: 0, which: 219) 2: raw key event keyup (key: 222, char: 0, which: 222) 3: raw key event keyup (key: 219, char: 0, which: 219) 4: raw key event keyup (key: 222, char: 0, which: 222) 5: raw key event keyup (key: 219, char: 0, which: 219) 6: raw key event keyup (key: 222, char: 0, which: 222) 7: raw key event keyup (key: 219, char: 0, which: 219) 8: raw key event keyup (key: 222, char: 0, which: 222) 9: raw key event keyup (key: 219, char: 0, which: 219) 10: raw key event keyup (key: 222, char: 0, which: 222)

Results in Firefox (pressed the key 3 times):

0: Display initialized 1: raw key event keydown (key: 0, char: 0, which: 0) 2: raw key event keypress (key: 0, char: 0, which: 0) 3: raw key event keyup (key: 0, char: 0, which: 0) 4: raw key event keydown (key: 0, char: 0, which: 0) 5: raw key event keypress (key: 0, char: 0, which: 0) 6: raw key event keyup (key: 0, char: 0, which: 0) 7: raw key event keydown (key: 0, char: 0, which: 0) 8: raw key event keypress (key: 0, char: 0, which: 0) 9: raw key event keyup (key: 0, char: 0, which: 0)

danielhb commented 9 years ago

Let me report the things that are getting in my way at this moment:

• browser differences. Each browser treats keyboard events in a different manner. Firefox doesn't provide any keyCode for the dead keys. Chrome doesn't provide all the events when pressing a dead key. At this moment it will be very hard to fix this bug in a cross-browser way

• the attribute keyCode is deprecated according to the Moziilla docs (https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent). We're now supposed to use KeyboardEvent.key attribute instead, but, at this moment, this attribute is not fully implemented by any browser. Firefox 37 has partial support for it but without dead keys yet. There is a bug opened to track the implementation by Mozilla (https://bugzilla.mozilla.org/show_bug.cgi?id=680830). In my opinion noVNC will need to review the keyboard.js implementation when this attribute became available, not using keyCode at any point or only if the browser has no other alternative.

• With the current keyCode implementation in Chrome I didn't find a way to implement accentuation. You can simulate this easily even with a en_us keyboard. Using the default en_us layout (without dead keys), pressing the " " (grave) key will print the character immediately. Changing the layout to en_us with dead keys, the char will not be printed in the first key stroke. We need a second key press to print the character because the system was waiting to see if the dead key will compose a new char (" à " for example). At this moment, we can't distinguish between the " " char and the dead key " ` ". The new attribute KeyboardEvent.key would report the value "DEAD_GRAVE" for the latter.

• I have tried to find a way to detect the current keyboard layout in Javascript but, as far as I can tell, only IE has support for that (haven't tested it)

• I've also looked for a way to disable the browser's keyboard shortcuts altogether instead of doing all the filtering noVNC does. Not much luck in that too.

I hope these information can help anyone trying to solve this bug. With the future implementations of the new 'key' attribute I hope we can fix it.

jalfd commented 9 years ago

Firefox doesn't provide any keyCode for the dead keys. Chrome doesn't provide all the events when pressing a dead key. At this moment it will be very hard to fix this bug in a cross-browser way

Yep. However, events for dead keys aren't strictly necessary. What matters is that the key following the dead key has a valid char/charCode property. After all, the entire point in a dead key is that it's dead. Pressing it doesn't generate a character that we can send to the VNC server. Instead, we just ignore it and wait and see what character is generated by the next keypress. (But of course, that depends on the browser telling us what that key is at least)

Also note that keyCode isn't really a very useful property. It tells us some implementation-defined name for the physical key, but not which character the keypress generated. The only way in which noVNC could translate that into a character would be if the user (1) explicitly told us which keyboard layout to assume and (2) we had tables describing every possible keyboard layout in detail. And even then we would have to implement some fairly complicated logic for combining and composing characters, knowing exactly which character would be generated if this key is pressed after that dead key, and this other modifier key is held down. That's not practical. It would be insanely complicated. So what we currently do instead is this:

there is a set of keys that are "fixed" and always have the same meaning (enter, space, tab, caps lock, ctrl, alt, backspace and so on). For those, the keyCode property actually tells us what we need to do, and we can act on that.
for all graphical characters, the keyCode is useless, and we have to wait for an event that specifies either the char or charCode property. (Those are usually available on keypress events). These properties give us a Unicode code point value for the generated character, and we can trivially map that to a keysym identifier, which the RFB protocol expects.

The main thing we use keyCode for is really to match keydown, keypress and keyup events together. (keydown gives us a keyCode. When we see a keypress with that keyCode, we can look at its charCode to see which character to send to the server. When we see a keyup we can take its keyCode and use that to look up in an internal state table to see which character has been sent to the server. And then we can send a KeyUp event on that character)

So if the browser doesn't give us any events with char or charCode set, then it's pretty much game over. There's not much we can do (other than fixing the bug in the browser)

From the output you listed, it looks like neither Chrome and Firefox on Linux give us a charCode when you repeatedly press dead keys. That sucks.

In my opinion noVNC will need to review the keyboard.js implementation when this attribute became available, not using keyCode at any point or only if the browser has no other alternative.

Agreed. When I overhauled the keyboard handling, KeyboardEvent.key wasn't really useful, but as it gets better supported by browsers, we'll eventually need to switch over to that. But it sounds like that wouldn't solve the dead keys issue.

With the current keyCode implementation in Chrome I didn't find a way to implement accentuation

What is supposed to happen is this:

you press the dead key `
you get a keydown event specifying the keycode (followed by a keyup)
you press another key, say, e
you get a keydown specifying the keycode
you get a keypress specifying the charcode 0xe8 (the code point for è)
you get a keyup event.

That is, the actual composition of dead key + non-dead key happens by the browser, and it tells us that the resulting character is a è. So we don't need to do anything when a dead key is pressed. We just wait for the browser to tell us which character to send to the server. The browser, not noVNC, has to handle accentuation.

Now if only they'd do that correctly. :/

laggarcia commented 9 years ago

I agree that we have browser issues here, but even leaving it aside, I think there are some improvements we can do in order to make noVNC more reliable, specially when dealing with a VNC server that is run by QEMU to access a guest console.

If I am following the discussion here, Javascript code receives a unicode value from the browser, which noVNC translates to the value used by the RFB protocol, which states: "The key itself is specified using the "keysym" values defined by the X Window System, even if the client or server is not running the X Window System."

Using X Window System keysym values is known to cause issues to QEMU VNC server, mainly because if you are not running X Windows System on the server side, an X Windows System keysym is lots of times useless (and actually maps to the wrong key, depending on the application running on the VNC server). Because of that, Anthony Liguori proposed an extension to the RFB protocol which is understood by the QEMU VNC server and that enables it to deal directly with the key codes generated by the Linux kernel. I think one possible way to fix the keyboard issues we are having is to implement this in noVNC. Yes, that would need an additional translation from unicode value or X11 keysym value to Linux key code, but I think it would solve some of the issues (from what I read here, it seems that other issues are dependant on browser bugs...)

danielhb commented 9 years ago

I've worked with this issue for the last weeks and I've had some progress.

Chromium (= Google Chrome upstream) had an issue that was fixed recently about dead keys events ( https://code.google.com/p/chromium/issues/detail?id=478643 ). After some struggle compiling Chromium in a Fedora 21 (the recommended OS to build it is Ubuntu) I managed to get a build running and tested the dead keys there. I can say that, as far as dead keys are concerned in an en_us keyboard and a pt_br abnt2 keyboard, noVNC + Chromium works when connecting to Tiger VNC sever. After this discovery, all the work I've been doing in this issue is considering Chromium. If you're coming to this bug with a dead key problem in noVNC, I strongly recommend to give Chromium a shot.

As said by laggarcia in the previous message, I want noVNC to work properly in QEMU-VNC server. To make that happen, I'm working in implementing QEMU-VNC extensions into noVNC. Actually only one of them, the QEMU Extended Key Event Message. Basically this is the same message noVNC already sent in key press but with an extra field, the X11 keycode that generated the keysym. This conversion is being done by using a hashmap which was generated by parsing the mapping from gtk-vnc. This extension will only be enabled if the server sends a RFB Framebuffer Update saying that it supports it. Otherwise the default noVNC behavior takes place.

The current status: it works, but the dead keys are still a problem. After further debugging and investigation, I believe that this is a matter of which key events the client is sending to the server. noVNC does not send the dead keys to the server because, by design, dead keys does not send keypress events, only keydown (http://javascript.info/tutorial/keyboard-events). QEMU-VNC server requires the dead key to be sent as well - the combination is handled by the server. This is what I am looking at right now. I am trying to find a way to (1) send all the dead key events to the server and (2) make sure that this new workflow does not interfere with the "non-QEMU" workflow. (1) is presenting to be trickier than I've expected, but I believe that (2) shouldn't be much of a problem.

As always, any comments or tips are welcome.

danielhb commented 9 years ago

My conclusion after working in this bug for the last weeks is that the fix is not possible ATM. I'll post here how far I went and what are the current limitations that prevented the fix.

I've implemented the QEMU VNC extension into noVNC and it worked remarkably well for the en_us and pt_br keyboards. But it won't work for german and any other keyboard layout that is not QWERTY. The reason is that the QEMU VNC extension dictates that we must pass the XT scancode (= physical location of the key pressed. The 'Q' key in a QWERTY is the second key of the third row) to the VNC server. This information can be retrieved by applications that can grab the keyboard events directly, but in noVNC we are stuck by the info that the browser provides.

Firefox and Chrome does not provide such information - we can see the IE keycode, which is the same value for all the layouts, but there is no information about the current user layout. Thus, testing the german keyboard with the QEMU VNC extension, the Z and Y keys are switched, among others. The reason why it works with en_us and pt_br layouts is that the IE keycode the browsers provide matches the XT scancode for en_us. There is a W3C draft that describes extensions to the keyboard support for the browsers (https://dvcs.w3.org/hg/d4e/raw-file/tip/source_respec.htm), but this has no ETA unfortunately.

TL;DR to fully implement the feature we need more keyboard support from the browser side.

jomo commented 8 years ago

I'm using OS X on a MacBook where the builtin keyboard has a German layout, but I use an external keyboard with US layout. The OS X system language is English, the input language is set to U.S. and navigator.languages is ["en-US", "en"].

I use noVNC with Proxmox / QEMU in Google Chrome, connecting to a machine with keyboard set to us.iso.kdb: United States of America ISO-8859-1

However, pressing y prints z and / prints 7. That seems like a German keymap, though I can't figure out why that would be used.

I tested pressing y:

0: Display initialized
1: Touch device detected
2: raw key event keydown (key: 89, char: 0, which: 89)
3: raw key event keypress (key: 121, char: 121, which: 121)
4: RFB keypress down keysym: 121 key name: 121
5: raw key event keyup (key: 89, char: 0, which: 89)
6: RFB keypress  up  keysym: 121 key name: 121

Looking at keysym.js, 89 (0x0059) is Y and 121 (0x0079) is y.

That seems to be matched correctly.

Interestingly, using the German keyboard with input language set to German works when the VM keyboard is also set to German. However it does not work with everything set to US. I've also tried setting some things to German and some to US, but it only gets messed up.

tl;dr: everything is set to US but it seems to use a German keymap.

Am I doing anything wrong?

jomo commented 8 years ago

Actually, everything is (mostly) working when the OS X input language is set to German while actually using the US keyboard and VM keyboard set to US. That doesn't seem to be right, though.

olivierlambert commented 8 years ago

Same strange thing here (using noVNC in Xen Orchestra, see https://github.com/vatesfr/xo-web/ )

"en" layout in my system with VM "EN" keyboard: working great!
"en" layout in my system with VM "FR" keyboard: working great! (writing in French)

But if my own system layout is in "fr" (French), all is inverted, despite using "FR" or "EN" (or whatever) in the VM keyboard.

disaster123 commented 8 years ago

This one is pretty long. Is there any way or patch which works at least partly for a local installation / branch?

julien-f commented 8 years ago

Chome 48 has implemented KeyBoardEvent.code which represents the physical key that generated the event independently of the keyboard layout.

It's also supported no Firefox 38+ and Opera 35+ (source).

danielhb commented 8 years ago

Is anyone working actively to solve this issue? If not, I can try to implement the QEMU extension again. It might take a while (I worked in this one year ago ...) but now I believe it is feasible.

samhed commented 8 years ago

@danielhb I don't believe anyone is working on this at the moment. That would be awesome!

danielhb commented 8 years ago

@samhed alright, I'll pick it up from where I left one year ago, rebase with the current master and see how far we can advance this time.

I'll keep this bug updated with any developments

samhed commented 8 years ago

Great! Tell me if there is something I can do to help!

danielhb commented 8 years ago

Update: I am having good progress with this attempt. The core logic is ready and it's already functional. I've tested it with FR (azerty and dvorak) and German (classic) keyboards with success. The tests were made in a Fedora 23 host, Google Chrome 49, noVNC connecting to VMs created by virt-manager.

At this moment I am fixing some issues with Num Lock handling. After that I'll do a clean up (the code is a mess right now, swarmed with console.log() calls) and push it to a noVNC fork so everyone can give it a shot.

It's worth mentioning that this is a QEMU extension implementation and will fix the issue if, and only if, the VNC server supports this extension. I stood as far away as I could of the logic that implements the non-QEMU case. Also, any browser that does not implement the KeyboardEvent.code (see http://caniuse.com/#feat=keyboardevent-code ) will not be supported by this implementation (in short, it will work on latest Chrome, Firefox and Opera). I am considering adding a browser type/version check before enabling the QEMU extension.

Daniel

danielhb commented 8 years ago

I believe the code is ready to be tested and reviewed. Please feel free to test it with your keyboard layouts, using latest Chrome/Firefox/Opera and connecting to a QEMU-compatible vnc server such as a VM from virt-manager.

https://github.com/danielhb/noVNC

benbracha commented 8 years ago

+1 to @DirectXMan12 - I tried it with german keyboard, typing altGr+l which suppose to print "@", does nothing.

laggarcia commented 8 years ago

@benbracha @DirectXMAN12 Have you tested with @danielhb patches referenced above? They might fix your issue.

benbracha commented 8 years ago

@laggarcia - yes, I tried @danielhb version

danielhb commented 8 years ago

@benbracha can you specify which German layout are you using? Because I just tested here with my version, with the layout I believe it's the German default for Gnome and the "@" works fine. However it's AltGr+Q that gives "@", not AltGr+I.

danielhb commented 8 years ago

@benbracha don't know if this is exactly the layout you're using, but just tried it here with German - Austria (Macintosh) and it worked too (with AltGr + L ).

What browser are you using? The code will not activate in any browser but latest stable Firefox, Chrome and Opera

benbracha commented 8 years ago

I just installed a German keyboard on my mac (see its layout below) - and locally it prints "@" using alt+l, but I don't see this when using your noVNC version.

Am I missing something?

danielhb commented 8 years ago

What VNC server are you trying to connect to? Are you trying to connect to xvnc, tigervnc, QEMU vnc ...?

Supposing that you're connecting to a QEMU compatible VNC server, using Firefox >= 44 or Chrome >= 48 or Opera >= 36 and mapping the exact same keyboard layout inside the VM, it should work.

I've tested it a lot with Linux and Windows 10 but haven't tried Apple. I'll fire it up an old Mac Air here and see if there's something I didn't predict.

benbracha commented 8 years ago

Thanks. Sorry for not being verbose with the details. So: I'm connecting to a QEMU vnc, Chrome latest version. Probably what I'm missing is... "mapping the exact same keyboard layout inside the VM" - what do you mean by that?

(I'm used to work with guacamole, and at least as I understand - the keyboard layout of the VM is not important, as eventually the actual characters (charCode that are raised from keypressed JS events) are sent to the remote VM. I may miss something here though.. I tried your solution as I cannot figure out how to solve "dead-keys" issues which are not working with gacamole, and hoped you solved it).

laggarcia commented 8 years ago

(I'm used to work with guacamole, and at least as I understand - the keyboard layout of the VM is not important, as eventually the actual characters (charCode that are raised from keypressed JS events) are sent to the remote VM. I may miss something here though..

Keyboard layout is not important only when you are using the same graphical user interface on both sides (client and server), e.g. X11, which is what VNC protocol uses by default. charCode raised from keypressed JS event is way high level and a number of transformations happen between your key press, the operating system getting it and passing it to the JS engine. If you are connecting to a VM, the best way to deal with this is to send the actually keycode received by the operating system to the remote server (that's what QEMU provides through a VNC extension because on the VNC server end, you actually have a full operating system running, not only a graphical user interface). But if you do that you need to set the keyboard layout on the VM properly, as you are not sending charCodes to the VM, you are sending actually keycodes (which are much lower level and need to be mapped to a keyboard layout to be meaningful).

I tried your solution as I cannot figure out how to solve "dead-keys" issues which are not working with gacamole, and hoped you solved it).

Yeah, that's one of the issues you might see when passing charCodes to the VM instead of actual low level keycodes.

benbracha commented 8 years ago

@laggarcia Thanks for the explanation! Just to be clear, when you are saying:

Keyboard layout is not important only when you are using the same graphical user interface on both sides (client and server)

What do you mean by "client and server"? My set up has:

A client (my local machine, that use noVNC via browser) - Mac OS / Chrome
A server (the VM that runs QEMU and the noVNC proxy) - Ubuntu 14.04
A "client VM" (the VM that runs on top QEMU) - Ubuntu 14.04

In this setup - should I set the the "client VM" keyboard layout to German as well (like it is set on my Mac)?

danielhb commented 8 years ago

@benbracha I see where you're coming from. I'll explain why as succinct as I can, because this is a long story/topic and @laggarcia already explained a bit.

The implementation you're talking about is the regular VNC implementation of key events. You send the key symbol (keysym) to the remote server, the remote server shows it and that's it. This is trivial for VNC clients that have direct access to the keyboard map of the OS and can tell, for example, that AltGr+L does nothing in an English layout but it produces the keysym "@" in yours.

QEMU VNC servers, on the other hand, can't be treated as regular VNC servers. QEMU is a hardware emulator which emulates everything, including the keyboard. In this regular VNC implementation, when connecting to the QEMU server, sending a "@" keysym would cause QEMU to transform it back to the actual key strokes that generated it. In en_us layout, it would be Shift+2. But you haven't pressed shift+2, you pressed AltGr+L. But there's no way QEMU knows your layout beforehand. That leads to a lot of problems, as you might have noticed.

Then it comes the QEMU extension, the work I've done in noVNC. It does not rely on sending keysyms, but the actual physical key pressed. It's a different code from the regular noVNC keyboard handler. In your case for example, AltGr+L will be sent as 'key of row 6 column 5' + 'key of row 4 column 10'. This is what the QEMU VNC server receives and sends to the VM. So, in order to get the "@" in the VM, the VM must match your own keyboard layout. Supposing that you didn't change the VM keyboard, AltGr+L in a en_us layout gives you no symbol.

So, in order to properly make the keyboard work in your case, the VM layout must match the "source" layout.

danielhb commented 8 years ago

"In this setup - should I set the the "client VM" keyboard layout to German as well (like it is set on my Mac)?"

Exactly. Not only "German" but the exact same layout you're using. In Ubuntu15 it's called "German-Austria-Macintosh"

benbracha commented 8 years ago

Thanks @danielhb - this really sheds more light on this, and improve my understanding. I tried the set up the keyboard on the "client VM" as you suggested, using "sudo dpkg-reconfigure keyboard-configuration", and still couldn't get it work.

I you think this is not related to this issue, I would be happy to take this offline with you (email), as it can help me a lot.

I did notice this thing:

Even if I don't change my "client VM" keyboard and leave it as is (english), when I switch my mac between EN and DE keyboards and send "y" - the "client VM" behaves as expected - types "y" or "z" accordingly. According to your explanation, this shouldn't be possible unless I'll change the "client VM" keyboard to DE.. Maybe I'm missing something more basic with my setup? For example - I assume your changes relates only the the server-side of noVNC, as I still use regular noVNC client from http://kanaka.github.io/noVNC/noVNC/vnc.html. Should I use your vnc.html?

danielhb commented 8 years ago

On 04/13/2016 11:20 AM, Ben Bracha wrote:

Thanks @danielhb https://github.com/danielhb - this really sheds more light on this, and improve my understanding. I tried the set up the keyboard on the "client VM" as you suggested, using "sudo dpkg-reconfigure keyboard-configuration", and still couldn't get it work.

I don't know what dpkg-reconfigure keyboard-configuration does. I would rather set the keyboard manually. In Ubuntu 15 it's under 'Keyboard' -> 'Input sources'. Then select language and layout type. You can see a drawing of the keyboard layout to ensure that it matches yours. You're using Ubuntu 14 but I am guessing it is similar.

I did notice this thing:

Even if I don't change my "client VM" keyboard and leave it as is (english), when I switch my mac between EN and DE keyboards and send "y" - the "client VM" behaves as expected - types "y" or "z" accordingly. According to your explanation, this shouldn't be possible unless I'll change the "client VM" keyboard to DE.. Maybe I'm missing something more basic with my setup?

The reason is that the QEMU VNC extension isn't enabled. Otherwise pressing the 'Y' key (row 3 column 7 key) would always result in the "y" symbol in the VM set with English layout. In fact, the extension doesn't care about the client keyboard layout. It's the VM layout that counts.

Another thing that really counts is the browser version. You said that you're using latest Chrome. Which version is that in your case? You can see the version by issuing chrome://version in the address bar.

For example - I assume your changes relates only the the server-side of noVNC, as I still use regular noVNC client from http://kanaka.github.io/noVNC/noVNC/vnc.html. Should I use your vnc.html?

It's actually the opposite. My changes are on the client side, in the javascript files.

If you want to be sure that you're running the right code, just use the code from https://github.com/danielhb/noVNC . It's the noVNC master code

my patches and you use it the same way.

I you think this is not related to this issue, I would be happy to take this offline with you (email), as it can help me a lot.

I am interested to see your case working or at least figured because there's always a chance that I've missed some detail, perhaps something specific of Mac.

Feel free to email me at dhbarboza82@gmail.com if you want to take the discussion offline.

benbracha commented 8 years ago

Thanks, now I see it work (I didn't use your noVNC client side, only the server side, as I thought your changes were on the server side..). After setting the "client VM" to match my exact Mac layout (BTW - dpkg-reconfigure keyboard-configuration just let you do that in the Ubuntu terminal, as I don't have a desktop there..), I see the "@" sent when using AltGr+l. Nice!

It seems like dead-keys are working as well.. at least I tried the AltGr+n that generates a "~" and AltGr+u that generates quotes, although I couldn't get them to add "accent" For example: doing AltGr+n+n should do: "ñ" But I got ~n (it may be that Ubuntu terminal can't print it?)

danielhb commented 8 years ago

Nice to see it worked!

Ubuntu terminal doesn't print all the available characters. Try opening 'gedit' and test it there

On 04/13/2016 11:57 AM, Ben Bracha wrote:

Thanks, now I see it work (I didn't use your noVNC client side, only the server side, as I thought your changes were on the server side..). After setting the "client VM" to match my exact Mac layout (BTW - dpkg-reconfigure keyboard-configuration just let you do that in the Ubuntu terminal, as I don't have a desktop there..), I see the "@" sent when using AltGr+l. Nice!

It seems like dead-keys are working as well.. at least I tried the AltGr+n that generates a "~" and AltGr+u that generates quotes, although I couldn't get them to add "accent" For example: doing AltGr+n+n should do: "ñ" But I got ~n (it may be that Ubuntu terminal can't print it?)

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/kanaka/noVNC/issues/21#issuecomment-209491598

dkelson commented 8 years ago

@danielhb so in libvirt, with your patch, there should be no keymap set, correct?

For example:

<graphics type='vnc' listen='0.0.0.0' port='-1' autoport='yes'/>

instead of

<graphics type='vnc' listen='0.0.0.0' port='-1' autoport='yes' keymap='fr-ca'/>

danielhb commented 8 years ago

@dkelson yes, you're right. No keymap set in libvirt or QEMU, following the recommendation in the link you sent:

"Our recommendation is to never set the '-k' /keymap option at all these days. Recent QEMU / KVM and GTK-VNC releases support a VNC extension for sending raw keycodes, instead of localized keysyms. Thus is best to leave off the keymap in the config, and just configure it inside the guest OS."

brenard commented 8 years ago

@danielhb : it's work fine for me ! I port your patched version of noVNC in my webvirtcloud fork to try it : https://github.com/brenard/webvirtcloud/tree/html5_console

I make my tests with Chromium Version 49.0.2623.108 Built on 8.3, on multiple libvirt/KVM VNC instances without specific keymap configure in libvirt XML configuration, with french keymap configure in VM and french keyboard (azerty).

danielhb commented 8 years ago

I'm glad it worked @brenard ! Thanks for testing it!

danielhb commented 8 years ago

For anyone interested, I've backported the my implementation of the QEMU extension that fixes this bug to the latest noVNC release, 0.5.1. The code can be fetched here:

https://github.com/danielhb/noVNC/tree/0.5.1_qemu_extension

Same conditions apply (recent Firefox/Chrome/Opera browsers, must connect to a QEMU VNC server).

neufeind commented 7 years ago

Article by Daniel with further defails and background: https://www.ibm.com/developerworks/library/wa-support-multiple-keyboard-layouts-in-web-based-vnc-apps-trs/index.html

novnc / noVNC

Non-US keyboard layouts #21