お知らせ

  • 利用規約を守って投稿してください。また、よくある質問および投稿の手引きも参照してください。
  • メッセージの投稿にはアカウントが必要です。未登録の方は、ユーザ登録ページからアカウントを作成することができます。

#1 2019-03-01 14:06:32

kznj
メンバ
登録日: 2013-12-03

ubuntu18.04LTS をホストにしたKVM上のゲスト(VM)で、"無変換"キーが認識されない(キーイベントが発生しない)

* 現状
ubuntu18.04 LTS をホストにしたKVM環境を構築しその上でubuntuDesktop18.04LTSや16.04LTSのゲストを動かし始めました。
しかし、いずれのゲストでも"無変換"キーが認識されません(キーイベントが発生しない)
 
* 経緯と背景
今までは16.04LTSをホストにしていたのですが、HDがイカれましたのを契機にホストを18.04LTSで新規インストールしてKVM環境も再構築しました。
ゲストの定義ファイルやVMファイル本体(.qcow2)はバックアップがあったのでそこから復旧しました。
ゲストを動かし始めると"無変換"キーが認識されずキーに対応させておいた動作をしないことに気がつきました。
 
当方はノートブック型のPCを使っておりますが本体のキーボードが使い難いことからUSBキーボードを接続してそちら主たる入力に使っています。
"無変換"キーが認識されないことはPC本体のキーボードとUSBキーボードのどちらを使っても発生しています。
 
* 調査結果
KVM/qemuのゲスト定義ファイルが旧版(ホストが16.04時代のもの)であるため現状環境の18.04との不整合の可能性も考えられましたが、
virt-manager(GUI)上から新たにVM作成して以下を行ったのですが、"無変換"キーは認識されないままでした。
・ゲストの16.04LTSのVMファイル本体の内容はそのままで既存ディスクとして組み込む
・ゲストをまっさらの状態からubuntuDesktop18.04LTSでインストール
 
"無変換"キーが認識されていないことをもう少しツールで深堀りしてみました。
1) xevとevtest
ホスト上では、xevとevtestのいずれを使っても、"無変換"キーはイベントを発生させキーが認識される
ゲスト上では、xevとevtestのいずれを使っても、"無変換"キーはイベントを発生させずキーが認識されない
※ evtestの対象としたのは、"AT Translated Set 2 keyboard"という名前のinputデバイス。
  virt-manager(gui)上では"Virtual Input Device: Generic PS/2 Keyboard"に対応すると推測
 
ubuntu18.04LTSで動作可能なvirt-manager(GUI)からは、"Generic PS/2 Keyboard"に代えて"Generic USB Keyboard"と"Virtio Keyboard"というのも組み込み可能です。
VM上のinputデバイスとしては、"QEMU QEMU USB Keyboard"と"QEMU QEMU virtio Keyboard"に対応するようです。
この2つに対してもevtestを行ったところ"無変換"キーのイベントは発生しませんでした。それだけでなく"変換"や"ひらがな/カタカナ"、"半角/全角"キーもイベントが発生しませんでした。
 
** 考察とコメント
ホスト上では無変換キーのイベントが発生し認識されることからホスト側には問題無し。
ホストからゲストへイベントを引き渡す部分になにか問題あり……qemuのキーボード仮想化部分に問題有りか?
 
** 環境
1)旧環境(HD破損前)
ホスト:ubuntu Server 16.04 LTS(64bit) + パッケージ"ubuntu desktop"(--no-recomendsオプション)
ゲスト:ubuntu Desktop 16.04 LTS(64bit)
2)新環境(HD破損後再構築、"無変換"キーが認識されない)
ホスト:ubuntu Server 18.04 LTS(64bit) + パッケージ"ubuntu desktop"(--no-recomendsオプション)
ゲスト:a)ubuntu Desktop 16.04 LTS(64bit)
    i) 旧環境からそのままの移行版
    ii)新ゲストとして旧環境のqcow2をそのまま使って再構築したもの
ゲスト:b)ubuntu Desktop 18.04 LTS(64bit)
    i) 2)のii)をdo-release-upgradeしたもの
    ii)新ゲストとしてubuntu Desktop 18.04 LTS(64bit)を新規インストールしたもの
※新環境の4つのゲストはすべて同じく"無変換"キーが認識されません。
 
-- ホストのlinux --
Linux xxxxxx 4.15.0-45-generic #48-Ubuntu SMP Tue Jan 29 16:28:13 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
 
--- ホストのlibvirt&qemu --
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
 
