<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Stephen,</p>
<p>I hope that it will work with most computers using usb-to-serial
interfaces. The underlying usb-serial-for-android implementation
supports quite some chipsets.<br>
</p>
<p>I'd love for you to test the implementation!</p>
<p>You can grab a CI-Built apk from
<a class="moz-txt-link-freetext" href="https://github.com/Subsurface-divelog/subsurface/suites/505662208/artifacts/2634973">https://github.com/Subsurface-divelog/subsurface/suites/505662208/artifacts/2634973</a>
for testing. The source can be found at
<a class="moz-txt-link-freetext" href="https://github.com/charno/subsurface/tree/android-serial-clean">https://github.com/charno/subsurface/tree/android-serial-clean</a>,
the pull request at
<a class="moz-txt-link-freetext" href="https://github.com/Subsurface-divelog/subsurface/pull/2647">https://github.com/Subsurface-divelog/subsurface/pull/2647</a>.<br>
</p>
<p>Best regards<br>
Christof<br>
</p>
<div class="moz-cite-prefix">On 07.03.20 17:22, Stephen Goodall
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAL0txNoErgkjvugCeJXRgrow0myss1uMR0TGky=PrDpar9odmw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="auto">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 )
<div dir="auto"><br>
<div dir="auto">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</div>
<div dir="auto"><br>
</div>
<div dir="auto">Cheers!</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sun, 8 Mar 2020, 3:14 am
Dirk Hohndel via subsurface, <<a
href="mailto:subsurface@subsurface-divelog.org"
moz-do-not-send="true">subsurface@subsurface-divelog.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word;line-break:after-white-space"><br>
<div><br>
<blockquote type="cite">
<div>On Mar 7, 2020, at 5:27 AM, Christof Arnosti <<a
href="mailto:charno@charno.ch" target="_blank"
rel="noreferrer" moz-do-not-send="true">charno@charno.ch</a>>
wrote:</div>
<br>
<div>
<div>
<p>Hi Dirk,</p>
<p>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.</p>
</div>
</div>
</blockquote>
<div><br>
</div>
I will play with this in a couple of hours and most likely
merge your changes.</div>
<div><br>
<blockquote type="cite">
<div>
<div>
<p>Someone just tested with an Mares Nemo Wide
(Serial < 50000), and it did also work.<br>
</p>
</div>
</div>
</blockquote>
<div><br>
</div>
Excellent.</div>
<div><br>
<blockquote type="cite">
<div>
<div>
<p> </p>
<p>Just for clarification about the possible UI
changes (now that I'm more awake again), I would
envision a workflow like this:<br>
- 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.<br>
</p>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>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.</div>
<div>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.</div>
<div>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.</div>
<blockquote type="cite">
<div>
<div>
<p> - 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.<br>
</p>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>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</div>
<br>
<blockquote type="cite">
<div>
<div>
<p> - 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.</p>
</div>
</div>
</blockquote>
<div><br>
</div>
So again, you are suggesting to have a second (or
actually, fourth?) drop down with a driver class?</div>
<div><br>
<blockquote type="cite">
<div>
<div>
<p>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.<br>
</p>
</div>
</div>
</blockquote>
<div><br>
</div>
I believe so.</div>
<div><br>
</div>
<div>/D</div>
</div>
_______________________________________________<br>
subsurface mailing list<br>
<a href="mailto:subsurface@subsurface-divelog.org"
target="_blank" rel="noreferrer" moz-do-not-send="true">subsurface@subsurface-divelog.org</a><br>
<a
href="http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true">http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface</a><br>
</blockquote>
</div>
</blockquote>
</body>
</html>