Describe the bug
I'm pretty fresh to this sort of stuff so I used Claude to try to troubleshoot this, so feel free to let me know if there's anything missing or extra needed.
The driver crashes immediately on every startup attempt under a Wayland session, with:
AttributeError: 'NoneType' object has no attribute 'encode'
X11 sessions are not affected (per the driver's own logic, which has a separate, working code path for X11 modifier detection).
Steps to reproduce
- Install the driver on a Wayland (GNOME) session, layout
proartp16.
- Start the driver manually or via the systemd service:
/usr/share/asus-dialpad-driver/.env/bin/python3 /usr/share/asus-dialpad-driver/dialpad.py proartp16 /usr/share/asus-dialpad-driver
- Driver connects to Wayland, detects keyboard/touchpad, initializes virtual device successfully — then crashes as soon as it tries to load the keymap.
Full traceback
Traceback (most recent call last):
File ".../pywayland/dispatcher.py", line 46, in dispatcher_func
ret = func(self, *args)
File ".../dialpad.py", line 2176, in wl_keyboard_keymap_handler
wl_load_keymap_state()
File ".../dialpad.py", line 1846, in wl_load_keymap_state
load_evdev_key_for_wayland(char, keyboard_state)
File ".../dialpad.py", line 1782, in load_evdev_key_for_wayland
keysym = xkb.keysym_from_name(char)
File ".../xkbcommon/xkb.py", line 160, in keysym_from_name
return lib.xkb_keysym_from_name(name.encode('ascii'), flags)
AttributeError: 'NoneType' object has no attribute 'encode'
Root cause (as far as diagnosed)
set_defaults_keysym_name_associated_to_evdev_key_reflecting_current_layout() builds its default key table by calling mod_name_to_specific_keysym_name('Shift'), ('Control'), and ('Alt') as dictionary keys.
Under Wayland, mod_name_to_specific_keysym_name() determines a modifier's keysym name by scanning keyboard_state for which modifier is currently active/pressed at that exact instant. Since this runs once at startup — before the user has necessarily pressed any modifier key — the function's Wayland branch falls through all its loops without a match and implicitly returns None.
That None is then used as a dict key in the defaults table. Later, when the driver iterates that table and calls load_evdev_key_for_wayland(char, keyboard_state) for each entry, char is None for the affected modifier(s), and xkb.keysym_from_name(None) fails since None has no .encode() method.
The X11 equivalent (load_evdev_key_for_x11) does not have this issue, since it resolves keysyms via Xlib.XK.string_to_keysym() against a static keysym name rather than depending on live modifier press-state at startup.
Suggested fix direction
mod_name_to_specific_keysym_name()'s Wayland branch should fall back to the same static mod_to_specific_keysym_name dict it already defines (used in the X11/no-display branches) when no modifier is currently pressed, rather than implicitly returning None. This static fallback appears to already exist in the function for other cases — it just isn't reached in the Wayland branch when the scan finds no active modifier.
Impact
Any Wayland session hits this on every startup — not specific to this laptop model or layout. Confirmed working around it by using an X11 session instead, but this means DialPad (and likely NumberPad, if it shares this modifier-detection code) is currently unusable on Wayland entirely.
Expected behavior
The driver starts cleanly under a Wayland (GNOME) session without crashing, connects to the keyboard/touchpad, and DialPad becomes usable — touching the top-right touchpad corner brings up the dial, and rotation/center-tap gestures trigger the configured shortcuts, matching the behavior already confirmed working under X11 on the same hardware/layout.
Relevant log output
Desktop
- Laptop: ASUS ProArt PX13, GoPro Edition (HN7306EAC)
- OS: Zorin OS 18.1 (Ubuntu 24.04 base)
- Kernel: 7.0.0-28-generic
- Session: Wayland (GNOME)
- Driver version: v2.3.0, layout
proartp16
Describe the bug
I'm pretty fresh to this sort of stuff so I used Claude to try to troubleshoot this, so feel free to let me know if there's anything missing or extra needed.
The driver crashes immediately on every startup attempt under a Wayland session, with:
X11 sessions are not affected (per the driver's own logic, which has a separate, working code path for X11 modifier detection).
Steps to reproduce
proartp16.Full traceback
Root cause (as far as diagnosed)
set_defaults_keysym_name_associated_to_evdev_key_reflecting_current_layout()builds its default key table by callingmod_name_to_specific_keysym_name('Shift'),('Control'), and('Alt')as dictionary keys.Under Wayland,
mod_name_to_specific_keysym_name()determines a modifier's keysym name by scanningkeyboard_statefor which modifier is currently active/pressed at that exact instant. Since this runs once at startup — before the user has necessarily pressed any modifier key — the function's Wayland branch falls through all its loops without a match and implicitly returnsNone.That
Noneis then used as a dict key in the defaults table. Later, when the driver iterates that table and callsload_evdev_key_for_wayland(char, keyboard_state)for each entry,charisNonefor the affected modifier(s), andxkb.keysym_from_name(None)fails sinceNonehas no.encode()method.The X11 equivalent (
load_evdev_key_for_x11) does not have this issue, since it resolves keysyms viaXlib.XK.string_to_keysym()against a static keysym name rather than depending on live modifier press-state at startup.Suggested fix direction
mod_name_to_specific_keysym_name()'s Wayland branch should fall back to the same staticmod_to_specific_keysym_namedict it already defines (used in the X11/no-display branches) when no modifier is currently pressed, rather than implicitly returningNone. This static fallback appears to already exist in the function for other cases — it just isn't reached in the Wayland branch when the scan finds no active modifier.Impact
Any Wayland session hits this on every startup — not specific to this laptop model or layout. Confirmed working around it by using an X11 session instead, but this means DialPad (and likely NumberPad, if it shares this modifier-detection code) is currently unusable on Wayland entirely.
Expected behavior
The driver starts cleanly under a Wayland (GNOME) session without crashing, connects to the keyboard/touchpad, and DialPad becomes usable — touching the top-right touchpad corner brings up the dial, and rotation/center-tap gestures trigger the configured shortcuts, matching the behavior already confirmed working under X11 on the same hardware/layout.
Relevant log output
Desktop
proartp16