-- ゲストのlinux(16.04LST分) --
Linux xxxxx 4.10.0-42-generic #46~16.04.1-Ubuntu SMP Mon Dec 4 15:57:59 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
 
** 資料
(イベントが"発生しない"のは現象として確認できても"~しない"は記録できません。資料としては省きます)
  
** 教えていただきたいこと
「ワークラウンド含めて対処方法」はもちろん知りたいのですが、それ以外に次のようなことがあります。
1)更なる調査をするとしたらなにをすればいいのか?なにを調べればいいのか?
2)Xウィンドウ(X.org)のxkbが原因である可能性があるか?
3)IMEの違いが影響するか?(当方訳あって"ibus-anthy"を使っています)
 
以上、ご教授ご助言よろしくお願いいたします。

オフライン

 

#2 2019-03-10 20:45:48

geeko
新しいメンバ
登録日: 2019-03-10

Re: ubuntu18.04LTS をホストにしたKVM上のゲスト(VM)で、"無変換"キーが認識されない(キーイベントが発生しない)

openSUSE15.0ですが同じ症状でこちらの投稿をヒントにQEMUを2.11.1から3.1.0に更新したら直りました。
3.1.0にまでしなくてもサブマシンは2.12.0で問題なかったのでそのあたりは柔軟に。

オフライン

 

#3 2019-03-11 20:04:59

kznj
メンバ
登録日: 2013-12-03

Re: ubuntu18.04LTS をホストにしたKVM上のゲスト(VM)で、"無変換"キーが認識されない(キーイベントが発生しない)

geeko による投稿:

openSUSE15.0ですが同じ症状でこちらの投稿をヒントにQEMUを2.11.1から3.1.0に更新したら直りました。
3.1.0にまでしなくてもサブマシンは2.12.0で問題なかったのでそのあたりは柔軟に。

qemuをあげて解決されましたか……

わたしは逆にKVMホストを16.04LTSにして、それに伴いqemuを2.5.0に戻しました。
再インストールこそしましたが、18.04LTS(qemu2.11.1)でのトラブル発生前の環境と同じなので問題は起きていません。

現状の16.04LTS調べたことはまた別途報告させていただきます。

オフライン

 

#4 2019-03-11 20:23:30

kznj
メンバ
登録日: 2013-12-03

Re: ubuntu18.04LTS をホストにしたKVM上のゲスト(VM)で、"無変換"キーが認識されない(キーイベントが発生しない)

** 現状

この記事をポストした後で別のHDDを使ってホストを16.04LTSにしたKVM環境を再構築しました。
VMも18.04LTSのHDDからlibvirtが使うゲストの定義ファイル(.xml)やVMの実体ファイル(.qcow2)を復元してゲストを実行しました。
その結果「無変換キーがゲスト上で認識される」ことを確認しました。xevやevtestでも無変換キーは検出されます。

KVMホストの18.04LTSと16.04LTSが違うだけですから、状況的に「無変換キーがゲスト上で認識されない」のはホスト側に原因があると判断されます。

** 調査結果

1) KVM/qemu周辺

KVM/qemuまわりは
 qemu   2.5.0 → 2.11.1
 libvirt  1.3.1 → 4.0.0
へバージョンが上がっています。
 
qemuはだいぶ変わってしまっているので単純比較ができません。
qemuの2.5.0と2.11.1のファイルに、文字列"enkan"でgrepをかけてヒットしたファイルを3つに分類してみます。
A) 2.5.0にのみ存在するファイル
 A-1)./roms/u-boot/include/linux/input.h
 A-2)./include/standard-headers/linux/input.h
B) 2.11.1にのみ存在するファイル
 B-1)./include/standard-headers/linux/input-event-codes.h
 B-2)./qapi/ui.json
 B-3)./ui/keycodemapdb/data/keymaps.csv
 B-4)./hw/input/ps2.c
 B-3)./pc-bios/keymaps/(ja以外のファイル)……2.5.0でもこれらのファイルは存在するがMUHENKANについての記述無し
C) 2.5.0と2.11.1に共通で存在するファイル
 C-1) ./pc-bios/keymaps/ja
 C-2) ./ui/x_keymap.c
 C-3) ./ui/vnc_keysym.h

A-1)とA-2)、B-1)で無変換キー(MUHENKAN)に関して以下の同じ定義(#define)をしています。
>#define KEY_MUHENKAN     94

B-2)は、変換キー(henkan)の記述はありますが、無変換キー(muhenkan)についての記述はありません。

