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, < [email protected]> wrote: > > > On Mar 7, 2020, at 5:27 AM, Christof Arnosti <[email protected]> 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 < 50000), 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 > [email protected] > http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface >
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
