[BUG] Button mapping broken: Keyboard event not received by application

[MarcelWaldvogel]

Description
Creating a mapped action to a keyboard event does not result in that keyboard event being accepted by an application.

To Reproduce

• Create an input mapping from a presenter button to a key.
• Go to an application accepting text input.
• Press that button.
• The application does not respond to that key.

Expected behavior
The application does respond to the key.

Desktop/Linux Environment (please complete the following information):

• Linux Distribution and Version: Debian Bookworm
• Desktop/Window Manager and Version: GNOME 43.6 (Wayland)
• Did you built Projecteur yourself?: Both y+n (Debian Bookworm standard and my powerpointer branch (PR Basic support for Kensington PowerPointer #215)
  (If yes: Please run cmake for existing build directories, to ensure the generated version info is up to date)
• What is the output of projecteur -f ?:

Projecteur 1.0-alpha.203
  - git-branch: kensington-powerpointer
  - git-hash: 1388d2c067be45be35286ac394ae30ae855eb917
  - compiler: GNU 12.2.0
  - build-type: Release
  - qt-version: (build: 5.15.8, runtime: 5.15.8)
  - device-scan: (errors: 0, devices: 1 [readable: 1, writable: 1])

The hash is this one

• What is the output of projecteur -d ?:

Projecteur 0.10; device scan

 * Found 1 supported devices. (1 readable, 1 writable)

 +++ name:     'Kensington PowerPointer'
     userName: 'Kensington PowerPointer'
     vendorId:  1ea7
     productId: 0002
     phys:      usb-0000:03:00.4-2
     busType:   BusType::Usb
     devices:   /dev/input/event23, /dev/input/event27, /dev/input/event25, /dev/input/event26, /dev/input/event24
     readable:  true
     writable:  true

Other information

• Running evtest on the uinput device (Projecteur_virtual_keyboard for the current state, Projecteur_input_device for the Bookworm version from the v0.9.2 tag) shows the events being sent (the action is E):

Event: time 1699734912.334021, type 1 (EV_KEY), code 18 (KEY_E), value 1
Event: time 1699734912.334021, -------------- SYN_REPORT ------------
Event: time 1699734912.334053, type 1 (EV_KEY), code 18 (KEY_E), value 0
Event: time 1699734912.334053, -------------- SYN_REPORT ------------

However, nobody seems to receive it.

• dmesg shows the following:

[306262.896348] ------------[ cut here ]------------
[306262.896353] add_uevent_var: buffer size too small
[306262.896367] WARNING: CPU: 5 PID: 197281 at lib/kobject_uevent.c:671 add_uevent_var+0x118/0x130
[306262.896377] Modules linked in: uinput snd_usb_audio snd_usbmidi_lib snd_rawmidi usbhid ctr ccm xt_conntrack nft_chain_nat xt_MASQUERADE nf_nat nf_conntrack_netlink nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xfrm_user xfrm_algo xt_addrtype nft_compat nf_tables libcrc32c nfnetlink br_netfilter bridge stp llc rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device cmac algif_hash algif_skcipher af_alg qrtr overlay bnep binfmt_misc nls_ascii nls_cp437 vfat fat squashfs snd_ctl_led btusb iwlmvm btrtl snd_hda_codec_realtek btbcm snd_hda_codec_generic btintel btmtk ledtrig_audio snd_hda_codec_hdmi mac80211 snd_hda_intel bluetooth intel_rapl_msr uvcvideo snd_intel_dspcfg intel_rapl_common libarc4 videobuf2_vmalloc snd_intel_sdw_acpi videobuf2_memops snd_hda_codec jitterentropy_rng edac_mce_amd iwlwifi videobuf2_v4l2 snd_pci_acp6x snd_hda_core drbg kvm_amd videobuf2_common snd_pci_acp5x snd_hwdep joydev ansi_cprng snd_pcm snd_rn_pci_acp3x cfg80211 ucsi_acpi videodev snd_acp_config ecdh_generic
[306262.896459]  snd_timer kvm typec_ucsi irqbypass mc snd_soc_acpi ecc snd roles rapl sp5100_tco wmi_bmof ccp pcspkr snd_pci_acp3x soundcore rfkill typec watchdog k10temp cm32181 industrialio acpi_cpufreq amd_pmc ac hid_multitouch evdev serio_raw msr parport_pc ppdev lp parport fuse loop efi_pstore configfs efivarfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic dm_crypt dm_mod amdgpu gpu_sched nvme drm_buddy i2c_algo_bit nvme_core crc32_pclmul t10_pi drm_display_helper crc32c_intel cec crc64_rocksoft_generic rc_core ghash_clmulni_intel xhci_pci crc64_rocksoft drm_ttm_helper sha512_ssse3 xhci_hcd crc_t10dif ttm hid_generic sha512_generic crct10dif_generic aesni_intel crct10dif_pclmul drm_kms_helper i2c_hid_acpi usbcore crypto_simd crc64 drm i2c_hid cryptd video i2c_piix4 usb_common crct10dif_common battery hid wmi button
[306262.896541] CPU: 5 PID: 197281 Comm: projecteur Tainted: G        W          6.1.0-13-amd64 #1  Debian 6.1.55-1
[306262.896546] Hardware name: HP HP EliteBook 855 G7 Notebook PC/8760, BIOS S77 Ver. 01.06.00 07/29/2021
[306262.896548] RIP: 0010:add_uevent_var+0x118/0x130
[306262.896552] Code: 5b 41 5c 5d e9 d9 61 44 00 48 c7 c7 00 ef 41 8e e8 9d 0f 6e ff 0f 0b b8 f4 ff ff ff eb ce 48 c7 c7 28 ef 41 8e e8 88 0f 6e ff <0f> 0b eb e9 e8 8f f3 06 00 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f
[306262.896555] RSP: 0018:ffffb93a8d007bd0 EFLAGS: 00010282
[306262.896558] RAX: 0000000000000000 RBX: ffff9afa98b21000 RCX: 0000000000000000
[306262.896560] RDX: 0000000000000002 RSI: ffffffff8e39ec9e RDI: 00000000ffffffff
[306262.896562] RBP: ffffb93a8d007c30 R08: 0000000000000000 R09: ffffb93a8d007a40
[306262.896564] R10: 0000000000000003 R11: ffffffff8eabd3e8 R12: 0000000000000009
[306262.896565] R13: 0000000000000000 R14: ffffffff8e3fa918 R15: 0000000000000000
[306262.896567] FS:  00007f9c49754d00(0000) GS:ffff9b016f940000(0000) knlGS:0000000000000000
[306262.896570] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[306262.896572] CR2: 00007f9c2344c000 CR3: 0000000105b08000 CR4: 0000000000350ee0
[306262.896574] Call Trace:
[306262.896577]  <TASK>
[306262.896581]  ? __warn+0x7d/0xc0
[306262.896585]  ? add_uevent_var+0x118/0x130
[306262.896588]  ? report_bug+0xe6/0x170
[306262.896592]  ? irq_work_queue+0xa/0x50
[306262.896598]  ? handle_bug+0x41/0x70
[306262.896603]  ? exc_invalid_op+0x13/0x60
[306262.896607]  ? asm_exc_invalid_op+0x16/0x20
[306262.896615]  ? add_uevent_var+0x118/0x130
[306262.896618]  ? dev_uevent+0xba/0x2f0
[306262.896623]  kobject_uevent_env+0x356/0x660
[306262.896627]  device_del+0x2c8/0x410
[306262.896632]  input_unregister_device+0x41/0x60
[306262.896639]  uinput_destroy_device+0xba/0xc0 [uinput]
[306262.896647]  uinput_ioctl_handler.isra.0+0x37d/0x920 [uinput]
[306262.896656]  __x64_sys_ioctl+0x90/0xd0
[306262.896661]  do_syscall_64+0x5b/0xc0
[306262.896665]  ? fpregs_restore_userregs+0x56/0xe0
[306262.896670]  ? exit_to_user_mode_prepare+0x147/0x1d0
[306262.896675]  ? syscall_exit_to_user_mode+0x27/0x40
[306262.896678]  ? do_syscall_64+0x67/0xc0
[306262.896682]  ? exit_to_user_mode_prepare+0x147/0x1d0
[306262.896685]  ? syscall_exit_to_user_mode+0x27/0x40
[306262.896688]  ? do_syscall_64+0x67/0xc0
[306262.896692]  ? syscall_exit_to_user_mode+0x27/0x40
[306262.896695]  ? do_syscall_64+0x67/0xc0
[306262.896699]  ? fpregs_assert_state_consistent+0x22/0x50
[306262.896702]  ? exit_to_user_mode_prepare+0x40/0x1d0
[306262.896706]  entry_SYSCALL_64_after_hwframe+0x64/0xce
[306262.896710] RIP: 0033:0x7f9c4911cb5b
[306262.896714] Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1c 48 8b 44 24 18 64 48 2b 04 25 28 00 00
[306262.896716] RSP: 002b:00007ffc375a80d0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[306262.896719] RAX: ffffffffffffffda RBX: 000055e0d2f76f70 RCX: 00007f9c4911cb5b
[306262.896721] RDX: 0000000100000001 RSI: 0000000000005502 RDI: 0000000000000019
[306262.896723] RBP: 000055e0d3024cf0 R08: 0000000000000007 R09: 000055e0d325fa40
[306262.896725] R10: f53eddf8626649ca R11: 0000000000000246 R12: 000055e0d3024cf0
[306262.896726] R13: 000055e0d3024cc0 R14: 000055e0d32629c0 R15: 0000000100000001
[306262.896731]  </TASK>
[306262.896732] ---[ end trace 0000000000000000 ]---
[306267.112751] input: Projecteur_input_device as /devices/virtual/input/input150

This seems related to this bug, where the Xen virtual keyboard is also adding all possible keybits, resulting in an overly long MODALIAS and therefore exhausting the kernel buffer.

[MarcelWaldvogel]

Experimentally, I lowered the upper key limit from KEY_MACRO1 (0x290) to KEY_COMPOSE (127).

Now, the E is received by applications.

Judging from the following code/comment, may I presume that you ran into a similar problem earlier?

Projecteur/src/virtualdevice.cc

Lines 103 to 106 in eb9ff49

	for (int i = KEY_OK; i < KEY_MACRO1; ++i) {
	ioctl(fd, UI_SET_KEYBIT, i);
	}
	// will set key bits from i = KEY_MACRO1 to i < KEY_CNT also work?

[MarcelWaldvogel]

From the above-mentioned Debian bug discussion, it is my understanding that a kernel fix is required to really fix the problem (increase the buffer to handle these generic virtual keyboards).

Proposal:

• For the time being, lower the upper limit of the for loop to something smaller than KEY_MACRO1 (KEY_SELECTIVE_SCREENSHOT works for my setup and is not as radical a step as KEY_COMPOSE, which was just to see whether the number of supported keys was the culprit).
• Once a fixed kernel is released, find a way to determine whether the currently-running kernel is one with the fix. (The problem is not with the ioctl(), but at a later stage.)
• For a fixed kernel, raise the upper limit to KEY_CNT, for broken ones, keep them at the value below KEY_MACRO1.
• (Possibly already now find out whether it is an old enough kernel which did not propagate the error. This version seems to be "safe" in that the udev-related processing was able to continue.)

[jahnf]

Experimentally, I lowered the upper key limit from KEY_MACRO1 (0x290) to KEY_COMPOSE (127).

Now, the E is received by applications.

Judging from the following code/comment, may I presume that you ran into a similar problem earlier?

Projecteur/src/virtualdevice.cc

Lines 103 to 106 in eb9ff49

	for (int i = KEY_OK; i < KEY_MACRO1; ++i) {
	ioctl(fd, UI_SET_KEYBIT, i);
	}
	// will set key bits from i = KEY_MACRO1 to i < KEY_CNT also work?

Yes indeed there was an issue, I will have time to look into it again next week.

Thank you for the detailed information