Subsurface Mobile: Adding mares USB (cp210x) support; how to proceed

[Christof Arnosti]

Am 07.03.20 um 00:30 schrieb Dirk Hohndel via subsurface:
>
>> On Mar 6, 2020, at 3:23 PM, Christof Arnosti <charno at charno.ch
>> <mailto:charno at charno.ch>> wrote:
>>>>
>>>> There is a driver with CdcAcmSerialDriver in usb-serial-for-android!
>>>>
>>>> That's exactly the use case I had in mind when I proposed
>>>> driverclass-selection in the UI ;-)
>>>>
>>>
>>> I understand - but Subsurface-mobile would never ever get access to
>>> this if we don't claim the PID/VID correct?
>>> That's been my point here... even if you add that driverclass... how
>>> would Subsurface-mobile get access to that device in the first place?
>>> Maybe I'm just misunderstanding how this is supposed to work.
>>
>> If I understand correctly, the device_filter.xml is only necessary to
>> get the popup which then leads to the download-page.
>>
>> In the Java code, all devices known to UsbManager are compared by
>> PID/VID by UsbSerialProber (from usb-serial-for-android). When
>> there's a match there is a check if we have permission to use this
>> device, and if not the permission is requested. Then the device is used.
>>
>
> Ahh, that's the part that I didn't realize. I thought you never get to
> see devices that you haven't registered. In that case, yes, indeed
> your idea to have those generic diver-classes available does make
> sense. I'd still hide them in general as this should be the exception
> (and I'd add some feature that makes it easy for people to send us
> email with the necessary information so we can add the VID/PID for them).
Perfect!
>
>> If we do the UsbManager-stuff beforehand to populate the device-list
>> (and then pass the selected usb device to Java android_serial_open)
>> we don't need the UsbSerialProber to check the attached device, but
>> only to find the correct driver class. If the driver class is also
>> passed to android_serial_open we can leave out the whole
>> UsbSerialProber-Stuff and directly instantiate the driver class with
>> the passed usb device. With all this it's still possible to check and
>> request for permission to access the device at runtime.
>>
>
> And here you are losing me again :-)
> Are you suggesting that we could walk through the list of devices and
> try to populate the dropdowns on the download page accordingly? That
> sounds like a great idea.
Yes, that's exactly what I tried to suggest. Thanks for putting it in
understandable words, it's getting late here.
>  
>>
>> I didn't consciously check for devices not entered in the
>> device_filter.xml, but I entered "my" PID/VID pair quite late in the
>> development cycle. I also have seen and used the "ask permission"
>> popup which happens when a device not in device_filter.xml is used. I
>> will test this tomorrow by removing "my" entry from the
>> device_filter.xml.
>>
>
> Excellent. Should I wait for further updates from you before merging
> the current code?

Hmm... I'd propose that I add the CdcAcm-driver for the Icon HD VID/PID
(if this works then all the PID/VIDs from
libdivecomputer.org/drivers.html are be supported! :-D) tomorrow, and
that you then merge the code if everything else is fine.

Work on the UI could be done in a separate branch, and I'm happy to help
on the driver side.

>
> /D
Best regards
Christof
>
>
> _______________________________________________
> subsurface mailing list
> subsurface at subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20200307/272fb002/attachment.html>