On Thu Mar 19 11:19:31 2026 +0000, Rémi Bernon wrote:
A struct list would be simpler than an array here IMO. Also I think the local cache as it is implemented might be prone to race conditions, when multiple processes are refreshing the device lists at the same time. The registry should be the primary source and updated from the enumerated devices, and then the local cache updated from the registry when necessary, not the other way around. But maybe we don't even need a cache and we could store the device path in the registry as well? This is a bit tricky, and IMO comes down to how closely we want to match native's behavior.
A `guidInstance` value can represent a different device path in separate processes, it has to do with device enumeration order. Enumeration order is determined by the time of when a process first sees a joystick's device instance ID. I have tests for this in my branch [here](https://gitlab.winehq.org/cmcadams/wine/-/commits/WIP/dinput-instance-guid-v...), under `dinput/tests: Add tests for joystick enumeration order.` This is also why I chose to use an array instead of a list, to make it easier to reorder things after populating the array. Our enumeration code uses setupapi, which enumerates by `VID/PID` pairs, and within `VID/PID` pairs it enumerates based on the device instance ID string in ascending order. I have code in that branch to sort the array based on connection order after populating it. So, the registry only stores `guidInstance` and `DIPROP_JOYSTICKID` values for a particular VID/PID/device index pair, and that VID/PID/device index pair can represent a different device path per-process. Beyond that the device path for a pairing can change depending on if a device is connected/disconnected, which is why I think a local cache is necessary. Does that make sense? The whole thing is kind of a mess, and I may have misunderstood what you're proposing :) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10364#note_132796