<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">Am 07.03.20 um 00:30 schrieb Dirk
Hohndel via subsurface:<br>
</div>
<blockquote type="cite"
cite="mid:80969050-52D2-4D92-B0B2-C6B7D7001360@hohndel.org">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<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=""
moz-do-not-send="true">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>
</blockquote>
Perfect!<br>
<blockquote type="cite"
cite="mid:80969050-52D2-4D92-B0B2-C6B7D7001360@hohndel.org">
<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 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.</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>
</blockquote>
Yes, that's exactly what I tried to suggest. Thanks for putting it
in understandable words, it's getting late here.<br>
<blockquote type="cite"
cite="mid:80969050-52D2-4D92-B0B2-C6B7D7001360@hohndel.org">
<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>
</blockquote>
<p>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. <br>
</p>
<p>Work on the UI could be done in a separate branch, and I'm happy
to help on the driver side.<br>
</p>
<blockquote type="cite"
cite="mid:80969050-52D2-4D92-B0B2-C6B7D7001360@hohndel.org">
<div><br class="">
</div>
<div>/D</div>
</blockquote>
Best regards<br>
Christof<br>
<blockquote type="cite"
cite="mid:80969050-52D2-4D92-B0B2-C6B7D7001360@hohndel.org"><br
class="">
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
subsurface mailing list
<a class="moz-txt-link-abbreviated" href="mailto:subsurface@subsurface-divelog.org">subsurface@subsurface-divelog.org</a>
<a class="moz-txt-link-freetext" href="http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface">http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface</a>
</pre>
</blockquote>
</body>
</html>