Reassign Microchip pid:vid 04d8:000a from FTDI -> CDC

[TheSven73]

According to the Linux kernel tree [1], Microchip pid:vid 04d8:000a is generally a CDC ACM device, implemented by a demo firmware application.

However, some vendors have re-used this vid:pid for other types of firmware, emulating FTDI chips. The Linux kernel attempts to detect such cases by matching on interface class/subclass/proto. If these are ff/ff/00 it uses FTDI, otherwise CDC.

Given that current library code cannot do such matching, we should re-assign the pid:vid to CDC, as this is correct in the majority of cases.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f08dea734844aa42ec57c229b0b73b3d7d21f810

Signed-off-by: Sven Van Asbroeck TheSven73@gmail.com

[felHR85]

Thanks @TheSven73 !! Maybe it is possible to implement the same solution using the Android USB api

[TheSven73]

Yes that's a great idea :)

The easiest way is to keep a list of matcher objects. When looking for a match, we just loop through them and call virtual match(UsbDevice dev) on each object. If that's not fast enough, we could use a HashMap, but we should probably check the speed first, before embarking on an optimization.

PS How do you feel about using Kotlin for this particular class? It's Google's preferred Android language now. Much more expressive. And library users would not even notice.

[felHR85]

@TheSven73 Feel free to implement it if you want to. The Hashmap way looks nicer to me. I am using java because of inertia but I welcome contributions in Kotlin.

[TheSven73]

When I look at the ftdi Linux device list, I see quite a few special cases. A special case is anything not of the form:

{ USB_DEVICE(XXX_VID, XXX_PID) },

If you would like this library to have the same matching behaviour as Linux, then perhaps it would be best to look for a solution which will mimic the Linux matcher in general.

But that can be left to later, and we can apply this minimally invasive pull request first. Except if you are worried that some of your users are actually using the FTDI version of this pid:vid, and this particular pull request will break the library for them?

[felHR85]

@TheSven73 In the long term We will have to mimic that behavior but now I guess that's enough. I am not aware of any user using that version of pid/vid

[TheSven73]

@felHR85 I'll make something minimally invasive that mimics the kernel behaviour, only in case of the problematic Microchip pid:vid. Does that sound like a good compromise? If so, expect it early next week.

[felHR85]

@TheSven73 Perfectly fine by me :)