Re: [PATCH] MarbleDebug: don't use a class extending QIODevice as a null device

2017-04-17 Thread Stefan Fuchs 
Hello Lubomir, hello All,

Am 09.04.2017 um 22:15 schrieb Lubomir I. Ivanov:
> From: "Lubomir I. Ivanov" 
>
> For some reason on Windows 10 the NullDevice class approach
> causes an infinite loop because QtCore cannot obtain a mutex lock
> (ntdll.dll!_NtWaitForSingleObject) for the text stream.
>
> Using this method of passing the location of the system null device
> to QFile, "should" work better.
>
> Reported-by: Stefan Fuchs 
> Signed-off-by: Lubomir I. Ivanov 
> ---
>
> untested in marble for the reported use case!
> i've tested it in a standalone "hello-world" type of project.
>
> this is a patch for the MarbleDebug.cpp file in the Subsurface branch:
> against 4325da9 [ssrf/Subsurface-branch]
> ---
>  src/lib/marble/MarbleDebug.cpp | 28 +++-
>  1 file changed, 7 insertions(+), 21 deletions(-)

I applied the patch, continued testing and now have new results:
I don't have a "zombie" Subsurface.exe any more every ~10th startup but
I see a "real" crash. Call stacks of two occurrences attached. I guess
what I'm seeing is the very same problem somewhere in Marble because it
again starts at:
libssrfmarblewidgetd.dll!run 
[/home/stefan/Entwicklung/Subsurface/marble-source/src/lib/marble/FileLoader.cpp
@ 138]

Can I do s.th. to provide more debugging output?

Best regards
Stefan

BTW: This refers to https://github.com/Subsurface-divelog/marble/pull/1

-- 

Stefan Fuchs
E-Mail: sfu...@gmx.de 

Registers:
eax=5a8951c0 ebx=58cf6c08 ecx=5a85817c edx= esi=03c79c60 edi=03c79c60
eip=1a972bed esp=03c79380 ebp=03c793a8 iopl=0 nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b efl=0206

AddrPC   Params
1A972BED 03C793BC  03C793D8  Qt5Widgetsd.dll!operator->  
[/home/stefan/Entwicklung/Subsurface/mxe-2016-10-12/tmp-qtbase-i686-w64-mingw32.shared/qtbase-opensource-src-5.7.0/src/widgets/../../include/QtCore/../../src/corelib/global/qlogging.h
 @ 92]
1A99C5BE 03C79454    Qt5Widgetsd.dll!parent  
[/home/stefan/Entwicklung/Subsurface/mxe-2016-10-12/tmp-qtbase-i686-w64-mingw32.shared/qtbase-opensource-src-5.7.0/src/widgets/../../include/QtCore/../../src/corelib/global/qlogging.h
 @ 92]
1A9A1CD7 003E 001D 001D  Qt5Widgetsd.dll!parentWidget  
[/home/stefan/Entwicklung/Subsurface/mxe-2016-10-12/tmp-qtbase-i686-w64-mingw32.shared/qtbase-opensource-src-5.7.0/src/widgets/../../include/QtCore/../../src/corelib/tools/qstring.h
 @ 554]
1A57ABAE 003E 03C79454 03C79458  Qt5Widgetsd.dll!window  
[/home/stefan/Entwicklung/Subsurface/mxe-2016-10-12/tmp-qtbase-i686-w64-mingw32.shared/qtbase-opensource-src-5.7.0/src/widgets/kernel/qwidget.cpp
 @ 4354]
1A58A814 03C794A0 5AAB17E0 03C794B8  Qt5Widgetsd.dll!update  
[/home/stefan/Entwicklung/Subsurface/mxe-2016-10-12/tmp-qtbase-i686-w64-mingw32.shared/qtbase-opensource-src-5.7.0/src/widgets/kernel/qwidget.cpp
 @ 10961]
1A58A6FA  0002   Qt5Widgetsd.dll!update  
[/home/stefan/Entwicklung/Subsurface/mxe-2016-10-12/tmp-qtbase-i686-w64-mingw32.shared/qtbase-opensource-src-5.7.0/src/widgets/kernel/qwidget.cpp
 @ 10930]
1A587084 03C7D694 04454CFC 03C796B8  Qt5Widgetsd.dll!event  
[/home/stefan/Entwicklung/Subsurface/mxe-2016-10-12/tmp-qtbase-i686-w64-mingw32.shared/qtbase-opensource-src-5.7.0/src/widgets/kernel/qwidget.cpp
 @ 9050]
1A6527D8 03C7D694 03C79C60 03C796F8  Qt5Widgetsd.dll!event  
[/home/stefan/Entwicklung/Subsurface/mxe-2016-10-12/tmp-qtbase-i686-w64-mingw32.shared/qtbase-opensource-src-5.7.0/src/widgets/widgets/qabstractbutton.cpp
 @ 966]
1A719AF8 03C7D694 03C7D694 03C79738  Qt5Widgetsd.dll!event  
[/home/stefan/Entwicklung/Subsurface/mxe-2016-10-12/tmp-qtbase-i686-w64-mingw32.shared/qtbase-opensource-src-5.7.0/src/widgets/widgets/qtoolbutton.cpp
 @ 983]
1A54F90C 5AB126A8 03C7D694 03C79768  Qt5Widgetsd.dll!notify_helper  
[/home/stefan/Entwicklung/Subsurface/mxe-2016-10-12/tmp-qtbase-i686-w64-mingw32.shared/qtbase-opensource-src-5.7.0/src/widgets/kernel/qapplication.cpp
 @ 3799]
1A54F75A 03C79CD0 03C79CB0 03C7A530  Qt5Widgetsd.dll!notify  
[/home/stefan/Entwicklung/Subsurface/mxe-2016-10-12/tmp-qtbase-i686-w64-mingw32.shared/qtbase-opensource-src-5.7.0/src/widgets/kernel/qapplication.cpp
 @ 3762]
040E98A2 5AB126A8 03C7D694   Qt5Cored.dll!notifyInternal2  
[/home/stefan/Entwicklung/Subsurface/mxe-2016-10-12/tmp-qtbase-i686-w64-mingw32.shared/qtbase-opensource-src-5.7.0/src/corelib/kernel/qcoreapplication.cpp
 @ 988]
1A8C5459 5AB126A8 03C7D694 58D08AE0  Qt5Widgetsd.dll!sendEvent  
[/home/stefan/Entwicklung/Subsurface/mxe-2016-10-12/tmp-qtbase-i686-w64-mingw32.shared/qtbase-opensource-src-5.7.0/src/widgets/../../include/QtCore/../../src/corelib/global/qglobal.h
 @ 636]
1A587110 03C7D694 03C7D694 03C79F98  Qt5Widgetsd.dll!event  
[/home/stefan/Entwicklung/Subsurface/mxe-2016-10-12/tmp-qtbase-i686-w64-mingw32.shared/qtbase-opensource-src-5.7.0/src/widgets/kernel/qwidget.cpp
 @ 9055]
1A71141F 03C7D694 03C7D694 03C7A008  Qt5Widg

Re: [PATCH] MarbleDebug: don't use a class extending QIODevice as a null device

