-
Notifications
You must be signed in to change notification settings - Fork 272
Description
System Details:
- Keyboard: Keychron K3 Pro
- Vial Version: v0.7.5 (x86_64.AppImage)
- Operating System: Arch Linux
- Kernel: Linux admin 6.18.3-arch1-1 Update readme to include docs links #1 SMP PREEMPT_DYNAMIC Fri, 02 Jan 2026 17:52:55 +0000 x86_64 GNU/Linux
Summary
The Vial GUI launches successfully but does not detect the Keychron K3 Pro. The issue persists even when running the AppImage as the root user, indicating the problem
is not related to device permissions. Standard udev rule configurations have proven completely ineffective.
Core Issue
The underlying problem appears to be a failure of Vial to interface with the hidraw device, even when all permissions are granted. The kernel correctly identifies the
keyboard and creates the hidraw nodes, but Vial cannot see or use them. Since running as root does not solve the problem, this is not a user-level permissions issue.
Troubleshooting Steps Done
- Kernel Device Detection: Confirmed the kernel properly detects the keyboard and creates hidraw nodes. See dmesg log below.
udevRule Configuration:- Attempted multiple udev rules in /etc/udev/rules.d/ (including the generic Vial rule, a device-specific rule with VID:PID 3434:0230, and simplified variations).
- Confirmed rules were correctly placed, owned by root, and had -rw-r--r-- permissions.
- The udev daemon was reloaded (udevadm control --reload && udevadm trigger) and the device was unplugged/replugged after each change.
- Result: All udev rules were consistently ignored. The permissions on /dev/hidraw* devices remained crw------- root root.
- Search for Conflicting Rules: Searched for the device's vendor ID (3434) in both /etc/udev/rules.d/ and /usr/lib/udev/rules.d/. No conflicting rules were found.
- Running as Root:
- Used xhost +si:localuser:root to grant the root user access to the X display.
- Launched the Vial AppImage using sudo.
- Result: The GUI successfully launched, but the device was still not detected. This confirms the issue is not permissions-based.
- Check for Exclusive Device Access: Used sudo lsof /dev/hidraw* to check if another process had an exclusive lock on the device files.
- Result: lsof returned no output, indicating no other process was using the files.
- Hardware Checks: Ensured the physical switch on the keyboard was set to "Windows" mode.
Relevant Logs
lsusb Output:
1 Bus 003 Device 004: ID 3434:0230 Keychron Keychron K3 Pro
dmesg Output upon connection:
1 [18457.701843] usb 3-1: new full-speed USB device number 7 using xhci_hcd
2 [18457.849188] usb 3-1: New USB device found, idVendor=3434, idProduct=0230, bcdDevice= 1.00
3 [18457.849193] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
4 [18457.849196] usb 3-1: Product: Keychron K3 Pro
5 [18457.849198] usb 3-1: Manufacturer: Keychron
6 [18457.865370] input: Keychron Keychron K3 Pro as /devices/pci0000:00/0000:00:08.1/0000:2f:00.3/usb3/3-1/3-1:1.0/0003:3434:0230.0015/input/input53
7 [18457.952934] hid-generic 0003:3434:0230.0015: input,hidraw0: USB HID v1.11 Keyboard [Keychron Keychron K3 Pro] on usb-0000:2f:00.3-1/input0
8 [18457.956346] hid-generic 0003:3434:0230.0016: hiddev96,hidraw1: USB HID v1.11 Device [Keychron Keychron K3 Pro] on usb-0000:2f:00.3-1/input1
9 [18457.961406] input: Keychron Keychron K3 Pro Mouse as /devices/pci0000:00/0000:00:08.1/0000:2f:00.3/usb3/3-1/3-1:1.2/0003:3434:0230.0017/input/input54
10 [18457.961519] input: Keychron Keychron K3 Pro System Control as /devices/pci0000:00/0000:00:08.1/0000:2f:00.3/usb3/3-1/3-1:1.2/0003:3434:0230.0017/input/input55
11 [18458.011928] input: Keychron Keychron K3 Pro Consumer Control as /devices/pci0000:00/0000:00:08.1/0000:2f:00.3/usb3/3-1/3-1:1.2/0003:3434:0230.0017/input/input56
12 [18458.012004] input: Keychron Keychron K3 Pro Keyboard as /devices/pci0000:00/0000:00:08.1/0000:2f:00.3/usb3/3-1/3-1:1.2/0003:3434:0230.0017/input/input57
13 [18458.044949] hid-generic 0003:3434:0230.0017: input,hidraw2: USB HID v1.11 Mouse [Keychron Keychron K3 Pro] on usb-0000:2f:00.3-1/input2
ls -l /dev/hidraw* Output (shows ineffective udev rules):
1 crw------- 1 root root 243,0 Jan 18 04:19 /dev/hidraw0
2 crw------- 1 root root 243,1 Jan 18 04:19 /dev/hidraw1
3 crw------- 1 root root 243,2 Jan 18 04:19 /dev/hidraw2