B-3)は、変換キー(KEY_HENKAN)と無変換キー(KEY_MUHENKAN)両方の記述があります。
>KEY_HENKAN,92,,,0x79,0x64,0x86,138,,,,,,,Convert,HENK,henkan,,
>KEY_MUHENKAN,94,,,0x7b,0x67,0x85,139,,,,,,,NonConvert,NFER,,,

B-4)は、QEMUコードをスキャンコードに変換するテーブル(Table to convert from QEMU codes to scancodes)が3種類定義されています。
3種類それぞれの用途は不明ですが、ここに変換キー(KEY_HENKAN)はありますが無変換キー(KEY_MUHENKAN)の記述がありません。

C-1)は、2.5.0だと
>Muhenkan 0x7b
と定義されていたのが
2.11.1だと
># evdev 94 (0x5e): no evdev -> QKeyCode mapping (xkb keysym Muhenkan)
QKeyCode(*1)へのマッピングに置き換えれています。
 
因みに、変換キー(henkan)は、2.5.0と2.11.1の両方でmapping無しで定義されています。
2.5.0
>Henkan_Mode_Real 0x79
2.11.1
># evdev 92 (0x5c), QKeyCode "henkan", number 0x79
>Henkan_Mode 0x79
 
C-2)は、結構変わっていて
2.11.1でトレース関数とエラーレポート関数が追加されたようで
> #include "trace.h"
> #include "qemu/error-report.h"
それを受けて、各所でfprintfでワーニングメッセージを出していた箇所が
> trace_keymap_unmapped(keysym);
> warn_report("no scancode found for keysym %d", keysym);
で置き換えられています。
それ以外では、parse_keyboard_layoutという関数があり、C-1)の./pc-bios/keymaps/jaを行単位に解釈しています。
そのコアな部分がほぼ全面的に書き換えられています。
これはまあいいとして……
 
問題は、この関数の中で./pc-bios/keymaps/jaの行単位の処理時に
ここで行頭が"#"……つまりコメント行ですが、これは読み飛ばされてキーボードレイアウトとして認識されません。
 
C-1)で書いたように、無変換キー(Muhenkan)はQKeyCodeへのマッピング扱いでコメント行です。
つまり、無変換キー(Muhenkan)はparse_keyboard_layoutで処理されません。
 
C-3)は、2.11.1では
>{"Page_Down", 0xff56}, /* XK_Page_Down */
の前後に、同一のシンボルコード(0xff56)で
> {"Next", 0xff56},
> {"Prior", 0xff55},
が追加されています。

*1:QkeyCode 
 調べてみたんですが詳細がよくわかりません。
 推測として"Q(emu) Key Code"の意味で、qemuが統一的にキーコードを取り扱うために独自のコードを割り振ってるのかもしれせまん。

** 考察とコメント
・qemuのソースを大雑把に比較しただけでも、ubuntu18.04LTSに入っているqemu2.11.1ではキーボードのキーの扱いが変更されている
・その変更は一部のキーをQKeyCodeを介してX Windowのkeysymにマッピングするらしい(推測)
・無変換キー(KEY_MUHENKAN)もそのマッビングの対象になっている
・QKeyCodeマッピングは無変換キー(KEY_MUHENKAN)以外にも適用されているので特別な扱いではなく、qemu2.11.1ではHWキーイベントと並ぶ一般的な取扱い方である
 
** 教えていただきたいこと
※qemuのバージョンを上げて解決された実績が確認されたのでqemu2.11.1のままでなんとかしようとするのは徒労の予感がしますが、ubuntu18.04LST(Bionic Beaver)に対応するqemuは、2.11.xで止まってるので……

「ワークラウンド含めて対処方法」はもちろん知りたいのですが、特に知りたいのは以下のことです。
1)QKeyCodeマッピング扱いになっているキーのイベントを発生されるにはどうするばいいのか?
2)Xウィンドウ(X.org)のxkbの設定をいじれば対応できるのか?
3)無変換キー(KEY_MUHENKAN)が機能しなかった18.04LTSの環境では、HWイベントを検証するevtestでもX Windowイベントを検証するxevでも、無変換キー(KEY_MUHENKAN)はイベントとして認識されていないが、それでもなんとか対応方法があるのか?
 
以上、ご教授ご助言よろしくお願いいたします。

** 資料

1)KVMホストを16.04LTSにした環境でゲスト上で実行したxev&evtest

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) 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

オフライン

 

#5 2019-03-13 16:42:06

kznj
メンバ
登録日: 2013-12-03

Re: ubuntu18.04LTS をホストにしたKVM上のゲスト(VM)で、"無変換"キーが認識されない(キーイベントが発生しない)

geeko による投稿:

