[Bug] [Linux] Wii U Pro Controller (Bluetooth, hid-wiimote) is detected as a bare Wii Remote: no accelerate, D-pad left acts as A

[YacineAyari]

Before you continue

• I'm on the latest release of WiiCompiled.
• I searched the existing issues and nobody has reported this yet.
• The problem does NOT also happen on Dolphin or a real Wii (if it does, it's a game/mod issue, not a WiiCompiled issue).

WiiCompiled version

v0.2.31 (Linux AppImage) and main @ 149cfef

What kind of bug is it?

Input / controllers

What happens?

A genuine Wii U Pro Controller paired over Bluetooth is unusable in-game on Linux:

• In menus, only D-pad left does anything, and it acts as confirm (A).
• In a race, no button accelerates. The only thing that works is the left face button (Y), which makes the camera look behind.
• The [controller] bindings in Config.toml and the F10 mapping have no effect. Even after setting the Classic Controller Pro preset (a = "east", b = "south", …), nothing changes.

Expected: the pad works like any other gamepad, either through the [controller] bindings or as Kind::WiiUPro.

Possibly related: #207. That report also has a Pro-style controller whose F10 mappings have no effect (the symptom of being routed through KPAD). This report has a specific, Linux-only cause, described below.

Root cause

On Linux, SDL's HIDAPI Wii driver does not claim the pad. By default /dev/hidraw* is root:root 0600, and the kernel hid-wiimote driver is already bound to it. SDL therefore falls back to the evdev device the kernel creates, and that device is named:

Nintendo Wii Remote Pro Controller

SDL's built-in mapping for it is correct and positional (verified with a small SDL3 test program, same SDL 3.4.4 as the build):

0500a9177e0500003003000001000000,Nintendo Wii Remote Pro Controller,a:b0,b:b1,back:b8,dpdown:b14,dpleft:b15,dpright:b16,dpup:b13,guide:b10,leftshoulder:b4,leftstick:b11,lefttrigger:b6,leftx:a0,lefty:a1,rightshoulder:b5,rightstick:b12,righttrigger:b7,rightx:a2,righty:a3,start:b9,x:b3,y:b2,hint:!SDL_GAMECONTROLLER_USE_BUTTON_LABELS:=1,platform:Linux,

Physical A reports east, B reports south, and the D-pad reports dpleft/dpup/…, exactly as the kernel's wiimod_pro_map defines.

The problem is KindForName() in runtime/src/wii_remote_input.cpp:

if (NameContains(name, "Wii U Pro Controller")) return Kind::WiiUPro;
if (!NameContains(name, "Wii Remote")) return Kind::NotWii;
...
return Kind::Remote;

"Nintendo Wii Remote Pro Controller" does not contain "Wii U Pro Controller", but it does contain "Wii Remote". The pad is therefore classified as Kind::Remote and read through KPAD as a sideways Wii Remote, which bypasses the PAD layer and its mappings. The raw Wii Remote buttons are read from joystick buttons starting at SDL_GAMEPAD_BUTTON_MISC1 (15). On this evdev device, raw button 15 is BTN_DPAD_LEFT, so D-pad left becomes Wii Remote "A". Button "2" (sideways accelerate) maps to a raw index the device doesn't have, so nothing accelerates.

This happens whatever wii_remotes is set to, because the classification is purely name-based.

Suggested fix

In KindForName(), treat the kernel's name as a regular gamepad before the "Wii Remote" check:

// Linux hid-wiimote exposes the Wii U Pro Controller as a plain evdev gamepad
// named "Nintendo Wii Remote Pro Controller" (not SDL's HIDAPI Wii driver):
// route it through PAD like any other pad, not through KPAD.
if (NameContains(name, "Wii Remote Pro Controller")) return Kind::NotWii;

It should not return Kind::WiiUPro. That path assumes SDL's HIDAPI Wii driver layout: the raw D-pad fallback on joystick buttons 11-14 in aurora-main/lib/dolphin/pad/pad.cpp and in the F10 "Raw D-pad" readout. On the evdev device, those indices are THUMBL, THUMBR, DPAD_UP and DPAD_DOWN.

Optionally, __PADSetDefaultMapping could default this evdev pad to the Nintendo layout (A = east), so it works out of the box without the preset.

What were you doing? / How to reproduce

1. On Linux, pair a Wii U Pro Controller over Bluetooth (the kernel hid_wiimote module loads automatically).
2. Leave /dev/hidraw* permissions at the default (not user-accessible).
3. Launch WiiCompiled, then try to navigate the menus or accelerate in a race.

Workaround

Put SDL's own mapping, under a name that contains neither Wii Remote nor Wii U Pro Controller, into ~/.local/share/WiiCompiled/gamecontrollerdb.txt (loaded by controller_mapping_wizard::LoadPersistedMappings()):

0500a9177e0500003003000001000000,Nintendo Wii U Pro (Linux),a:b0,b:b1,back:b8,dpdown:b14,dpleft:b15,dpright:b16,dpup:b13,guide:b10,leftshoulder:b4,leftstick:b11,lefttrigger:b6,leftx:a0,lefty:a1,rightshoulder:b5,rightstick:b12,righttrigger:b7,rightx:a2,righty:a3,start:b9,x:b3,y:b2,platform:Linux,

Then set the Classic Controller Pro preset in F10. After that the pad works fully: menus, accelerate, brake, drift, items and tricks.

Screenshot / video

No response

Logs

Relevant lines (SDL input log, `wii_remotes = true` run):

[sdl] Added HIDAPI device 'Nintendo RVL-CNT-01-UC' VID 0x057e, PID 0x0330, bluetooth 1, ... path = /dev/hidraw5, driver = NONE (DISABLED)

`/proc/bus/input/devices`:

I: Bus=0005 Vendor=057e Product=0330 Version=0001
N: Name="Nintendo Wii Remote Pro Controller"
H: Handlers=event15 js0

GPU + driver version

Intel Arc (Meteor Lake iGPU), Mesa Vulkan

Windows version

N/A - Linux: Ubuntu 26.04, kernel 7.0.0-31-generic