Limit automatic detection of Braille Displays that use generic USB IDs that might match other devices

[bramd]

Is your feature request related to a problem? Please describe.

This is a follow up of the discussion in #18444 (comment).

There are multiple Braille Displays that use generic USB vendor and product IDs. These displays contain USB serial converters that use the default VID/PID from their manufacturer. This means that other USB serial converters or converters built-in to other non-braille devices can match the auto detection for these displays.

Since we don't know what is connected to these serial devices and how they react to our requests from various Braille Display Drivers, NV Access wants to limit automatic detection of those devices. The discussion has been separated from the PR to keep the scope of the PR small and to discuss it with more users that might be affected and check the NVDA issues, but not read the PRs.

Describe the solution you'd like

I'm not sure which way to go yet. Here are some options offered by me in #18444 (comment)

1. Disable generic IDs in the default configspec
2. Add an option to NVDA's first launch dialog: "Enable automatic detection of Braille Displays (you can always change this later)" with the options:

• Disabled
• Safe, excludes certain USB devices (default)
• Full, might cause problems with other USB serial devices

3. Add a button "Revert to safe defaults" in the braille displays to detect dialog
4. Show a popup if a generic device is connected to USB:

• "It seems you connected a {deviceName} braille display. However, this device is not configured for automatic detection by NVDA since it can cause problems with other devices if we try to detect it automatically. Would you like to use this device as a Braille Display? Please note that you can always change this by checking/unchecking this display in NVDA's Select Braille Display dialog."
• Options: "Yes, this time only", "Yes and detect it automatically in the future", "No, not this time", "No and don't ask again"
• We need to track this state somehow and probably expose it to the user

One or more of these could be implemented.

Describe alternatives you've considered

Keep the situation as is if we have a way to ensure that this doesn't cause problems in practice.

Additional context

Please read the whole discussion in #18444 for more context.

[bramd]

CC @LeonarddeR, @dkager, @FelixGruetzmacher, @michaelDCurran

[LeonarddeR]

See also #15928. This is how we handled this in the past for Albatross displays. It seems the Albatross folks have solved this appropriately. There is no reason to apply automatic detection constraints to displays with generic VID/PID, but with proper description.
Unfortunately, at least the folks at Handy Tech haven't handled this properly, the bus reported description is also generic there.

[seanbudd]

Lets just accept the first one "Disable generic IDs in the default configspec".