openSUSE15.0ですが同じ症状でこちらの投稿をヒントにQEMUを2.11.1から3.1.0に更新したら直りました。
3.1.0にまでしなくてもサブマシンは2.12.0で問題なかったのでそのあたりは柔軟に。

 
 
qemuを3.1.0にあげて(もしくは2.12.0でも)、無変換キー(Muhenkan)がKVMのゲストで認識されたようなので、以下のバージョンでqemuのソースコードの一部を比較してみました。
A) qemu 2.11.1
B) qemu 2.11.2
C) qemu 2.12.0
 
比較対象のファイルは、Muhenkanに関しての定義または操作が入っている次のものです。
a) pc-bios/keymaps/ja 
b) ui/x_keymap.c    
c) ui/x_keymap.h    
d) ui/vnc_keysym.h   
e) hw/input/ps2.c   
 
まず、A)の2.11.1とB)の2.12.2の間では、少なくとも対象ファイルについては差異ありません。
このため「無変換キー(Muhenkan)がKVMのゲストで認識されない」という現象は、2.11.1→2.11.2では解消しないと推測されます。
 
それ以外を比較するとA)のqemu 2.11.1(それと同一のB)のqemu 2.12.2の2バージョン)と、C)のqemu 2.12.0は相当変更があります。
 
それでも、a)のpc-bios/keymaps/jaと、d)のui/vnc_keysym.hは同じです。
 
b)のui/x_keymap.cとc)のui/x_keymap.hは次の点が変わりました。
- X Windowのキーコードをスキャンコードに変換するx_keycode_to_pc_keycodeテーブルをqemuが自前で定義していたが、それが無くなり、X11の定義を参照するようなった。
- (キー)デバイスイベントをスキャンコードに変換するevdev_keycode_to_pc_keycodeテーブルをqemuが自前で定義していたが、それが無くなった。
- 上記2つに対応して、それぞれのテーブルの走査して値を返していたtranslate_xfree86_keycode関数と、translate_evdev_keycode関数が無くなった。
- 無くなった関数の代わりに、qemu_xkeymap_mapping_table関数で一本化した。
 
e)のhw/input/ps2.cも次の点が変わりました。
- キーボードの種別(XT、AT、PS/2)に応じてQEMU codes(*1)をスキャンコードに変換していた3つのテーブルqcode_to_keycode_set1〜3が無くなりました。
- 無くなったテーブルに代わって、qemu_input_map_qcode_to_atset1〜3(*2)が使われるている。
 
*1:QKey Codeのことだと推測されます。
*2:このテーブルはgrepで検索しても出て来ません。qemuのC言語以外の記述か、qemu外にあるオブジェクトなど特殊なもののようです。
 
※ b)とe)の変更が大きかったので、以下のような無変換キー(Muhenkan)の"no evdev"扱いがどう処理されるようになったのか簡単には分かりませんでした。
># evdev 94 (0x5e): no evdev -> QKeyCode mapping (xkb keysym Muhenkan)
 
 
私見含めてまとめると以下のようになります。
- 18.04LTSにおいて「無変換キー(Muhenkan)がKVMのゲストで認識されない」現象は、qemu-2.11.1をqemu-2.12.0以降にすれば解消しそうだ
- その根拠は、2.12.0に上げて解消した実績がOpenSUSEで出ている。ソースを比較してみると2.11.x→2.12.0の変更具合からも期待出来る
- ただ、18.04LTSのqemuは現状2.11.1でそれ以降が出ていないので、2.12.0以降にするには次のどちらかが必要になる
* 18.04LTS(Bionic Beaver)から18.10(Cosmic Cuttlefish)にして、qemuを2.12.0にする ※但しLTSを手離すことになる
* qemu-2.12.0をソースからビルドする
- それ以外では、16.04LTSにしてqemu-2.5.0に戻す方法もある

オフライン

 

#6 2019-03-14 07:45:52

Templer
メンバ
登録日: 2009-07-08

Re: ubuntu18.04LTS をホストにしたKVM上のゲスト(VM)で、"無変換"キーが認識されない(キーイベントが発生しない)

何も調べていない人間が発言することをおゆるしください。

evdevという文字が目に止まってちょっと思ったのですが、16.04まではXのinputに文字通りのevdevドライバーが使われていました。ですが、18.04からはlibinputドライバーが使われるようになっています。その影響で、ということはありませんでしょうか?

オフライン

 

#7 2019-03-14 15:03:51

kznj
メンバ
登録日: 2013-12-03

Re: ubuntu18.04LTS をホストにしたKVM上のゲスト(VM)で、"無変換"キーが認識されない(キーイベントが発生しない)

