new releases

Enviado desde mi iPad

This also happens on the mobile version (master and test flight), with Suunto EON Core. I have seen it a couple of times. Connection with BLE is made correctly, firmware version etc. written on screen and then no dives found. If you try again without restarting ssrf it works. I thought it was something like a ble tineout. There are no indications in the normal logs.

Post by Dirk Hohndel
The other issue I see on Mac is that some of the dialogs have partially cut off texts. I'm currently trying to figure out how to even debug this. There's no reason I can figure out why those should not automatically size correctly...

I can confirm that. It hits the divedetails window among others. I have not searched for it, but I saw about a month ago.

Post by Dirk Hohndel
What other bugs do we know of for either desktop or mobile?

mobile: the ssrf logo in the coral picture, still shows as a black spot.

rgds
jan I

Post by Dirk Hohndel
I just pushed the latest strings to transifex, hopefully two weeks of warning should make it reasonably easy to get the translations dealt with...
Thanks everyone!
/D
_______________________________________________
subsurface mailing list
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Linus Torvalds

2018-06-16 05:40:38 UTC

Post by Dirk Hohndel
So far I found one odd bug in Subsurface-mobile with downloading from the Suunto EON Steel. Even though I had new dives on the DC, Subsurface-mobile told me there were no new dives. I added debug output and tried again, and of course it worked correctly :-/

I've been trying to debug this today, and it isn't really us doing
anything wrong per se, it's that BLE communication isn't reliable, and
we don't handle lost packets correctly.

So everything works as long as no packets are lost. Which is sadly not
nearly as common as it should be.

I'm trying to figure out how we should re-send the command when the
reply gets lost, but I don't have any traces for this, so I'm mainly
just guessing and doing some trial-and-error.

Wish me luck.

In the meantime, "just retry" is the way to get it to work.
Eventually it will - at least as long as you're not trying to download
too much, and at least as long as the environment isn't too noisy for
BLE.

Linus

Linus Torvalds

2018-06-16 06:14:49 UTC

On Sat, Jun 16, 2018 at 2:40 PM Linus Torvalds

Post by Linus Torvalds
In the meantime, "just retry" is the way to get it to work.
Eventually it will - at least as long as you're not trying to download
too much, and at least as long as the environment isn't too noisy for
BLE.

I can also make the EON Core crash when there are enough BLE packet
errors. It's probably because we do not re-try - we just fail that
command and then go to the next one. Which will also usually fail,
because we've now confused the EON Core.

So I've gotten "SYSTEM FAILURE" "ERR - c1500000" three times today
while trying to debug this. That resets the time and date on the dive
computer, btw, but Suunto tells me that it doesn't affect the actual
deco calculations even if it happens between dives. I got similar
things when I did things wrong over USB, so I'm not entirely
surprised, but it does make for more exciting debugging.

I'll try to figure out what the proper re-try sequence is. I've
already fixed some of my wrong assumptions of the protocol, but they
don't really matter (the "connection ID" magic value isn't actually 4
bytes, it's a 2-byte magic value and there are two bytes of flags. I
think that's where I need to fill in retransmit information is, but
I'm flying mostly blind.

Linus

Thomas Fänge

2018-06-16 06:45:04 UTC

HI all!

Post by Linus Torvalds

Post by Dirk Hohndel
What other bugs do we know of for either desktop or mobile?

Post by Linus Torvalds
On Sat, Jun 16, 2018 at 2:40 PM Linus Torvalds

Post by Dirk Hohndel
In the meantime, "just retry" is the way to get it to work.
Eventually it will - at least as long as you're not trying to download
too much, and at least as long as the environment isn't too noisy for
BLE.