2017-04-17 Thread Lubomir I. Ivanov 
On 17 April 2017 at 21:04, Stefan Fuchs  wrote:
> Hello Lubomir, hello All,
>
> Am 09.04.2017 um 22:15 schrieb Lubomir I. Ivanov:
>
>
> I applied the patch, continued testing and now have new results:
> I don't have a "zombie" Subsurface.exe any more every ~10th startup but I
> see a "real" crash. Call stacks of two occurrences attached. I guess what

hello, something isn't right here.

0420BBA8 0020 0001 5B92FCC8  Qt5Cored.dll! ??
[/home/stefan/Entwicklung/Subsurface/mxe-2016-10-12/tmp-qtbase-i686-w64-mingw32.shared/qtbase-opensource-src-5.7.0/src/corelib/../../include/QtCore/../../src/corelib/io/qtextstream.h
@ 217]
04038406 5A913E94 5AAADBD8 0427600A  Qt5Cored.dll! ??
[/home/stefan/Entwicklung/Subsurface/mxe-2016-10-12/tmp-qtbase-i686-w64-mingw32.shared/qtbase-opensource-src-5.7.0/src/corelib/io/qdebug.cpp
@ 158]
22E78B1F 0001 5AA22CA8 0006  libssrfmarblewidgetd.dll!run
[/home/stefan/Entwicklung/Subsurface/marble-source/src/lib/marble/FileLoader.cpp
@ 138]

Marble's FileLoader does a:
mDebug() << "starting parser for" << d->m_filepath;

MarbleDebug does returns this for mDebug(), post applying the patch
and if MarbleDebug::m_enabled() == false:
static QFile *nullDevice = new QFile(QProcess::nullDevice());
if ( !nullDevice->isOpen() )
nullDevice->open(QIODevice::WriteOnly);
return QDebug( nullDevice );

qdebug.cpp @ 158 is the destructor for the QDebug object in 5.7.

it asserts releasing a "stream" object, because the size of it's ring
buffer is 0. this should not happen.
the destructor seems to be called because the object is going out of
scope (maybe?). i don't understand why the stream is being released
though.
maybe that's caused by the concurrency issues you've reported earlier.

your best bet is to change the function to this:

QDebug mDebug()
 {
return QDebug( QtDebugMsg ); // or "return qDebug();"
}

which will essentially enable debug output for everything in Marble,
until we write a dummy Class with an overloaded << operator to void
all the incoming debug calls.

lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PATCH] MarbleDebug: don't use a class extending QIODevice as a null device

2017-04-17 Thread Stefan Fuchs 
Hello Lubomir,

Am 17.04.2017 um 21:01 schrieb Lubomir I. Ivanov:
> your best bet is to change the function to this:
>
> QDebug mDebug()
>  {
> return QDebug( QtDebugMsg ); // or "return qDebug();"
> }
>
> which will essentially enable debug output for everything in Marble,
> until we write a dummy Class with an overloaded << operator to void
> all the incoming debug calls.
Yes, agreed. I did this already once before following your suggestion
and I now did it again in a little different way by enabling a line Dirk
recently added in MarbleDebug.cpp:

namespace Marble
{
bool MarbleDebug::m_enabled = true;
// bool MarbleDebug::m_enabled = false;

Even with my limited skills I can guess that will give the same result.
And yes: In both cases no more crashes.
And yes: I see lot's of marble debug output now if I start under windows
from the PowerShell.


But still two questions, one maybe stupid:
- Why could it be that eventually in Marble FileLoader::run every ~10th
startup the "different" branch including line 138 is executed? Does this
happen unintentionally? This is executed for d->m_contents.isEmpty()==true.
- Can this change also go into Dirks Subsurface-marble branch? Maybe
also other users are affected?

Best regards
Stefan

-- 

Stefan Fuchs
E-Mail: sfu...@gmx.de 

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PATCH] MarbleDebug: don't use a class extending QIODevice as a null device

2017-04-17 Thread Thiago Macieira 
On segunda-feira, 17 de abril de 2017 12:01:48 PDT Lubomir I. Ivanov wrote:
> QDebug mDebug()
>  {
> return QDebug( QtDebugMsg ); // or "return qDebug();"
> }
> 
> which will essentially enable debug output for everything in Marble,
> until we write a dummy Class with an overloaded << operator to void
> all the incoming debug calls.

It would be better to use a category and then simply turn the category off. It 
can be enabled manually by users with QT_LOGGING_RULES environment variable.

See http://doc.qt.io/qt-5/qloggingcategory.html.

This functionality didn't exist in Qt 4, which is why Marble rolled out its 
own.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PATCH] Visualisation of individual oxygen sensor data for CCR dives

2017-04-17 Thread Jef Driesen 

On 14-04-17 21:57, Anton Lundin wrote:

On 13 April, 2017 - Jef Driesen wrote:


On 2017-04-12 10:47, Anton Lundin wrote:


The issue with current libdivecomputer DC_SAMPLE_PPO2 is that you cant
distinguish between ha "real" "voted" pO2 and the raw sensor value.

I would like to see a option to export both, and be able to handle them
differently


We could introduce a new structure that carries a sensor index
(similar to DC_SAMPLE_PRESSURE):

struct ppo2 {
unsigned int sensor;
double value;
};

That way we can easily report multiple DC_SAMPLE_PPO2 values, each
with a
different sensor id. And for the voted/calculated ppO2, we can use
some magic value, like:

#define DC_SENSOR_NONE 0x

(Just like we already have DC_GASMIX_UNKNOWN).


That would be great.

Another thing would be to expose the voting information. Seeing when the
sensor was voted out and the sensors performance after, is quite
relevant for trying to diagnose what happened.


Unless I missed something, the voting info isn't stored in the sample data, only 
in the dive header. I'm not a CCR diver, but isn't the voting done for each 
sample? If that's correct, then the voting bits in the dive header aren't very 
useful, right? So I don't think we can report voting info.


I assume the voting bits in the dive header indicate the sensor has been voted 
out one or more times during the dive, but not necessary for the entire dive?


Jef
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PATCH] Visualisation of individual oxygen sensor data for CCR dives

2017-04-17 Thread Jef Driesen 

On 14-04-17 22:04, Anton Lundin wrote:

On 14 April, 2017 - Jef Driesen wrote:


On 2017-04-13 17:04, Jef Driesen wrote:
I tried a different approach yesterday. Instead of adding 1024 to
the calibration value, I simply used the stored value as is, and
calculated the average ppO2 over all three sensors. Then I plotted
all those values against the average ppO2 reported by the device.
And guess what, there is a nice linear relationship between the two!
Doing a linear regression on the data gives a scaling factor of 2.2.


Interesting find.


For the example above this gives:

Sensor 0: 0.642 = 33 mV * 885 / 10.0 * 2.2
Sensor 1: 0.630 = 29 mV * 989 / 10.0 * 2.2
Sensor 2: 0.674 = 26 mv * 1179 / 10.0 * 2.2

As you can see, the average ppO2 (0.648) is now very close to the
average ppO2 reported by the device (0.65). This seems to be true
for all samples. The largest difference is now 0.018.

The next question is of course what's the source of this factor 2.2?


Could it be that the calibration value is stored in some odd format, and
thats where the / 10.0 * 2.2 part comes from?


