#10664 closed defect (fixed)
Keyboard not known to VirtualBox (X11 from MAC, host Ubuntu srv 12.04) -> fixed in releases after 4 Mar 2013 (4.2 series and later)
| Reported by: | stefans | Owned by: | |
|---|---|---|---|
| Component: | host support | Version: | VirtualBox 4.1.16 |
| Keywords: | keyboard not known, X11 | Cc: | |
| Guest type: | X11 | Host type: | Linux |
Description
When opening virtual box through an ssh forwarded X11 connection I get the "Your keyboard type does not appear to be known to VirtualBox." message.
Front-end machine with the X11 server: mac book pro, native keyboard:
- X11: XQuartz 2.6.3 (xorg-server 1.10.3)
- OSX:
$ sw_vers ProductName: Mac OS X ProductVersion: 10.7.3 BuildVersion: 11D50b
Back-end machine running the VirtualBox program: Ubuntu Server 12.04.
Attachments (9)
Change History (45)
by , 12 years ago
comment:2 by , 11 years ago
stefans, Tonin, it looks like the XKB extension on your system is not working the way I expect it to. Would you be able to build and run a small C programme which I will attach and attach the output to the ticket? That may give a clue as to whether the problem is in VirtualBox or your systems. Thanks.
by , 11 years ago
Test programme for the key names provided by the XKB extension.
comment:3 by , 11 years ago
Yes, I can try to do that, however I'm not sure how to compile the code you posted, my C skills are a bit behind... I tried the following:
antoine@baobab:~$ gcc xkbtest.c -o xkbtest -I/usr/local/include -L/usr/local/lib -lX11 /tmp//ccquh936.o: In function `main': xkbtest.c:(.text+0x5b): undefined reference to `error' xkbtest.c:(.text+0x92): undefined reference to `error' xkbtest.c:(.text+0xc1): undefined reference to `error'
comment:4 by , 11 years ago
Well, after a bit of tweaking and changing the error(1, 0, "...") calls with perror("...") I had the following output:
antoine@baobab:~$ gcc xkbtest.c -o xkbtest -I/usr/local/include -L/usr/local/lib -lX11 antoine@baobab:~$ exit Connection to baobab closed. antoine@amarante:~$ ssh -X baobab Last login: Tue Feb 19 18:13:31 2013 from amarante FreeBSD 9.1-RELEASE (GENERIC) #0 r243825: Tue Dec 4 09:23:10 UTC 2012 Welcome to FreeBSD! antoine@baobab:~$ ./xkbtest 0: , 1: , 2: , 3: , 4: , 5: , 6: , 7: , 8: , 9: , 10: , 11: , 12: , 13: , 14: , 15: , 16: , 17: , 18: , 19: , 20: , 21: , 22: , 23: , 24: , 25: , 26: , 27: , 28: , 29: , 30: , 31: , 32: , 33: , 34: , 35: , 36: , 37: , 38: , 39: , 40: , 41: , 42: , 43: , 44: , 45: , 46: , 47: , 48: , 49: , 50: , 51: , 52: , 53: , 54: , 55: , 56: , 57: , 58: , 59: , 60: , 61: , 62: , 63: , 64: , 65: , 66: , 67: , 68: , 69: , 70: , 71: , 72: , 73: , 74: , 75: , 76: , 77: , 78: , 79: , 80: , 81: , 82: , 83: , 84: , 85: , 86: , 87: , 88: , 89: , 90: , 91: , 92: , 93: , 94: , 95: , 96: , 97: , 98: , 99: , 100: , 101: , 102: , 103: , 104: , 105: , 106: , 107: , 108: , 109: , 110: , 111: , 112: , 113: , 114: , 115: , 116: , 117: , 118: , 119: , 120: , 121: , 122: , 123: , 124: , 125: , 126: , 127: , 128: , 129: , 130: , 131: , 132: , 133: , 134: , 135: , 136: , 137: , 138: , 139: , 140: , 141: , 142: , 143: , 144: , 145: , 146: , 147: , 148: , 149: , 150: , 151: , 152: , 153: , 154: , 155: , 156: , 157: , 158: , 159: , 160: , 161: , 162: , 163: , 164: , 165: , 166: , 167: , 168: , 169: , 170: , 171: , 172: , 173: , 174: , 175: , 176: , 177: , 178: , 179: , 180: , 181: , 182: , 183: , 184: , 185: , 186: , 187: , 188: , 189: , 190: , 191: , 192: , 193: , 194: , 195: , 196: , 197: , 198: , 199: , 200: , 201: , 202: , 203: , 204: , 205: , 206: , 207: , 208: , 209: , 210: , 211: , 212: , 213: , 214: , 215: , 216: , 217: , 218: , 219: , 220: , 221: , 222: , 223: , 224: , 225: , 226: , 227: , 228: , 229: , 230: , 231: , 232: , 233: , 234: , 235: , 236: , 237: , 238: , 239: , 240: , 241: , 242: , 243: , 244: , 245: , 246: , 247: , 248: , 249: , 250: , 251: , 252: , 253: , 254:
comment:5 by , 11 years ago
Another try, invoking setxkbmap before (which makes a different behavior in VirtualBox console, but still no working keyboard).
antoine@amarante:~$ ssh -X baobab Last login: Tue Feb 19 19:06:59 2013 from amarante FreeBSD 9.1-RELEASE (GENERIC) #0 r243825: Tue Dec 4 09:23:10 UTC 2012 Welcome to FreeBSD! antoine@baobab:~$ setxkbmap be -model mac antoine@baobab:~$ ./xkbtest 0: , 1: , 2: , 3: , 4: , 5: , 6: , 7: , 8: , 9: ESC, 10: AE01, 11: AE02, 12: AE03, 13: AE04, 14: AE05, 15: AE06, 16: AE07, 17: AE08, 18: AE09, 19: AE10, 20: AE11, 21: AE12, 22: BKSP, 23: TAB, 24: AD01, 25: AD02, 26: AD03, 27: AD04, 28: AD05, 29: AD06, 30: AD07, 31: AD08, 32: AD09, 33: AD10, 34: AD11, 35: AD12, 36: RTRN, 37: LCTL, 38: AC01, 39: AC02, 40: AC03, 41: AC04, 42: AC05, 43: AC06, 44: AC07, 45: AC08, 46: AC09, 47: AC10, 48: AC11, 49: TLDE, 50: LFSH, 51: BKSL, 52: AB01, 53: AB02, 54: AB03, 55: AB04, 56: AB05, 57: AB06, 58: AB07, 59: AB08, 60: AB09, 61: AB10, 62: RTSH, 63: KPMU, 64: LALT, 65: SPCE, 66: CAPS, 67: FK01, 68: FK02, 69: FK03, 70: FK04, 71: FK05, 72: FK06, 73: FK07, 74: FK08, 75: FK09, 76: FK10, 77: NMLK, 78: SCLK, 79: KP7, 80: KP8, 81: KP9, 82: KPSU, 83: KP4, 84: KP5, 85: KP6, 86: KPAD, 87: KP1, 88: KP2, 89: KP3, 90: KP0, 91: KPDL, 92: SYRQ, 93: MDSW, 94: LSGT, 95: FK11, 96: FK12, 97: HOME, 98: UP, 99: PGUP, 100: LEFT, 101: II65, 102: RGHT, 103: END, 104: DOWN, 105: PGDN, 106: INS, 107: DELE, 108: KPEN, 109: RCTL, 110: PAUS, 111: PRSC, 112: KPDV, 113: RALT, 114: BRK, 115: LWIN, 116: RWIN, 117: MENU, 118: FK13, 119: FK14, 120: FK15, 121: FK16, 122: FK17, 123: KPDC, 124: LVL3, 125: ALT, 126: KPEQ, 127: SUPR, 128: HYPR, 129: XFER, 130: I02, 131: NFER, 132: I04, 133: AE13, 134: I06, 135: I07, 136: I08, 137: I09, 138: I0A, 139: I0B, 140: I0C, 141: I0D, 142: I0E, 143: I0F, 144: I10, 145: I11, 146: I12, 147: I13, 148: I14, 149: I15, 150: I16, 151: I17, 152: I18, 153: I19, 154: I1A, 155: I1B, 156: META, 157: K59, 158: I1E, 159: I1F, 160: I20, 161: I21, 162: I22, 163: I23, 164: I24, 165: I25, 166: I26, 167: I27, 168: I28, 169: I29, 170: K5A, 171: I2B, 172: I2C, 173: I2D, 174: I2E, 175: I2F, 176: I30, 177: I31, 178: I32, 179: I33, 180: I34, 181: K5B, 182: K5D, 183: K5E, 184: K5F, 185: I39, 186: I3A, 187: I3B, 188: I3C, 189: K62, 190: K63, 191: K64, 192: K65, 193: K66, 194: I42, 195: I43, 196: I44, 197: I45, 198: K67, 199: K68, 200: K69, 201: K6A, 202: I4A, 203: K6B, 204: K6C, 205: K6D, 206: K6E, 207: K6F, 208: HKTG, 209: KANA, 210: EISU, 211: AB11, 212: I54, 213: I55, 214: I56, 215: I57, 216: I58, 217: I59, 218: I5A, 219: K74, 220: K75, 221: K76, 222: I5E, 223: I5F, 224: I60, 225: I61, 226: I62, 227: I63, 228: I64, 229: I65, 230: I66, 231: I67, 232: I68, 233: I69, 234: I6A, 235: I6B, 236: I6C, 237: I6D, 238: I6E, 239: I6F, 240: I70, 241: I71, 242: I72, 243: I73, 244: I74, 245: I75, 246: I76, 247: I77, 248: I78, 249: I79, 250: I7A, 251: I7B, 252: I7C, 253: I7D, 254: I7E
by , 11 years ago
| Attachment: | VBox-setxkbmap-be.log added |
|---|
VBox.log Tonin after call to setxkbmap be -model mac
comment:6 by , 11 years ago
Good work getting the test programme working. For (useless) information, "error(3)" isn't quite the same as "perror(3)", in particular because "error(1, ...)" terminates the programme when it is called, but that really doesn't matter here of course.
Before calling setxkbmap the data is clearly invalid. The documentation for the calls we are making to the X server does not give any indication that this may happen, so I assumed it would not. Obviously I have to rethink that assumption, but since the call succeeds and simply returns empty data it may be worth thinking about what constitutes success. If it can return empty data it may also be able to return partial data which isn't enough to work with. Then again, I could define that to be the user's problem, since it is clearly possible to fix the data returned.
After your call to setxkbmap the data returned looks correct, so I assume that my code is not handling it correctly, and I will have to take a a look to work out why not.
I assume that ssh is not important in the equation here, since it should just be proxying the connection to the X server without changing the data going through it. The output from your second run of xkbtest should provide me with enough information to support your XQuartz layout even without XKB working correctly, assuming that the data will be the same on different XQuartz systems. (I can probably check that in the X.Org source code.)
comment:7 by , 11 years ago
ssh X11 forwarding is clearly working fine for the QT4 windows of VirtualBox (Virtual Box Manager for example, the keyboard works perfectly when typing in the description fields), so yes it seems it's not the issue here. And this is with or without a call to setxkbmap, but I guess this is a different story and that VirtualBox needs the raw keyboard events where QT might be ok with only the chars coming in.
If there is anything else you want me to test on my side, let me know.
follow-up: 9 comment:8 by , 11 years ago
On closer inspection the output after the setxbkmap command looks reasonable. You say that the console still doesn't handle keyboard input correctly at that point. Could you describe more precisely what does and doesn't work?
comment:9 by , 11 years ago
Replying to michael:
On closer inspection the output after the setxbkmap command looks reasonable. You say that the console still doesn't handle keyboard input correctly at that point. Could you describe more precisely what does and doesn't work?
The keys are all messed up. There's not a single key that is in its correct position, even space and return produce other chars. I cannot input a correct username and password at the login prompt.
comment:10 by , 11 years ago
Could it be that you need an option to setxkbmap to say that your server is XQuartz?
comment:11 by , 11 years ago
I'm not sure where the issue lies... Some people are reporting the same issue to the XQuartz developers although it is not clear if the issue is with XQuartz or not. Some KVM users are reporting a similar issue when trying to use the virt-manager in the same way.
I tried different settings with setxkbmap and had different results in VirtualBox, but still not a single one with some correct keys... I'm a bit clueless now.
comment:12 by , 11 years ago
On the setxkbmap manual page I see the following (though I assume you have read it too):
"If you have an Xserver and a client shell running on different comput‐ ers and XKB configuration files on those machines are different you can get problems specifying a keyboard map by model, layout, options names. This is because setxkbcomp converts these names to names of XKB config‐ uration files according to files that are on the client side computer, then it sends the file names to the server where the xkbcomp has to compose a complete keyboard map using files which the server has. Thus if the sets of files differ significantly the names that the setxkbmap generates can be unacceptable on the server side. You can solve this problem by running the xkbcomp on the client side too. With the -print option setxkbmap just prints the file names in an appropriate format to its stdout and this output can be piped directly to the xkbcomp input. For example, the command
setxkbmap us -print | xkbcomp - $DISPLAY
makes both steps run on the same (client) machine and loads a keyboard map into the server."
Might that be relevant?
comment:13 by , 11 years ago
$ setxkbmap de -print
says
xkb_keymap {
xkb_keycodes { include "evdev+aliases(qwertz)" }; xkb_types { include "complete" }; xkb_compat { include "complete" }; xkb_symbols { include "pc+de+inet(evdev)" }; xkb_geometry { include "pc(pc105)" };
};
here. That doesn't look like the right thing for XQuartz, as I wouldn't expect "evdev" to be on use on OS X.
comment:14 by , 11 years ago
This looks relevant:
http://thread.gmane.org/gmane.comp.freedesktop.xorg.devel/4956
Would you have any way of testing a patch to VirtualBox if I provided one? Given that you are on FreeBSD I can't get you a binary.
comment:15 by , 11 years ago
Yes, I actually have 4.2.6 compiled from source (FreeBSD ports), it shouldn't be too difficult to add a patch to that (if it's against 4.2.6 code).
comment:16 by , 11 years ago
Here you go then. This should apply against 4.2.6 as well.
Index: src/VBox/Frontends/Common/VBoxKeyboard/keyboard.c
===================================================================
--- src/VBox/Frontends/Common/VBoxKeyboard/keyboard.c
+++ src/VBox/Frontends/Common/VBoxKeyboard/keyboard.c
@@ -548,5 +548,7 @@
/**
* Checks for the XKB extension, and if it is found initialises the X11 keycode
- * to XT scan code mapping by looking at the XKB names for each keycode.
+ * to XT scan code mapping by looking at the XKB names for each keycode. As it
+ * turns out that XKB can return an empty list we make sure that the list holds
+ * enough data to be useful to us.
*/
static unsigned
@@ -555,4 +557,6 @@
int major = XkbMajorVersion, minor = XkbMinorVersion;
XkbDescPtr pKBDesc;
+ unsigned cFound = 0;
+
if (!XkbLibraryVersion(&major, &minor))
return 0;
@@ -575,4 +579,5 @@
{
keyc2scan[i] = xkbMap[j].uScan;
+ ++cFound;
break;
}
@@ -580,5 +585,5 @@
XkbFreeNames(pKBDesc, XkbKeyNamesMask, True);
XkbFreeKeyboard(pKBDesc, XkbAllComponentsMask, True);
- return 1;
+ return cFound >= 45 ? 1 : 0;
}
comment:17 by , 11 years ago
By the way you should run the patched version without calling setxkbmap. It should notice the empty mapping and fall back to a different method. If it works then attaching the log file should provide me with useful information to support XQuartz better. If not then tell me the result anyway.
comment:18 by , 11 years ago
Result is slightly the same as before (without any call to setxkbmap, like in my very first try). In this situation the console doesn't receive much key events, only return, some function keys and keypad keys are actually printing something.
comment:19 by , 11 years ago
Could you try starting a virtual machine with the environment variable "LOG_KB_SECONDARY" set to something (e.g. to 1) and attach what it prints to standard output? Thanks. (I hope that this code is still working as it should, given how long it is since some one has needed it.)
by , 11 years ago
| Attachment: | LOG_KB_SECONDARY.txt added |
|---|
stdout for patched 4.2.6 and no call to setxkbmap
comment:20 by , 11 years ago
Here you are. It's the french-mac keyboard that is selected, which is close to the belgian-mac keyboard that I have. Still, most keys are dead keys.
comment:21 by , 11 years ago
The key code detection seems to be working right (apart from the fact that it is missing the Belgian layout). So the question - for me - is why it is not making use of it.
comment:22 by , 11 years ago
See this page by the way, which suggests that Apple only have one layout for France and Belgium<1>. And indeed, I was peering at the bad graphics on their home page<2> trying to spot the difference.
<1> http://ubuntuforums.org/showthread.php?t=1732854 <2> http://support.apple.com/kb/ht2841
comment:23 by , 11 years ago
It would be great if you could try the following patch in addition to the first one, again without running setxkbmap. By the way, I am very confused that our mapping detection code fails to find your "Q" key although it finds every other one.
Index: src/VBox/Frontends/Common/VBoxKeyboard/keyboard.c
===================================================================
--- src/VBox/Frontends/Common/VBoxKeyboard/keyboard.c (revision 83877)
+++ src/VBox/Frontends/Common/VBoxKeyboard/keyboard.c (working copy)
@@ -637,6 +637,15 @@
if (byXkbOK)
*byXkbOK = byXkb;
+ /* Fall back to the one which did work. */
+ if (!byXkb)
+ {
+ if (byType)
+ X11DRV_InitKeyboardByType(display);
+ else
+ X11DRV_InitKeyboardByLayout(display);
+ }
+
/* Remap keycodes after initialization. Remapping stops after an
identity mapping is seen */
if (remapScancodes != NULL)
by , 11 years ago
| Attachment: | LOG_KB_SECONDARY-2.txt added |
|---|
stdout for patched 4.2.6 (2 patches) and no call to setxkbmap
comment:24 by , 11 years ago
This time, the stdout on the ssh session showed the keyboard detection output twice, not sure why.
comment:25 by , 11 years ago
That is actually expected (if I think about it). What interests me though is the virtual machine log and (even more) whether the keyboard works any better now. And whether you have any idea what my code might have against your "Q" key!
comment:26 by , 11 years ago
I wasn't sure at first as I had been playing with different settings in both the host, the guest and XQuartz to try make something work. But now I can happily say it: IT WORKS!
Your last patch indeed made it works. The VBox.log still says that the keyboard doesn't seem to be known to VirtualBox. But the console was working like an AZERTY keyboard, and after changing the guest console keyboard configuration to 'fr' and 'mac' variant (instead of plain 'be' config, you're right, belgian and french Apple keyboards are actually the same, thank you Apple marketing for making us believe otherwise) I now got a fully working keyboard in the VirtualBox console! Yeah!
To be complete, I must say that it works when my Debian guest is fully started. If I brake in GRUB while booting, then I have a plain QWERTY keyboard (US I guess) under my hands, which is acceptable.
I really must thank you for this correction and for your support: Thank you!
comment:27 by , 11 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
| Summary: | Keyboard not known to VirtualBox (X11 from MAC, host Ubuntu srv 12.04) → Keyboard not known to VirtualBox (X11 from MAC, host Ubuntu srv 12.04) -> fixed as of 21 Feb 2013; not fixed in 4.2.x |
Glad I was able to solve that. And just to sum everything up, in case it is of interest...
VirtualBox has three different methods of detecting the X11 keyboard mapping (that is, how the "key code" numbers which the X server uses to describe physical key positions are best mapped to PC scan codes; this may be approximate if e.g. the X server has a keyboard which doesn't look much like a PC one). We can do the detection by looking at the keyboard mapping (i.e. a French keyboard has a ".?" key but a US one doesn't) and working backwards from there; or by looking at the key codes for well known keys like Control, Alt and Shift and seeing if they match a mapping we know; or just asking XKB for the position on the keyboard of each key code.
On your system only the first method was working, but due to a bug in the code we were still trying to use the third method. That method works nearly everywhere, which is why no one ever noticed that the other two were broken. And the output in the log file is the information I need to make the second method work too, so that we can work right with XQuartz servers even if the first method fails. I was able to check the information here: http://xquartz.macosforge.org/trac/ticket/511
And I have also solved the problem of the "Q" key - it is detected, but simply not logged due to another minor bug.
follow-up: 32 comment:29 by , 11 years ago
I will after all add one more patch - the change I mentioned to detect XQuartz by the second method. This should make the log message go away and more importantly the keyboard should still work after applying it. Since this patch will go into VirtualBox it would be nice if you could test that it doesn't break your set-up again.
Index: src/VBox/Frontends/Common/VBoxKeyboard/keyboard-types.h
===================================================================
--- src/VBox/Frontends/Common/VBoxKeyboard/keyboard-types.h (revision 83903)
+++ src/VBox/Frontends/Common/VBoxKeyboard/keyboard-types.h (revision 83904)
@@ -76,6 +76,8 @@
0x64, 0x66, 0x43, 0x44, 0x45, 0x46, 0x47, 0x48, 0x49, 0x4a },
{ "evdev", 0x25, 0x32, 0x42, 0x17, 0x9, 0x24, 0x6f, 0x74,
0x71, 0x72, 0x43, 0x44, 0x45, 0x46, 0x47, 0x48, 0x49, 0x4a },
+ { "XQuartz", 0x43, 0x40, 0x41, 0x38, 0x3d, 0x2c, 0x86, 0x85,
+ 0x83, 0x84, 0x82, 0x80, 0x6b, 0x7e, 0x68, 0x69, 0x6a, 0x6c },
{ NULL, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } /* Sentinel */
};
@@ -114,6 +116,23 @@
0x0, 0x165, 0x0, 0x0, 0x0, 0x165, 0x166, 0x167, 0x168, 0x169, 0x16a, 0x16b, 0x16c, 0x16d, 0x0, 0x143,
0x141, 0x0, 0x157, 0x105, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0
},
+ { 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x1e, 0x1f, 0x20, 0x21, 0x23, 0x22, 0x2c, 0x2d,
+ 0x2e, 0x2f, 0x29, 0x30, 0x10, 0x11, 0x12, 0x13, 0x15, 0x14, 0x2, 0x3, 0x4, 0x5, 0x7, 0x6,
+ 0xd, 0xa, 0x8, 0xc, 0x9, 0xb, 0x1b, 0x18, 0x16, 0x1a, 0x17, 0x19, 0x1c, 0x26, 0x24, 0x28,
+ 0x25, 0x27, 0x2b, 0x33, 0x35, 0x31, 0x32, 0x34, 0xf, 0x39, 0x56, 0xe, 0x0, 0x1, 0x0, 0x15b,
+ 0x2a, 0x3a, 0x38, 0x1d, 0x36, 0x138, 0x11d, 0x15c, 0x0, 0x0, 0x0, 0x37, 0x0, 0x4e, 0x0, 0x1,
+ 0x0, 0x0, 0x0, 0x135, 0x11c, 0x0, 0x4a, 0x0, 0x0, 0x0, 0x52, 0x4f, 0x50, 0x51, 0x4b, 0x4c,
+ 0x4d, 0x47, 0x0, 0x48, 0x49, 0x0, 0x0, 0x0, 0x3f, 0x40, 0x41, 0x3d, 0x42, 0x43, 0x0, 0x57,
+ 0x0, 0x64, 0x0, 0x65, 0x0, 0x44, 0x0, 0x58, 0x0, 0x66, 0x6e, 0x147, 0x149, 0x153, 0x3e, 0x14f,
+ 0x3c, 0x151, 0x3b, 0x14b, 0x14d, 0x150, 0x148, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
+ 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
+ 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
+ 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
+ 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
+ 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
+ 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
+ 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0
+ },
{ 0 } /* Sentinel */
};
comment:30 by , 11 years ago
| Resolution: | fixed |
|---|---|
| Status: | closed → reopened |
I'm joining the conversation a bit late here, but it looks to me like there's still something wrong here since you're committing some hard coded values for an "XQuartz" keyboard type.
"XQuartz" does not correspond to a particular keyboard. The keyboard layout is generated at runtime based on the user's OS X keyboard layout (we query the entire mapping and generate an XKB layout at runtime). It is also changed when the user changes their layout.
You should check out the code in Xnest and xf86-video-nested for how to query the keymap and follow it when it changes on the hosting X11 server.
comment:31 by , 11 years ago
Jeremy, the "XQuartz" keyboard "type" actually corresponds to the way the XQuartz server maps key codes to physical keyboard keys, which we represent as PC AT scan codes. We detect XQuartz by comparing the key codes for some key symbols which are rarely re-mapped and usually exist, namely left control, left shift, caps lock, the function keys and a few others. In deference to old traditions we also check for swapped control and caps lock. This is not meant to be bullet proof (some people will re-map their shift key), merely a way to improve our chances of getting the right mapping, where it is one of two fall-backs if (as is the case with XQuartz) we can't use the XKB key names for the purpose. And of course we are not actually interested in the key map, as virtual guest systems expect to see scan codes, not symbols.
Does that sound more reasonable to you?
comment:32 by , 11 years ago
Replying to michael:
I will after all add one more patch - the change I mentioned to detect XQuartz by the second method. This should make the log message go away and more importantly the keyboard should still work after applying it. Since this patch will go into VirtualBox it would be nice if you could test that it doesn't break your set-up again.
Hi Michael,
I just integrated your latest patch and it is running fine. Keyboard works as well as yesterday and I don't see the warning message in the log anymore. Thanks!
comment:33 by , 11 years ago
Thank you for testing and for your good work on debugging this problem! I must point out that you used the VBoxSDL front-end, which does not print any keyboard-related warnings, even if there are some; it does use the same code though, so if the keyboard works there it should work in the VirtualBox front-end. When you start a machine using the VirtualBox front-end you shouldn't see any warnings either, and you should see a message saying "Using known keycode mapping for keycode to scan code conversion". If you don't add any more replies to this ticket then I will assume that that is the case.
I will keep this ticket open for a few days in case Jeremy has anything to add. Otherwise I will treat the issue as sorted.
comment:34 by , 11 years ago
Yes, starting the VirtualBox front-end I now see:
00:00:00.532173 Using known keycode mapping for keycode to scan code conversion
comment:35 by , 11 years ago
| Resolution: | → fixed |
|---|---|
| Status: | reopened → closed |
Thanks again for testing. Jeremy doesn't seem to have anything to add, so I will close the ticket again.
comment:36 by , 11 years ago
| Summary: | Keyboard not known to VirtualBox (X11 from MAC, host Ubuntu srv 12.04) -> fixed as of 21 Feb 2013; not fixed in 4.2.x → Keyboard not known to VirtualBox (X11 from MAC, host Ubuntu srv 12.04) -> fixed in releases after 4 Mar 2013 (4.2 series and later) |
|---|
Same issue for me here with the following setup:
The keyboard on the X11 session is working fine in the VirtualBox windows (VirtualBox Manager and even the Settings page from the VirtualBox Console). But the console itself doesn't get much keyboard events.