Thanks a lot for the contribution!

I'm not sure prepending the id in productName can reliably solve the issue you described. The id is not a stable value—it depends on the order in which devices are connected or discovered—so it’s not suitable for serialization into persistent storage like the configuration file.

When I originally designed this, I considered using serialNumber to distinguish identical devices. While not all devices have it (for example, my Logitech USB receiver), in my experience, devices connected via Bluetooth usually do provide a serial number.

Also, this change introduces a breaking change: since the productName would change, existing configuration schemes would stop working unless users manually update their configuration.

I'm not sure prepending the id in productName can reliably solve the issue you described. The id is not a stable value—it depends on the order in which devices are connected or discovered—so it’s not suitable for serialization into persistent storage like the configuration file.

Yeah, I was just doing some testing and noticed that and made a change (force pushed) to basically just add the #1 or #2 at the end IF there are duplicates...

Also, this change introduces a breaking change: since the productName would change, existing configuration schemes would stop working unless users manually update their configuration.

Well, what I just changed would now only break configurations IF people had multiple identical devices-- which might be unlikely?

Thanks for your quick response.

I'm still not convinced duplicateIdentifier is stable. It relies on device connection order, which can lead to issues like reconnected devices being assigned new, duplicate identifiers (e.g., reconnected #1 becoming #2). This means configurations could be randomly applied after restarts, which isn't ideal.

I agree that it makes sense to distinguish between devices with the same product name in the UI. However, our first step should probably be figuring out how to get a stable serial number / identifier for them. If you can shed some light on why the device isn't acquiring a serial number, we might be able to offer more targeted solutions.

I'm still not convinced duplicateIdentifier is stable. It relies on device connection order, which can lead to issues like reconnected devices being assigned new, duplicate identifiers (e.g., reconnected #1 becoming #2). This means configurations could be randomly applied after restarts, which isn't ideal.

Yeah, that's something I did not consider...

I agree that it makes sense to distinguish between devices with the same product name in the UI. However, our first step should probably be figuring out how to get a stable serial number / identifier for them. If you can shed some light on why the device isn't acquiring a serial number, we might be able to offer more targeted solutions.

Unfortunately, it looks like the CST Laser Trackball devices don't have serial numbers:

How about the commit I just pushed up now? I added 'locationID' to devices and made the DeviceMatcher fallback to locationID if serialNumber is nil.. What do you think of that approach?

and also just changed the UI's duplicate handling of CST Trackball #1 to CST Trackball [serial or location] since that numbering was unreliable.

Adding locationId matching sounds promising! I'll test this change when I have time, and thank you again for your contribution.

However, the logic around implementing locationId matching will be quite complex. This is mainly because:

• If we unconditionally add locationId matching: Every time users plug a device into a different USB port, the system would recognize it as a "new" device. This would force them to reconfigure all their devices, significantly impacting the user experience.
• If we determine whether to add locationId matching based on duplicate devices: While this approach sounds more reasonable, it could complicate future adjustments to existing configuration schemes or require us to re-evaluate how current configurations are applied.

Ideally, we'll need a more comprehensive scheme management user interface to effectively handle these scenarios.

I also noticed #906. This locationId approach might not fully address all the use cases there, especially when devices are connected via the same port (meaning their locationId is identical). In such scenarios, it would still be impossible to distinguish between them. A more robust, though labor-intensive, solution would be to adapt to each manufacturer's private protocol—like hidpp—to obtain individual device serial numbers.

This PR is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 10 days.