Will this affect all USB computers with Android? Very exciting!! I had a
look but made no progress (C++ is not something I've worked with so it
would have been a miracle if I had made progress :D )
I've got a Cressi Leonardo and a Suunto Zoop, and an Android 9 phone if you
want me to test those out with any changes. Let me know the branch and I
can build it and test it out
Cheers!
On Sun, 8 Mar 2020, 3:14 am Dirk Hohndel via subsurface, <
subsurface@subsurface-divelog.org> wrote:
>
>
> On Mar 7, 2020, at 5:27 AM, Christof Arnosti wrote:
>
> 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.
>
>
> I will play with this in a couple of hours and most likely merge your
> changes.
>
> Someone just tested with an Mares Nemo Wide (Serial < 5), and it did
> also work.
>
>
> Excellent.
>
> 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.
>
>
> I'm not sure what you mean by only showing the entries with a specified
> driver class. I thought the driver class is something that you would select
> in that Connection drop down as an alternative to the found devices.
> My guess is that on the vast, vast majority of Android devices you will
> only ever get one USB device. Maybe if someone uses a hub for some reason
> (maybe to power the phone while reading dives?) one might see more, but in
> general that would surprise me.
> So we should optimize the user experience for the common case. Which means
> to try and identify the one USB serial device that is connected.
>
> - 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.
>
>
> Correct - I played with that back when working on the Intent code and
> while there are a couple you can explicitly identify, for most that is not
> possible
>
> - 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.
>
>
> So again, you are suggesting to have a second (or actually, fourth?) drop
> down with a driver class?
>
> 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.
>
>
> I believe so.
>
> /D
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