I can also make the EON Core crash when there are enough BLE packet
errors. It's probably because we do not re-try - we just fail that
command and then go to the next one. Which will also usually fail,
because we've now confused the EON Core.
So I've gotten "SYSTEM FAILURE" "ERR - c1500000" three times today
while trying to debug this. That resets the time and date on the dive
computer, btw, but Suunto tells me that it doesn't affect the actual
deco calculations even if it happens between dives. I got similar
things when I did things wrong over USB, so I'm not entirely
surprised, but it does make for more exciting debugging.
I'll try to figure out what the proper re-try sequence is. I've
already fixed some of my wrong assumptions of the protocol, but they
don't really matter (the "connection ID" magic value isn't actually 4
bytes, it's a 2-byte magic value and there are two bytes of flags. I
think that's where I need to fill in retransmit information is, but
I'm flying mostly blind.
Linus
_______________________________________________
subsurface mailing list
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Dirk Hohndel

2018-06-16 06:55:39 UTC

Post by Thomas FÃ¤nge
HI all!

Post by Dirk Hohndel
What other bugs do we know of for either desktop or mobile?

I don't have a single Android device where our way of doing this ever worked (and I have six different Android tablets and phones). So I can't help with even testing this.
What we really need is to fix libusb to be able to open the port.
It seems that there are two approaches that people have been working on, if anyone with an Android device and an FTDI dive computer wants to give it a try:

This is the first one - that hasn't seen much activity in the last two years.

https://gitlab.com/madresistor/libusb/commits/android <https://gitlab.com/madresistor/libusb/commits/android>

This one seems more active, but again, someone would have to spend some quality time on understanding how this would work from a Subsurface-mobile perspective.

https://github.com/libusb/libusb/pull/242 <https://github.com/libusb/libusb/pull/242>

/D

Thomas Fänge

2018-06-16 07:01:41 UTC

Ok, fair enough...

Vacation is coming up, and I could at least try to give it a go. I should
be able to debug etc, but first try to understand the code.

Cheers,
Thomas

Post by Thomas FÃ¤nge
HI all!

Post by Dirk Hohndel
What other bugs do we know of for either desktop or mobile?

