VirtualBox

Ticket #2595 (reopened defect)

Opened 5 years ago

Last modified 2 years ago

Problems with custom keyboard layout Neo 2.0 and Virtualbox 2.0.4 -> fixed post-3.2

Reported by: Berniyh Owned by:
Priority: major Component: other
Version: VirtualBox 3.2.6 Keywords: keyboard layout neo
Cc: Guest type: other
Host type: Linux

Description

I'm using the Neo 2.0 keyboard layout, which can be found at  http://www.neo-layout.org

When one uses setxkbmap to set the layout to neo (ie setxkbmap de neo, after installing the new xkbmap file) and starts a virtual machine (for example running Windows or Linux, doesn't really matter which guest), several keys don't work, for example the number keys 2, 4, 5 etc.

If one starts Vbox with the layout set to QWERTZ (standard german layout), and then changes the layout while Vbox is running, most of the keys work, except for the modifier keys M3 und M4, which still represent their "old" functionality, like Caps-Lock or "< >".

I've seen some tickets about other custom keyboard layouts, but most of them don't have those major changes that Neo has, with the modifier keys.

Attachments

vboxkeyboard.tar.bz2 Download (32.1 KB) - added by michael 4 years ago.
Source code of keyboard library
VBoxKeyboard-32bit.tar.gz Download (16.4 KB) - added by michael 4 years ago.
Library file for 32bit Linux hosts
VBoxKeyboard-64bit.tar.gz Download (18.1 KB) - added by michael 4 years ago.
Library file for 64bit Linux hosts

Change History

comment:1 Changed 5 years ago by michael

  • Status changed from new to closed
  • Resolution set to wontfix

I hate to say it, but I don't think that this layout is going to work with VirtualBox. The reason for this is the way we map X11 key codes to PC scan codes. In fact, we have two methods of doing this - the first tries to match the current keyboard layout with one known to VirtualBox, and the second works by comparing the X11 key codes of modifier keys with a couple of well-known mappings. Neither will work in this case. I suggest that you work around this by setting the layout to QWERTZ when you start VirtualBox and installing the Neo layout in the guest.

comment:2 Changed 5 years ago by Berniyh

Hm, I see, but the real problem isn't that it doesn't support the layout, the problem is, that it makes the keyboard completely unusable.

Since it works when I start with a known keyboard layout, maybe there could be an option in the vbox settings to enforce a standard keyboard layout. (I did request something like that for KDE, too, but it would make sense in VirtualBox, too.) That should be possible, at least if I didn't get wrong how Virtualbox works. ;)

comment:3 Changed 5 years ago by Berniyh

  • Status changed from closed to reopened
  • Resolution wontfix deleted

Forgot to reopen the Ticket.

Feel free to close it again if even that won't happen.

comment:4 Changed 5 years ago by michael

What do you mean by "enforce a standard keyboard layout"? X11 only has one layout, unlike Windows which has one per application AFAIK, and I don't think people would appreciate VirtualBox changing that when it starts up.

comment:5 Changed 5 years ago by Berniyh

Well, when I set the layout to QWERTZ (or QWERTY), Virtualbox will work fine, even if I change the layout everywhere else again, so: setxkbmap de VirtualBox & (+starting the desired virtual machine) setxkbmap de neo

This will result in VirtualBox (unlike every other app) will still act like the layout is set to QWERTZ and thus all keys will work fine in the virtual machine (meaning, that I could install the layout in the virtual machine if I want to).*) So my guess was, that VirtualBox can ignore whatever the current layout is (didn't fully get how it exactly works) and just use the keyboard as if the QWERTZ layout had been set.

That's why I thought, that it should be possible to just override the current layout. That wouldn't mean, that VirtualBox would change the X11 setting, it would just mean, that VirtualBox sends whatever the selected (for example QWERTY) layout would result in to the virtual machine instead of what the current layout would result in.

This is a very common thing for games, which quite often just act as if the user has the US (QWERTY) layout selected - even if you're using something completely different normally - because they have been optimized for a specific layout.

*) Just to make that clear, I got KDE's layout selector disabled, so there is no magic going on that changes the layout on app switching.

comment:6 Changed 5 years ago by michael

Unfortunately I'm not aware of any way of ignoring the current layout. If you know of any open source code that does this please give me a pointer so that I can look at it.

comment:7 Changed 5 years ago by Berniyh

Sorry, I'm neither familiar with the source code of VirtualBox, nor am I a programmer at all, so I doubt that I can help you, unfortunately.

All I can tell you is that VirtualBox after starting a VM will keep using the layout that has been set at the start of the VM, even if one switches to another layout using setxkbmap. That's why I thought that it ignores the X11 setting at some point or in certain situations.

comment:8 follow-up: ↓ 9 Changed 5 years ago by wicking

In Version 2.1 of VirtualBox the problem is solved. It doesn’t matter which layout you choose on your host system, the layout in the guest system is the one, that is used. So this ticket could be closed, I think.

comment:9 in reply to: ↑ 8 ; follow-up: ↓ 10 Changed 5 years ago by Berniyh

Replying to wicking:

