VirtualBox

Ticket #5543 (new defect)

Opened 4 years ago

Last modified 5 months ago

Japanese KB Hankaku key on linux guest (keycode = 49) is repeated incessantly !

Reported by: zephyrus Owned by:
Priority: major Component: other
Version: VirtualBox 3.0.10 Keywords: Japnese KB hankaku
Cc: Guest type: Linux
Host type: Windows

Description (last modified by frank) (diff)

On a linux guest under XP host, with a Japanese KB, a key called Hankaku key (actually hankaku/zenkaku swap key or whatever) is handled somewhat in a buggy manner.

When we press the key, sometimes the key is repeated continuously for no apparent reason, and we have to hit the key or other keys to stop this repeating. Well if lucky, that is. I had to close the window system in one or two instances when I first hit this bug.

This is really annoying and the only sane countermeasure for this buggy behavior is to disable key repeat for this particular key.

xset -r 49

49 is because the key code is reported as 49 under linux for this keyboard.

I checked VirtualBox ticket and there is Ticket #2847 which mentions the handling of this particular key "hankaku" on solaris. But then I notice something fishy there. The keycode reported in ticket #2847 is different from the above 49.

The exact X event generated when the key autorepeats itself for no apparent reason is as follows: captured by xev.

KeyRelease event, serial 33, synthetic NO, window 0x3a00001,

root 0x48, subw 0x0, time 635847596, (777,131), root:(781,181), state 0x0, keycode 49 (keysym 0x60, grave), same_screen YES, XLookupString gives 1 bytes: (60) "`" XFilterEvent returns: False

KeyPress event, serial 33, synthetic NO, window 0x3a00001,

root 0x48, subw 0x0, time 635847596, (777,131), root:(781,181), state 0x0, keycode 49 (keysym 0x60, grave), same_screen YES, XLookupString gives 1 bytes: (60) "`" XmbLookupString gives 1 bytes: (60) "`" XFilterEvent returns: False

KeyRelease event, serial 33, synthetic NO, window 0x3a00001,

root 0x48, subw 0x0, time 635847629, (777,131), root:(781,181), state 0x0, keycode 49 (keysym 0x60, grave), same_screen YES, XLookupString gives 1 bytes: (60) "`" XFilterEvent returns: False

I have found out this flakey behavior earlier this year, and thought it was only my keyboard. But then I experienced on other PC with different keyboard, and figured out it is NOT only my keyboard. And sure enough, when I searched similar problems using google, I found out there ARE MANY perplexed Japanese users (linux guest mostly since I am a user of linux host and interested in such users. It seems that only linux guest users get bitten by this bug.)

Anyway, one of the blog pages I found mentioned this crude kludge of

xset -r 49

and it works for me now. (Of course, no auto-repeating for this particular is available now.)

I think there must be something wrong in the keyboard handler of VirtualBox or guest utility for linux which may need fixing.

TIA

PS: Oh, I now noticed that the key actually is considered accent grave. How interesting.

PPS: I mention the version is 3.0.10, but many users experience this problem (maybe unique to Japanese KB?) since last year it seems so it affects 2.x and even 1.y etc. as well although the cursory check lists 2.4 users being affected by this bug last year.

PPS: Someone mentioned that XP IME (A frontend to input Japanese characters) may steal key up event(?) for this particular key before virtual box has time to see it. Right, accent grave is used to control the Japanese character input handling coupled with ALT key on an English keyboard. [But I am not sure if this stealing of key up event before virtualbox sees it is true or not. I am not sure I saw the same key-repeating problem under vmware. I need to check.] So this is a rumor until substantiated. PPPS: Anyway, this is a major nuisance. Many ubuntu BBS in Japan mention to disable this key for ubuntu-guest under virtualbox as one of the first thing to do after installation from what I gather.

Change History

comment:1 in reply to: ↑ description Changed 4 years ago by claudio_

Replying to zephyrus:

xset -r 49

...

PS: Oh, I now noticed that the key actually is considered accent grave. How interesting.

You noticed the key has the wrong key code (49). As you can see from other bug reports, e.g. #6046 in several occasions two keys are swapped which in X show up as keycode 49 and keycode 94. Usually this affects Mac OS X hosts, but maybe the same is true in your case. So you could look if there is some other key on your keyboard which sends to X keycode 94. This would be then the Hankaku key instead of the one you expect it to be normally.

comment:2 Changed 4 years ago by zephyrus

Claudio,

Thank you for the pointer to #6046.

I think the fix mentioned there seems to closing in on the culprit. But then, the similar fix need to be done for ordinary Japanese keyboard (JP 106 ?), I think. Anyone can fix the proper keyboard handler C source file?

comment:3 Changed 13 months ago by H2O

I seem this problem happens on Windows hosts. It occurs on any guest OS.

Japanese keyboard has "Hankaku / Zenkaku | Kanji" key(H/Z key). This key has special function on Windows.
If we press the H/Z key with the Alt key, This key performs as a general key. Otherwise the H/Z key emulates a toggle button.