What I would wish for, is that using a DC with OTG cable on the mobile
version should work again. Apparently this worked before 4.7.5, and seems
to be related to opening a FTDI port on Android (bug #1240).
I don't have a single Android device where our way of doing this ever
worked (and I have six different Android tablets and phones). So I can't
help with even testing this.
What we really need is to fix libusb to be able to open the port.
It seems that there are two approaches that people have been working on,
if anyone with an Android device and an FTDI dive computer wants to give it
This is the first one - that hasn't seen much activity in the last two years.
https://gitlab.com/madresistor/libusb/commits/android
This one seems more active, but again, someone would have to spend some
quality time on understanding how this would work from a Subsurface-mobile
perspective.
https://github.com/libusb/libusb/pull/242
/D

Anton Lundin

2018-06-16 07:26:34 UTC

Post by Thomas FÃ¤nge
HI all!

Post by Dirk Hohndel
What other bugs do we know of for either desktop or mobile?

I don't have a single Android device where our way of doing this ever worked (and I have six different Android tablets and phones). So I can't help with even testing this.
What we really need is to fix libusb to be able to open the port.
This is the first one - that hasn't seen much activity in the last two years.
https://gitlab.com/madresistor/libusb/commits/android <https://gitlab.com/madresistor/libusb/commits/android>
This one seems more active, but again, someone would have to spend some quality time on understanding how this would work from a Subsurface-mobile perspective.
https://github.com/libusb/libusb/pull/242 <https://github.com/libusb/libusb/pull/242>

I really don't like either of those two approaches. Both of them require
you to rewrite all the libusb-open code, which is going to be a pita for
us. We don't call libusb directly, we just call libdivecomputer or
libftdi which calls into libusb for us.

The approach I've worked on is to replace the discovery code in libusb
with something which jni's into android to provide the list of devices.
That way we still just modify libusb and let all the callers think
they're talking to a bog standard libusb on a normal system.

libusb is old egnough to have multiple backends for talking to different
generations of the usb interfaces so its resonably straight forward to
plumb in a "custom-android" backend which jni's into android filling in
the right data structures.

Somewhere I have some half ass first take at implementing this that
doesn't work.

Another approach to solve the FTDI issue in specific is to replace the
serial_ftdi.c code all together with a implementation using the official
android ftdi driver (d2xx.jar) and doing jni calls into it. The downside
with this is that we would drop support for all pure libusb devices,
like the eon steel, and so on.

//Anton

--
Anton Lundin +46702-161604

Linus Torvalds

2018-06-16 07:41:45 UTC

Post by Anton Lundin
Another approach to solve the FTDI issue in specific is to replace the
serial_ftdi.c code all together with a implementation using the official
android ftdi driver (d2xx.jar) and doing jni calls into it. The downside
with this is that we would drop support for all pure libusb devices,
like the eon steel, and so on.

It's likely only the Atomic Aquatics Cobalt that we would need to worry about.

On a phone, you'd use BLE to talk to the EON Steel and the Scubapro
G2, which are the main usbhid users (which in turn uses libusb -
unless HIDPI works on Android?).

Of course, BLE is flaky, so USB *could* be good on Android, but let's
be honest - nobody is going to bother.

Linus

Dirk Hohndel

2018-06-16 05:41:14 UTC

Linus is looking into that one

I can confirm that. It hits the divedetails window among others. I have not searched for it, but I saw about a month ago.

I think I have fixed this. Waiting for comments from Robert

Post by Dirk Hohndel
What other bugs do we know of for either desktop or mobile?

mobile: the ssrf logo in the coral picture, still shows as a black spot.

Right. I noticed that as well.

/D

Robert Helling

2018-06-16 06:00:01 UTC

Dirk,

I can confirm that. It hits the divedetails window among others. I have not searched for it, but I saw about a month ago.

I think I have fixed this. Waiting for comments from Robert

I had a similar issue a few months ago with some progress dialogue. This was a Qt bug on Mac (which I filed) and did some work around for that specific dialogue.

Let me try to find that.

For which windows did you encounter this?

Robert

Robert Helling

2018-06-16 06:03:42 UTC

Hi,

Post by Robert Helling
I had a similar issue a few months ago with some progress dialogue. This was a Qt bug on Mac (which I filed) and did some work around for that specific dialogue.
Let me try to find that.

here it is:

https://github.com/Subsurface-divelog/subsurface/issues/1041 <https://github.com/Subsurface-divelog/subsurface/issues/1041>
https://bugreports.qt.io/browse/QTBUG-65750?attachmentViewMode=list <https://bugreports.qt.io/browse/QTBUG-65750?attachmentViewMode=list>

Does this look familiar?

Robert

Jan Iversen

2018-06-16 06:05:56 UTC

Post by Robert Helling
Hi,

https://github.com/Subsurface-divelog/subsurface/issues/1041 <https://github.com/Subsurface-divelog/subsurface/issues/1041>
https://bugreports.qt.io/browse/QTBUG-65750?attachmentViewMode=list <https://bugreports.qt.io/browse/QTBUG-65750?attachmentViewMode=list>
Does this look familiar?

That is exactly what I have on my Mac :-(
(Qt 5.10)

rgds
Jan I

Post by Robert Helling
Robert
_______________________________________________
subsurface mailing list
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Dirk Hohndel

2018-06-16 06:43:48 UTC

Post by Robert Helling
Hi,

Yep. I wonder if my fix does the trick for you.

https://github.com/Subsurface-divelog/subsurface/pull/1383 <https://github.com/Subsurface-divelog/subsurface/pull/1383>
/D

Murillo Bernardes

2018-06-16 09:10:54 UTC

Murillo Bernardes

Linus is looking into that one

I can confirm that. It hits the divedetails window among others. I have not searched for it, but I saw about a month ago.

I think I have fixed this. Waiting for comments from Robert

Post by Dirk Hohndel
What other bugs do we know of for either desktop or mobile?

mobile: the ssrf logo in the coral picture, still shows as a black spot.

Right. I noticed that as well.

This is a Kirigami bug. Unfortunately I could not track this the last
two weeks. I'll get back to it now.

Dirk Hohndel

2018-06-16 10:00:27 UTC

Post by Murillo Bernardes

Post by Jan Iversen
mobile: the ssrf logo in the coral picture, still shows as a black spot.

Right. I noticed that as well.

This is a Kirigami bug. Unfortunately I could not track this the last
two weeks. I'll get back to it now.

I'm fixing this right now...

/D

Berthold Stoeger

2018-06-16 09:06:32 UTC

Hi,

Post by Dirk Hohndel
What other bugs do we know of for either desktop or mobile?

Not a bug, but perhaps remove the cryptic debug messages from
libdivecomputer.c? I know I was confused. Proposed patch attached.

After the release, could we perhaps try to finally get PR#799 out (or
trashed)? I have access to a Windows-PC, but I need feedback / suggestions.

Berthold

Miika Turkia

2018-06-16 10:08:34 UTC

Post by Dirk Hohndel
What other bugs do we know of for either desktop or mobile?

I have had some crashes on iPhone when syncing new data from cloud. Apparently Subsurface-mobile crashes after the sync, as new data is available on next start.

was there some way to get the crash log out of iPhone? Running 4.7.8.287

miika

Robert C. Helling

2018-06-16 12:32:20 UTC

Hi,

Post by Miika Turkia
was there some way to get the crash log out of iPhone? Running 4.7.8.287

Go to settings, privacy , analytics (or whatever that is called in your language). You’ll find everything there.

Best
Robert

Stefan Fuchs

2018-06-17 12:06:46 UTC

Hallo Dirk,

Post by Dirk Hohndel
What other bugs do we know of for either desktop or mobile?

One doubt: I remember that with some commit someone introduced a kind of
debug output of the available transport protocols for a connected DC.
This shows up in this red error bar at the bottom of the Subsurface
window. See screenshot attached.
Will this be automatically disabled for a release build? Or may we need
to remove this again?

Best regards
Stefan

--
Stefan Fuchs
E-Mail: ***@gmx.de <mailto:***@gmx.de>

Dirk Hohndel

2018-06-17 12:16:30 UTC

Post by Stefan Fuchs
Hallo Dirk,

Post by Dirk Hohndel
What other bugs do we know of for either desktop or mobile?

One doubt: I remember that with some commit someone introduced a kind of debug output of the available transport protocols for a connected DC. This shows up in this red error bar at the bottom of the Subsurface window. See screenshot attached.
Will this be automatically disabled for a release build? Or may we need to remove this again?

That someone was me and this is not automatically disabled - please file an issue as I'm about to go to bed and will forget otherwise (or send a PR :-) )

/D

Berthold Stoeger

2018-06-17 13:33:41 UTC

Post by Stefan Fuchs
Hallo Dirk,

Post by Dirk Hohndel
What other bugs do we know of for either desktop or mobile?

One doubt: I remember that with some commit someone introduced a kind of
debug output of the available transport protocols for a connected DC.
This shows up in this red error bar at the bottom of the Subsurface
window. See screenshot attached. Will this be automatically disabled for
a release build? Or may we need to remove this again?

That someone was me and this is not automatically disabled - please file an
issue as I'm about to go to bed and will forget otherwise (or send a PR :-)
)

