[TEST REQUEST] Windows Bluetooth LE build

Lubomir I. Ivanov neolit123 at gmail.com
Sat Jun 9 18:12:20 PDT 2018


On 10 June 2018 at 03:26, Dirk Hohndel <dirk at hohndel.org> wrote:
>
>> On Jun 9, 2018, at 4:59 PM, Linus Torvalds <torvalds at linux-foundation.org> wrote:
>>
>> On Sat, Jun 9, 2018 at 4:44 PM Lubomir I. Ivanov <neolit123 at gmail.com> wrote:
>>>
>>> @DC_VERSION@ = e97a47cca55973199715df0f818b4955e60d3a31
>>> that's due to dodging autotools on Windows.
>>
>> Hmm. You're missing the "Re-instate the lack of handshaking for the
>> Scubapro Aladin Sport Matrix" commit, but it doesn't matter for
>> anything else.
>>
>> I don't think the "echo" thing is from any serial line echo, I think
>> it's just that the dive computer is supposed to echo back the commands
>> to you as a kind of "ack" (well, _some_ dive computers do that, the
>> protocols are all different).
>
> Yes, I believe that is indeed the case. I no longer have a working OSTC,
> so I can't test that, but I will test my other BLE dive computers this afternoon.
>
>> So this is not a "you have to implement echo in the LE stack" issue.
>>
>> Your debug log doesn't actually have the IO that is done. That seems
>> to be a Qt issue. We ask for debug output, and some versions of Qt
>> will give that:
>>
>>        QLoggingCategory::setFilterRules(QStringLiteral("qt.bluetooth*
>> = true"));
>>
>> and others will apparently just ignore it.
>
> IIRC that depends on how Qt is built. Since Lubomir builds his own
> Qt for this purpose, we should be able to adjust this behavior
>

so i noticed that the "qt.bluetooth." output is missing in Subsurface:
this can be controlled in a couple of ways in Qt:
   QLoggingCategory::setFilterRules(QStringLiteral("qt.bluetooth*=true"));

or vai this env. variable:
   QT_LOGGING_RULES=qt.bluetooth*=true

both cases do not work for Subsurface with the same library (DLL) it
works with a standalone (e.g. hello-win32-ble) example in both release
and debug mode, so it must be something that Subsurface is doing that
prevents it.
i do not know what, maybe some of the qDebug() handling magic that we are doing.

it's probably best to not rely on it.

>> I wonder if we should just add data debugging to our
>> characteristcStateChanged() and characteristicWritten() functions,
>> just so that we'd get that packet output even when Qt doesn't do it.
>
> I think that would be smart especially for new BLE devices
>

i will add some debug output to these functions and re-upload.

lubomir
--


More information about the subsurface mailing list