My first thought was that it represents some kind of relative value. If you look 
at one of my previous emails, you'll notice that the default value for the 
calibration (when not yet calibrated) is 2100 for the Petrel. And the 
calibration values for the Predator are all near the value 1000. Relative that's 
a factor of 2.1. That's not close enough to 2.2 to produce correct ppO2 values, 
but it's the only explanation I have that makes some sense to me.


BTW, the fact that the calibration values are near 1000 is also why adding 1024 
worked for most samples. If the value is a bit higher than 1000, then the result 
is pretty close to multiplying with 2.2.



And is correct for all Predators?


How did it line up on the petrels?


I only checked for the predators. For the petrel, the results are already 
correct without the 2.2 scaling factor. So applying it there too, will produce 
wrong results. So this is most likely something specific to the predators only.


Jef
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PATCH] MarbleDebug: don't use a class extending QIODevice as a null device

2017-04-17 Thread Lubomir I. Ivanov 
On 17 April 2017 at 22:29, Thiago Macieira  wrote:
> On segunda-feira, 17 de abril de 2017 12:01:48 PDT Lubomir I. Ivanov wrote:
>> QDebug mDebug()
>>  {
>> return QDebug( QtDebugMsg ); // or "return qDebug();"
>> }
>>
>> which will essentially enable debug output for everything in Marble,
>> until we write a dummy Class with an overloaded << operator to void
>> all the incoming debug calls.
>
> It would be better to use a category and then simply turn the category off. It
> can be enabled manually by users with QT_LOGGING_RULES environment variable.
>
> See http://doc.qt.io/qt-5/qloggingcategory.html.
>

thanks, for the suggestion, Thiago.

Stefan, could you please test the attached patch and if it works,
submit it to Github for approval.

lubomir
--
From 64bac042e3378108eeab1b66a18fa5f63d91e5fa Mon Sep 17 00:00:00 2001
From: "Lubomir I. Ivanov" 
Date: Mon, 17 Apr 2017 23:15:23 +0300
Subject: [PATCH] MarbleDebug: use QLoggingCategory to disable logging via
 mDebug()

Signed-off-by: Lubomir I. Ivanov 
---
 src/lib/marble/MarbleDebug.cpp | 13 +++--
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/src/lib/marble/MarbleDebug.cpp b/src/lib/marble/MarbleDebug.cpp
index 5f53f6f..6c00dfd 100644
--- a/src/lib/marble/MarbleDebug.cpp
+++ b/src/lib/marble/MarbleDebug.cpp
@@ -11,7 +11,7 @@
 #include "MarbleDebug.h"
 
 #include 
-#include 
+#include 
 
 namespace Marble
 {
@@ -20,15 +20,8 @@ bool MarbleDebug::m_enabled = false;
 
 QDebug mDebug()
 {
-if ( MarbleDebug::isEnabled() ) {
-return QDebug( QtDebugMsg );
-}
-else {
-static QFile *nullDevice = new QFile(QProcess::nullDevice());
-if ( !nullDevice->isOpen() )
- nullDevice->open(QIODevice::WriteOnly);
- return QDebug( nullDevice );
-}
+QLoggingCategory::defaultCategory()->setEnabled(QtDebugMsg, MarbleDebug::isEnabled());
+return QDebug( QtDebugMsg );
 }
 
 bool MarbleDebug::isEnabled()
-- 
1.7.11.msysgit.0

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PATCH] Visualisation of individual oxygen sensor data for CCR dives

2017-04-17 Thread Anton Lundin 
On 17 April, 2017 - Jef Driesen wrote:

> On 14-04-17 21:57, Anton Lundin wrote:
> >On 13 April, 2017 - Jef Driesen wrote:
> >
> >>On 2017-04-12 10:47, Anton Lundin wrote:
> >>>
> >>>The issue with current libdivecomputer DC_SAMPLE_PPO2 is that you cant
> >>>distinguish between ha "real" "voted" pO2 and the raw sensor value.
> >>>
> >>>I would like to see a option to export both, and be able to handle them
> >>>differently
> >>
> >>We could introduce a new structure that carries a sensor index
> >>(similar to DC_SAMPLE_PRESSURE):
> >>
> >>struct ppo2 {
> >>unsigned int sensor;
> >>double value;
> >>};
> >>
> >>That way we can easily report multiple DC_SAMPLE_PPO2 values, each
> >>with a
> >>different sensor id. And for the voted/calculated ppO2, we can use
> >>some magic value, like:
> >>
> >>#define DC_SENSOR_NONE 0x
> >>
> >>(Just like we already have DC_GASMIX_UNKNOWN).
> >
> >That would be great.
> >
> >Another thing would be to expose the voting information. Seeing when the
> >sensor was voted out and the sensors performance after, is quite
> >relevant for trying to diagnose what happened.
> 
> Unless I missed something, the voting info isn't stored in the
> sample data, only in the dive header. I'm not a CCR diver, but isn't
> the voting done for each sample? If that's correct, then the voting
> bits in the dive header aren't very useful, right? So I don't think
> we can report voting info.
> 
> I assume the voting bits in the dive header indicate the sensor has
> been voted out one or more times during the dive, but not necessary
> for the entire dive?

I guess that the voting is evaluated in each sample, but when a sensor
is voted out, its out for good.


If the voting information won't be exposed via mainline libdivecomputer,
its a simple patch to add a DC_FIELD_STRING as a Subsurface patch.


Anyway, I think its really important information that should be exposed.


//Anton


-- 
Anton Lundin+46702-161604
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PATCH] MarbleDebug: don't use a class extending QIODevice as a null device

2017-04-17 Thread Thiago Macieira 
On segunda-feira, 17 de abril de 2017 13:24:26 PDT Lubomir I. Ivanov wrote:
> On 17 April 2017 at 22:29, Thiago Macieira  wrote:
> > On segunda-feira, 17 de abril de 2017 12:01:48 PDT Lubomir I. Ivanov 
wrote:
> >> QDebug mDebug()
> >> 
> >>  {
> >>  
> >> return QDebug( QtDebugMsg ); // or "return qDebug();"
> >> 
> >> }
> >> 
> >> which will essentially enable debug output for everything in Marble,
> >> until we write a dummy Class with an overloaded << operator to void
> >> all the incoming debug calls.
> > 
> > It would be better to use a category and then simply turn the category
> > off. It can be enabled manually by users with QT_LOGGING_RULES
> > environment variable.
> > 
> > See http://doc.qt.io/qt-5/qloggingcategory.html.
> 
> thanks, for the suggestion, Thiago.
> 
> Stefan, could you please test the attached patch and if it works,
> submit it to Github for approval.

This disables the debug output for the default category, that is, every user 
of qDebug().

I was suggesting turning mDebug() into qCDebug(...).

// in a header
namespace Marble {
Q_DECLARE_LOGGING_CATEGORY(loggingCategory)
}
#define mDebug  qCDebug(Marble::loggingCategory)

// in one source file
namespace Marble {
Q_LOGGING_CATEGORY(loggingCategory, "marble", QtWarningMsg)
}

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PATCH] MarbleDebug: don't use a class extending QIODevice as a null device

2017-04-17 Thread Lubomir I. Ivanov 
On 17 April 2017 at 23:46, Thiago Macieira  wrote:
> This disables the debug output for the default category, that is, every user
> of qDebug().
>

