In a VM of the KVM host of "ubuntu 18.04 LTS", 'Muhenkan' key has become ineffective(it doesn't fire event).

After That：In a VM of the KVM host of "ubuntu 18.04 LTS", 'Muhenkan' key has become ineffective(it doesn't fire event).

** current status
After posting the original article I rebuilt the KVM environment of 16.04 LTS in another HDD.
I restored the guest definition files(.xml) that 'libvirt' uses and the VM entity files(.qcow2) from the 18.04 LTS HDD and I executed the guests.
In the result, I confirmed that "Muhenkan" key was recognized on the guest. In 'xev' and 'evtest" tool, "Muhenkan" key was detected.

In the KVM host, there is the difference between 18.04 LTS and 16.04 LTS.
And so it is judged that just on the host there is a cause that "Muhenkan" key can not be recognized on guest.

** verification
1) Around KVM / qemu

These version are updateed as the below.
 qemu 2.5.0 → 2.11.1
 libvirt 1.3.1 → 4.0.0

"qemu" has changed so much that I couldn't do simple comparison.
I did "grep" with the string "enkan" against the files of qemu's 2.5.0 and 2.11.1 and I've tried to classify these files that were hit into 3 classes.

A) Files that exist only in qemu 2.5.0
 A-1)./roms/u-boot/include/linux/input.h
 A-2)./include/standard-headers/linux/input.h
 B-1)./include/standard-headers/linux/input-event-codes.h
A) Files that exist only in qemu 2.11.1
 B-2)./qapi/ui.json
 B-3)./ui/keycodemapdb/data/keymaps.csv
 B-4)./hw/input/ps2.c
 B-3)./pc-bios/keymaps/(Files other than 'ja')……These files exist even in 2.5.0 but they have no descrption about MUHENKAN
C) Files that exist in both qemu 2.5.0 and qemu 2.11.1
 C-1) ./pc-bios/keymaps/ja
 C-2) ./ui/x_keymap.c
 C-3) ./ui/vnc_keysym.h

In A-1) and A-2), B-1), there is the same definitions (#define) for "MUHENKAN" key as the below.
>#define KEY_MUHENKAN 94

In B-2), there is the description for "HENKAN" key but there is no description for ""MUHENKAN" key.

In B-3), there are descriptions for both "KEY_HENKAN" key and "KEY_MUHENKAN" key.
>KEY_HENKAN,92,,,0x79,0x64,0x86,138,,,,,,,Convert,HENK,henkan,,
>KEY_MUHENKAN,94,,,0x7b,0x67,0x85,139,,,,,,,NonConvert,NFER,,,

In B-4), Three types of tables are defined to convert QEMU codes to scan codes.
The each use of the three types is unknown but there is only a description for "KEY_HENKAN" key but no description for "KEY_MUHENKAN" key.

In C-1), the definition as the below in qemu 2.5.0
>Muhenkan 0x7b
is replaced "QKeyCode(*1) mapping" as the below in qemu 2.11.1
># evdev 94 (0x5e): no evdev -> QKeyCode mapping (xkb keysym Muhenkan)

Additionally "Henkan" key is defined without "QkeyCode mapping" in both qemu 2.5.0 and qemu 2.11.1.
2.5.0
>Henkan_Mode_Real 0x79
2.11.1
># evdev 92 (0x5c), QKeyCode "henkan", number 0x79
>Henkan_Mode 0x79

In C-2), many differences has occurred.
It seems that trace functions and error report functions are added in 2.11.1 and new "include"s were added.
> #include "trace.h"
> #include "qemu/error-report.h"
According to that, the various places where warning message was issued by fprintf has been replaced as the below.
> trace_keymap_unmapped (keysym);
> warn_report ("no scancode found for keysym% d", keysym);

Besides that, "parse_keyboard_layout" function which interprets lines of "./pc-bios/keymaps/ja" ( that is C-1) ) , its core part has been almost completely rewritten.
However it is not a big matter, the matter is the below.
In "parse_keyboard_layout" function, at the time of line processing of "./pc-bios/keymaps/ja", the line with the beggining character of "#", this is a comment line, is skipped and not recognized as a keycode.
As I wrote about C-1), "Muhenkan" key is defined in a comment line to be handled as "QKeyCode mapping". That is, "Muhenkan" key is not processed in "parse_keyboard_layout" function.

