<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body>
<p>Hi Dirk,</p>
<p>Thanks for your answer.<br>
</p>
<div class="moz-cite-prefix">On 06.03.20 17:06, Dirk Hohndel wrote:<br>
</div>
<blockquote type="cite"
cite="mid:844AE633-8A07-4B78-B678-9A988AF54D84@hohndel.org">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
Christof,
<div class=""><br class="">
</div>
<div class="">I'm excited to see the progress!</div>
<div class="">Unfortunately my 'main' computer is currently being
repaired which makes it harder for me to create Android beta
builds, but it should be possible to do the testing with builds
from the CI system.<br class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On Mar 6, 2020, at 6:19 AM, Christof Arnosti
<<a href="mailto:charno@charno.ch" class=""
moz-do-not-send="true">charno@charno.ch</a>> wrote:</div>
<div class="">
<div class=""><br class="">
<p class="">So I just added the missing PID / VID and
prepared a pull request at <a
class="moz-txt-link-freetext"
href="https://github.com/Subsurface-divelog/subsurface/pull/2647"
moz-do-not-send="true">https://github.com/Subsurface-divelog/subsurface/pull/2647</a>,
in the hope that some more people see the changes and
maybe install the CI-generated android package so that
we can more easily get feedback from people owning
other computers.</p>
</div>
</div>
</blockquote>
<div><br class="">
</div>
I will definitely look at that later this afternoon (Pacific
Time). I will comment / send questions about the pull request
on GitHub.</div>
</div>
</blockquote>
I'm looking forward! :)<br>
<blockquote type="cite"
cite="mid:844AE633-8A07-4B78-B678-9A988AF54D84@hohndel.org">
<div class="">
<div>
<blockquote type="cite" class="">
<div class="">
<div class="">
<blockquote type="cite"
cite="mid:7e979a6f-9a54-c942-692b-8fa7a07976cb@charno.ch"
class="">
<blockquote type="cite"
cite="mid:20200306074321.GD47181@hirohito.acc.umu.se"
class="">
<blockquote type="cite" class="">
<pre class="moz-quote-pre" wrap="">Problems:
- usb read timeout is not working due to an android Bug
(<a class="moz-txt-link-freetext" href="https://stackoverflow.com/questions/9108548/android-usb-host-bulktransfer-is-losing-data" moz-do-not-send="true">https://stackoverflow.com/questions/9108548/android-usb-host-bulktransfer-is-losing-data</a>).
Currently I start all read-requests without timeout. For Android API
level 26 (Oreo 8.0), the used awaitRequest()-Method has an added
</pre>
</blockquote>
<blockquote type="cite" class="">
<pre class="moz-quote-pre" wrap="">timeout-parameter which could be used.
- Not all dc_custom functionality is implemented. Notably so
get_available (which seems to be used only optionally) and set_break
(used by cochran_commander.c and reefnet_sensuspro.c).
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">No worries, just leave them for now. We can always implement them
later.</pre>
</blockquote>
The problem is less doing the implementation but more
missing support in usb-serial-for-android. So to
implement the features we would have to change (and
possibly upstream) usb-serial-for-android. The
maintainer seems to be quite active.<br class="">
</blockquote>
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div><br class="">
</div>
<div>Many of the projects in this space have been very
supportive of changes submitted for our use case, so I'd
definitely try to go that route.</div>
</div>
</div>
</blockquote>
I will have a look at it.<br class="">
<blockquote type="cite"
cite="mid:844AE633-8A07-4B78-B678-9A988AF54D84@hohndel.org">
<div class="">
<div>
<blockquote type="cite" class="">
<div class="">
<div class="">
<blockquote type="cite"
cite="mid:7e979a6f-9a54-c942-692b-8fa7a07976cb@charno.ch"
class="">
<blockquote type="cite"
cite="mid:20200306074321.GD47181@hirohito.acc.umu.se"
class="">
<blockquote type="cite" class="">
<pre class="moz-quote-pre" wrap="">TODO:
- Add known PID/VID pairs at
<a class="moz-txt-link-freetext" href="https://github.com/charno/subsurface/blob/android-serial-clean/android-mobile/src/org/subsurfacedivelog/mobile/AndroidSerial.java#L94" moz-do-not-send="true">https://github.com/charno/subsurface/blob/android-serial-clean/android-mobile/src/org/subsurfacedivelog/mobile/AndroidSerial.java#L94</a>.
For this the default probe table has to be modified, which seems quite
straight-forward. Do you somewhere have a list of PID / VID / Used
Chipset-thruples?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">I think our current scheme where we "open" a virtual device, "ftdi" or
in your code "usb-serial-for-android" is a bad way of doing it. I think
its better if we where to present the list of detected usb devices to
the user, and let the user pick which usb device to connect against.
The crazy hunting for vid/pid's in serial_ftdi_open_device is just
begging for trouble in my mind.
I think open should take a usb bus/device and just use it. It also
solves any issues where a crazy user plugins in multiple devices at once
and then downloads data off one or more of them.
That said, the PID/VID lists are in:
<a class="moz-txt-link-freetext" href="https://github.com/Subsurface-divelog/subsurface/blob/master/core/serial_ftdi.c#L153" moz-do-not-send="true">https://github.com/Subsurface-divelog/subsurface/blob/master/core/serial_ftdi.c#L153</a>
<a class="moz-txt-link-freetext" href="https://github.com/Subsurface-divelog/subsurface/blob/master/android-mobile/res/xml/device_filter.xml" moz-do-not-send="true">https://github.com/Subsurface-divelog/subsurface/blob/master/android-mobile/res/xml/device_filter.xml</a>
Some are documented on <a class="moz-txt-link-freetext" href="https://www.libdivecomputer.org/drivers.html" moz-do-not-send="true">https://www.libdivecomputer.org/drivers.html</a> to.
Jef might know if there are more vid/pid's to care about, or if that
list is up to date.</pre>
</blockquote>
<p class="">This sounds like a good idea. I don't know
Qt / qml at all, so that's possibly work for another
person.</p>
<p class="">What I think would be a nice way would be
to provide a list similar to this:<br class="">
- <UsbDeviceName> usb-serial-for-android
(autodetect driver)<br class="">
- <UsbDeviceName> usb-serial-for-android (<span
class="pl-smi">Cp21xx)<br class="">
</span>- <UsbDeviceName>
usb-serial-for-android (Ftdi<span class="pl-smi">)<br
class="">
</span>- <UsbDeviceName>
usb-serial-for-android (Prolific<span class="pl-smi">)<br
class="">
</span>- <UsbDeviceName>
usb-serial-for-android (Ch34x<span class="pl-smi">)<br
class="">
</span>- <UsbDeviceName>
usb-serial-for-android (CdcAcm<span class="pl-smi">)<br
class="">
</span>- <UsbDeviceName> libftdi (deprecated)</p>
</blockquote>
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>That's a lot and might make things harder on small
screens.</div>
<div>Also, under which circumstances do you think that the
deprecated libftdi solution would be preferable? Wouldn't we
just want to remove that?</div>
<div>One thing that I implemented a while ago was the intent
handling that opened Subsurface-mobile when a serial device
was plugged in; again, which situation would require the
user to specifically select the chipset?</div>
<div>I'm just trying to understand how this would be used (and
how we would document things).</div>
</div>
</div>
</blockquote>
<p>If we have a complete list of PID/VIDs, we don't need the
chipset-selection. The chipset selection would be nice to have for
computers which aren't yet in the PID/VID list. <br>
</p>
<p>The libftdi implementation is superior in the way that it
supports break, so for cochran_commander.c and reefnet_sensuspro.c
computers it's currently the only option. But if we get
break-support in usb-serial-for-android, that's probably really
obsolete.</p>
<blockquote type="cite"
cite="mid:844AE633-8A07-4B78-B678-9A988AF54D84@hohndel.org">
<div class="">
<div>
<blockquote type="cite" class="">
<div class="">
<div class="">
<blockquote type="cite"
cite="mid:7e979a6f-9a54-c942-692b-8fa7a07976cb@charno.ch"
class="">
<p class="">With this options, basically all
divecomputers with supported usb-to-serial
interfaces could be opened. If it's a known VID/PID
pair, the (default) autodetect connection could be
used, and otherwise a specific driver could be
chosen.<br class="">
</p>
</blockquote>
</div>
</div>
</blockquote>
<div><br class="">
</div>
Given that the universe of dive computers that libdivecomputer
supports is really rather small, my guess is that we should be
able to assemble a fairly complete list of VID/PIDs, but I'll
need to read the code to make sure I understand how that
manual selection would work, I guess :-)</div>
<div><br class="">
<blockquote type="cite" class="">
<div class="">
<div class="">
<blockquote type="cite"
cite="mid:7e979a6f-9a54-c942-692b-8fa7a07976cb@charno.ch"
class="">
<p class=""> </p>
<p class="">The open call could then be easily adopted
with the information, either by parsing the string
(ugly, and possibly creates problems when multiple
devices of the same type are connected), or by
directly passing an (android) UsbDevice-Object and
the driver-classname to the serial_usb_android_open
function.</p>
</blockquote>
</div>
</div>
</blockquote>
<div><br class="">
</div>
Since we should have the UsbDevice object through the intent,
that seems like it should work, no? Or am I missing something
(it's been a while that I tried (and failed) to work on that.</div>
</div>
</blockquote>
<p>I usually work in the way that I manually open the subsurface
divecomputer screen and then select the computer from there. So I
don't get an intent at all. But of course it would be possible to
query UsbManager from there to get a list of UsbDevice-Objects
(which we then can use to fill the connectionlistmodel). Currently
the connectionlistmodel only contains strings, and I didn't have a
look into how it works exactly, so I don't have a good answer
here.</p>
<p>If we have a complete list of PID/VID, we would only have to pass
the UsbDevice-Object to the serial_android_usb_open call. I'll
have a look into it.<br>
</p>
<blockquote type="cite"
cite="mid:844AE633-8A07-4B78-B678-9A988AF54D84@hohndel.org">
<div class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">
<div class="">
<blockquote type="cite"
cite="mid:7e979a6f-9a54-c942-692b-8fa7a07976cb@charno.ch"
class="">
<blockquote type="cite"
cite="mid:20200306074321.GD47181@hirohito.acc.umu.se"
class="">
<blockquote type="cite" class="">
<pre class="moz-quote-pre" wrap="">- remove serial_ftdi? -> there are at least the cochran_commander.c and
reefnet_sensuspro.c computers which won't work with
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">Just leave it for now. We can always kill it off later when/if we no
longer find it useful. We currently use it on more platforms than just
android, and its issues are android specific so it might still be
usefull.</pre>
</blockquote>
Ah, I didn't know that it's used on different
platforms.<br class="">
</blockquote>
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>Yes, it's available on our desktop platforms as well as
it sometimes helps to make it easier to connect to
divecomputers</div>
<div><br class="">
</div>
<blockquote type="cite" class="">
<div class="">
<div class="">
<blockquote type="cite"
cite="mid:7e979a6f-9a54-c942-692b-8fa7a07976cb@charno.ch"
class="">
<p class="">Thanks again for all the feedback. If
testing with other divecomputers (preferably also
with other serial chipsets) goes well, is there
anything missing before this can be merged? Should I
open a pull request already?</p>
</blockquote>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
<div class="">Thanks for opening the pull request. I'll comment
there and we can figure out next steps once a few people had a
chance to test.</div>
<div class=""><br class="">
</div>
<div class="">/D</div>
</blockquote>
Thank you and best regards<br>
Christof<br>
</body>
</html>