yep, i later figured that might happen.

> I was suggesting turning mDebug() into qCDebug(...).
>
> // in a header
> namespace Marble {
> Q_DECLARE_LOGGING_CATEGORY(loggingCategory)
> }
> #define mDebug  qCDebug(Marble::loggingCategory)
>
> // in one source file
> namespace Marble {
> Q_LOGGING_CATEGORY(loggingCategory, "marble", QtWarningMsg)
> }
>

i've tried returning a qCDebug() from mDebug, but it cannot be done.
so how can the flag MarbleDebug::isEnabled() be used then to
conditionally show debug output in Marble?

lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PATCH] MarbleDebug: don't use a class extending QIODevice as a null device

2017-04-17 Thread Lubomir I. Ivanov 
On 18 April 2017 at 00:02, Lubomir I. Ivanov  wrote:
> On 17 April 2017 at 23:46, Thiago Macieira  wrote:
>> This disables the debug output for the default category, that is, every user
>> of qDebug().
>>
>
> yep, i later figured that might happen.
>
>> I was suggesting turning mDebug() into qCDebug(...).
>>
>> // in a header
>> namespace Marble {
>> Q_DECLARE_LOGGING_CATEGORY(loggingCategory)
>> }
>> #define mDebug  qCDebug(Marble::loggingCategory)
>>
>> // in one source file
>> namespace Marble {
>> Q_LOGGING_CATEGORY(loggingCategory, "marble", QtWarningMsg)
>> }
>>
>
> i've tried returning a qCDebug() from mDebug, but it cannot be done.
> so how can the flag MarbleDebug::isEnabled() be used then to
> conditionally show debug output in Marble?
>

i guess we could just do a:
void MarbleDebug::setEnabled(bool enabled)
{
Marble::loggingCategory.setEnabled(enabled);
MarbleDebug::m_enabled = enabled;
}

lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PATCH] MarbleDebug: don't use a class extending QIODevice as a null device

2017-04-17 Thread Thiago Macieira 
On segunda-feira, 17 de abril de 2017 14:10:28 PDT Lubomir I. Ivanov wrote:
> i guess we could just do a:
> void MarbleDebug::setEnabled(bool enabled)
> {
> Marble::loggingCategory.setEnabled(enabled);
> MarbleDebug::m_enabled = enabled;
> }

I'd go a little further and drop the m_enabled variable completely. You don't 
need it, let the bit in the QLoggingCategory variable keep the state.

You'd have:

namespace MarbleDebug {
Q_LOGGING_CATEGORY(category, "marble", QtWarningMsg)

void setEnabled(bool enabled)
{
category.setEnabled(QtDebugMsg, enabled);
}

bool isEnabled()// do you even need this function?
{
return category.isDebugEnabled();
}
} //namespace MarbleDebug

This changes to the MarbleDebug namespace too.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PATCH] MarbleDebug: don't use a class extending QIODevice as a null device

2017-04-17 Thread Lubomir I. Ivanov 
On 18 April 2017 at 00:18, Thiago Macieira  wrote:
> On segunda-feira, 17 de abril de 2017 14:10:28 PDT Lubomir I. Ivanov wrote:
>> i guess we could just do a:
>> void MarbleDebug::setEnabled(bool enabled)
>> {
>> Marble::loggingCategory.setEnabled(enabled);
>> MarbleDebug::m_enabled = enabled;
>> }
>
> I'd go a little further and drop the m_enabled variable completely. You don't
> need it, let the bit in the QLoggingCategory variable keep the state.
>
> You'd have:
>
> namespace MarbleDebug {
> Q_LOGGING_CATEGORY(category, "marble", QtWarningMsg)
>
> void setEnabled(bool enabled)
> {
> category.setEnabled(QtDebugMsg, enabled);
> }
>
> bool isEnabled()// do you even need this function?
> {
> return category.isDebugEnabled();
> }
> } //namespace MarbleDebug
>
> This changes to the MarbleDebug namespace too.
>

thanks, i think i understand.

here are the updated Marble files and a patch diff for review.
i can't build Marble to test these changes ATM though.

lubomir
--
From 79005f97063620f4f7da0d087a045f4f6da02d70 Mon Sep 17 00:00:00 2001
From: "Lubomir I. Ivanov" 
Date: Tue, 18 Apr 2017 00:36:17 +0300
Subject: [PATCH] MarbleDebug: use a custom QLoggingCategory

---
 src/lib/marble/MarbleDebug.cpp | 22 --
 src/lib/marble/MarbleDebug.h   | 12 +---
 2 files changed, 9 insertions(+), 25 deletions(-)

diff --git a/src/lib/marble/MarbleDebug.cpp b/src/lib/marble/MarbleDebug.cpp
index 5f53f6f..7ee9a4f 100644
--- a/src/lib/marble/MarbleDebug.cpp
+++ b/src/lib/marble/MarbleDebug.cpp
@@ -10,35 +10,21 @@
 
 #include "MarbleDebug.h"
 
-#include 
-#include 
+#include 
 
 namespace Marble
 {
-// bool MarbleDebug::m_enabled = true;
-bool MarbleDebug::m_enabled = false;
 
-QDebug mDebug()
-{
-if ( MarbleDebug::isEnabled() ) {
-return QDebug( QtDebugMsg );
-}
-else {
-static QFile *nullDevice = new QFile(QProcess::nullDevice());
-if ( !nullDevice->isOpen() )
- nullDevice->open(QIODevice::WriteOnly);
- return QDebug( nullDevice );
-}
-}
+Q_LOGGING_CATEGORY(category, "marble", QtDebugMsg)
 
 bool MarbleDebug::isEnabled()
 {
-return MarbleDebug::m_enabled;
+return category.isDebugEnabled();
 }
 
 void MarbleDebug::setEnabled(bool enabled)
 {
-MarbleDebug::m_enabled = enabled;
+category.setEnabled(QtDebugMsg, enabled);
 }
 
 } // namespace Marble
diff --git a/src/lib/marble/MarbleDebug.h b/src/lib/marble/MarbleDebug.h
index 74b71ae..03b2db4 100644
--- a/src/lib/marble/MarbleDebug.h
+++ b/src/lib/marble/MarbleDebug.h
@@ -12,12 +12,15 @@
 #define MARBLE_MARBLEDEBUG_H
 
 #include 
+#include 
 
 #include "marble_export.h"
 
 namespace Marble
 {
 
+Q_DECLARE_LOGGING_CATEGORY(category)
+
 /**
   * a class which takes all the settings and exposes them
   */
@@ -35,15 +38,10 @@ public:
  */
 static void setEnabled(bool enabled);
 
-private:
-static bool m_enabled;
-
 };
 
-/**
-  * a function to replace qDebug() in Marble library code
-  */
-MARBLE_EXPORT QDebug mDebug();
+// logging category
+#define mDebug qCDebug(Marble::category)
 
 } // namespace Marble
 
-- 
1.7.11.msysgit.0

//
// This file is part of the Marble Virtual Globe.
//
// This program is free software licensed under the GNU LGPL. You can
// find a copy of this license in LICENSE.txt in the top directory of
// the source code.
//
// Copyright 2009  Patrick Spendrin 
//

#include "MarbleDebug.h"

#include 