In Version 2.1 of VirtualBox the problem is solved. It doesn’t matter which layout you choose on your host system, the layout in the guest system is the one, that is used. So this ticket could be closed, I think.

Did you set something special? Because it still doesn't work over here, I have to change to a standard keyboard layout before I start the VM. After starting the VM, I can switch back, but if I don't do it that way, several keys won't work. (like 1, 2, 3 etc.)

Using vbox 2.1.4, btw.

comment:10 in reply to: ↑ 9 Changed 5 years ago by wicking

Replying to Berniyh:

Replying to wicking:

In Version 2.1 of VirtualBox the problem is solved. It doesn’t matter which layout you choose on your host system, the layout in the guest system is the one, that is used. So this ticket could be closed, I think.

Did you set something special? Because it still doesn't work over here, I have to change to a standard keyboard layout before I start the VM. After starting the VM, I can switch back, but if I don't do it that way, several keys won't work. (like 1, 2, 3 etc.)

Oops. I have the same problems now. Strange because I remember that it was ok with version 2.1.0 or 2.1.2. I’ll try it again with those older versions, maybe it was working and now it doesn’t work any more.

Using vbox 2.1.4, btw.

Me too. I just updated. Now most of the letters work, but not the numbers.

comment:11 Changed 5 years ago by Finswimmer

Using vbox 3.0.0 I have still the same problem. This workaround:

setxkbmap de VirtualBox & sleep 4 setxkbmap de neo

also does not help: 1-0 is not working "-" is "p" "q" is "-" "p" is "q"

and so on...

comment:12 Changed 5 years ago by Finswimmer

Using vbox 3.0.0: If I have in KDE the normal QWERTZ Layout, I can use NEO in Guest(Windows XP) If I have in KDE NEO Layout, Caps Lock Button is not working any longer.

Tobi

comment:13 Changed 5 years ago by rggjan

Same problem here... the missing numbers 1-0 are especially a problem.

comment:14 Changed 5 years ago by michael

See ticket #2302 .

comment:15 Changed 4 years ago by michael

Ticket #7193 has been marked a duplicate of this one.

comment:16 Changed 4 years ago by michael

  • Version changed from VirtualBox 2.0.4 to VirtualBox 3.2.6

comment:17 Changed 4 years ago by michael

Ticket #5278 has been marked a duplicate of this one.

comment:18 Changed 4 years ago by michael

Ticket #7530 has been marked a duplicate of this one.

comment:19 Changed 4 years ago by dov.grobgeld@…

This is in continuation of #7530 that was marked as a duplicate of this bug.

Michal said:

Unfortunately, we can't just do straight keycode to scan code mapping...

Out of curiosity, why not? There is a direct scancode to keycode translation happening in the host so why can't you just do a reverse translation back to scancodes?

But if is not possible, why don't you add a configurable user keysym to scan code translation table, so that advanced users can set up the translation. With such a external translation table it would be easy to write a host configuration tool where the user builds up their desired scancodes.

(One thing that I have learned from writing software is that every advanced system may have hundreds to thousands of configuration parameters. I tend to export all of these to the user. Why recompile the software if all that is needed is to override some translation table or some other configuration option? I wish there was similar tuning of VirtualBox.)

comment:20 Changed 4 years ago by dov.grobgeld@…

Btw, I found the following summary and historical overview of scancodes and keycodes that may be useful in solving this bug:

 http://berrange.com/posts/2010/07/04/a-summary-of-scan-code-key-codes-sets-used-in-the-pc-virtualization-stack/

From what I understand of this summary, it appears that there in Linux is a static translation of scancodes to keycodes (albeit different for XT/AT and USB HID keyboards), so it should be possible to use a reverse mapping to get the scancodes.

comment:21 Changed 4 years ago by michael

Dov: I will quickly sumarise how we handle keyboard translation on X11 hosts. In fact we have two algorithms for doing this. The first one, which is the preferred one, is to try to determine whether one of the two standard X.Org PC mappings is in use (kbd or evdev). We do this by checking the keycodes of certain keys that are not likely to vary - like the left side modifier keys, tab, the first eight function keys - and seeing if they match one of the well-known mappings (and we do check for swapped ctrl and caps lock). If they do, we use that mapping, but certain custom keyboard layouts, like Neo and probably like your Dvorak layout, defeat this.

The second algorithm originally came from Wine, although a lot of work has gone into it since then. It works by reading the symbols attached to each keycode and comparing them to standard national layouts, and working back from there to the keyboard mapping. This is needed in particular for Sunray and I believe for X over ssh and VNC (although I should probably add Sunray to the standard layouts).

A third algorithm which we currently don't implement (as I wasn't aware of it at the time) would be to use XKB to get a map of the keycodes based on the physical location of the keys on the keyboard. I will implement this when I find time for it.

And regarding manually overriding the mapping - I had completely forgotten about it, but see #2302.

comment:23 Changed 4 years ago by michael

  • Summary changed from Problems with custom keyboard layout Neo 2.0 and Virtualbox 2.0.4 to Problems with custom keyboard layout Neo 2.0 and Virtualbox 2.0.4 -> fixed post-3.2