Templer による投稿:

……16.04まではXのinputに文字通りのevdevドライバーが使われていました。ですが、18.04からはlibinputドライバーが使われるようになっています。その影響で、ということはありませんでしょうか?

 
 
漠然としたご指摘で反応しにくいんですが
「Xのinputは、16.04まではevdevドライバーが使われていたが、18.04からはlibinputドライバーになったので、そこで無変換キー(Mukenkan)の取扱いが変わった(=認識されなくなった)のではないか?」
と解釈させていただきます。
そうだとして、その指摘は現象と整合しません。
 
1) 18.04LTSを使ったKVMホスト上で、無変換キー(Mukenkan)は認識されている
 
libinputドライバーになったことで無変換キー(Mukenkan)の取扱いが変わった(=認識されなくなった)のなら、18.04LTSを使ったKVMホストで直に起動したターミナル、アプリ等、KVMのゲストでないものにおいても、無変換キー(Mukenkan)が認識されなくなりそうですが、そんなことはありませんでした。
18.04LTSを使ったKVMホストの上で、無変換キー(Mukenkan)は認識されており、xevでもevtestでも無変換キー(Mukenkan)のイベントは発生しています。
 
そのことは、この記事の#1に下記のように書いておきました。ホストとは18.04LTSのKVMホストです。
>1) xevとevtest
>ホスト上では、xevとevtestのいずれを使っても、"無変換"キーはイベントを発生させキーが認識される
 
2) 無変換キー(Mukenkan)が認識されなくないゲストは、18.04LTSと16.04LTSの両方である
 
問題としている「KVMゲスト上で無変換キー(Mukenkan)の認識されない」現象は、18.04LTSと16.04LTSの両方で起きています。
libinput-driverになっているのは18.04LTSのほうですからこちらで問題の現象が起きるのはご指摘と整合します。
しかし、16.04LTSのゲストは従来のevdev-driverの動作なので問題は起きないと思われますが実際には起きています。
 
ゲストに18.04LTSと16.04LTSの両方を使ったことは、この記事の#1に下記のように書いておきました。
>*現状
>ubuntu18.04 LTS をホストにしたKVM環境を構築しその上でubuntuDesktop18.04LTSや16.04LTSのゲストを動かし始めました。
>しかし、いずれのゲストでも"無変換"キーが認識されません(キーイベントが発生しない)
 
3) evdev-driverとlibinput-driverの関係
 
こちらのWikipedia(EN)の記事( https://en.wikipedia.org/wiki/Evdev )を見てください。
>It sits below the process that handles input events, in between the kernel and that process.
> Linux kernel → libevdev → xf86-input-evdev → X server → X client
> 
>For Weston/Wayland, the stack would look like this:
> Linux kernel → libevdev → libinput → Weston → Wayland client
>
>Since version 1.16 the xorg-xserver obtained support for libinput:
> Linux kernel → libevdev → libinput → xf86-input-libinput → X server → X client

一番目がXがevdev-driver(Xf86-input-evdev)を使う場合で、三番目がlibinput-driver(libinput&xf86-input-libinput)を使う場合に相当します。
いずれの場合もlibevdevを介しています。libevdevとはevdevつまりevent device((=/dev/input/にあるデバイスファイル)とのI/Fライブラリです。
その上にあるのがXのevdev-driverとlibinput-driverになりますが、libinput-driverがlibevdevから上がるイベントをイベント種別で区別して特別なことをしない限り、evdev-driverとlibinput-driverは同質と見做せます。
 
念のため、18.04LTS(Bionic Beaver)に対応するlibinput-driverのソースを見てみましたが、イベント種別を使って振り分けるような処理はないので、無変換キー(Mukenkan)を特別扱いはしていないようです。
また、1)で述べたように、無変換キー(Muhenkan)は、/dev/input/のデバイスファイルを検証するevtestでも、Xのイベントを検証するxevでも、イベントを発生させキーが認識されています。つまり、イベントがそのまま無選別・無加工でXまで上がっているように見えます。
そのことからも、libinput-driverがイベント種別を使って振り分けるような処理はしてないと思われます。
 
【補足】
ubuntuと、Xorg-serverパッケージ、driver(evdev-driver、libinput-driver)の間のバージョンの対応は下記のようになっています。
16.04LTS(Xenial Xerus)   xorg-server-1.18.4  xserver-xorg-input-evdev-2.10.5、libinput-driver-1.6.3
18.04LTS(Bionic Beaver)  xorg-server-1.19.6  libinput-driver-1.10.4

オフライン

 

Board footer

Powered by FluxBB