Am 07.03.20 um 00:30 schrieb Dirk Hohndel via subsurface: > >> On Mar 6, 2020, at 3:23 PM, Christof Arnosti <cha...@charno.ch >> <mailto:cha...@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@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