namespace Marble
{

Q_LOGGING_CATEGORY(category, "marble", QtDebugMsg)

bool MarbleDebug::isEnabled()
{
return category.isDebugEnabled();
}

void MarbleDebug::setEnabled(bool enabled)
{
category.setEnabled(QtDebugMsg, enabled);
}

} // namespace Marble
//
// This file is part of the Marble Virtual Globe.
//
// This program is free software licensed under the GNU LGPL. You can
// find a copy of this license in LICENSE.txt in the top directory of
// the source code.
//
// Copyright 2009  Patrick Spendrin 
//

#ifndef MARBLE_MARBLEDEBUG_H
#define MARBLE_MARBLEDEBUG_H

#include 
#include 

#include "marble_export.h"

namespace Marble
{

Q_DECLARE_LOGGING_CATEGORY(category)

/**
  * a class which takes all the settings and exposes them
  */
class MARBLE_EXPORT MarbleDebug
{
public:
/**
 * @brief isEnabled returns whether debug information output is generated
 */
static bool isEnabled();

/**
 * @brief setEnabled Toggle debug information output generation
 * @param enabled Set to true to enable debug output, false to disable
 */
static void setEnabled(bool enabled);

};

// logging category
#define mDebug qCDebug(Marble::category)

} // namespace Marble

#endif
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PATCH] MarbleDebug: don't use a class extending QIODevice as a null device

2017-04-17 Thread Thiago Macieira 
On segunda-feira, 17 de abril de 2017 14:41:13 PDT Lubomir I. Ivanov wrote:
> On 18 April 2017 at 00:18, Thiago Macieira  wrote:
> > On segunda-feira, 17 de abril de 2017 14:10:28 PDT Lubomir I. Ivanov 
wrote:
> >> i guess we could just do a:
> >> void MarbleDebug::setEnabled(bool enabled)
> >> {
> >> 
> >> Marble::loggingCategory.setEnabled(enabled);
> >> MarbleDebug::m_enabled = enabled;
> >> 
> >> }
> > 
> > I'd go a little further and drop the m_enabled variable completely. You
> > don't need it, let the bit in the QLoggingCategory variable keep the
> > state.
> > 
> > You'd have:
> > 
> > namespace MarbleDebug {
> > Q_LOGGING_CATEGORY(category, "marble", QtWarningMsg)
> > 
> > void setEnabled(bool enabled)
> > {
> > 
> > category.setEnabled(QtDebugMsg, enabled);
> > 
> > }
> > 
> > bool isEnabled()// do you even need this function?
> > {
> > 
> > return category.isDebugEnabled();
> > 
> > }
> > } //namespace MarbleDebug
> > 
> > This changes to the MarbleDebug namespace too.
> 
> thanks, i think i understand.
> 
> here are the updated Marble files and a patch diff for review.
> i can't build Marble to test these changes ATM though.

Looks good, so long as "Marble::category" isn't too generic a name.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PATCH] MarbleDebug: don't use a class extending QIODevice as a null device

2017-04-17 Thread Lubomir I. Ivanov 
On 18 April 2017 at 00:47, Thiago Macieira  wrote:
> On segunda-feira, 17 de abril de 2017 14:41:13 PDT Lubomir I. Ivanov wrote:
>> On 18 April 2017 at 00:18, Thiago Macieira  wrote:
>> > On segunda-feira, 17 de abril de 2017 14:10:28 PDT Lubomir I. Ivanov
> wrote:
>> >> i guess we could just do a:
>> >> void MarbleDebug::setEnabled(bool enabled)
>> >> {
>> >>
>> >> Marble::loggingCategory.setEnabled(enabled);
>> >> MarbleDebug::m_enabled = enabled;
>> >>
>> >> }
>> >
>> > I'd go a little further and drop the m_enabled variable completely. You
>> > don't need it, let the bit in the QLoggingCategory variable keep the
>> > state.
>> >
>> > You'd have:
>> >
>> > namespace MarbleDebug {
>> > Q_LOGGING_CATEGORY(category, "marble", QtWarningMsg)
>> >
>> > void setEnabled(bool enabled)
>> > {
>> >
>> > category.setEnabled(QtDebugMsg, enabled);
>> >
>> > }
>> >
>> > bool isEnabled()// do you even need this function?
>> > {
>> >
>> > return category.isDebugEnabled();
>> >
>> > }
>> > } //namespace MarbleDebug
>> >
>> > This changes to the MarbleDebug namespace too.
>>
>> thanks, i think i understand.
>>
>> here are the updated Marble files and a patch diff for review.
>> i can't build Marble to test these changes ATM though.
>
> Looks good, so long as "Marble::category" isn't too generic a name.
>

ok, i've renamed it to Marable::loggingCategory.

Stefan, could you please try building and running the attached patch?
you can toggle the debugging with MarbleDebug::setEnabled(true/false)
e.g. from the Subsurface source code.

lubomir
--
//
// This file is part of the Marble Virtual Globe.
//
// This program is free software licensed under the GNU LGPL. You can
// find a copy of this license in LICENSE.txt in the top directory of
// the source code.
//
// Copyright 2009  Patrick Spendrin 
//

#ifndef MARBLE_MARBLEDEBUG_H
#define MARBLE_MARBLEDEBUG_H

#include 
#include 

#include "marble_export.h"

namespace Marble
{

Q_DECLARE_LOGGING_CATEGORY(loggingCategory)

/**
  * a class which takes all the settings and exposes them
  */
class MARBLE_EXPORT MarbleDebug
{
public:
/**
 * @brief isEnabled returns whether debug information output is generated
 */
static bool isEnabled();

/**
 * @brief setEnabled Toggle debug information output generation
 * @param enabled Set to true to enable debug output, false to disable
 */
static void setEnabled(bool enabled);

};

// logging category
#define mDebug qCDebug(Marble::loggingCategory)

} // namespace Marble

#endif
//
// This file is part of the Marble Virtual Globe.
//
// This program is free software licensed under the GNU LGPL. You can
// find a copy of this license in LICENSE.txt in the top directory of
// the source code.
//
// Copyright 2009  Patrick Spendrin 
//

#include "MarbleDebug.h"

#include 

namespace Marble
{

Q_LOGGING_CATEGORY(loggingCategory, "marble", QtDebugMsg)

bool MarbleDebug::isEnabled()
{
return loggingCategory.isDebugEnabled();
}

void MarbleDebug::setEnabled(bool enabled)
{
loggingCategory.setEnabled(QtDebugMsg, enabled);
}

} // namespace Marble
From 4548472e15b3424c68d9099d67b2a97b36ebb643 Mon Sep 17 00:00:00 2001
From: "Lubomir I. Ivanov" 
Date: Tue, 18 Apr 2017 00:36:17 +0300
Subject: [PATCH] MarbleDebug: use a custom QLoggingCategory

---
 src/lib/marble/MarbleDebug.cpp | 22 --
 src/lib/marble/MarbleDebug.h   | 12 +---
 2 files changed, 9 insertions(+), 25 deletions(-)

diff --git a/src/lib/marble/MarbleDebug.cpp b/src/lib/marble/MarbleDebug.cpp
index 5f53f6f..57bc1c9 100644
--- a/src/lib/marble/MarbleDebug.cpp
+++ b/src/lib/marble/MarbleDebug.cpp
@@ -10,35 +10,21 @@
 
 #include "MarbleDebug.h"
 