Note that I posted a patch to the list in <***@laptop>. Will
make it a PR.

Berthold

Dirk Hohndel

2018-06-24 01:02:54 UTC

OK, second call :-)

Thanks to many of you we have resolved a bunch of bugs and I think we are pretty close to ready.

I am thinking of randomly bumping the release numbers up to 4.8 for Subsurface and 2.1 for Subsurface-mobile.

The latest strings were pushed; there was really only one "new" string and I'm the one who created it in order for a message in the error case to make more sense to the user.

I'll ask the same question as last week: any more issues we really need to fix before the release? Or are we about good to go?

I don't have a firm timeline in mind - I have some time to work on Subsurface today (part of the day is spent on a plane, the rest mostly sitting around doing not much - which is just like being on a plane), tomorrow may be rather busy, Tuesday is 39 hours long, leaving Beijing in the morning and arriving before we depart (based on local time) in Portland - so maybe I'll do the release in the second half of the week when jetlag keeps me from sleeping? :-)

/D

Robert C. Helling

2018-06-24 05:42:27 UTC

Dirk,

Post by Dirk Hohndel
I'll ask the same question as last week: any more issues we really need to fix before the release? Or are we about good to go?

I have this pull request open on bug fixes in bailout. I was hoping for Willem to comment on it. That (or potentially an improved version if somebody finds anything wrong with it) should definitely go into the next desktop version

