<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 6, 2020, at 3:23 PM, Christof Arnosti <<a href="mailto:charno@charno.ch" class="">charno@charno.ch</a>> wrote:</div><div class=""><div class=""><blockquote type="cite" cite="mid:0697B819-8F60-4734-91C5-5DF237643C72@hohndel.org" class=""><div class=""><blockquote type="cite" class=""><div class=""><div class=""><p class="">There is a driver with CdcAcmSerialDriver in
usb-serial-for-android!</p><p class="">That's exactly the use case I had in mind when
I proposed driverclass-selection in the UI ;-)</p>
</div>
</div>
</blockquote>
<br class="">
</div>
<div class="">I understand - but Subsurface-mobile would never ever get
access to this if we don't claim the PID/VID correct?</div>
<div class="">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?</div>
<div class="">Maybe I'm just misunderstanding how this is supposed to work.</div>
</blockquote><p class="">If I understand correctly, the device_filter.xml is only
necessary to get the popup which then leads to the download-page.
<br class="">
</p><p class="">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.</p></div></div></blockquote><div><br class=""></div>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).</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div class=""><p class="">If we do the UsbManager-stuff beforehand to populate the
device-list (and then pass the selecte 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.</p></div></div></blockquote><div><br class=""></div>And here you are losing me again :-)</div><div>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.</div><div> <br class=""><blockquote type="cite" class=""><div class=""><div class=""><p class="">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.<br class="">
</p>
</div></div></blockquote><br class=""></div><div>Excellent. Should I wait for further updates from you before merging the current code?</div><div><br class=""></div><div>/D</div><br class=""></body></html>