-#include 
-#include 
+#include 
 
 namespace Marble
 {
-// bool MarbleDebug::m_enabled = true;
-bool MarbleDebug::m_enabled = false;
 
-QDebug mDebug()
-{
-if ( MarbleDebug::isEnabled() ) {
-return QDebug( QtDebugMsg );
-}
-else {
-static QFile *nullDevice = new QFile(QProcess::nullDevice());
-if ( !nullDevice->isOpen() )
- nullDevice->open(QIODevice::WriteOnly);
- return QDebug( nullDevice );
-}
-}
+Q_LOGGING_CATEGORY(loggingCategory, "marble", QtDebugMsg)
 
 bool MarbleDebug::isEnabled()
 {
-return MarbleDebug::m_enabled;
+return loggingCategory.isDebugEnabled();
 }
 
 void MarbleDebug::setEnabled(bool enabled)
 {
-MarbleDebug::m_enabled = enabled;
+loggingCategory.setEnabled(QtDebugMsg, enabled);
 }
 
 } // namespace Marble
diff --git a/src/lib/marble/MarbleDebug.h b/src/lib/marble/MarbleDebug.h
index 74b71ae..46bed7e 100644
--- a/src/lib/marble/MarbleDebug.h
+++ b/src/lib/marble/MarbleDebug.h
@@ -12,12 +12,15 @@
 #define MARBLE_MARBLEDEBUG_H
 
 #include 