I would rather merge it as is than not doing anything at all about it.

Best
Robert
From the phone so I don’t have the PR number ready.

Dirk Hohndel

2018-06-24 07:01:55 UTC

Your call, not an area of the code that I'd be second guessing you.

If you want it to go in, then I'd prefer as soon as possible so it sees at least a little testing

/D

Post by Dirk Hohndel
Dirk,

Post by Dirk Hohndel
I'll ask the same question as last week: any more issues we really

need to fix before the release? Or are we about good to go?
I have this pull request open on bug fixes in bailout. I was hoping for
Willem to comment on it. That (or potentially an improved version if
somebody finds anything wrong with it) should definitely go into the
next desktop version
I would rather merge it as is than not doing anything at all about it.
Best
Robert
From the phone so I don’t have the PR number ready.

--
from my phone.

Jan Iversen

2018-06-24 07:30:44 UTC

Dirkh

You added release blocker on issue #1405, I suppose that means it needs to be solved :-)

rgds
jan i

Enviado desde mi iPad

Post by Dirk Hohndel
Your call, not an area of the code that I'd be second guessing you.
If you want it to go in, then I'd prefer as soon as possible so it sees at least a little testing
/D

Post by Dirk Hohndel
Dirk,

Post by Dirk Hohndel
I'll ask the same question as last week: any more issues we really

--
from my phone.
_______________________________________________
subsurface mailing list
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Dirk Hohndel

2018-06-24 09:01:58 UTC

Indeed - the problem is that I cannot reproduce it even though I'm on the same distro...
So unless someone else comes up with a suggestion, I'm not sure what to do.

But thanks for the reminder

/D

Post by Jan Iversen
Dirkh
You added release blocker on issue #1405, I suppose that means it needs to be solved :-)
rgds
jan i
Enviado desde mi iPad

Post by Dirk Hohndel
Your call, not an area of the code that I'd be second guessing you.
If you want it to go in, then I'd prefer as soon as possible so it sees at least a little testing
/D

Post by Dirk Hohndel
Dirk,

Post by Dirk Hohndel
I'll ask the same question as last week: any more issues we really

--
from my phone.
_______________________________________________
subsurface mailing list
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Jef Driesen

2018-06-26 08:00:08 UTC

Post by Dirk Hohndel
We have lapsed on our goal to do regular releases.
Can we use the next two weeks to get both desktop and mobile into
releasable shape? Linus and I are doing "in the field testing" this
week in Japan - and true to our past track record, we have brought a
freak storm to Okinawa...
So far I found one odd bug in Subsurface-mobile with downloading from
the Suunto EON Steel. Even though I had new dives on the DC,
Subsurface-mobile told me there were no new dives. I added debug
output and tried again, and of course it worked correctly :-/
The other issue I see on Mac is that some of the dialogs have
partially cut off texts. I'm currently trying to figure out how to
even debug this. There's no reason I can figure out why those should
not automatically size correctly...
What other bugs do we know of for either desktop or mobile?
I just pushed the latest strings to transifex, hopefully two weeks of
warning should make it reasonably easy to get the translations dealt
with...
Thanks everyone!

I pushed the fix for the Mac OS X timer bug. Can you make sure that
makes it into the next release? There is also support for the
DiveComputer.eu dive computer. Would be nice to have that included as
well. They are very eager to see support for their dive computer in
subsurface :-)

Jef

Dirk Hohndel

2018-06-26 15:19:31 UTC

I pushed the fix for the Mac OS X timer bug. Can you make sure that makes it into the next release? There is also support for the DiveComputer.eu dive computer. Would be nice to have that included as well. They are very eager to see support for their dive computer in subsurface :-)

Cool. I really appreciate the heads up.
Linus will pull this and I'll update Subsurface before creating the release.

Thanks

/D

g***@free.fr

2018-06-26 08:23:22 UTC