I have added code for the XKB algorithm to svn (r32874 and r32875) which should fix this. A backport to 3.2 is not likely, but I can attach the changed library file to this ticket for anyone who is interested in giving it a try. It is from the development code, but should (please keep a back-up of the old file though!) be compatible with the 3.2 series too.

Changed 4 years ago by michael

Source code of keyboard library

comment:24 in reply to: ↑ 22 Changed 4 years ago by wicking

Replying to michael:

By the way, see  http://www.virtualbox.org/svn/vbox/trunk/src/VBox/Frontends/Common/VBoxKeyboard/ for the code.

Hooray! I noticed the reason why Neo layout doesn’t work. The files

 http://www.virtualbox.org/svn/vbox/trunk/src/VBox/Frontends/Common/VBoxKeyboard/keyboard-layouts.h  http://www.virtualbox.org/svn/vbox/trunk/src/VBox/Frontends/Common/VBoxKeyboard/keyboard-list.h

are just to old. The Neo layout has changed a little bit since the generation of these two files (seems to be four years ago).

And: A lot of other layouts have changed—at least slightly—,too.

So, why not just regenerate or update those files? This should make a lot of people happy (not just the hackers that use dvorak or neo but the people whose layout was changed in the last four years, which are quite a lot of languages).

Thank you in advance. :-)

comment:25 follow-up: ↓ 26 Changed 4 years ago by michael

wicking: no, Neo was never supported in our layout list (not even four years ago), as we only do standard national layouts. If you do know of standard layouts which are not correct though, I would appreciate it if you pointed them out.

Neo should work with VirtualBox on any X client/server setup with XKB (notably XFree86/X.Org back to at least the year 2000) in future major releases due to the code I added in r32874 and r32875. I say "should" as this is not yet well tested, but you can test with current 3.2 releases of VirtualBox by copying the updated files I attached above.

comment:26 in reply to: ↑ 25 ; follow-up: ↓ 27 Changed 4 years ago by wicking

Replying to michael:

wicking: no, Neo was never supported in our layout list (not even four years ago), as we only do standard national layouts. If you do know of standard layouts which are not correct though, I would appreciate it if you pointed them out.

Ok, but why is the Neo layout listed in the two files i mentioned in my last post? Are they just a waste of server space? Aren’t those files used in VirtualBox as you compile it?

Neo should work with VirtualBox on any X client/server setup with XKB (notably XFree86/X.Org back to at least the year 2000) in future major releases due to the code I added in r32874 and r32875. I say "should" as this is not yet well tested, but you can test with current 3.2 releases of VirtualBox by copying the updated files I attached above.

That’s great and I will try that. But I’m still interested why a four year old version of Neo was in those files and if that could have solved the problem earlier.

comment:27 in reply to: ↑ 26 Changed 4 years ago by michael

Replying to wicking:

Ok, but why is the Neo layout listed in the two files i mentioned in my last post? Are they just a waste of server space? Aren’t those files used in VirtualBox as you compile it?

Indeed you are right and I take my words back. I had actually seen that in there when I first created the file (automatically based on the X.Org keyboard mapping list), but hadn't drawn the connection with this ticket. I suppose that if it is popular enough to be a standard X.Org layout then it is something we can add to our list; I will regenerate the list from the current X.Org when I get round to it. In the meantime though I hope that your issue is solved by the change I mentioned in comment 23.

comment:28 Changed 4 years ago by michael

Ticket #1891 has been marked a duplicate of this one.

Changed 4 years ago by michael

Library file for 32bit Linux hosts

Changed 4 years ago by michael

Library file for 64bit Linux hosts

comment:29 Changed 4 years ago by michael

I updated the library files as I realised that the old ones would not work correctly with Neo's modifiers. As an added bonus, the new files make key code remapping as in ticket #2302 work fully. By the way, the usual disclaimer applies to all test code.

comment:30 Changed 3 years ago by frank

  • Status changed from reopened to closed
  • Resolution set to fixed

The fix should be in 4.0.

comment:31 Changed 2 years ago by dov.grobgeld@…

  • Status changed from closed to reopened
  • Resolution fixed deleted

This was marked as fixed more than a year ago, but I never got it to work, and after being driven nuts with about control and alt jumping back and forth I did a check today and saw that it doesn't work.

Expected behavior:

xev in the host should return the same keycodes for the same keys in a X11 host as with a X11 guest.

Actual behavior.

I get different keycode values in the host and outside:

 | Key name   | Keycode x11 host | Keycode x11 guest |
 |------------+------------------+-------------------|
 | CapsLock   |               66 |                37 |
 | Left Cntrl |               37 |                64 |
 | Win key    |              133 |               133 |
 | Left Alt   |               64 |               133 |

Note that in the X11 host, the keycodes are independent of the keyboard mapping, and I expect the same unmapped keyboard codes to be passed to VirtualBox as well.

But perhaps I'm missing something, is the use of xkb for the keyboard a user settable option? If so, where do you set it?

Version of VirtualBox is: 4.1.8 r75467

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use