Device gets re-detected but with fewer axes

[code-monet]

I have a wheel that, as far as I can tell, is only misbehaving with Joystick Gremlin. The device starts off being detected as:

[2025-11-02 16:28:15.651] [debug] [info] {91A5C840-6C71-11EF-8002-444553540000}: Processing device: VelocityOne Race
[2025-11-02 16:28:15.658] [debug] [info] Device summary: VelocityOne Race {91A5C840-6C71-11EF-8002-444553540000}
[2025-11-02 16:28:15.658] [debug] [info] Axis=7 Buttons=124 Hats=2
[2025-11-02 16:28:15.658] [debug] [info] Axis map
[2025-11-02 16:28:15.658] [debug] [info]   linear=1 id=1
[2025-11-02 16:28:15.658] [debug] [info]   linear=2 id=2
[2025-11-02 16:28:15.658] [debug] [info]   linear=3 id=3
[2025-11-02 16:28:15.658] [debug] [info]   linear=4 id=4
[2025-11-02 16:28:15.658] [debug] [info]   linear=5 id=5
[2025-11-02 16:28:15.658] [debug] [info]   linear=6 id=6
[2025-11-02 16:28:15.658] [debug] [info]   linear=7 id=7
[2025-11-02 16:28:15.658] [debug] [info]   linear=0 id=0

But at some point this happens:

[2025-11-02 17:00:42.124] [debug] [info] {91A5C840-6C71-11EF-8002-444553540000}: Processing device: VelocityOne Race
[2025-11-02 17:00:42.137] [debug] [warning] VelocityOne Race {91A5C840-6C71-11EF-8002-444553540000}: Overriding reported number of axes,  capabilities=7 enumerated=3
[2025-11-02 17:00:42.137] [debug] [info] Device summary: VelocityOne Race {91A5C840-6C71-11EF-8002-444553540000}
[2025-11-02 17:00:42.137] [debug] [info] Axis=3 Buttons=124 Hats=2
[2025-11-02 17:00:42.137] [debug] [info] Axis map
[2025-11-02 17:00:42.137] [debug] [info]   linear=1 id=1
[2025-11-02 17:00:42.137] [debug] [info]   linear=2 id=2
[2025-11-02 17:00:42.137] [debug] [info]   linear=3 id=6
[2025-11-02 17:00:42.137] [debug] [info]   linear=0 id=0
[2025-11-02 17:00:42.137] [debug] [info]   linear=0 id=0
[2025-11-02 17:00:42.137] [debug] [info]   linear=0 id=0
[2025-11-02 17:00:42.137] [debug] [info]   linear=0 id=0
[2025-11-02 17:00:42.137] [debug] [info]   linear=0 id=0

(there are other lines in between but probably not relevant). At this point, the "USB Game Controllers" control panel app still shows all the axes responding, as does the device manufacturer's own PC app.

Have you seen or heard of something like this before? On my end I'll try adding some debug lines to Dill and see what's going on.

[code-monet]

I have confirmed that this bit of code is causing the problem:

        else
        {
            // Some other invalid axis count information returned, simply trust the
            // axis enumeration
            info.axis_count = axis_indices.size();
            for(size_t i=0; i<axis_indices.size(); ++i)
            {
                info.axis_map[i].linear_index = i+1;
                info.axis_map[i].axis_index = axis_indices[i];
            }
            logger->warn(
                "{} {}: Overriding reported number of axes,  capabilities={} enumerated={}",
                info.name,
                guid_to_string(info.device_guid),
                capabilities.dwAxes,
                axis_indices.size()
            );
        }

The heuristic of checking that the axis has a non-zero value to determine if it's "in use" doesn't seem to be documented anywhere and isn't working for my device. After disabling this else case, I have not had any issues. If you can recall why this was added, I can look into fixing this part of the code. My guess is that you don't want to show axes that don't appear to be in use?

[WhiteMagic]

The problem is that in case there is a disagreement on the number of axes, it's impossible to build the axis map as that information is not there. That means for less than 8 axes the code would have to guess what order they are in. Maybe it could be changed to be sequential in that case. Is that the layout of the device you see this happening with? In any case I strongly suspect that a device reporting these two out of sync is a fault with how the device reports it's information even it's happy to work.

[code-monet]

That means for less than 8 axes the code would have to guess what order they are in

This is true (but not actually the problem here); it seems in general it's easier to assume an axis/button/hat doesn't exist until it shows a change. This approach might be quite disruptive to Gremlin's design philosophy, though.

---

The issue here happens when you do know the number of axes but the cited code block decides they don't exist. You are getting axes count from two sources:

1. As reported by DirectInput.
2. As detected by your heuristic - whether the very first reading from the device for that axis is nonzero.

I couldn't find any reference online for heuristic 2, and disabling it allows my device to work just fine with Dill.

[WhiteMagic]

Ah yeah that form is awkward though it's only partially about the number of axes. The issue comes from there not being a nicer way that I know of, to get the actual axis map information. Technically it could be built over time, but the only way to notify for that would be to claim a device disconnect and reconnect. I can't say why the check doesn't seem to work on some devices, as it doesn't really seem to have to do with what's available as it works just fine with devices that get newly detected for which neither dill nor the OS would have state.

I'm not sure which of the parts of the code you disable, but no matter which else loop is retained dill will be in an awkward state as the number of axes will not be in sync with the number of non-zero entries in the axis map. Which depending how Gremlin uses the information could lead to really quirky results.

The logic could be improved a bit to at least keep things in sync (if unsafe due to not knowing about gaps).

[code-monet]

I can't say why the check doesn't seem to work on some devices

The heuristic I linked assumes that a zero reading for an axis implies it doesn't exist. Experimentally it seems to work on the very first reading after connecting to a device, but subsequent readings give the actual axis value, which can legitimately be zero.

I only see this issue with sprung axes that rest at one end of their travel range - pedals and paddles on racing wheels but not the steering wheel itself, for example.