wParam-to-actual-input-mode correspondence:
wParam=0x00f3 : Hankaku mode (Alphabet/Number input mode)
wParam=0x00f4 : Zenkaku mode (Japanese character input mode)

In addition, I look like that "ibus" has taken a self measure against this problem.


Case 1: press a H/Z key alone
 down H/Z key   -> send WM_KEYUP (wParam = 0x00f3, lParam = 0xc0290001)
                      and WM_KEYDOWN (wParam = 0x00f4, lParam = 0x00290001)
 up   H/Z key   -> no window message
 down H/Z key   -> send WM_KEYUP (wParam = 0x00f4, lParam = 0xc0290001)
                      and WM_KEYDOWN (wParam = 0x00f3, lParam = 0x00290001)
 up   H/Z key   -> no window message
 down H/Z key   -> send WM_KEYUP (wParam = 0x00f3, lParam = 0xc0290001)
                      and WM_KEYDOWN (wParam = 0x00f4, lParam = 0x00290001)
                      :
                      : Windows sends no window message until begins auto-repeat
                      :
                   send WM_KEYUP (wParam = 0x00f4, lParam = 0xc0290001)
                      and WM_KEYDOWN (wParam = 0x00f3, lParam = 0x00290001)
                   send WM_KEYUP (wParam = 0x00f3, lParam = 0xc0290001)
                      and WM_KEYDOWN (wParam = 0x00f4, lParam = 0x00290001)
                   send WM_KEYUP (wParam = 0x00f4, lParam = 0xc0290001)
                      and WM_KEYDOWN (wParam = 0x00f3, lParam = 0x00290001)
                      :
                      : auto-repeat
                      :
 up   H/Z key   -> no window message

Case 2: press Shift + H/Z key
 down Shift key -> send WM_KEYDOWN (wParam = 0x0010, lParam = 0x002a0001)
                      :
                      : Windows sends no window message until begins auto-repeat
                      :
                   send WM_KEYDOWN (wParam = 0x0010, lParam = 0x402a0001)
                      :
                      : auto-repeat
                      :
 down H/Z   key -> send WM_KEYUP (wParam = 0x00f3, lParam = 0xc0290001)
                      and WM_KEYDOWN (wParam = 0x00f4, lParam = 0x00290001)
                      :
                      : Windows sends no window message until begins auto-repeat
                      :
                   send WM_KEYUP (wParam = 0x00f4, lParam = 0xc0290001)
                      and WM_KEYDOWN (wParam = 0x00f3, lParam = 0x00290001)
                   send WM_KEYUP (wParam = 0x00f3, lParam = 0xc0290001)
                      and WM_KEYDOWN (wParam = 0x00f4, lParam = 0x00290001)
                   send WM_KEYUP (wParam = 0x00f4, lParam = 0xc0290001)
                      and WM_KEYDOWN (wParam = 0x00f3, lParam = 0x00290001)
                      :
                      : auto-repeat
                      :
 up   H/Z key   -> no window message
 up   Shift key -> send WM_KEYUP (wParam = 0x0010, lParam = 0xc02a0001)

Case 3: Alt + H/Z key
 down Alt key   -> send WM_SYSKEYDOWN (wParam = 0x0012, lParam = 0x20380001)
                      :
                      : Windows sends no window message until begins auto-repeat
                      :
                   send WM_SYSKEYDOWN (wParam = 0x0012, lParam = 0x60380001)
                      :
                      : auto-repeat
                      :
 down H/Z key   -> send WM_SYSKEYDOWN (wParam = 0x0019, lParam = 0x20290001)
                      :
                      : Windows sends no window message until begins auto-repeat
                      :
                   send WM_SYSKEYDOWN (wParam = 0x0019, lParam = 0x60290001)
                      :
                      : auto-repeat
                      :
 up   H/Z key   -> send WM_SYSKEYUP (wParam = 0x0019, lParam = 0xe0290001)
 up   Alt key   -> send WM_KEYUP (wParam = 0x0012, lParam = 0xc0380001)
Last edited 13 months ago by H2O (previous) (diff)

comment:4 follow-up: ↓ 5 Changed 13 months ago by frank

  • Description modified (diff)

H2O, you saw this with VBox 4.2.10, right?

comment:5 in reply to: ↑ 4 Changed 13 months ago by H2O

Replying to frank:

H2O, you saw this with VBox 4.2.10, right?

Sorry, I did not describe its version which I inspected.
VirtualBox version: 4.2.10
Host OS: Windows XP Professional SP 3, Windows 7 Professional x64 SP1
Guest OS: Windows 2000 Professional SP 4, Ubuntu 12.04

Method to solve by VirtualBox:

To treat virtual-keycode 0xf3 event and 0xf4 event as "childer and backquote key" of US101.

Method to solve by host OS:

To set "Japanese(Japan) - US keyboard" as the default input method.

Last edited 12 months ago by H2O (previous) (diff)

comment:6 Changed 5 months ago by H2O

VBox 4.2.14+ is worked correct. Thanks someone to fix it up.

Last edited 5 months ago by H2O (previous) (diff)
Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use