In C-3), in 2.11.1, before and after the definition as the below
> {"Page_Down", 0xff 56}, / * XK_Page_Down * /
2 definitions with the same symbol code (0xff 56) were added as the below.
> {"Next", 0xff 56},
> {"Prior", 0xff 55},

*1: QkeyCode
I tried to investigate but I do not get the details.
As a guess, Is is "Q(emu) Key Code", "qemu" may assign its own codes in order to handle key codes in a unified way.

** consideration & comment
- In Comparing "qemu" sources codes roughly, qemu 2.11.1 in ubuntu 18.04 LTS has changed keyboard 'skey handling
- In that change,it seems to map hardware keys to X Windows keys (keyym) via "QKeyCode".
- "MUHENKAN"(or "KEY_MUHENKAN") key is processed in that mapping("QKeyCode mapping").
- "QKeyCode mapping" is applied to other keys than "MUHENKAN" key, and so it is not a specially handling way. In qemu 2.11.1, it is an another general way than the one it does directly to hardware key events.

** requested items
Of course, I would like to know "How could I resolve? Are there workrounds?". But Especially I'do like to know the following.
- For the keys processed in "QKeyCode mapping", What shold I do to generate their key events?
- By making any trick in the configuration of xkb(X KeyBoard extension), Could I resolve this trouble?
- In the guest of the KVM environment of 18.04 LTS in which "MUHENKAN" key did not work, "evtest" did not detect the hardware event for it and "xev" which did not detect the X window event for it. In the situation where these events can not be detected, could I deal with them?

I would appreciate your guidance.

** data
1) the result of Xev & evtest executed on guest in environment with KVM host set to 16.04 LTS

a) xev
KeyPress event, serial 34, synthetic NO, window 0x4200001,
    root 0x276, subw 0x0, time 70692883, (-393,-568), root:(1109,304),
    state 0x10, keycode 102 (keysym 0xff22, Muhenkan), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 37, synthetic NO, window 0x4200001,
    root 0x276, subw 0x0, time 70692958, (-393,-568), root:(1109,304),
    state 0x10, keycode 102 (keysym 0xff22, Muhenkan), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

b) evtest
ls -la /dev/input/by-path/
合計 0
drwxr-xr-x 2 root root 100 3月 8 19:37 .
drwxr-xr-x 3 root root 200 3月 8 19:37 ..
lrwxrwxrwx 1 root root 9 3月 8 19:37 platform-i8042-serio-0-event-kbd -> ../event1
lrwxrwxrwx 1 root root 9 3月 8 19:37 platform-i8042-serio-1-event-mouse -> ../event3
lrwxrwxrwx 1 root root 9 3月 8 19:37 platform-i8042-serio-1-mouse -> ../mouse0

sudo evtest /dev/input/event1
Input driver version is 1.0.1
Input device ID: bus 0x11 vendor 0x1 product 0x1 version 0xab41
Input device name: "AT Translated Set 2 keyboard"
Supported events:

Testing ... (interrupt to exit)
Event: time 1552111588.973062, type 4 (EV_MSC), code 4 (MSC_SCAN), value 7b
Event: time 1552111588.973062, type 1 (EV_KEY), code 94 (KEY_MUHENKAN), value 1
Event: time 1552111588.973062, -------------- SYN_REPORT ------------
Event: time 1552111589.031956, type 4 (EV_MSC), code 4 (MSC_SCAN), value 7b
Event: time 1552111589.031956, type 1 (EV_KEY), code 94 (KEY_MUHENKAN), value 0
Event: time 1552111589.031956, -------------- SYN_REPORT ------------
Event: time 1552111590.734106, type 4 (EV_MSC), code 4 (MSC_SCAN), value 7b
Event: time 1552111590.734106, type 1 (EV_KEY), code 94 (KEY_MUHENKAN), value 1
Event: time 1552111590.734106, -------------- SYN_REPORT ------------
Event: time 1552111590.775968, type 4 (EV_MSC), code 4 (MSC_SCAN), value 7b
Event: time 1552111590.775968, type 1 (EV_KEY), code 94 (KEY_MUHENKAN), value 0

2) the difference in version around KVM/qemu

a)18.04LTS
Compiled against library: libvirt 4.0.0
Using library: libvirt 4.0.0
Using API: QEMU 4.0.0
Running hypervisor: QEMU 2.11.1

b)16.04LTS
QEMU　QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.34), Copyright (c) 2003-2008 Fabrice Bellard
libvirt　libvirtd (libvirt) 1.3.1

This question was expired because it remained in the 'Open' state without activity for the last 15 days.