**TL;DR: !3714** Sinowealth and Redragon devices. There are a few cases of VID/PID pair conflicts with actual devices having incompatible protocols, and no known way to distinguish them, which leads to a bricking risk. We do have "default-disabled" detectors now that allow those controllers to be listed as supported, yet only actually detected when the user enables them in settings. Yet, this doesn't resolve the cases when multiple controllers could be built for the same VID/PID pair. Here is the list of known models that all share the pair [**258A:0049**]: | Model | Issue link | Compatibility with existing controller | |---|---|---| | Redragon KS82-B | #4106 | Has cfg.ini in issue and nothing else | | Redragon K614 Anivia | #3706 | No data at all | | Redragon K617 Fizz | #2172 | **Works with FL ESPORTS F11 code** | | Redragon K618 | #2886 | Incompatible, bricked by F11 code, no other data | | Redragon k621 | #2679 | Incompatible, bricked by F11 code, no other data | | Redragon K622 Horus | #3333 | No data at all | | Redragon K628 Pro | #4352 | Has captures in issue | | Redragon K632 NOCTIS PRO | #5798 | Has captures in issue | | Redragon K636 Kitava | #5588 | No data at all | | Redragon K642 | #4756 | No data at all | | Redragon K649 Elf | #5613 | No data at all | | Redragon K653 Sion Pro Wired | #5673 | Has captures in issue | | Redragon K668 Trundle | #5929 | Has captures in issue | | **Non-Redragon** | | | | FL ESPORTS F11 | No issue | **WORKS**. Currently listed in detectors and disabled | | Hyrax HCK61 | #5566 | No data at all | | Machenike K500 | #3365 | Has it's own controller that works | | Deltaco Gaming PK95 | #4599 | Has captures in issue | | AULA F3261 | #4385 | Has captures in issue | | tecware phantom+ elite |#3637 | Has captures in issue | | MAD Dog GK850W | #5118 | Has captures in issue | | Maroc4Gaming M68 | #4859 | No data at all | For the pair 258A:0016 | Model | Issue link | State | |---|---|---| | Zuoya X51 | No issue | Working - the code was written for it specifically | | Havit [] | No issue | Compatible with Zuoya - same protocol | | Havit Gamenote KB473L | #3901 | Has captures, more LEDs than Zuoya but probably same protocol | | Redragon K568 | #673 | Unknown but probably same as K568-2 | | Redragon K568-2 Dark Avenger | #1331 | Was working with Zuoya controller | | EvoFox Katana Pro | #4642 / #4643 | No data at all | | Marvo KG965G | #4442 | App suspiciously similar to Redragon's, but no data provided | | Marvo [KG934] Bigbang S1 | #4194 | Has captures | | Millenium MT2 Mini | #3653 | No data | | G-LAB Keyz Rubidium | #3608 | No data | | G-LAB Keyz Rubidium Evolution 2 | #1378 | Works with Zuoya protocol | | Mars Gaming MKREVOPRO | #3140 | Has captures | | T-Dagger BORA | #984 / #1269 | Works with Zuoya protocol but with wrong layout | Extra big thanks to @mguimard for collecting most of this list in one place I may have a better solution. There could be made a sort of "dummy" controller that is shown in the UI when a device with conflict is detected. This "dummy" would have no LEDs to work with, no zones and no modes, but it would have device configuration available in the UI. The configuration window would contain only one combobox that lets the user select what device model it actually is. With a big warning about risks of selecting the wrong one. And when the model is confirmed, and bricking risks are accepted, this "dummy" would then construct the chosen controller in it's place: {width=900 height=545} This whole thing could be built entirely within exsting API and requires no core or UI-side changes (unless we want to express the warning better). {width=840 height=550} This same approach could be used instead of "default-disabled" detectors under some additional conditions. **I would assume that ALL Redragon keyboards in the list (except K617) use a different protocol from all the other brands, and thus could brick if detected improperly. However, bc the official Redragon app does detect the model SOMEHOW, I would assume that it can be probed and the manual selection proxy would be the option for when that fails.** This doesn't call for actually using "RGBController_Dummy", but instead, a sort of "Proxy" controller would need to be written that can manage another controller inside of it and pass all requests down to it transparently, except the ones related to device configuration (and mimic an empty controller when no controller exists, without taking up too much memory). I am currently making a prototype, but wanted to get some opinions/comments before publishing an MR. Another important note: IF the user happens to have more than one device from this list, this won't work. The next time any of these is re-connected, or if a device is connected after another model from this list was once configured, the newly connected one will be (probably) set to the wrong model. I am working on a way to resolve this too.