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

Christof Arnosti charno at charno.ch
Sat Mar 7 05:27:58 PST 2020


Hi Dirk,

I did the integration of the Icon HD VID/PID pair, so if the testing is
successful I think there is nothing left for me to do before a merge.

Someone just tested with an Mares Nemo Wide (Serial < 50000), and it did
also work.

Just for clarification about the possible UI changes (now that I'm more
awake again), I would envision a workflow like this:
- When opening the divecomputer-screen, or pressing the refresh button
("Neu Scannen" in german), get all UsbDevices by issuing
UsbManager.getDeviceList(). Use these to populate the connection
("Verbindung") list. (Only show the entries with specified driver-class
when this is activated in the settings). I think there has to be done
some work in the bt-discovery part so that these two mechanisms can work
together.
- When a device from the connection list is selected, maybe try to guess
Vendor / Model by data provided in the UsbDevice-Object. There is
already some code in QMLManager::showDownloadPage. I'm not sure how much
there can be done since it seems that a lot of devices use the same
PID/VIDs.
- When the download-button is pressed, the UsbDevice-Object of the
selected connection (and if selected the name of the driver-class)
should be passed to serial_android_usb_open. From there on I can do the
work.

There would probably also have to be done some changes when receiving
the USB_DEVICE_ATTACHED intent so that the correct entry of the list is
preselected.

Best regards
Christof

On 07.03.20 02:11, Dirk Hohndel via subsurface wrote:
>
>
>> On Mar 6, 2020, at 5:03 PM, Christof Arnosti <charno at charno.ch
>> <mailto:charno at charno.ch>> wrote:
>>> 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.
>
> It is indeed.
>
>>>> 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
>> <http://libdivecomputer.org/drivers.html> are be supported! :-D)
>> tomorrow, and that you then merge the code if everything else is fine.
>>
>
> That sounds excellent to me. I can test this and then merge the PR.
>
>> Work on the UI could be done in a separate branch, and I'm happy to
>> help on the driver side.
>>
>
> That was my plan. I'll do the UI / integration work and we'll figure
> out what's needed on the driver side to make this work.
>
> So exciting!
>
> /D
>
>
> _______________________________________________
> 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/84ca486d/attachment.html>


More information about the subsurface mailing list