+#include 
 
 #include "marble_export.h"
 
 namespace Marble
 {
 
+Q_DECLARE_LOGGING_CATEGORY(loggingCategory)
+
 /**
   * a class which takes all the settings and exposes them
   */
@@ -35,15 +38,10 @@ public:

Re: [PATCH] MarbleDebug: don't use a class extending QIODevice as a null device

2017-04-17 Thread Thiago Macieira 
On segunda-feira, 17 de abril de 2017 14:53:12 PDT Lubomir I. Ivanov wrote:
> Stefan, could you please try building and running the attached patch?
> you can toggle the debugging with MarbleDebug::setEnabled(true/false)
> e.g. from the Subsurface source code.

Or by setting in your environment:

QT_LOGGING_RULES=marble.debug=true

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Failing to connect to shearwater perdix on linux with subsurface

2017-04-17 Thread Robert Sevat 
Hello,

I am unable to setup a bluetooth connection with subsurface to my
shearwater perdix on linux. I've run out of troubleshooting ideas. Maybe
you guys have some pointers/ideas.
-
System information:
Arch linux 4.10.3-1-ARCH

Bluetooth package information:
bluez 5.44-1
bluez-utils-compat 5.44-1

Subsurface version: 4.6.3.235

Shearwater Perdix system info:
Features: 20080
Firmware: v44/BT04

Using the USB hardware bluetooth dongle that I got with the dive
computer. It's recognized correctly: [31281.452921] usb 3-1.6: new
full-speed USB device number 32 using ehci-pci

bluetooth service is running:
[robert@dt-rs ~]$ systemctl status bluetooth
● bluetooth.service - Bluetooth service
   Loaded: loaded (/usr/lib/systemd/system/bluetooth.service; disabled;
vendor preset: disabled)
   Active: active (running) since Tue 2017-04-18 00:04:20 CEST; 20min ago
 Docs: man:bluetoothd(8)
 Main PID: 24599 (bluetoothd)
   Status: "Running"
Tasks: 1 (limit: 4915)
   CGroup: /system.slice/bluetooth.service
   └─24599 /usr/lib/bluetooth/bluetoothd
-

I followed the guide in the faq (https://subsurface-divelog.org/faq/)
'How do I download dives from my Shearwater Petrel 2 (or other Bluetooth
dive computer) on Linux?'

All steps below are done while the dive computer is in it's 3 minute
countdown in which you can connect to it.

[robert@dt-rs]$ bluetoothctl -a
[NEW] Controller 00:1A:7D:DA:71:14 DT-RS [default]
[NEW] Device E2:70:EE:3B:89:1E Perdix
Agent registered
[bluetooth]# agent on
Agent is already registered
[bluetooth]# default-agent
Default agent request successful
[bluetooth]# scan on
Discovery started
[CHG] Controller 00:1A:7D:DA:71:14 Discovering: yes
[CHG] Device E2:70:EE:3B:89:1E RSSI: -66
[CHG] Device E2:70:EE:3B:89:1E RSSI: -75
[CHG] Device E2:70:EE:3B:89:1E RSSI: -67
[CHG] Device E2:70:EE:3B:89:1E RSSI: -77
[bluetooth]# trust E2:70:EE:3B:89:1E
[CHG] Device E2:70:EE:3B:89:1E Trusted: yes
Changing E2:70:EE:3B:89:1E trust succeeded
[CHG] Device E2:70:EE:3B:89:1E RSSI: -68
[bluetooth]# pair E2:70:EE:3B:89:1E
Attempting to pair with E2:70:EE:3B:89:1E
[CHG] Device E2:70:EE:3B:89:1E Connected: yes
[NEW] Primary Service
/org/bluez/hci0/dev_E2_70_EE_3B_89_1E/service000a
1801--1000-8000-00805f9b34fb
Generic Attribute Profile
[NEW] Primary Service
/org/bluez/hci0/dev_E2_70_EE_3B_89_1E/service000b
fe25c237-0ece-443c-b0aa-e02033e7029d
Vendor specific
[NEW] Characteristic
/org/bluez/hci0/dev_E2_70_EE_3B_89_1E/service000b/char000c
27b7570b-359e-45a3-91bb-cf7e70049bd2
Vendor specific
[NEW] Descriptor
/org/bluez/hci0/dev_E2_70_EE_3B_89_1E/service000b/char000c/desc000e
2902--1000-8000-00805f9b34fb
Client Characteristic Configuration
[NEW] Descriptor
/org/bluez/hci0/dev_E2_70_EE_3B_89_1E/service000b/char000c/desc000f
2901--1000-8000-00805f9b34fb
Characteristic User Description
[CHG] Device E2:70:EE:3B:89:1E UUIDs: 1800--1000-8000-00805f9b34fb
[CHG] Device E2:70:EE:3B:89:1E UUIDs: 1801--1000-8000-00805f9b34fb
[CHG] Device E2:70:EE:3B:89:1E UUIDs: fe25c237-0ece-443c-b0aa-e02033e7029d
[CHG] Device E2:70:EE:3B:89:1E ServicesResolved: yes
[CHG] Device E2:70:EE:3B:89:1E Paired: yes
Pairing successful
[Perdix]# info E2:70:EE:3B:89:1E
Device E2:70:EE:3B:89:1E
Name: Perdix
Alias: Perdix
Paired: yes
Trusted: yes
Blocked: no
Connected: yes
LegacyPairing: no
UUID: Generic Access Profile(1800--1000-8000-00805f9b34fb)
UUID: Generic Attribute Profile (1801--1000-8000-00805f9b34fb)
UUID: Vendor specific   (fe25c237-0ece-443c-b0aa-e02033e7029d)
RSSI: -68



So after successfully pairing I try to setup the RFCOMM connection.
(note it did not ask for a pin: , even though it's in 'AUTH' mode as
can be seen below in the hciconfig output)

[robert@dt-rs ~]$ sudo hciconfig
hci0:Type: Primary  Bus: USB
BD Address: 00:1A:7D:DA:71:14  ACL MTU: 310:10  SCO MTU: 64:8
UP RUNNING INQUIRY AUTH
RX bytes:41250 acl:48 sco:0 events:2165 errors:0
TX bytes:10476 acl:40 sco:0 commands:883 errors:0

[robert@dt-rs ~]$ sudo rfcomm -i hci0 connect /dev/rfcomm0
E2:70:EE:3B:89:1E
Can't connect RFCOMM socket: Host is down
[robert@dt-rs ~]$ sudo rfcomm -i hci0 connect /dev/rfcomm0
E2:70:EE:3B:89:1E 2
Can't connect RFCOMM socket: Host is down
[robert@dt-rs ~]$ sudo rfcomm -i hci0 connect /dev/rfcomm0
E2:70:EE:3B:89:1E 3
Can't connect RFCOMM socket: Host is down
[robert@dt-rs ~]$ sudo rfcomm -i hci0 connect /dev/rfcomm0
E2:70:EE:3B:89:1E 4
Can't connect RFCOMM socket: Host is down
[robert@dt-rs ~]$ sudo rfcomm -i hci0 connect /dev/rfcomm0
E2:70:EE:3B:89:1E 5
Can't connect RFCOMM socket: Host is down
[robert@dt-rs ~]$ sudo rfcomm -i hci0 connect /dev/rfcomm0
E2:70:EE:3B:89:1E 6
Can't connect RFCOMM socket: Host is down
[robert@dt-rs ~]$ sudo sdptool -i hci0 records E2:70:EE:3B:89:1E
Failed to connect to SDP server on E2:70:EE:3B

Re: Failing to connect to shearwater perdix on linux with subsurface

2017-04-17 Thread Rick Walsh 
Hi Robert,

On 18 Apr. 2017 11:59 am, "Robert Sevat"  wrote:

Hello,

I am unable to setup a bluetooth connection with subsurface to my
shearwater perdix on linux. I've run out of troubleshooting ideas. Maybe
you guys have some pointers/ideas.
-
System information:
Arch linux 4.10.3-1-ARCH

Bluetooth package information:
bluez 5.44-1
bluez-utils-compat 5.44-1

Subsurface version: 4.6.3.235

Shearwater Perdix system info:
Features: 20080
Firmware: v44/BT04

Using the USB hardware bluetooth dongle that I got with the dive
computer. It's recognized correctly: [31281.452921] usb 3-1.6: new
full-speed USB device number 32 using ehci-pci

bluetooth service is running:
[robert@dt-rs ~]$ systemctl status bluetooth
● bluetooth.service - Bluetooth service
   Loaded: loaded (/usr/lib/systemd/system/bluetooth.service; disabled;
vendor preset: disabled)
   Active: active (running) since Tue 2017-04-18 00:04:20 CEST; 20min ago
 Docs: man:bluetoothd(8)
 Main PID: 24599 (bluetoothd)
   Status: "Running"
Tasks: 1 (limit: 4915)
   CGroup: /system.slice/bluetooth.service
   └─24599 /usr/lib/bluetooth/bluetoothd
-

I followed the guide in the faq (https://subsurface-divelog.org/faq/)
'How do I download dives from my Shearwater Petrel 2 (or other Bluetooth
dive computer) on Linux?'


We should update the faq. Can you please try the "native bluetooth" method
in the user manual? It is much easier. The rfcomm method was necessary for
earlier versions of subsurface but is not very user friendly.

Now, hopefully that works. But it may not. My understanding is that it
should work with the original Perdix but more recent units and the Perdix
ai do not support ordinary bluetooth, only Bluetooth LE. Work is underway
to support BLE in subsurface but it's not there yet.


All steps below are done while the dive computer is in it's 3 minute
countdown in which you can connect to it.

[robert@dt-rs]$ bluetoothctl -a
[NEW] Controller 00:1A:7D:DA:71:14 DT-RS [default]
[NEW] Device E2:70:EE:3B:89:1E Perdix
Agent registered
[bluetooth]# agent on
Agent is already registered
[bluetooth]# default-agent
Default agent request successful
[bluetooth]# scan on
Discovery started
[CHG] Controller 00:1A:7D:DA:71:14 Discovering: yes
[CHG] Device E2:70:EE:3B:89:1E RSSI: -66
[CHG] Device E2:70:EE:3B:89:1E RSSI: -75
[CHG] Device E2:70:EE:3B:89:1E RSSI: -67
[CHG] Device E2:70:EE:3B:89:1E RSSI: -77
[bluetooth]# trust E2:70:EE:3B:89:1E
[CHG] Device E2:70:EE:3B:89:1E Trusted: yes
Changing E2:70:EE:3B:89:1E trust succeeded
[CHG] Device E2:70:EE:3B:89:1E RSSI: -68
[bluetooth]# pair E2:70:EE:3B:89:1E
Attempting to pair with E2:70:EE:3B:89:1E
[CHG] Device E2:70:EE:3B:89:1E Connected: yes
[NEW] Primary Service
/org/bluez/hci0/dev_E2_70_EE_3B_89_1E/service000a
1801--1000-8000-00805f9b34fb
Generic Attribute Profile
[NEW] Primary Service
/org/bluez/hci0/dev_E2_70_EE_3B_89_1E/service000b
fe25c237-0ece-443c-b0aa-e02033e7029d
Vendor specific
[NEW] Characteristic
/org/bluez/hci0/dev_E2_70_EE_3B_89_1E/service000b/char000c
27b7570b-359e-45a3-91bb-cf7e70049bd2
Vendor specific
[NEW] Descriptor
/org/bluez/hci0/dev_E2_70_EE_3B_89_1E/service000b/char000c/desc000e
2902--1000-8000-00805f9b34fb
Client Characteristic Configuration
[NEW] Descriptor
/org/bluez/hci0/dev_E2_70_EE_3B_89_1E/service000b/char000c/desc000f
2901--1000-8000-00805f9b34fb
Characteristic User Description
[CHG] Device E2:70:EE:3B:89:1E UUIDs: 1800--1000-8000-00805f9b34fb
[CHG] Device E2:70:EE:3B:89:1E UUIDs: 1801--1000-8000-00805f9b34fb
[CHG] Device E2:70:EE:3B:89:1E UUIDs: fe25c237-0ece-443c-b0aa-e02033e7029d
[CHG] Device E2:70:EE:3B:89:1E ServicesResolved: yes
[CHG] Device E2:70:EE:3B:89:1E Paired: yes
Pairing successful
[Perdix]# info E2:70:EE:3B:89:1E
Device E2:70:EE:3B:89:1E
Name: Perdix
Alias: Perdix
Paired: yes
Trusted: yes
Blocked: no
Connected: yes
LegacyPairing: no
UUID: Generic Access Profile(1800--1000-8000-00805f9b34fb)
UUID: Generic Attribute Profile (1801--1000-8000-00805f9b34fb)
UUID: Vendor specific   (fe25c237-0ece-443c-b0aa-e02033e7029d)
RSSI: -68



So after successfully pairing I try to setup the RFCOMM connection.
(note it did not ask for a pin: , even though it's in 'AUTH' mode as
can be seen below in the hciconfig output)

[robert@dt-rs ~]$ sudo hciconfig
hci0:Type: Primary  Bus: USB
BD Address: 00:1A:7D:DA:71:14  ACL MTU: 310:10  SCO MTU: 64:8
UP RUNNING INQUIRY AUTH
RX bytes:41250 acl:48 sco:0 events:2165 errors:0
TX bytes:10476 acl:40 sco:0 commands:883 errors:0

[robert@dt-rs ~]$ sudo rfcomm -i hci0 connect /dev/rfcomm0
E2:70:EE:3B:89:1E
Can't connect RFCOMM socket: Host is down
[robert@dt-rs ~]$ sudo rfcomm -i hci0 connect /dev/rfcomm0
E2:70:EE:3B:89:1E 2
Can't connect RFCOMM socket: Host is down
[robert@dt-rs ~]$ sudo rfcomm -i hci0 connect

Re: [PATCH] FAQ: update section on Bluetooth on Linux

2017-04-17 Thread Rick Walsh 
Can this be applied? Or something similar?

On 6 Apr. 2017 8:28 am, "Rick Walsh"  wrote:

> Setting up an RFCOMM connection has not been required for a long time.
>
> Reported-by: Stephen Hemminger 
> Signed-off-by: Rick Walsh 
> ---
>  Documentation/FAQ.wordpress | 115 ++
> --
>  1 file changed, 5 insertions(+), 110 deletions(-)
>
> diff --git a/Documentation/FAQ.wordpress b/Documentation/FAQ.wordpress
> index cd26f0d..1bc9c74 100644
> --- a/Documentation/FAQ.wordpress
> +++ b/Documentation/FAQ.wordpress
> @@ -124,116 +124,11 @@ Dive history is different than the dive profiles on
> the log. The history only ke
>  If you have downloaded your dives to different dive logging software
> before they were overwritten, there is a high change that Subsurface can
> import these. However, if the logs are only on your dive computer, they
> cannot be salvaged after being over written by new dives.
>
>  [/expand]
> -[expand title="How do I download dives from my Shearwater Petrel 2 (or
> other Bluetooth dive computer) on Linux?"]
> -
> -Setting up a connection to download dives from your Bluetooth-enabled
> device, such as the Shearwater Petrel, is not yet an automated process and
> will generally require the command prompt.  It is essentially a three step
> process.
> -
> -
> -Enable Bluetooth controller and pair your dive computer
> -Establish an RFCOMM connection
> -Download the dives with Subsurface
> -
> -
> -Users have reported difficulties with some Bluetooth controllers.  If you
> have an onboard controller, try that first.  It is simplest if you remove
> any USB Bluetooth dongles.  If you have a USB dongle that came with your
> dive computer, try that before any others.
> -
> -Make sure you know how to put your dive computer into upload mode.  On
> the Shearwater Petrel, Petrel 2 and Nerd, cycle through the menu, select
> 'Dive Log', then 'Upload Log'.  The display will read 'Initializing', then
> 'Wait PC 3:00' and will countdown.  Once the connection is established, the
> display reads 'Wait CMD ...' and the countdown continues.  When downloading
> the dive from Subsurface, the display reads 'Sending' then 'Sent Dive'.
> -
> -To establish the connection you need to have root access through sudo or
> su, and you will need to have the correct permissions on your system to
> download the dives.  On Fedora 22 and probably most other systems, this
> means becoming a member of the dialout group if you are not already.  This
> can be done graphically, or on the command terminal, enter:
> -sudo usermod -a -G dialout
> username
> -Log out and log in for the change to take effect.
> -
> -Enabling the Bluetooth controller and pairing your dive computer
> -You may be able to set up the Bluetooth controller and pair your dive
> computer using your distros graphical environment.  Once you've set your
> dive computer to upload mode, click the Bluetooth icon in the system tray
> and selecting 'Add new device'.  Your dive computer should appear.  If
> asked for a password, enter .  Write down or copy the MAC address of
> your dive computer - you'll need this later.  It should be in the form
> 00:11:22:33:44:55.
> -
> -If the graphical method didn't work, you need to pair the device from the
> command line.  Open a terminal and use hciconfig to check the Bluetooth
> controller status
> -hciconfig
> -hci0:   Type: BR/EDR  Bus: USB
> -BD Address: 01:23:45:67:89:AB  ACL MTU: 310:10  SCO MTU: 64:8
> -DOWN
> -RX bytes:504 acl:0 sco:0 events:22 errors:0
> -TX bytes:92 acl:0 sco:0 commands:21 errors:0
> -This tells you you have one controller, with MAC address
> 01:23:45:67:89:AB, connected as hci0.  Its status is 'DOWN', i.e. not
> powered.  Additional controllers will appear as hci1, etc.  If you didn't
> have a Bluetooth dongle plugged in when you booted your computer, hci0 is
> probably the onboard.  We need to power on the controller and enable
> authentication:
> -sudo hciconfig hci0 up auth
> -(enter password when prompted)
> -hciconfig
> -hci0:   Type: BR/EDR  Bus: USB
> -BD Address: 01:23:45:67:89:AB  ACL MTU: 310:10  SCO MTU: 64:8
> -UP RUNNING PSCAN AUTH
> -RX bytes:1026 acl:0 sco:0 events:47 errors:0
> -TX bytes:449 acl:0 sco:0 commands:46 errors:0
> -Check that the status now includes 'UP', 'RUNNING' AND 'AUTH'
> -
> -If there are multiple controllers running, it's easiest if you turn off
> the controller(s) you don't plan to use. E.g.
> -sudo hciconfig hci1 down
> -Next step is to 'trust' and 'pair' the dive computer.  On distros with
> Bluez 5, such as Fedora 22, you can use a tool called blutootctl, which
> will bring up its own command prompt.
> -bluetoothctl
> -[NEW] Controller 01:23:45:67:89:AB localhost.localdomain [default]
> -[bluetooth]# agent on
> -Agent registered
> -[bluetooth]# default-agent
> -Default agent request successful
> -[bluetooth]# scan on c

Re: Failing to connect to shearwater perdix on linux with subsurface

2017-04-17 Thread Linus Torvalds 
On Mon, Apr 17, 2017 at 3:28 PM, Robert Sevat  wrote:
>
> I am unable to setup a bluetooth connection with subsurface to my
> shearwater perdix on linux. I've run out of troubleshooting ideas. Maybe
> you guys have some pointers/ideas.

This looks like the BLE version (Bluetooth LE, aka 4.0), rather than rfcomm.

> [NEW] Primary Service
> /org/bluez/hci0/dev_E2_70_EE_3B_89_1E/service000a
> 1801--1000-8000-00805f9b34fb
> Generic Attribute Profile

The above looks very much like a GATT thing, not a rfcomm thing. Which
is how the BLE thing works, but we don't support it under Subsurface
yet.

> It fails to setup the RFCOMM connection on channels 1-6, nor is it able
> to lookup what channel it should be. It gets 'host is down'.

Yeah, there's no traditional RFCOMM there at all, afaik. So you
apparently have one of the newer Perdix ones that have new bluetooth.

   Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface