Re: WebKit -> WebEngine
On Sun, 31 Oct 2021 at 21:20, Dirk Hohndel wrote: > > > On Oct 31, 2021, at 11:58 AM, Robert Helling wrote: > > thanks for the responses Dirk and Robert. i read the other threads to got more familiar with the rest of the problems with the Qt6 transition. > > For the time being, it shouldn’t be too much of a problem. I just have to > > reintroduce a number of #ifdefs to make the choice between WebEngine and > > WebKit optional depending on what is available for the system at hand. I > > just removed those as I was under the impression that the transition is a > > clear step forward. The transition does not add any functionality. I would > > only argue that it simplifies the printing logic quite a bit. > While I think that having the cleaner code would be a huge win - if we > completely lose Windows support (still our largest user group - but Android > is catching up), that would suck. And of course, eventually we'll have to transition to Qt 6 everywhere, including Windows, but we'll burn that bridge when we get there :/ having the #ifdefs and continuing to build for Windows using Qt5 + WebKit seems like an OK temporary solution here. as mentioned earlier, i can help with reviews. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: WebKit -> WebEngine
On Sun, 31 Oct 2021 at 17:12, Robert Helling wrote: > > HI everybody, > > I wanted to report on my progress in replacing Subsurface’s use of WebKit by > WebEngine. I had already done this in the part of the user manual, but as > this transition was only fragmentary at the time the corresponding code was > removed at a later point. > > So I reinserted it and also made quite some progress on the printing part. So > much that I want to share it with you at this point. You can find it at > > https://github.com/atdotde/subsurface/tree/webengineagain > > I removed a lot of code originally contributed by Gehad ElRobey as a GSoC > student in 2015 but what I have now appears to be a lot simpler to me. > > It still requires some cleaning up and there are a few things to fix. > Specifically, at the moment, the print preview is broken and there is a > mysterious empty page at the end of the print out. But I think the bulk of > the work is done and it is time more eyes should have a look. I particular I > would like to hear from Lubomir as he was the project’s mentor at the time > IIRC. > hi Robert. thank you for working on this. it was discussed in the past that the WebEngine change has to happen eventually, but i think i recall blockers outside of the usage in printing and user manual - e.g. build process, distribution? could be wrong, not remembering correctly. if that is not longer the case, great... overall, if the printing "stack" port is one-to-one with the old code and we are not introducing user visible regressions this seems fine. if you send a PR broken into relevant commits i can try to find time for review, but likely only code review, without building and testing locally. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Request for testers
On Tue, 23 Jun 2020 at 18:32, Jason Bramwell wrote: > > 4.9.6 seems to work fine when set to Auto but again instantly fails when set > to force LE. If i remove the pairing and retry it seems like it doesn’t even > try to communicate over the Bluetooth to re-establish the pairing whereas if > I revert to Auto then I get the pop-up asking if I want to accept the pairing > and download works. > > > > So no, the new test build is no more broken with Windows 10 than the existing > build when it comes to Bluetooth (as far as I am concerned). > thank you for confirming that we don't have a regression at least. as mentioned earlier, this could be due to a number of factors related to the native Windows BLE stack or your drivers. there isn't anything sensible that Subsurface can do about it for the time being. from my tests with BLE on Windows 10, both OSTC+ and Perdix AI worked but they required the interactions that i've listed in my previous email. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Request for testers
hello everyone, could you please try an older version of Subsurface such as: http://subsurface-divelog.org/downloads/subsurface-4.9.6.exe to ensure that it works for you and that the build change we are introducing here is not what is the cause for the BLE failures. note that you need to first uninstall the existing version of Subsurface before trying a new install. also note that the native Windows BLE backend that Subsurface uses has a number of issues which are out of our control. you must: - install the latest drivers for your device. - update Windows 10 to the latest version, older versions of Windows have issues / are unlikely to work. - use "force LE" when scanning for devices. - if a device fails to connect try to unpair it, pair again, try to download again. thank you for taking the time to test. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Perdix AI import error
>> yes, OSTC+ got quite stable after the latest Windows 10 updates. >> the Perdix AI still has problems with the native backend. On Sun, 10 Nov 2019 at 12:08, tormento wrote: > > Which brand/model of BT dongle? > without a dongle. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Perdix AI import error
On Sat, 9 Nov 2019 at 18:20, tormento wrote: > > OSTC uses BT LE as Perdix? > yes, OSTC+ got quite stable after the latest Windows 10 updates. the Perdix AI still has problems with the native backend. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Perdix AI import error
> I tried whatever kind of trick. the un-pair, pair trick works for me. make sure you have the latest BT chip drivers too. > I have no problem at all with Shearwater Cloud and that’s strange. The Shearwater Cloud is using a different Windows backend called Windows RT. Subsurface is using the native Windows backend. There is no way for us to fix that unless we re-write Subsurface as a Universal Windows Platform app in C#, which is no-go. Windows 10 needs to sort their flakiness for some chipsets on the native backend. For instance the OSTC+ with latest Windows 10, connected fine each time and does not need the un-pair, pair trick. lubomir -- On Sat, 9 Nov 2019 at 17:28, tormento wrote: > > I tried whatever kind of trick. > > I have no problem at all with Shearwater Cloud and that’s strange. > > If a Windows issue, how can it be solved or worked around? > > Alberto > > P.S I’d like to know if other Perdix have same issues. > > Il giorno sab 9 nov 2019 alle 15:12 Lubomir I. Ivanov > ha scritto: >> >> on Windows, try unpairing and pairing the Perdix before each downlioad >> from Subsurface. >> the status of the device in the Control Panel should turn from Paired >> to Connected if successful. >> please note, this is a Windows issue and not a Subsurface issue. >> >> lubomir >> -- >> >> On Mon, 4 Nov 2019 at 11:28, tormento wrote: >> > >> > Ok, I tried to download dive on another laptop with integrated BT with or >> > without dongle and don't work there too. >> > >> > In the meantime I have done it with newest Testflight build on iOS but I'd >> > like to be able to download from Windows version too. >> > >> > Alberto >> > >> > Il giorno sab 2 nov 2019 alle ore 07:48 Jef Driesen >> > ha scritto: >> >> >> >> On 2/11/19 07:41, tormento wrote: >> >> > I am getting errors while importing dives from Perdix AI with its BT >> >> > dongle (I >> >> > don't hava any other to try) while it's own software can import dives >> >> > correctly. >> >> > >> >> > I select choose Bluetooth mode, find the Perdix and save. >> >> > >> >> > When I try to import, I get: >> >> > >> >> > Connecting to BLE device >> >> > Connecting >> >> > >> >> > Then a error windows pops up with "Dive data import error". >> >> > >> >> > image.png >> >> > >> >> > The log tells: >> >> > >> >> > Subsurface: v4.9.3-242-g9c8fbe494db2, built with libdivecomputer >> >> > v0.7.0-devel-Subsurface-NG (426a39fc7378cac3f5b1d3983be38d56ab526e78) >> >> > INFO: Open: transport=32 >> >> > INFO: Configure: baudrate=115200, databits=8, parity=0, stopbits=0, >> >> > flowcontrol=0 >> >> > INFO: Timeout: value=3000 >> >> > INFO: Sleep: value=300 >> >> > INFO: Purge: direction=3 >> >> > INFO: Write: size=11, data=0100FF0105002E902000C0 >> >> > >> >> > No .bin is generated. >> >> >> >> Uncheck the "Save libdivecomputer dumpfile" checkbox. The Shearwater >> >> Perdix AI >> >> communication protocol doesn't support memory dumps. Trying to download a >> >> memory >> >> dump will always fail with DC_STATUS_UNSUPPORTED. >> >> >> >> For the diagnostics purposes, the log file is sufficient for these models. >> >> >> >> Jef >> > >> > ___ >> > subsurface mailing list >> > subsurface@subsurface-divelog.org >> > http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface > > ___ > subsurface mailing list > subsurface@subsurface-divelog.org > http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Perdix AI import error
on Windows, try unpairing and pairing the Perdix before each downlioad from Subsurface. the status of the device in the Control Panel should turn from Paired to Connected if successful. please note, this is a Windows issue and not a Subsurface issue. lubomir -- On Mon, 4 Nov 2019 at 11:28, tormento wrote: > > Ok, I tried to download dive on another laptop with integrated BT with or > without dongle and don't work there too. > > In the meantime I have done it with newest Testflight build on iOS but I'd > like to be able to download from Windows version too. > > Alberto > > Il giorno sab 2 nov 2019 alle ore 07:48 Jef Driesen > ha scritto: >> >> On 2/11/19 07:41, tormento wrote: >> > I am getting errors while importing dives from Perdix AI with its BT >> > dongle (I >> > don't hava any other to try) while it's own software can import dives >> > correctly. >> > >> > I select choose Bluetooth mode, find the Perdix and save. >> > >> > When I try to import, I get: >> > >> > Connecting to BLE device >> > Connecting >> > >> > Then a error windows pops up with "Dive data import error". >> > >> > image.png >> > >> > The log tells: >> > >> > Subsurface: v4.9.3-242-g9c8fbe494db2, built with libdivecomputer >> > v0.7.0-devel-Subsurface-NG (426a39fc7378cac3f5b1d3983be38d56ab526e78) >> > INFO: Open: transport=32 >> > INFO: Configure: baudrate=115200, databits=8, parity=0, stopbits=0, >> > flowcontrol=0 >> > INFO: Timeout: value=3000 >> > INFO: Sleep: value=300 >> > INFO: Purge: direction=3 >> > INFO: Write: size=11, data=0100FF0105002E902000C0 >> > >> > No .bin is generated. >> >> Uncheck the "Save libdivecomputer dumpfile" checkbox. The Shearwater Perdix >> AI >> communication protocol doesn't support memory dumps. Trying to download a >> memory >> dump will always fail with DC_STATUS_UNSUPPORTED. >> >> For the diagnostics purposes, the log file is sufficient for these models. >> >> Jef > > ___ > subsurface mailing list > subsurface@subsurface-divelog.org > http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Development Questions
>> As far as I can see the options are build under WSL using the MinGW, or >> with MXE cross compile under a standard Linux box. > I strongly advise against native builds. I believe we still have only one > person who successfully did that. It's insanely painful. The container MXE > builds on the other hand are really straight forward. +1 >> Any etiquette for proposing changes etc. I should know about beyond sign-off >> lines with pull requests? > Smaller things are fine as pull request. For bigger or more fundamental > changes I always suggest an email to the developer mailing list, first. A few > areas have informal owners and it makes sense to get their take before > spending time on something they'll reject... yep, PRs should be scoped and if they contain multiple commits the commits should make scoped changes too. also PRs/commits should have detailed descriptions. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Facebook integration - I'm considering to completely remove this feature
PSA: i've sent a PR to remove the Facebook feature from Subsurface: https://github.com/Subsurface-divelog/subsurface/pull/1958 lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Subsurface 4.8.5 and Subsurface-mobile 2.1.6 soon
On Thu, 24 Jan 2019 at 14:42, Jan Mulder wrote: >> > So, I did a second Windows 8 try using my OSTC3. Configure DC works > "always" when connecting over BT, but fails over BLE. Download sort of > works. Sort of, as it sometimes succeeds and sometimes fails. I cannot > really tell which way the data came in (which is related to my issue on > GitHub #1891). But maybe that Windows 8 machine is not recent enough to > work properly under BLE. > yep, in fact Windows 10 (10.0.17134) is the minimum version that is somehow stable. status update: - installer: http://subsurface-divelog.org/downloads/test/subsurface-4.8.4-66-g2b9da3504b05.exe - windows 10 version 10.0.17134.523 - latest BT(LE) drivers from motherboard vendor - Perrdix AI needs removing the device and adding it back again but download work consistently after doing that every time. - OSTC+ stable, works first try with no reconnect needed. seems like Subsurface is a non-factor for BTLE Windows failures at this point. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: PING: Subsurface-mobile user manual
hi, On Fri, 30 Nov 2018 at 21:47, Willem Ferguson wrote: > > > I am working with the mobile user manual. A question: > thanks, Willem! > When selecting the Map option from the main menu, a world map is > presented. But, on my Android machine, no dive sites are shown. It is as > if no dives are selected. But I do not think dives can be selected from > the mobile dive list, only dive trips. So I am not sure what the map > should show. What is the intended behaviour? > dives should be shown without selection from "Map" as long as they have GPS data. just tried it on the latest mobile build (for desktop) - see attachment. some things to check: 1) check if the map is zoomed in enough. 2) check if the dives have GPS data. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: latest Windows build
the map works for me for me using the -339 installer. had to temp disable my local Qt setup to make sure that DLLs are picked from the installer properly. On Wed, 14 Nov 2018 at 12:36, Dirk Hohndel wrote: > > On Wed, Nov 14, 2018 at 11:02:37AM +0100, Jan Mulder wrote: > > On 14-11-2018 09:30, Dirk Hohndel wrote: > > > > > > I know that a couple of you have access to BLE dive computers and Windows > > > machines. I'd really appreciate if you could give this latest installer a > > > try: > > > > > > http://subsurface-divelog.org/downloads/test/subsurface-4.8.3-339-g5963a15bbd84.exe > > > > I did a quick test on a Windows 8.1 box. The good news is that I managed to > > download (once) from my OSTC3 over BLE, but it was a painful experience. Got > > numerous failing sessions, and after I re-paired the DC, I was able to to > > the successful download, but only once. Interestingly, download over BT was > > unstable as well. I know that the OSTC can get in some sort of undefined > > state when trying BT and BLE right after each other, so drawing firm > > conclusions from my attempt does not seem right. > > Given that this is only supposed to work on Windows 10 (latest) I'm rather > surprised that you got it to download on 8.1 at all. > And yes, Lubomir also is running into BLE issues with his OSTC, even on > Windows 10. > > So to me this is actually fairly good news. It means that I bundled the > correct libraries and that it tries to download from BLE in the first > place. > > I hope someone else is able to test on Windows 10 with one of the "easier" > dive computers (I guess Shearwater Teric/Pedix AI or Scubapro G2 - I'm not > sure if anyone has been able to even pair a Suunto EON Steel/Core with > Windows so far...) > i never tested < 10. the Windows drivers are super flaky and it requires the latest Windows 10 update. also it required the latest drivers for my MB chip vendor. i can download from both OSTC+ and Perdix AI, but they do still need the regular un-pair / pair pattern. discussions about Windows 10 are pointing out that this will be further improved in future updates. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Windows build(s) for 4.8.4
On Tue, 13 Nov 2018 at 22:47, Dirk Hohndel wrote: > > > On Nov 13, 2018, at 6:20 AM, Lubomir I. Ivanov wrote: > > On Tue, 13 Nov 2018 at 15:40, Dirk Hohndel wrote: > > > On Tue, Nov 13, 2018 at 06:34:29PM +0800, Dirk Hohndel wrote: > > > According to https://github.com/mxe/mxe/issues/2070 there is at least one > project that managed to get QtWebKit to build with MXE - but from what I > can tell this must have been on W64. Which made me wonder if it made sense > for us to have two Windows binaries... a 32bit binary without BLE support, > based on Qt 5.9 (just like the last one). And a 64bit binary, hopefully > with both BLE and QtWebKit support. After all, BLE requires the latest > Windows 10 and no one in their right mind is running this in 32bit mode, > right? > > > I spoke too soon. I can't get this to work at all, so still no QtWebKit > for Qt 5.10 or later under MXE :-( > > > i guess we have the option to wait until Qt and MXE goes back to > QtWebKit officially. > such a build will have both BLE and QtWebkit for Windows? > > what i really wanted us to have, even if we don't release official / > experimental BLE support for Windows soon, is to have a Windows BLE > installer that i can point users to so that they can test their DCs. > right now i have to point them either to an old version (was it -46) > or to my own build which is super haxored and even lacks QImage > support. > > if -46 is sufficient for this we can continue recommending it. > > > I really want a 4.8.4 build to point people to. > I need to go back and see how I created -46. Does it have maps? > so -46 is not the correct one, sorry. it was -17. maps work for it and also just tested and it downloads dives from the Perdix AI (BTLE) too. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Windows build(s) for 4.8.4
On Tue, 13 Nov 2018 at 15:40, Dirk Hohndel wrote: > > On Tue, Nov 13, 2018 at 06:34:29PM +0800, Dirk Hohndel wrote: > > > > According to https://github.com/mxe/mxe/issues/2070 there is at least one > > project that managed to get QtWebKit to build with MXE - but from what I > > can tell this must have been on W64. Which made me wonder if it made sense > > for us to have two Windows binaries... a 32bit binary without BLE support, > > based on Qt 5.9 (just like the last one). And a 64bit binary, hopefully > > with both BLE and QtWebKit support. After all, BLE requires the latest > > Windows 10 and no one in their right mind is running this in 32bit mode, > > right? > > I spoke too soon. I can't get this to work at all, so still no QtWebKit > for Qt 5.10 or later under MXE :-( > i guess we have the option to wait until Qt and MXE goes back to QtWebKit officially. such a build will have both BLE and QtWebkit for Windows? what i really wanted us to have, even if we don't release official / experimental BLE support for Windows soon, is to have a Windows BLE installer that i can point users to so that they can test their DCs. right now i have to point them either to an old version (was it -46) or to my own build which is super haxored and even lacks QImage support. if -46 is sufficient for this we can continue recommending it. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: working towards 4.8.4 and 2.1.5
On Thu, 1 Nov 2018 at 16:38, Dirk Hohndel wrote: > - figure out what's wrong with the Windows builds an BT/BLE (apparently at > least the Travis binaries don't use the correct BT DLL) > should we announce BTLE / Windows in release notes and / or the announcement body? my vote would be yes with outlining "experimental". that video i did is out of date, but perhaps we can create just a gist or pastebin with some instructions? i can also record another video? instructions: -- - Make sure you have the latest Windows 10 update. - Make sure you have the latest BTLE drivers for you PC or BTLE dongle. - Make sure that your BTLE dive computer is paired in Control Panel. - If connectivity from Subsurface to the BTLE device fails, try unpairing and pairing again. -- lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: who can test what...
On Wed, 10 Oct 2018 at 00:43, Dirk Hohndel wrote: > > On Tue, Oct 09, 2018 at 10:26:53PM +0200, Salvador Cuñat wrote: > > > > > > > > > I can test on Linux, Windows and Android, but just build on linux as I > > > > don't have a building environment set on Windows. > > > > > > So since a couple people have said this, just to repeat what I said in a > > > different thread... with current master building for Windows locally is as > > > easy as > > > > > Yes, yes, I use to cross build on mxe, I'd just thought you meant > > native building which seems only possible for Lubomir :-) > > Correct. I believe Lubomir is still the only person ever to get the native > build to actually work. > > He's special :-) > containers FTW, i guess. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [BLE] Windows 10 status update
On Tue, 9 Oct 2018 at 05:19, Linus Torvalds wrote: > > On Mon, Oct 8, 2018 at 6:33 PM Lubomir I. Ivanov wrote: > > > > the solution that the user suggests is to get a BLE dongle. not a good > > option for the end user. > > Actually, it's probably a reasonable option. > > iirc, the Shearwater actually *came* with a dongle, exactly because > Windows bluetooth is so flaky. I suspect Dirk just didn't think to > bring it with him. > > See for example > > https://www.shearwater.com/bluetooth-quick-start/ > > also, bluetooth dongles are actually pretty cheap. You can find ones > that do BLE for $6.99 on Amazon, and a few slightly better ones for > not much more (I have the Plugable one, for example, which sells for > $12.95). > > The biggest problem is to make sure the dongle really does BLE and has > a good driver, because there are some low-end things that only do > traditional BT, and apparently a number of garbage things that have > bad drivers. > > Also, range for the dongles seems to be pretty pitiful. > > But for people with thousand-dollar dive computers that do bluetooth, > having to buy a $10 dongle is probably pretty acceptable. > thanks, i will try getting a BLE dongle. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
[BLE] Windows 10 status update
observations after testing the Shearwater Perdix AI on Windows 1010.0.17134 https://en.wikipedia.org/wiki/Windows_10_version_history#Version_1803_(April_2018_Update) - i think i found a way to pair and connect the device consistently, so that i can initialize a download for dives. it simply requires a lot of trial and error and pairing / unpairing, due to flakyness. once looking at the list of Bluetooth devices in the Control Panel - the device has to be in "connected" state for it to receive GATT operations otherwise it would just fail with a GATT operation timeout. - i'm observing a random 20 / 30 / 40 second disconnect of the device once the "Start Bluetooth" screen from the device was started. this drops the download of dives or any other operations as the device simply disconnects for no apparent reason. - the same disconnect is not observable on the OSTC+. for the OSTC+ once the "Start Bluetooth" screen is entered from the device it stays connected until the screen is Exited or until and error or the FF command is received. - i have tried both official software packages that Shearwater distributes: - Shearwater Desktop - completely fails to discover the device. does not matter if it's paired, connected or unpaired. - Shearwater Cloud - this software discovers the DC and connects to it, but then fails for the same X seconds disconnect reason while downloading the dives. - found a related issue: https://social.msdn.microsoft.com/Forums/en-US/a60e63cb-1a78-4791-9702-f79c01700ffd/windows-10-creators-update-disconnects-ble-connection-after-2030-seconds-for-no-reason?forum=wdk the solution that the user suggests is to get a BLE dongle. not a good option for the end user. - i have tried googling further for this thinking about power saving settings and such, trying to find something that is causing the device to disconnect, to no avail. the laptop is always connected to power while testing. - i have tried writing a custom application that tries to "keep-alive" the connection by having a worker thread running that consistently enumerates the list of characteristics for the service of interest. wrote the same app in C++, C# and UWP form with the same results. tried googling for similar solutions, to no avail. - tried connecting to the device using by Android phone and nRF Connect. the result is that the device does not auto disconnect while the timer is still running, which makes it clear that the device is working. this leaves me in a bit of a checkmate situation. i did notice great improvements in discovery and pairing after the 1010.0.17134 update, but i cannot update this version of Windows further to see if the latest fixes the issues. ** options left to try: - i've noticed that toggling the notifications via the descriptor does reset the timer, so i can try having that in a worker thread to keep-alive the connect, but it might simply not prevent the disconnect, or it might even reset the download or cause it to error in a case where a characteristic does not receive a packet properly. quite skeptical about this one. - update Windows... - contact Shearwater support... lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: BT_SUPPORT
On Mon, 8 Oct 2018 at 21:31, Dirk Hohndel wrote: > > > Now that we have either BT or BLE support on all platforms, I wonder if it's > still worth > maintaining all the ifdefs around the code to allow us to compile without BT. > I'm just > not sure I see the value... certainly all of our builds are BT-enabled. > > Thoughts? > i'm on the fence, leaning towards removing them. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Wed, 3 Oct 2018 at 01:38, Steve wrote: > > Subject: Re: [TEST REQUEST] Windows Bluetooth LE build > > hello, > Ok I gave the new program a go on the Petrel2Ext but it is saying it doesn't > support BTLE? > > It should be the first Petrel I tried but I haven't had coffee yet so I tried > the other one that I no longer have just in case I picked the wrong address. > > device # 1 > addr: "00:13:43:0C:65:AC" > name: "Petrel" > coreConfiguration: QFlags(0x2) it detected the Petrel as BT device not BTLE; this is what the 0x2 means. if it supports both BT and BTLE it should be (0x1 | 0x2) or 0x1 or 0x3. does this device support BTLE? if yes, could you please try a couple of things: - try scanning for the BTLE device again from the Windows Control Panel? - try this new build of Subsurface once you have a paired BTLE computer: https://www.dropbox.com/s/zslq3ughx9ciehj/_deploy_win32_ble.zip?dl=0 the new program can also be used point if the device is detected as BT / BTLE. thanks lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Tue, 2 Oct 2018 at 05:27, Lubomir I. Ivanov wrote: > > On Mon, 1 Oct 2018 at 16:17, Dirk Hohndel wrote: > > > > > > > On Sep 30, 2018, at 6:40 PM, Lubomir I. Ivanov > > > wrote: > > >> > > >> Rebooted. Nothing else running, just the cmd.exe > > >> > > >> Same output - semaphore timeout period has expired. > > >> > > > > > ...but something else here, the Qt code is doing everything correctly > and i cannot blame it, at this point. > for now i can only blame Windows' BT support and BT as a whole. > yeah...the pairing process is super broke and unreliable via the Windows Control Panel UI. at this point i'm tempted to go with a helper C# app that does the pairing for the sake of avoiding the above UI. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Mon, 1 Oct 2018 at 16:17, Dirk Hohndel wrote: > > > > On Sep 30, 2018, at 6:40 PM, Lubomir I. Ivanov wrote: > >> > >> Rebooted. Nothing else running, just the cmd.exe > >> > >> Same output - semaphore timeout period has expired. > >> > > did some more testing here. my phone's BT is off all the time, i don't anything to use it with. i'm able to reproduce this error if i pair and connect my phone using NRF Connect with the DC, and then try to connect and write a descriptor using the qt-bt-discovery.exe app. to get out of this scenario i disconnect from the NRF Connect app. at this point qt-bt-discovery.exe writes the descriptor correctly. but this is not consistent - it can lead into all sorts of weird conditions, like: - writing the descriptor from the .EXE app disconnects the phone. - if the phone is disconnected after that, it can no longer connect to the device and the phone BT has to be turned off/on. - if the phone "takes ownership" of the device, the Windows BT has to be turned off/on, but then it decides to forget the the DC 50% of the time. - rediscovering the device in Windows might fail to pair or the discovery process even crashes - OS restart is required. this proves to me that there are ownership issues here, but also that the whole process is quite unreliable. so if another device other than the Windows laptop is connected to the DC, writing to a service will simply fail with the semaphore error and there would be no other indication. could you try turning all suspect local devices off for such a test? ...but something else here, the Qt code is doing everything correctly and i cannot blame it, at this point. for now i can only blame Windows' BT support and BT as a whole. > Also, how do I quit the program? Ctrl-C doesn't appear to work. All I can > figure out is kill the cmd.exe. > That doesn't seem like the right way to do this :-) > i have updated the test app to now properly exit on ctrl+c: https://www.dropbox.com/s/ehkoklydtnrvzxg/_qt-bt-discovery.zip?dl=0 lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Mon, 1 Oct 2018 at 16:17, Dirk Hohndel wrote: > > > > On Sep 30, 2018, at 6:40 PM, Lubomir I. Ivanov wrote: > >> > >> Rebooted. Nothing else running, just the cmd.exe > >> > >> Same output - semaphore timeout period has expired. > >> > > > > side questions: > > - does random addresses set to off make a difference? > > No, I seem to get the same results. > > > - is that the correct descriptor to enable notifications? > > > > Yes. > > Also, how do I quit the program? Ctrl-C doesn't appear to work. All I can > figure out is kill the cmd.exe. > That doesn't seem like the right way to do this :-) > sorry, i seem to be out of ideas at this point. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Mon, 1 Oct 2018 at 16:17, Dirk Hohndel wrote: > > > > On Sep 30, 2018, at 6:40 PM, Lubomir I. Ivanov wrote: > >> > >> Rebooted. Nothing else running, just the cmd.exe > >> > >> Same output - semaphore timeout period has expired. > >> > > > > side questions: > > - does random addresses set to off make a difference? > > No, I seem to get the same results. > > > - is that the correct descriptor to enable notifications? > > > > Yes. > > Also, how do I quit the program? Ctrl-C doesn't appear to work. All I can > figure out is kill the cmd.exe. > That doesn't seem like the right way to do this :-) > was too tired to add proper handling of the second thread. can be started from explorer too and closed with the [x]. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Mon, 1 Oct 2018 at 04:24, Dirk Hohndel wrote: > > > > On Sep 30, 2018, at 6:20 PM, Dirk Hohndel wrote: > >> this comes directly from the Windows GATT backend for writing descriptors. > >> https://docs.microsoft.com/en-us/windows/desktop/api/bluetoothleapis/nf-bluetoothleapis-bluetoothgattsetdescriptorvalue > >> > >> ERROR_SEM_TIMEOUT can happen in a case where the service path is > >> already opened in another process and this process has acquired an > >> exclusive lock on the path. > >> for instance, this can happen if i start BLE Explorer, connect to the > >> same device and start changing values in a service. then run the > >> qt-bt-discovery test app and try to do the same while both apps are > >> running. > > > > OK, I don't have BLE Explorer. I do have the settings app open, though. > > And I am not 100% sure if I maybe had Subsurface open as well - but > > that shouldn't have been in BLE mode. > > > > Let me reboot again to make sure nothing else is running and try from there > > Rebooted. Nothing else running, just the cmd.exe > > Same output - semaphore timeout period has expired. > side questions: - does random addresses set to off make a difference? - is that the correct descriptor to enable notifications? lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Mon, 1 Oct 2018 at 04:24, Dirk Hohndel wrote: > > > On Sep 30, 2018, at 6:20 PM, Dirk Hohndel wrote: > >> this comes directly from the Windows GATT backend for writing descriptors. > >> https://docs.microsoft.com/en-us/windows/desktop/api/bluetoothleapis/nf-bluetoothleapis-bluetoothgattsetdescriptorvalue > >> > >> ERROR_SEM_TIMEOUT can happen in a case where the service path is > >> already opened in another process and this process has acquired an > >> exclusive lock on the path. > >> for instance, this can happen if i start BLE Explorer, connect to the > >> same device and start changing values in a service. then run the > >> qt-bt-discovery test app and try to do the same while both apps are > >> running. > > > > OK, I don't have BLE Explorer. I do have the settings app open, though. > > And I am not 100% sure if I maybe had Subsurface open as well - but > > that shouldn't have been in BLE mode. > > > > Let me reboot again to make sure nothing else is running and try from there > > Rebooted. Nothing else running, just the cmd.exe > > Same output - semaphore timeout period has expired. > about reboot - i think if left for a while it hybernates and if brought up, it's not a real shutdown or reboot as it restores state from RAM. StartMenu -> Restart should act like a real reboot. do you have Shearwater software installed on this machine? my other guess is that the software in question might be running a background process or a service, that potentially can acquire a lock on the GATT services. GATT services are just paths in virtual filesystem, so services are opened with the CreateFile API. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Mon, 1 Oct 2018 at 03:38, Dirk Hohndel wrote:
>
> The crazy thing is that this morning I successfully downloaded from this very
> dive computer. And I have not the faintest clue what I have changed. I have
> gone back to the same binary that I am pretty sure is the one that I used…
> doesn’t work.
>
>
has the machine been restarted since the morning?
>
> First we have this:
>
> qt.bluetooth.windows: Unable to get value for characteristic
> "{27b7570b-359e-45a3-91bb-cf7e70049bd2}" of the service
> "{fe25c237-0ece-443c-b0aa-e02033e7029d}" : "No attribute found within the
> given attribute handle range."
>
>
this can happen in a case where a characteristic is WriteOnly.
the Qt stack tries to pre-populate values of a all characteristics in
a map when it discovers them, but it would still complain if it cannot
obtain a value of a WriteOnly char.
this can be improved in the Qt stack, but for now we can ignore it as
it's not critical.
>
> And then the whole “semaphore timeout period has expired” thing…
>
this comes directly from the Windows GATT backend for writing descriptors.
https://docs.microsoft.com/en-us/windows/desktop/api/bluetoothleapis/nf-bluetoothleapis-bluetoothgattsetdescriptorvalue
ERROR_SEM_TIMEOUT can happen in a case where the service path is
already opened in another process and this process has acquired an
exclusive lock on the path.
for instance, this can happen if i start BLE Explorer, connect to the
same device and start changing values in a service. then run the
qt-bt-discovery test app and try to do the same while both apps are
running.
lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Sun, 30 Sep 2018 at 20:28, Dirk Hohndel wrote: > > > > On Sep 30, 2018, at 10:23 AM, Lubomir I. Ivanov wrote: > > > > i think you've mentioned that only the Shearwater DCs worked. > > based on the conversation history, i don't think the Teric worked yet. > > The Teric is the Shearwater Teric :-) > > I have been testing with three dive computers so far > > Shearwater Petrel (BT classic only) > Shearwater Perdix AI (BLE only) > Shearwater Teric (BLE only) > > my other BLE dive computer (Suunto EON Steel) tries very hard > to be invisible and requires some trickery to pair to - I haven't > figured out how to do this on Windows. > this link contains updated testing app for the WIN32 BLE stack: https://www.dropbox.com/s/ehkoklydtnrvzxg/_qt-bt-discovery.zip?dl=0 using this app i can: 1) discover the OSTC+ 2) list it's services 3) list characteristics and descriptors for a service 4) it has a prompt that asks if you want to write / read descriptors / characteristics - using the prompt i can enable notifications by writing 0100 to a certain descriptor. - i can then enter the dive computer into download mode by writing BB to a certain characteristic. this app can be used to debug if the Qt WIN32 stack works for the devices we are having problems with. next step would be to attach libdivecomputer to this and debug a complete download, but i'm not sure where i would have the time to do that. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Sun, 30 Sep 2018 at 20:28, Dirk Hohndel wrote: > > On Sep 30, 2018, at 10:23 AM, Lubomir I. Ivanov wrote: > > > > i think you've mentioned that only the Shearwater DCs worked. > > based on the conversation history, i don't think the Teric worked yet. > > The Teric is the Shearwater Teric :-) > > I have been testing with three dive computers so far > > Shearwater Petrel (BT classic only) > Shearwater Perdix AI (BLE only) > Shearwater Teric (BLE only) > oh, they are the same brand...that figures. > my other BLE dive computer (Suunto EON Steel) tries very hard > to be invisible and requires some trickery to pair to - I haven't > figured out how to do this on Windows. > we have the option to contact Suunto with some questions for this one. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Sun, 30 Sep 2018 at 19:11, Dirk Hohndel wrote: > > On Sep 30, 2018, at 9:05 AM, Lubomir I. Ivanov wrote: > > > > Subsurface from that installer downloaded the dives successfully from > > the OSTC+ in BTLE mode. > > Nice. > > > which DC and which operation broke - discovery, connection or perhaps > > download? > > My two Shearwater DCs and it's the download. I wonder if I fat fingered > removing the > random address thing. Because it discovers them correctly, it just doesn't > connect > to them (just where I was last night). > > Having breakfast, then I'll play with it some more. > you can also try the small testing app i've sent with the Shearwater DCs. it doesn't use random addresses, just a plain ->connect(). lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Sun, 30 Sep 2018 at 18:58, Dirk Hohndel wrote: > > > > On Sep 30, 2018, at 8:55 AM, Lubomir I. Ivanov wrote: > > > > On Sun, 30 Sep 2018 at 18:33, Dirk Hohndel wrote: > >> > >> Patches pushed to master. New Windows installer is up here: > >> > > > > minor nit: disabling the random addresses here on Windows: > > https://github.com/Subsurface-divelog/subsurface/commit/0422cd3662e8e890887f38c2a7e718195ebcb601#diff-ab43016677a714cafdf4c151ebf6dcb2R408 > > > > would also require to #ifdef `use_random_address()` otherwise it will > > have an unused warning. > > > > the patch that removes the WinBluetoothDeviceDiscoveryAgent usage > > seems good to me. > > > >> http://subsurface-divelog.org/downloads/test/subsurface-4.8.3-17-g53341c037d5a.exe > >> > > > > i will try this installer on Windows 10, just in case. > > Feel free, but even switching back to Qt 5.11 didn't make it work for me. > Which means that I broke something in my cleanup. Which sucks. > > But at least we know we are close. :-/ > Subsurface from that installer downloaded the dives successfully from the OSTC+ in BTLE mode. which DC and which operation broke - discovery, connection or perhaps download? lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Sun, 30 Sep 2018 at 18:33, Dirk Hohndel wrote: > > Patches pushed to master. New Windows installer is up here: > minor nit: disabling the random addresses here on Windows: https://github.com/Subsurface-divelog/subsurface/commit/0422cd3662e8e890887f38c2a7e718195ebcb601#diff-ab43016677a714cafdf4c151ebf6dcb2R408 would also require to #ifdef `use_random_address()` otherwise it will have an unused warning. the patch that removes the WinBluetoothDeviceDiscoveryAgent usage seems good to me. > http://subsurface-divelog.org/downloads/test/subsurface-4.8.3-17-g53341c037d5a.exe > i will try this installer on Windows 10, just in case. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Sun, 30 Sep 2018 at 08:56, Dirk Hohndel wrote:
>
> Latest test binary:
>
> http://subsurface-divelog.org/downloads/test/WINBLE-subsurface-4.8.3-12-g2952cd818617.exe
>
>
>
> This basically removes all the Q_OS_WIN code and uses the Linux path for
> Windows:
>
>
my assumption is that this installer has the QBluetoothDiscoveryAgent
for Windows, patch applied?
perhaps more testing for this is needed by others, but i would suggest
we merge such a patch in master too.
>
> Emit: "DB:3B:75:83:D8:6E"
>
> Starting download from BT
>
> qt_ble_open( DB:3B:75:83:D8:6E )
>
> connected to the controller for device DB:3B:75:83:D8:6E
>
> .. discovering services
>
> Found uuid: "{1800--1000-8000-00805f9b34fb}"
>
> Found service "{1800--1000-8000-00805f9b34fb}"
>
> .. created service object QLowEnergyService(0x777bf90)
>
> Found uuid: "{1801--1000-8000-00805f9b34fb}"
>
> Found service "{1801--1000-8000-00805f9b34fb}"
>
> .. created service object QLowEnergyService(0x777bee8)
>
> Found uuid: "{fe25c237-0ece-443c-b0aa-e02033e7029d}"
>
> Found service "{fe25c237-0ece-443c-b0aa-e02033e7029d}"
>
> .. created service object QLowEnergyService(0x777bde0)
>
> .. done discovering services
>
> Found service "{1800--1000-8000-00805f9b34fb}" "Generic Access"
>
> Found service "{1801--1000-8000-00805f9b34fb}" "Generic Attribute"
>
> Found service "{fe25c237-0ece-443c-b0aa-e02033e7029d}" "Unknown Service"
>
>c: "{27b7570b-359e-45a3-91bb-cf7e70049bd2}"
>
> d: "{2902--1000-8000-00805f9b34fb}"
>
> d: "{2901--1000-8000-00805f9b34fb}"
>
> Using service "{fe25c237-0ece-443c-b0aa-e02033e7029d}" as preferred service
>
> .. enabling notifications
>
> Using read characteristic "{27b7570b-359e-45a3-91bb-cf7e70049bd2}"
>
> now writing "0x0100" to the descriptor
> "{2902--1000-8000-00805f9b34fb}"
>
> QTime("22:52:48.325") packet SEND "0100ff010400228010c0"
>
> QTime("22:52:48.325") packet WAIT
>
> QTime("22:53:00.326") packet SEND "0100ff0105002e902000c0"
>
> Deleting BLE object
>
> Finishing download thread: "Dive data import error"
>
>
>
>
>
> Looks great discovering services and stuff, but then we time out waiting for
> a response (and the Teric stays in “CMD WAIT” state).
>
> But we find the device and clearly SOME communication is happening.
>
>
i'm not sure why that is happening.
given the OSTC+ download works i'm going to assume it's our code is
not accommodated to the Teric in the case of the Qt win32 stack.
questions:
- what is the state of Petrel with the the new discovery code
(QBluetoothDiscoveryAgent under Windows)?
- does Teric work on Linux?
>
> Subsurface asks us to pair and if we try to pair that fails (the code was
> hacked to still allow us to save that address). So my guess is that is where
> we still have problems (and yes, the Windows 10 Bluetooth manager lists the
> Teric as paired).
>
i must admit i'm a bit confused. i'm not sure why Subsurface asks to
pair - can you show a screenshot? on Windows the pairing should only
happen via the Control Panel...
the earlier test we did with the small app that tries to connect
worked for the Teric and it connected, means the device is correctly
paired in Control Planel.
at this point, after we discover the address of the device we can just
connect to it and then discover it's services.
address hacks should not be needed.
lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Sun, 30 Sep 2018 at 04:40, Dirk Hohndel wrote: > > > > On Sep 29, 2018, at 3:58 PM, Lubomir I. Ivanov wrote: > > oh, our discovery seems to happen in the front end. > > https://github.com/Subsurface-divelog/subsurface/blob/master/desktop-widgets/btdeviceselectiondialog.cpp > > > > with the custom WinBluetoothDeviceDiscoveryAgent > > i remembered now. > > https://github.com/Subsurface-divelog/subsurface/blob/master/desktop-widgets/btdeviceselectiondialog.cpp#L605 > > Correct. And that's where we hard code the PowerOff error, btw. > > I have now added a new version that prints the actual error... > > WSALookupServiceBegin results in "No such service is known. The service > cannot be found in the specified name space" > Which is the error string for WSASERVICE_NOT_FOUND > "This error is returned for a bluetooth service discovery request if no > remote bluetooth devices were found." > > And that makes sense because no BT devices were on. But what about my BLE > devices??? I have tons of them. > > But I think this is pointing me in the right direction. Next step: improve > our error and debug messages :-) > the discovery in the latest Qt win/wip branch works for me. it detects my devices and guesses their types. i can connect to the DC device too. if the small app that i just posted works for you we can just replace the WSA (WinBluetoothDeviceDiscoveryAgent) usage with the QBluetoothDeviceDiscoveryAgent from Qt. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Sun, 30 Sep 2018 at 04:34, Dirk Hohndel wrote: > > > > On Sep 29, 2018, at 6:28 PM, Lubomir I. Ivanov wrote: > > > > could you please download the following zip when you have a minute: > > https://www.dropbox.com/s/dem58v91bk6qcjj/qt-bt-discovery.zip?dl=0 > > > sorry, copy pasted a WIP link. here is the actual one: https://www.dropbox.com/s/ehkoklydtnrvzxg/_qt-bt-discovery.zip?dl=0 lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Sun, 30 Sep 2018 at 01:14, Dirk Hohndel wrote: > > > > On Sep 29, 2018, at 3:07 PM, Lubomir I. Ivanov wrote: > > > >> > >> Interestingly enough, the two BLE dive computers I tried with are > >> both Shearwaters who AFAIK require random addresses. I don't > >> see, however, how that would cause the error pairing. > >> > >> The third one (Suunto EON Steel) I couldn't figure out how to even > >> pair with Windows 10... > >> > >> Still trying to figure out how to get the logging to work... > >> > > > > > > Dirk notice that Steve is being able to discover the device, but then > > fails to connect: > > (screenshot). > > > > from what i've understood on your end it fails finding the device in > > the list of BT(LE) devices nearby, so it fails in an earlier step? > > > > But Steve has a Petrel 2, right? And AFAIK the Petrel 2 will ALWAYS > switch to BT Classic if the computer supports that. So even though it > includes a BLE radio, that only seems to actually work when you connect > BLE only. And reading the sources I don't think that's what we do. We > seem to scan both at the same time. > > Actually, this is a part of the sources that REALLY puzzles me... > > threadLE = new QThread; > threadWorkerLE = new ThreadWorkerDeviceDiscovery; > threadWorkerLE->moveToThread(threadLE); > > Dirk, Steve and et al. could you please download the following zip when you have a minute: https://www.dropbox.com/s/dem58v91bk6qcjj/qt-bt-discovery.zip?dl=0 this is a minimal Qt application that includes BT device discovery. 1) it will first ask you to press enter to start make sure the BTLE devices are turned on / have battery. 2) it might take a while... 3) then it should dump a list of found devices each having a name and a # configuration legend (QFlags...): - 0x0 -> unknown type - 0x1 -> BTLE - 0x2 -> BT classic - 0x3 -> BT smart (can be either BT or BTLE) http://doc.qt.io/qt-5/qbluetoothdeviceinfo.html#CoreConfiguration-enum 4) in the console pick a # (e.g. 2) and press enter 5) it would then try to connect to the device. if it succeeds it should print out "ConnectedState", if it fails it should print something else. please try your BTLE DCs and report the results. this is a mandatory step if we want to continue with our improvements and it will narrow our guessing game. thanks. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Sun, 30 Sep 2018 at 01:14, Dirk Hohndel wrote: > > > > On Sep 29, 2018, at 3:07 PM, Lubomir I. Ivanov wrote: > > > >> > >> Interestingly enough, the two BLE dive computers I tried with are > >> both Shearwaters who AFAIK require random addresses. I don't > >> see, however, how that would cause the error pairing. > >> > >> The third one (Suunto EON Steel) I couldn't figure out how to even > >> pair with Windows 10... > >> > >> Still trying to figure out how to get the logging to work... > >> > > > > > > Dirk notice that Steve is being able to discover the device, but then > > fails to connect: > > (screenshot). > > > > from what i've understood on your end it fails finding the device in > > the list of BT(LE) devices nearby, so it fails in an earlier step? > > > > But Steve has a Petrel 2, right? And AFAIK the Petrel 2 will ALWAYS > switch to BT Classic if the computer supports that. So even though it > includes a BLE radio, that only seems to actually work when you connect > BLE only. And reading the sources I don't think that's what we do. We > seem to scan both at the same time. > > Actually, this is a part of the sources that REALLY puzzles me... > > threadLE = new QThread; > threadWorkerLE = new ThreadWorkerDeviceDiscovery; > threadWorkerLE->moveToThread(threadLE); > connect(threadWorkerLE, ::discoveryCompleted, > this, ::completeLeDevicesDiscovery); > connect(threadLE, ::finished, threadWorkerLE, > ::deleteLater); > connect(threadLE, ::finished, threadLE, ::deleteLater); > threadLE->start(); > > threadClassic = new QThread; > threadWorkerClassic = new ThreadWorkerDeviceDiscovery; > threadWorkerClassic->moveToThread(threadClassic); > connect(threadWorkerClassic, > ::discoveryCompleted, this, > ::completeClassicDevicesDiscovery); > connect(threadClassic, ::finished, threadWorkerClassic, > ::deleteLater); > connect(threadClassic, ::finished, threadClassic, > ::deleteLater); > threadClassic->start(); > > So this creates to ThreadWorkerDeviceDiscovery objects. How does the LE one > know to scan for BLE only, and the Classic one to scan for Classic only? > I must be missing something obvious - but this just confuses me. > the BTLE and BT-classic in the Windows API have different discovery methods. while i contributed parts of the above code, the separable discovery was already in place. also the above code hasn't seen a lot of testing. but i don't think we are using QBluetoothDeviceDiscoveryAgent in our code on Windows, is that correct? looking at this i cannot figure out how the discovery on WIndows is happening: https://github.com/Subsurface-divelog/subsurface/blob/master/core/btdiscovery.cpp#L101 lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Sun, 30 Sep 2018 at 00:07, Steve wrote: > Steve, if you have a minute could you please test this installer again (the link is the same): https://www.dropbox.com/s/zslq3ughx9ciehj/_deploy_win32_ble.zip?dl=0 has a minor update. this is just a shot in the dark but it disables explicit random addresses on Windows for the Petrel. thanks lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Sun, 30 Sep 2018 at 00:57, Linus Torvalds wrote: > > On Sat, Sep 29, 2018 at 2:47 PM Lubomir I. Ivanov wrote: > > > > random addresses should not be used on Win32. > > Afaik, the dive computers that need random addresses will simply not > respond to the static ones. > > It's not a "choice" you can make. It's the other end that says that > they need a random address. > > Now, it's possible that Windows does the selection automatically > (that's how it *should* work, and Bluez is being stupid about it), but > then it shouldn't matter whether you set the random address bit or > not. > my suspicion was by raised by the earlier report by Steve, where i saw: > qt_ble_open( 00:13:43:0D:DB:D4 ) > "The system cannot find the path specified." > failed to connect to the controller 00:13:43:0D:DB:D4 with error "Remote > device cannot be found" https://github.com/Subsurface-divelog/subsurface/blob/master/core/qt-ble.cpp#L406-L412 between our `qt_ble_open()` written to `stdout` and the `controller->connectToDevice();` we only have the `use_random_address()` which would result in true for Petrel. so we might want to wrap that in #if define() for Windows just to test it and be sure. of course, the alternative here is that the address is wrong. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Sun, 30 Sep 2018 at 00:47, Lubomir I. Ivanov wrote: > > On Sun, 30 Sep 2018 at 00:43, Dirk Hohndel wrote: > > > > > > > On Sep 29, 2018, at 2:29 PM, Lubomir I. Ivanov > > > wrote: > > >> > > >> Subsurface v4.8.2-74-g110fbbf7dbb3, > > >> built with libdivecomputer v0.7.0 > > >> built with Qt Version 5.9.5, runtime from Qt Version 5.10.1 > > > > So these tests are still with an older binary. Would it make sense > > to start testing with newer binaries? > > > > http://subsurface-divelog.org/downloads/test/WINBLE-subsurface-4.8.3-6-g4486c66f498a.exe > > > > I tried to enable the BLE discovery logging, but that didn't quite work, it > > seems. > > You mentioned that this needs a debug build (which doesn't appear to be the > > case on other OSs)... > > so this will need more tinkering :-/ > > > > i'm seeing one problem with our source code. this should be wrapped in: > > #if !defined(Q_OS_WIN) > ... > #endif > > https://github.com/Subsurface-divelog/subsurface/blob/master/core/qt-ble.cpp#L408-L409 > > random addresses should not be used on Win32. > but it feels like the function is a NOP on Windows, we need to test if that's the case by disabling it: http://doc.qt.io/qt-5/qlowenergycontroller.html#setRemoteAddressType lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Sun, 30 Sep 2018 at 00:43, Dirk Hohndel wrote: > > > > On Sep 29, 2018, at 2:29 PM, Lubomir I. Ivanov wrote: > >> > >> Subsurface v4.8.2-74-g110fbbf7dbb3, > >> built with libdivecomputer v0.7.0 > >> built with Qt Version 5.9.5, runtime from Qt Version 5.10.1 > > So these tests are still with an older binary. Would it make sense > to start testing with newer binaries? > > http://subsurface-divelog.org/downloads/test/WINBLE-subsurface-4.8.3-6-g4486c66f498a.exe > > I tried to enable the BLE discovery logging, but that didn't quite work, it > seems. > You mentioned that this needs a debug build (which doesn't appear to be the > case on other OSs)... > so this will need more tinkering :-/ > i'm seeing one problem with our source code. this should be wrapped in: #if !defined(Q_OS_WIN) ... #endif https://github.com/Subsurface-divelog/subsurface/blob/master/core/qt-ble.cpp#L408-L409 random addresses should not be used on Win32. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Sun, 30 Sep 2018 at 00:25, Steve wrote:
>
> Ok another test but this time even though I paired with Windows settings
> properly twice and it said it was setup it looked to me as if it was not
> paired correctly so I tried with Bluetooth LE Explorer and paired with that
> (as I did for the OSTC3+) and this time it looks better but still not working.
> See attached screenshot and log files.
>
from my experience if i paired within BLE Explorer and then tried to
use Subsurface it would not work as the service path is already used
by another process.
> Output:
>
> Subsurface v4.8.2-74-g110fbbf7dbb3,
> built with libdivecomputer v0.7.0
> built with Qt Version 5.9.5, runtime from Qt Version 5.10.1
> built with libgit2 0.23.0
> can't find Subsurface localization for locale "en-US"
> Plugins Directory: QDir(
> "D:/Documents/Diving/Software/subsurface/_deploy_win32_ble/_deploy_win32_ble/plugins"
> , nameFilters = { "*" }, QDir::SortFlags( Name | IgnoreCase ) ,
> QDir::Filters( Dirs|Files|Drives|AllEntries ) )
> QPixmap::scaleHeight: Pixmap is a null pixmap
> QPixmap::scaleHeight: Pixmap is a null pixmap
> QPixmap::scaleHeight: Pixmap is a null pixmap
> QPixmap::scaleHeight: Pixmap is a null pixmap
> Set the current dive site: 0
> Set the current dive site: 0
>
> File locations:
>
> cloud URL set as
> "https://cloud.subsurface-divelog.org//git/stevewilli...@internode.on.net[stevewilli...@internode.on.net];
> Local git storage:
> C:\Users\steve\AppData\Roaming\Subsurface/cloudstorage/f419375139b19f7f
> Cloud URL:
> https://cloud.subsurface-divelog.org//git/stevewilli...@internode.on.net[stevewilli...@internode.on.net]
> Image filename table: C:\Users\steve\AppData\Roaming\Subsurface/hashes
> Local picture directory:
> C:\Users\steve\AppData\Roaming\Subsurface/picturedata/
>
> QPixmap::scaleHeight: Pixmap is a null pixmap
> Starting download from BT
> Unimplemented code.
> qt_ble_open( 00:13:43:0D:DB:D4 )
> connected to the controller for device 00:13:43:0D:DB:D4
> .. discovering services
> Found uuid: "{1800--1000-8000-00805f9b34fb}"
> Found service "{1800--1000-8000-00805f9b34fb}"
> .. created service object QLowEnergyService(0x9074100)
> Found uuid: "{180a--1000-8000-00805f9b34fb}"
> Found service "{180a--1000-8000-00805f9b34fb}"
> .. created service object QLowEnergyService(0x90743d0)
> Found uuid: "{fe25c237-0ece-443c-b0aa-e02033e7029d}"
> Found service "{fe25c237-0ece-443c-b0aa-e02033e7029d}"
> .. created service object QLowEnergyService(0x9076110)
> Unable to get value for characteristic
> "{27b7570b-359e-45a3-91bb-cf7e70049bd2}" of the service
> "{fe25c237-0ece-443c-b0aa-e02033e7029d}" : "No attribute found within the
> given attribute handle range."
> .. done discovering services
> Found service "{1800--1000-8000-00805f9b34fb}" "Generic Access"
>c: "{2a00--1000-8000-00805f9b34fb}"
>c: "{2a01--1000-8000-00805f9b34fb}"
> Found service "{180a--1000-8000-00805f9b34fb}" "Device Information"
>c: "{2a29--1000-8000-00805f9b34fb}"
> Found service "{fe25c237-0ece-443c-b0aa-e02033e7029d}" "Unknown Service"
>c: "{27b7570b-359e-45a3-91bb-cf7e70049bd2}"
> d: "{2901--1000-8000-00805f9b34fb}"
> d: "{2902--1000-8000-00805f9b34fb}"
> .. ignoring standard service "{1800--1000-8000-00805f9b34fb}"
> .. ignoring standard service "{180a--1000-8000-00805f9b34fb}"
> Using service "{fe25c237-0ece-443c-b0aa-e02033e7029d}" as preferred service
> .. enabling notifications
> Using read characteristic "{27b7570b-359e-45a3-91bb-cf7e70049bd2}"
> now writing "0x0100" to the descriptor
> "{2902--1000-8000-00805f9b34fb}"
> INFO: dc_device_open error value of 0
> QTime("06:46:35.874") packet SEND "0100ff0105002e902000c0"
> Deleting BLE object
> Finishing download thread: "Dive data import error"
> Set the current dive site: 0
> Set the current dive site: 0
> Starting download from BT
> Unimplemented code.
> qt_ble_open( 00:13:43:0D:DB:D4 )
> connected to the controller for device 00:13:43:0D:DB:D4
> .. discovering services
> Found uuid: "{1800--1000-8000-00805f9b34fb}"
> Found service "{1800--1000-8000-00805f9b34fb}"
> .. created service object QLowEnergyService(0x90761b8)
> Found uuid: "{180a--1000-8000-00805f9b34fb}"
> Found service "{180a--1000-8000-00805f9b34fb}"
> .. created service object QLowEnergyService(0x9076218)
> Found uuid: "{fe25c237-0ece-443c-b0aa-e02033e7029d}"
> Found service "{fe25c237-0ece-443c-b0aa-e02033e7029d}"
> .. created service object QLowEnergyService(0x90765f0)
> Unable to get value for characteristic
> "{27b7570b-359e-45a3-91bb-cf7e70049bd2}" of the service
> "{fe25c237-0ece-443c-b0aa-e02033e7029d}" : "No attribute found within the
> given attribute handle range."
> .. done discovering services
> Found service "{1800--1000-8000-00805f9b34fb}" "Generic Access"
>c:
Re: [TEST REQUEST] Windows Bluetooth LE build
On Sun, 30 Sep 2018 at 00:07, Steve wrote:
>
> I found a minute to test with the petrel2 and could not get it to work.
> I also deleted the pairing with the pc and re-paired without success.
> See attached screenshot and log files.
> I don't have a lot of time to test for till Tuesday but might be able to do a
> little before then.
>
> Output:
>
> Subsurface v4.8.2-74-g110fbbf7dbb3,
> built with libdivecomputer v0.7.0
> built with Qt Version 5.9.5, runtime from Qt Version 5.10.1
> built with libgit2 0.23.0
> can't find Subsurface localization for locale "en-US"
> Plugins Directory: QDir(
> "D:/Documents/Diving/Software/subsurface/_deploy_win32_ble/_deploy_win32_ble/plugins"
> , nameFilters = { "*" }, QDir::SortFlags( Name | IgnoreCase ) ,
> QDir::Filters( Dirs|Files|Drives|AllEntries ) )
> QPixmap::scaleHeight: Pixmap is a null pixmap
> QPixmap::scaleHeight: Pixmap is a null pixmap
> QPixmap::scaleHeight: Pixmap is a null pixmap
> QPixmap::scaleHeight: Pixmap is a null pixmap
> Set the current dive site: 0
> Set the current dive site: 0
>
> File locations:
>
> cloud URL set as
> "https://cloud.subsurface-divelog.org//git/stevewilli...@internode.on.net[stevewilli...@internode.on.net];
> Local git storage:
> C:\Users\steve\AppData\Roaming\Subsurface/cloudstorage/f419375139b19f7f
> Cloud URL:
> https://cloud.subsurface-divelog.org//git/stevewilli...@internode.on.net[stevewilli...@internode.on.net]
> Image filename table: C:\Users\steve\AppData\Roaming\Subsurface/hashes
> Local picture directory:
> C:\Users\steve\AppData\Roaming\Subsurface/picturedata/
>
> QPixmap::scaleHeight: Pixmap is a null pixmap
> Starting download from BT
> Unimplemented code.
> qt_ble_open( 00:13:43:0D:DB:D4 )
> "The system cannot find the path specified."
> failed to connect to the controller 00:13:43:0D:DB:D4 with error "Remote
> device cannot be found"
> Finishing download thread: "Unable to open LE:00:13:43:0D:DB:D4 Shearwater
> (Petrel 2)"
> QPixmap::scaleHeight: Pixmap is a null pixmap
> Set the current dive site: 0
> Set the current dive site: 0
> QPixmap::scaleHeight: Pixmap is a null pixmap
> QPixmap::scaleHeight: Pixmap is a null pixmap
> Starting download from BT
> Unimplemented code.
> qt_ble_open( 00:13:43:0D:DB:D4 )
> "The system cannot find the path specified."
> failed to connect to the controller 00:13:43:0D:DB:D4 with error "Remote
> device cannot be found"
> Finishing download thread: "Unable to open LE:00:13:43:0D:DB:D4 Shearwater
> (Petrel 2)"
> Set the current dive site: 0
> Set the current dive site: 0
> QPixmap::scaleHeight: Pixmap is a null pixmap
> QPixmap::scaleHeight: Pixmap is a null pixmap
> QPixmap::scaleHeight: Pixmap is a null pixmap
> Press any key to continue . . .
>
thanks for testing the Petrel too, Steve!
i will have a look at the results.
lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Sat, 29 Sep 2018 at 20:26, Dirk Hohndel wrote: > > > > On Sep 28, 2018, at 8:19 PM, Lubomir I. Ivanov wrote: > > > > i can investigate their binary a little. > > we also have the option to just ask them - are they friendly? > > They are VERY friendly. I'll reach out to them. yes, after finding it's C# i don't have any immediate questions. > But as you mentioned, their's is > a C# app, so things might be different there. > Can we write a C# helper and pass the information to our app? > > this is not that easy. we spoke about a similar scenario when the Win32 discussions started with Alex about UWP. if such a helper is to be built: - it has to be built using the Windows SDK and MSVC as standalone app and not as a library. - if we get it to work with an older dot-net version it's going to be OK, if not we need to force users to update their dot-net setup before using and if we don't want to redistribute the whole target dot-net. - given it cannot be built using MINGW, we need to create something like a TCP Socket protocol to make Subsurface communicate with the helper app. i'm not sure i'm liking where this is going. given the OSTC+ already works, i'd prefer if can we find another solution. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Sat, 29 Sep 2018 at 20:26, Dirk Hohndel wrote:
>
>
> > On Sep 28, 2018, at 8:19 PM, Lubomir I. Ivanov wrote:
> >
> > i can investigate their binary a little.
> > we also have the option to just ask them - are they friendly?
>
> They are VERY friendly. I'll reach out to them. But as you mentioned, their's
> is
> a C# app, so things might be different there.
> Can we write a C# helper and pass the information to our app?
>
>
> In the meantime, I completed a compile of Qt 5.11.2 from source, added
> your wip/win qtconnectivity and did a make install to make sure that ALL
> of the files are copied to the right place.
>
> I created an installer from that (which is missing FB, printing, user manual,
> and apparently for some reason even the maps). You can find it on our website
> as
> http://subsurface-divelog.org/downloads/test/subsurface-4.8.2-92-gb05b8de05966.exe
>
do i need to test this installer, given it already worked with -91?
also TMK the -91 would have all the above modules that -92 is missing?
why do we need to upgrade to 5.11.2?
> I then purchased a new copy of Windows 10 (the things we do for our
> hobbies) and installed it on the same laptop that I do my "on hardware"
> Linux testing on.
>
> I paired the Teric with Windows (no problem there at all, found it right
> away).
>
> So now we have:
> - different laptop
> - different BT device (this is a USB dongle, other one was built in)
> - different Windows 10 install
> - NO anti virus, anything
>
> Still the exact same experience in Subsurface
> Regardless if I select Auto or Force LE, I get the Device discovery error.
> And I get it fairly quickly.
>
> If I put my BT-classic-only Petrel in BT mode, it gets detected within a
> second or two, and I can immediately download from it (without having
> to do any pairing first).
>
> So BT works, but somehow the BLE scan results in an error.
>
we might have a lurking bug in our discovery code.
i need to have a detailed look at it.
> You know the code much better than I do... in the scan path, what can
> create such an error? One thing that is odd about my office is that I can
> see more than a dozen BLE devices here on a regular scan. I wonder
> if one of the unpaired ones is causing this behavior. But give then need
> to pair first for BLE, that does seem unlikely, doesn't it?
as mentioned multiple times the Windows discovery and device
enumeration is super shaky.
i don't have other devices in my room and the detection works fine.
please bring this problem device to Sofia.
>
> Is there a way to get more debug info from the Qt BLE code to see WHY
> it created that error?
>
if QtConnectivity is built in debug mode and if you can try moving
this from qt-ble.cpp
QLoggingCategory::setFilterRules(QStringLiteral("qt.bluetooth* = true"));
to btdiscovery.cpp, it might output are better detailed message.
i only got the error if i completely disabled BT from control planel.
hard to say, will have another look.
> My plan for 4.8.3 is to switch back to my previous MXE setup so we have
> working Windows binaries with all components (but not BLE). But I really
> want to push on this BLE story. It feels like we are SO CLOSE.
>
given it works for me and Steven, it really feels like an isolated error.
is there are change we can announce -91 for testing so that we can
gather more feedback?
it feels like my installer is not reaching out to people.
lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Sat, 29 Sep 2018 at 18:55, Lubomir I. Ivanov wrote: > > On Sat, 29 Sep 2018 at 04:18, Lubomir I. Ivanov wrote: > > > > On 29 September 2018 at 04:13, Dirk Hohndel wrote: > > > > > >> On Sep 28, 2018, at 6:05 PM, Lubomir I. Ivanov > > >> wrote: > > >>> Nope, much easier. Case sensitive file system. Simply changing it to > > >>> winsock2.h does the trick. > > >>> > > >> > > >> looks like a potential patch i can send. > > > > > > yep. make it all lowercase :-) > > > > patch sent: > > https://codereview.qt-project.org/#/c/241465/ > > > > this patch was merged: > https://codereview.qt-project.org/#/c/241465/ > or rather it's in queue: `Status: INTEGRATING` lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Sat, 29 Sep 2018 at 04:18, Lubomir I. Ivanov wrote: > > On 29 September 2018 at 04:13, Dirk Hohndel wrote: > > > >> On Sep 28, 2018, at 6:05 PM, Lubomir I. Ivanov wrote: > >>> Nope, much easier. Case sensitive file system. Simply changing it to > >>> winsock2.h does the trick. > >>> > >> > >> looks like a potential patch i can send. > > > > yep. make it all lowercase :-) > > patch sent: > https://codereview.qt-project.org/#/c/241465/ > this patch was merged: https://codereview.qt-project.org/#/c/241465/ lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Sat, 29 Sep 2018 at 16:43, Steve wrote: > > > Got a chance to test this again with a good charge in the battery and it > completed successfully all the way this time. > > Let me know if you want the logs but I can report it all it all looks good. > thanks for testing Steve, at least now we know that the OSTC(3)+ works on BLE/Windows lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Sat, 29 Sep 2018 at 06:19, Lubomir I. Ivanov wrote: > > On Sat, 29 Sep 2018 at 06:10, Dirk Hohndel wrote: > > > > > > > On Sep 28, 2018, at 8:07 PM, Lubomir I. Ivanov > > > wrote: > > > > > > according to a post here UWP apps are only accessible via the Windows > > > Store: > > > https://www.tenforums.com/software-apps/47840-how-do-i-know-if-installed-app-universal-app.html > > > > > > if it's not installed via the Windows Store this means the Shearwater > > > devs know something that we don't know, as the Qt developers assured > > > me non-UWP apps don't have access to the pair API. > > > > Nope, not from the store. And DEFINITELY the app can pair with their > > dive computers without a problem. It finds the quickly and very reliably. > > > > i can investigate their binary a little. > we also have the option to just ask them - are they friendly? > on a quick look Sheerwater Cloud is written in C#, saw some dot-net EXE patchers and also the Mono runtime in their installer. so we are probably dealing with a case where it's not about UWP, but rather C# vs C: also the Microsoft pairing examples are in C#: https://github.com/Microsoft/Windows-universal-samples/blob/master/Samples/BluetoothLE/cs/Scenario1_Discovery.xaml.cs#L306 https://github.com/Microsoft/Windows-universal-samples/tree/master/Samples/BluetoothLE/cs for Subsurface, we don't have an option other than the one we have ATM. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Sat, 29 Sep 2018 at 06:10, Dirk Hohndel wrote: > > > > On Sep 28, 2018, at 8:07 PM, Lubomir I. Ivanov wrote: > > > > according to a post here UWP apps are only accessible via the Windows Store: > > https://www.tenforums.com/software-apps/47840-how-do-i-know-if-installed-app-universal-app.html > > > > if it's not installed via the Windows Store this means the Shearwater > > devs know something that we don't know, as the Qt developers assured > > me non-UWP apps don't have access to the pair API. > > Nope, not from the store. And DEFINITELY the app can pair with their > dive computers without a problem. It finds the quickly and very reliably. > i can investigate their binary a little. we also have the option to just ask them - are they friendly? > I'll bring you the Perdix AI next week, then you can try this first hand. sounds good. > >>> > > >>> - does the list of devices gets populated even if the red Subsurface > >>> error is shown? > >> > >> Sometimes it gets populated with BT devices if I select Auto instead > >> of Force LE. But if I get the error I mentioned, then it isn't populated > >> > > > > if it's only happening sometimes, it could be do two a couple of reasons: > > - malfunctioning chip on the laptop. > > - a software hook interrupting the scan. AV software can do that. > > But why doesn't that happen to Shearwater Cloud??? > i did a good amount of investigation on this and also asked around. it might be a case where it's not about UWP vs non-UWP but rather (C# or C++) vs C. for instance this post confirms my findings. [1] i need to go to bed now, will investigate more tomorrow or on Sunday. in the meantime if you can try another Windows machine and if we can get more feedback from users it would be great! [1] https://stackoverflow.com/questions/19959261/how-to-scan-for-bluetooth-low-energy-devices-in-windows-8-desktop thanks. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Sat, 29 Sep 2018 at 06:07, Lubomir I. Ivanov wrote: > > > > Sometimes it gets populated with BT devices if I select Auto instead > > of Force LE. But if I get the error I mentioned, then it isn't populated > > > > if it's only happening sometimes, it could be do two a couple of reasons: *it could be due to... lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Sat, 29 Sep 2018 at 06:01, Dirk Hohndel wrote: > > > > On Sep 28, 2018, at 7:58 PM, Lubomir I. Ivanov wrote: > > > > - is Shearwater Cloud an Universal Windows Platform app, those support > > scanning and pairing, unlike Subsurface which is a native app? > > How can I tell? (sorry) according to a post here UWP apps are only accessible via the Windows Store: https://www.tenforums.com/software-apps/47840-how-do-i-know-if-installed-app-universal-app.html if it's not installed via the Windows Store this means the Shearwater devs know something that we don't know, as the Qt developers assured me non-UWP apps don't have access to the pair API. > > > - i wonder if anti-virus is at play here, do you have an option to > > temp disable it? > > Work laptop. Let's try :-) might require admin privileges. > > > - did you try deleting all DCs from control panel -> restarting -> > > adding them again? > > I will do that next ok. > > > - does the list of devices gets populated even if the red Subsurface > > error is shown? > > Sometimes it gets populated with BT devices if I select Auto instead > of Force LE. But if I get the error I mentioned, then it isn't populated > if it's only happening sometimes, it could be do two a couple of reasons: - malfunctioning chip on the laptop. - a software hook interrupting the scan. AV software can do that. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Sat, 29 Sep 2018 at 05:52, Dirk Hohndel wrote: > > > > On Sep 28, 2018, at 7:46 PM, Dirk Hohndel wrote: > > > >> > >> On Sep 28, 2018, at 7:43 PM, Lubomir I. Ivanov wrote: > >> > >> On Sat, 29 Sep 2018 at 05:33, Dirk Hohndel wrote: > >>> > >>> > >>>> On Sep 28, 2018, at 7:26 PM, Dirk Hohndel wrote: > >>>> > >>>> Given the nature of the error message I'm thinking this might be an > >>>> unhealthy mix of versions... > >>> > >>> To test this theory I dug out a Bluetooth dive computer (an original > >>> BT-only > >>> Shearwater Petrel) and had no problem connecting to it and downloading > >>> dives from it. > >>> > >>> So now I'm no longer sure where the problem might be... > >>> > >> > >> i'm not sure either, but it seems that the OSTC+ works for me using that > >> build. > >> > >> so i guess on your side we have an issue that other users might face as > >> well. > >> the device discovery and pairing is problematic on Windows...and i've > >> raised that concern before. > >> > >> i wonder if a restart + removing + adding / pairing the devices would help. > >> on my side a restart often helps in cases the device cannot be found. > > > > So Windows tells me it sees the devices and is paired with both of them. > > I tried removing one or the other. Of course they are both very similar. > > I'll try another BLE dive computer that I have and see if that will play > > along... > > I installed Shearwater Cloud on that machine. It immediately connects > with both computers. Even while it is scanning, a scan with Subsurface > fails > - is Shearwater Cloud an Universal Windows Platform app, those support scanning and pairing, unlike Subsurface which is a native app? - i wonder if anti-virus is at play here, do you have an option to temp disable it? - did you try deleting all DCs from control panel -> restarting -> adding them again? - does the list of devices gets populated even if the red Subsurface error is shown? lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Sat, 29 Sep 2018 at 05:33, Dirk Hohndel wrote: > > > > On Sep 28, 2018, at 7:26 PM, Dirk Hohndel wrote: > > > > Given the nature of the error message I'm thinking this might be an > > unhealthy mix of versions... > > To test this theory I dug out a Bluetooth dive computer (an original BT-only > Shearwater Petrel) and had no problem connecting to it and downloading > dives from it. > > So now I'm no longer sure where the problem might be... > i'm not sure either, but it seems that the OSTC+ works for me using that build. so i guess on your side we have an issue that other users might face as well. the device discovery and pairing is problematic on Windows...and i've raised that concern before. i wonder if a restart + removing + adding / pairing the devices would help. on my side a restart often helps in cases the device cannot be found. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Sat, 29 Sep 2018 at 04:59, Lubomir I. Ivanov wrote: > > On Sat, 29 Sep 2018 at 04:57, Dirk Hohndel wrote: > > > > If you want to play with my binary, there are currently two on > > downloads/test > > > > The -90 is the test binary for 4.8.3 with unmodified Bluetooth libraries > > The -91 is the one with your branch of QtBluetooth > > > > ok, trying. > i cannot install Subsurface from the installer on the IT laptop (screenshot attached). looking for ways, but it seems blocked by WindowsDefender and there is no privileges for me to unblock that. if you can ZIP + upload the contents for me - i can test. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Sat, 29 Sep 2018 at 04:59, Lubomir I. Ivanov wrote: > > On Sat, 29 Sep 2018 at 04:57, Dirk Hohndel wrote: > > > > > > > On Sep 28, 2018, at 6:53 PM, Dirk Hohndel wrote: > > > > > > > > >> On Sep 28, 2018, at 6:51 PM, Dirk Hohndel wrote: > > >> > > >> No. In the Subsurface divecomputer download dialog I click on the '...' > > >> behind the > > >> Bluetooth mode text to open the scan window. There I click scan and some > > >> times > > >> it will show me some (actually, only a few) of the many many BT/BLE > > >> devices in > > >> my office, but about half of the time it will tell me that there was an > > >> error scanning > > >> because the BT device is off. > > >> > > > > > > The exact text is (below the Clear button) > > > > > > Device discovery error: The Bluetooth adaptor is powered off, power it on > > > before > > > doing discovery > > > > And of course the adapter is in fact on and in the Windows settings I see > > both of > > the BLE dive computers that I have sitting next to me right now... > > > > i can reproduce this error if i go into the control plane *panel. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Sat, 29 Sep 2018 at 04:57, Dirk Hohndel wrote: > > > > On Sep 28, 2018, at 6:53 PM, Dirk Hohndel wrote: > > > > > >> On Sep 28, 2018, at 6:51 PM, Dirk Hohndel wrote: > >> > >> No. In the Subsurface divecomputer download dialog I click on the '...' > >> behind the > >> Bluetooth mode text to open the scan window. There I click scan and some > >> times > >> it will show me some (actually, only a few) of the many many BT/BLE > >> devices in > >> my office, but about half of the time it will tell me that there was an > >> error scanning > >> because the BT device is off. > >> > > > > The exact text is (below the Clear button) > > > > Device discovery error: The Bluetooth adaptor is powered off, power it on > > before > > doing discovery > > And of course the adapter is in fact on and in the Windows settings I see > both of > the BLE dive computers that I have sitting next to me right now... > i can reproduce this error if i go into the control plane and turn bluetooth off manually. > > If you want to play with my binary, there are currently two on downloads/test > > The -90 is the test binary for 4.8.3 with unmodified Bluetooth libraries > The -91 is the one with your branch of QtBluetooth > ok, trying. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On 29 September 2018 at 04:42, Dirk Hohndel wrote: > One thing that I noticed with only BTSUPPORT was that every other time that > I tried to scan for Bluetooth devices in Subsurface, it would tell me that the > Bluetooth adapter was turned off. Have you seen that behavior? > no, i haven't. is that one of the red messages we show at the bottom of the main window? lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On 29 September 2018 at 04:13, Dirk Hohndel wrote: > >> On Sep 28, 2018, at 6:05 PM, Lubomir I. Ivanov wrote: >>> Nope, much easier. Case sensitive file system. Simply changing it to >>> winsock2.h does the trick. >>> >> >> looks like a potential patch i can send. > > yep. make it all lowercase :-) patch sent: https://codereview.qt-project.org/#/c/241465/ > >> yes, that header should be in the same location where windows.h is. > > Indeed, and with that I have a successful build. > Now I'm trying to put the files in place and create a new Subsurface build > good to hear, at this point the QtBluettooth* DLLs are required as part of the deployment. and for Subsurface's CMake: -DBLESUPPORT=1 -DBTSUPPORT=1 lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On 29 September 2018 at 04:04, Dirk Hohndel wrote: > >> On Sep 28, 2018, at 6:01 PM, Dirk Hohndel wrote: >> I use i686-w64-mingw32.shared-gcc (GCC) 4.9.4 as that's what's part of MXE >> right now. >> I wonder why there isn't a gcc5 > > there apparently is, but I haven't installed it. Looking into that. > >> A little while into the build I get this error: >> >> qbluetoothservicediscoveryagent_win.cpp:50:22: fatal error: WinSock2.h: No >> such file or directory >> >> I appear to be missing some part of the dev environment. Let's see what >> Google tells me about that with MXE :-) > > Nope, much easier. Case sensitive file system. Simply changing it to > winsock2.h does the trick. > looks like a potential patch i can send. yes, that header should be in the same location where windows.h is. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On 29 September 2018 at 03:10, Dirk Hohndel wrote: > On Fri, Sep 28, 2018 at 11:10:48PM +0300, Lubomir I. Ivanov wrote: >> >> once the Qt tree is in place this branch has to be fetched: >> http://code.qt.io/cgit/qt/qtconnectivity.git/log/?h=wip/win >> >> cd qtconnectivity >> git fetch origin wip/win:wip/win >> git checkout wip/win > > that part is easy. > >> at this point building Qt should use that branch. >> >> please mind that i every time i try to rebuild Qt something breaks for >> me, so i'm probably not the best person on giving advise how to build >> Qt. >> >> here is my windows CMD script for rebuilding + installing only >> qtconnectivity: >> >> @echo off >> cls >> echo >> echo CLEANUP... >> del /q C:\bin\qt\5.9.2\src\qtbase\lib\*Qt5Bluetooth* >> echo BUILDING... >> make -j4 module-qtconnectivity > NUL >> :: make -j4 module-qtdeclarative > NUL > > This assumes you already have a makefile. Here's what I got so far: > > /data/win/mxe-master/usr/bin/i686-w64-mingw32.shared-qmake-qt5 > Info: creating stash file > /data/winqt571/mxe-master/dirkhh/qtconnectivity/.qmake.stash > Info: creating cache file > /data/winqt571/mxe-master/dirkhh/qtconnectivity/.qmake.cache > > Running configuration tests... > Checking for BlueZ... no > Checking for WinRT Bluetooth API... no > Done running configuration tests. > > Configure summary: > > Qt Bluetooth: > BlueZ .. no > BlueZ Low Energy ... no > Linux Crypto API ... no > WinRT Bluetooth API (desktop & UWP) no > > That looks odd. Looks like I have no BT support at all. Is that what you > see as well? yes, my config command line is: configure -developer-build -opensource -nomake examples -nomake tests -no-opengl -no-qml-debug -skip qtwebengine after accepting the license i see: --- ... Qt Bluetooth: BlueZ .. no BlueZ Low Energy ... no Linux Crypto API ... no WinRT Bluetooth API (desktop & UWP) no at this point i run the above CMD file to build QtConnectivity. my GCC is: gcc version 5.3.0 (i686-posix-dwarf-rev0, Built by MinGW-W64 project) lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Thu, 27 Sep 2018 at 01:04, Lubomir I. Ivanov wrote: > > looks like the recent libdc + BLE refactor in Subsurface fixed the > issues i was having downloading from the OSTC+ on Windows, with my > custom Qt build. > so it wasn't an issue in the Qt stack. > > thanks goes to Linus, because i was stuck on this not being able to > figure out what's going on for a long time... > > log for proof: > https://pastebin.com/7DHZU855 > > -- > > link for testing my latest Subsurface test build for BLE on Win32: > https://www.dropbox.com/s/zslq3ughx9ciehj/_deploy_win32_ble.zip?dl=0 > > instructions: > > prerequisites: > - minimum Windows version for this is 8.1 > - make sure that Windows has detected and paired with your DC > > steps: > - extract the _deploy_win32_ble.zip ZIP in a folder somewhere > - navigate to the folder with Explorer and start _run.cmd > - a console window should open and next to it the Subsurface window > - start your BLE dive-computer and make it ready for downloading of dives > - in Subsurface goto Import -> Download from divecomputer > - select the following options (and pick paths): > [x] Save libdivecomputer dumpfile > [x] Save libdivecomputer logfile > - select the following option: > [x] Choose bluetooth download mode > - a dialog should open. select "Force LE" for mode, and click "Scan". > - your device should appear in the list. select it and click "Save" > - the "Device or mount point" field should now show your DC. > - click "Download". > > report back logs and dump files if it doesn't work for you. > recorded a quick video tutorial about pairing BLE devices on Windows 10: https://www.dropbox.com/s/1jivnitub9vq6do/win32_ble_tutorial.mp4?dl=0 lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On 29 September 2018 at 01:18, Lubomir I. Ivanov wrote: >> > > i think the code was fine building against 5.9 but they switched to a > new Qt feature that broke QtConnectivity against older QtBase and 5.11 > was now required. i don't think i got this right on the first attempt. trying again. i think it was a case where 5.9.5 was working file for the wip/win branch, but QtConnectivity started using a new feature (i don't remember which one) and i tried Qt 5.10. qmake in 5.10 failed building for me (there is a discussion with Thiago earlier in this thread about it), so that's why i switched to QtBase 5.11 and it worked. i think it's best, instead of trusting my memory, to just try building the QtConnectivity module from the wip/win branch against the version of Qt that you currently have (Qt 5.10.1) and see how it goes. please share error logs, if any. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On 29 September 2018 at 01:03, Dirk Hohndel wrote: > > > That looks… “interesting”. > So your code is Qt 5.9.5 based? > We are currently building against Qt 5.10.1 > I guess I’ll need to figure out if this works against Qt 5.10.1 as well or > if we are better off downgrading overall. > Not sure if I want to tackle this for Subsurface 4.8.3 - that sounds like I > might be breaking way too many things. > i think the code was fine building against 5.9 but they switched to a new Qt feature that broke QtConnectivity against older QtBase and 5.11 was now required. that's the only reason i did that switch. digging for the exact feature...i cannot find it / i don't remember. something else to note here, it seems that Alex hasn't merged the `dev` branch in the `wip/win` branch in a while, so if the build fails for you we need to ping him. > And on the off chance that this does sound even the least bit critical > (because I have been told by others today that I’m a bit grumpy): I am super > happy with your progress there. Lack of BLE support on Windows was a huge > concern for me and this is awesome. We may not get this for 4.8.3, but we > should be able to get “something” out very soon. > as said earlier, credit goes to Linus, as he fixed it by fixing the support for the other DC (was it a Mares?). lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On 28 September 2018 at 17:53, Lubomir I. Ivanov wrote: > On 28 September 2018 at 17:44, Dirk Hohndel wrote: >> >>> On Sep 28, 2018, at 6:36 AM, Anton Lundin wrote: >>> >>> So, some how we ended up being out of order. >>> >>> I would need to look at the libdivecomputer log file to. It might tell >>> us what actually happened. >> >> Yes, that would be good to follow up on >> >>>> i guess the biggest point here is that the BTLE Win32 stack works. >>> >>> YEY. >> >> Yes indeed. Now how do I add Lubomir's patches to my >> built-from-source-anyway Qt libraries for MXE? >> So we can get more people to test "official" binaries? >> > > i will post some instructions later today. > the changes to make win32-ble to work are part of an official branch. > setup know to work: > built with Qt Version 5.9.5, runtime from Qt Version 5.10.1 once the Qt tree is in place this branch has to be fetched: http://code.qt.io/cgit/qt/qtconnectivity.git/log/?h=wip/win cd qtconnectivity git fetch origin wip/win:wip/win git checkout wip/win at this point building Qt should use that branch. please mind that i every time i try to rebuild Qt something breaks for me, so i'm probably not the best person on giving advise how to build Qt. here is my windows CMD script for rebuilding + installing only qtconnectivity: @echo off cls echo echo CLEANUP... del /q C:\bin\qt\5.9.2\src\qtbase\lib\*Qt5Bluetooth* echo BUILDING... make -j4 module-qtconnectivity > NUL :: make -j4 module-qtdeclarative > NUL echo. echo echo COPYING... copy /y C:\bin\qt\5.9.2\src\qtbase\lib\Qt5Bluetooth* C:\bin\qt\5.9.2\mingw53_32\bin\ copy /y C:\bin\qt\5.9.2\src\qtbase\lib\Qt5Bluetooth* C:\bin\qt\5.9.2\mingw53_32\lib\ copy /y C:\bin\qt\5.9.2\src\qtbase\lib\libQt5Bluetooth* C:\bin\qt\5.9.2\mingw53_32\lib\ Qt5Bluetooth*.dll will be required for Subsurface deployments. hope that helps. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On 28 September 2018 at 17:44, Dirk Hohndel wrote: > >> On Sep 28, 2018, at 6:36 AM, Anton Lundin wrote: >> >> So, some how we ended up being out of order. >> >> I would need to look at the libdivecomputer log file to. It might tell >> us what actually happened. > > Yes, that would be good to follow up on > >>> i guess the biggest point here is that the BTLE Win32 stack works. >> >> YEY. > > Yes indeed. Now how do I add Lubomir's patches to my built-from-source-anyway > Qt libraries for MXE? > So we can get more people to test "official" binaries? > > So cool. So, so cool. i will post some instructions later today. the changes to make win32-ble to work are part of an official branch. > > (and yes, Lubomir, I'll bring with me next week one of my favorite dive > computers as that is a BLE device that's very different from the OSTC that > you have...) > sounds good. Steve, did you had a change to test again? also please share all the logs + dumps so that we can have a look. thanks. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On 27 September 2018 at 07:38, Dirk Hohndel wrote: > >> On Sep 26, 2018, at 9:34 PM, Lubomir I. Ivanov wrote: >> >> On 27 September 2018 at 07:31, Steve wrote: >>> >>> No I haven't tested more than this once yet. >>> I have put the battery on charge and I will test again with a full battery >>> as it was downloading for a long time so it could be low battery but will >>> confirm later. >> >> something to note here is that my DC is a prototype and it only has 10 dives. >> so they download fairly quick. > > Are you coming to Sofia next week, Lubomir? I could bring another dive > computer for you to test with. > One with more dives on it :-) > yes, bring some BLE DCs please. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On 27 September 2018 at 07:31, Steve wrote: > > No I haven't tested more than this once yet. > I have put the battery on charge and I will test again with a full battery as > it was downloading for a long time so it could be low battery but will > confirm later. > thanks, something to note here is that my DC is a prototype and it only has 10 dives. so they download fairly quick. it if fails again might a good idea to share the logs and libdc dump. you can zip them and attach to an email or via some file sharing service if they are too big. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On 27 September 2018 at 07:16, Steve wrote: > also double check the batter state. i try to keep the battery full while testing. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On 27 September 2018 at 07:16, Steve wrote:
>
> May have spoken too soon.
> Got an error dialog with "Dive data import error" message
>
> Last bit of the cmd window log below:
thanks a lot for testing!!
did you try more than once e.g. restarting and trying again?
it worked nicely for me 2 of 2 times for this OSTC+ unit.
> QTime("13:36:36.353") packet READ ""
> read 20
> QTime("13:36:36.354") packet WAIT
> QTime("13:36:48.367") packet SEND "ff"
> read 20
> QTime("13:36:48.375") packet WAIT
> QTime("13:36:48.508") packet RECV "4cff"
> QTime("13:36:48.508") packet READ "4cff"
> Deleting BLE object
> Finishing download thread: "Dive data import error"
> Set the current dive site: 72475123
> Set the current dive site: 72475123
>
this is entering the land of protocols and such in libdivecomputer
that i don't understand.
so i'm going to have to defer to others.
i guess the biggest point here is that the BTLE Win32 stack works.
lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On 27 September 2018 at 01:43, Linus Torvalds wrote: > On Wed, Sep 26, 2018 at 3:05 PM Lubomir I. Ivanov wrote: >> >> thanks goes to Linus, because i was stuck on this not being able to >> figure out what's going on for a long time... > > I suspect that if I fixed something, I fixed it for the same reason > the debug log got easier to read: less overlapping of IO and GATT > discovery. > > So the Qt windows BLE code may have been confused by IO happening to > one characteristic while another characteristic is still being > discovered, or something. > > But good to know that there's progress on the Windows side, even if it > was unintentional. > i'm not sure, tbh. the way i implemented it in Qt was using a job queue: - writeDescriptor, readDescriptor, writeChar, readChar type jobs are all added to the same queue in a worker thread. so read and write cannot happen in parallel, but rather the jobs wait in line. this was requested by the Qt maintainers. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
looks like the recent libdc + BLE refactor in Subsurface fixed the issues i was having downloading from the OSTC+ on Windows, with my custom Qt build. so it wasn't an issue in the Qt stack. thanks goes to Linus, because i was stuck on this not being able to figure out what's going on for a long time... log for proof: https://pastebin.com/7DHZU855 -- link for testing my latest Subsurface test build for BLE on Win32: https://www.dropbox.com/s/zslq3ughx9ciehj/_deploy_win32_ble.zip?dl=0 instructions: prerequisites: - minimum Windows version for this is 8.1 - make sure that Windows has detected and paired with your DC steps: - extract the _deploy_win32_ble.zip ZIP in a folder somewhere - navigate to the folder with Explorer and start _run.cmd - a console window should open and next to it the Subsurface window - start your BLE dive-computer and make it ready for downloading of dives - in Subsurface goto Import -> Download from divecomputer - select the following options (and pick paths): [x] Save libdivecomputer dumpfile [x] Save libdivecomputer logfile - select the following option: [x] Choose bluetooth download mode - a dialog should open. select "Force LE" for mode, and click "Scan". - your device should appear in the list. select it and click "Save" - the "Device or mount point" field should now show your DC. - click "Download". report back logs and dump files if it doesn't work for you. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: FTDI user space on Windows
On 15 September 2018 at 01:48, Bill Perry wrote:
> Yes, I can do PR. (once I figure out how to do signing)
feel free to ask any github related questions, if any.
> but I don't understand:
>
>> sleeping for small chunks of time can end up being better.
>
> The modification I did used the exact same constant 1ms sleep after each
> ftdi_read_data() call that the current code does but it checked elapsed time
> prior each 1ms sleep
> rather than counting the number of 1ms sleeps until they equaled the desired
> millisecond timeout.
> Counting the number of 1ms sleeps done does not work since it does account for
> the time inside the loop (which can be significant like 100+ ms) since
> sometimes the ftdi_read_data() doesn't return immediately
> when there is no data.
> That is why looking at elapsed time is required.
>
> Are you wanting something smarter than changing the way the loop exits by
> checking elapsed time instead of blindly looping {timout} times?
>
ah, i misunderstood the initial comment, sorry.
i'd encourage you to send the PR so that we can have a look at the
code and discuss it.
thanks
lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: FTDI user space on Windows
On 13 September 2018 at 21:44, Bill Perry wrote: > Just a reminder that last summer I saw that the code in serial_ftdi_read() > doesn't guarantee that a timeout occurs > in the desired timeout period. > Due to the way it is written, you can get MUCH longer delays when the bytes > don't stream in right away or > This was an issue I was fighting last year when I was trying to get retries > to work on the Pelagic data cable with Android. > It actually affects any ftdi device. > This is likely an issue on Windows as well. > > ftdi_read_data() took a few milliseconds of time before returning and that > time is not accounted for. > And on android the the LIBUSB_ERROR_INTERRUPTED was also happening. > This caused the while loop to loop for several minutes before timing out. > My solution (which I posted a patch for to the list back in Nov 2017) was to > get rid of slept and to always sleep for 1ms. > Then rather than comparing slept >= timeout - which doesn't work, was to use > gettimofday() > to check for the elapsed time to check for the desired timeout period. > sleeping for small chunks of time can end up being better. would you like to submit a github PR to address this improvement as per your experiments? lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: FTDI user space on Windows
On 10 September 2018 at 08:05, Dirk Hohndel wrote:
>
> This should be so simple. libtfdi is available in MXE, so just build against
> it, right?
> Except this:
>
> static dc_status_t serial_ftdi_sleep (void *io, unsigned int timeout)
> {
> ftdi_serial_t *device = io;
>
> if (device == NULL)
> return DC_STATUS_INVALIDARGS;
>
> INFO (device->context, "Sleep: value=%u", timeout);
>
> struct timespec ts;
> ts.tv_sec = (timeout / 1000);
> ts.tv_nsec = (timeout % 1000) * 100;
>
> while (nanosleep (, ) != 0) {
> if (errno != EINTR ) {
> SYSERROR (device->context, errno);
> return DC_STATUS_IO;
> }
> }
>
> return DC_STATUS_SUCCESS;
> }
>
> Turns out Windows doesn't have nanosleep. And I can't seem to find a
> function with comparable semantic, unless I use the one in the pthread
> library that is provided by MinGW which is not what we want to do.
> So the question becomes how to represent this with something that gives us
> the same semantic / functionality.
>
proposed patch:
https://github.com/Subsurface-divelog/subsurface/pull/1668
lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: subsurface builds, but dumps core at startup :(
On 12 September 2018 at 00:08, Berthold Stoeger wrote: > Hi Lubomir, > > On Tuesday, 11 September 2018 22:47:18 CEST Lubomir I. Ivanov wrote: > >> as a side note, i just verified that both the map widget and >> Subsurface as a whole work on Ubuntu 17.10 from the 4.8.1 AppImage. > > This is not really surprising, since my problems started exactly the day when > I upgraded from 17.10 to 18.04. If I can help to debug/isolate this problem, > let me know. At the moment I wouldn't even know where to start. Sounds like a > Debian (and by inheritance a Ubuntu / x-buntu) package problem, doesn't it? > > yes, probably. i don't know where to start with this myself. not to anyone surprise (i hope), my knowledge of how the QtLocation code works, is probably only slightly more than others. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: FTDI user space on Windows
On 10 September 2018 at 08:05, Dirk Hohndel wrote:
>
> This should be so simple. libtfdi is available in MXE, so just build against
> it, right?
> Except this:
>
> static dc_status_t serial_ftdi_sleep (void *io, unsigned int timeout)
> {
> ftdi_serial_t *device = io;
>
> if (device == NULL)
> return DC_STATUS_INVALIDARGS;
>
> INFO (device->context, "Sleep: value=%u", timeout);
>
> struct timespec ts;
> ts.tv_sec = (timeout / 1000);
> ts.tv_nsec = (timeout % 1000) * 100;
>
> while (nanosleep (, ) != 0) {
> if (errno != EINTR ) {
> SYSERROR (device->context, errno);
> return DC_STATUS_IO;
> }
> }
>
> return DC_STATUS_SUCCESS;
> }
>
> Turns out Windows doesn't have nanosleep. And I can't seem to find a
> function with comparable semantic, unless I use the one in the pthread
> library that is provided by MinGW which is not what we want to do.
> So the question becomes how to represent this with something that gives us
> the same semantic / functionality.
>
> I am anything but a Windows expert. Suggestions welcome.
>
i can have a look a bit later today.
lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: subsurface builds, but dumps core at startup :(
On 11 September 2018 at 23:39, Salvador Cuñat wrote: > Good night Lubomir. > > On Tue, Sep 11, 2018 at 11:01:04PM +0300, Lubomir I. Ivanov wrote: >> On 11 September 2018 at 22:30, Salvador Cuñat >> wrote: >> > >> > I've also tried 4.8.1 AppImage, but it's also failing: >> > >> > Auto configuration failed >> > 140221893212608:error:25066067:DSO support routines:DLFCN_LOAD:could not >> > load the shared library:dso_dlfcn.c:185:filename(libssl_conf.so): >> > libssl_conf.so: no se puede abrir el fichero del objeto compartido: No >> > existe el fichero o el directorio >> > 140221893212608:error:25070067:DSO support routines:DSO_load:could not >> > load the shared library:dso_lib.c:244: >> > 140221893212608:error:0E07506E:configuration file >> > routines:MODULE_LOAD_DSO:error loading dso:conf_mod.c:285:module=ssl_conf, >> > path=ssl_conf >> > 140221893212608:error:0E076071:configuration file >> > routines:MODULE_RUN:unknown module name:conf_mod.c:222:module=ssl_conf >> > QMutex: destroying locked mutex >> > Violación de segmento >> > >> >> this seems to me like a separate issue. >> the libssl_conf.so library cannot be found in the AppImage. >> > > Absolutely. Just to point out that AppImage is not an option for > debian unstable at this moment. > This seems related to recent changes in openssl package and is the > price of "unstable" tag ;-) > yep, i remembered about those openssl changes now and it think it was a big problem with regards to Qt. not sure what options we had, as this was an old discussion. as a side note, i just verified that both the map widget and Subsurface as a whole work on Ubuntu 17.10 from the 4.8.1 AppImage. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: subsurface builds, but dumps core at startup :(
On 11 September 2018 at 22:30, Salvador Cuñat wrote: > Good night Cristian > > On Tue, Sep 11, 2018 at 08:23:13AM -1000, Linus Torvalds wrote: >> On Tue, Sep 11, 2018 at 8:15 AM Cristian Ionescu-Idbohrn >> wrote: >> > >> > > I had a similar unexplained SIGSEGV that went away when building the >> > > whole tree from scratch. >> > >> > I did so too (I think). Still no joy :( >> >> Note that for me, it was subsurface itself that had the issue, not >> just the googlemaps plugin. >> >> But it was literally a "I can't make sense of that SIGSEGV", so I just >> nuked absolutely everything, so I'm not entirely sure what went wrong. >> > > I've been having same issue (in debian/unstable) for a while now, and, as > Linus > points out subsurface's build dir needs to be removed. I also remove the > googlemaps dir and then run build.sh > > In my case, the binary in subsurface/build still SIGSEVs but the one > installed in install-root/bin (or system wide /usr/local/bin) runs > without map, throwing an error: > > MapWidget.qml: cannot find a plugin named: googlemaps > qrc:/qml/MapWidget.qml:24: Error: Cannot assign [undefined] to > QDeclarativeGeoMapType* > > but at least runs. > > I've also tried 4.8.1 AppImage, but it's also failing: > > Auto configuration failed > 140221893212608:error:25066067:DSO support routines:DLFCN_LOAD:could not load > the shared library:dso_dlfcn.c:185:filename(libssl_conf.so): libssl_conf.so: > no se puede abrir el fichero del objeto compartido: No existe el fichero o el > directorio > 140221893212608:error:25070067:DSO support routines:DSO_load:could not load > the shared library:dso_lib.c:244: > 140221893212608:error:0E07506E:configuration file > routines:MODULE_LOAD_DSO:error loading dso:conf_mod.c:285:module=ssl_conf, > path=ssl_conf > 140221893212608:error:0E076071:configuration file routines:MODULE_RUN:unknown > module name:conf_mod.c:222:module=ssl_conf > QMutex: destroying locked mutex > Violación de segmento > this seems to me like a separate issue. the libssl_conf.so library cannot be found in the AppImage. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: subsurface builds, but dumps core at startup :(
On 11 September 2018 at 20:22, Berthold Stoeger wrote: > Looks like this: > https://github.com/Subsurface-divelog/subsurface/issues/1409 > > Glad that I'm not the only one observing this, as this will hopefully direct > more attention to this problem (which has the nasty side-effect that I can't > run mobile-on-desktop). > i've commented on this before, this is not broken in our AppImage builds. also both my local builds with Qt 5.9.1 on Ubuntu 17.10 and Qt 5.9.0 on Windows 7 do not reproduce the SIGSEGV. this makes the bug report relatively low priority and it ideally the developers that are experiencing the issue should help with debugging and get to the bottom of it. my best bet is miss matched Qt private headers. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: planning for 4.8.2
On 5 September 2018 at 23:32, Dirk Hohndel wrote: > - Documentation: any changes needed? the new `Dive media:` features have experimental state. up for a discussion, if we want to document this feature in the next version or in the near future. /cc Berthold and Willem on this topic. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: auto creating a log file on Windows
On 3 September 2018 at 19:09, Dirk Hohndel wrote: > >> On Sep 3, 2018, at 8:49 AM, Lubomir I. Ivanov wrote: >> >> On 3 September 2018 at 18:31, Dirk Hohndel wrote: >>> >>>> On Sep 3, 2018, at 8:26 AM, Lubomir I. Ivanov wrote: >>>> >>>> On 3 September 2018 at 18:12, Dirk Hohndel wrote: >>>>> Lubomir, >>>>> >>>>> In commit 0c74f7a2c8 you added a feature to automatically create a log >>>>> file >>>>> on Windows when started from a shortcut. I was just going to ask a user to >>>>> send me that log file but realized that I didn't know where it was in the >>>>> file >>>>> system. So I tried this and I cannot find it... >>>>> >>>>> Can you help? >>>>> >>>> >>>> the log files should be written in the folder where subsurface.exe is. >>>> we install Subsurface in "C:\Program Files (x86)\Subsurface" by >>>> default and the log files are created there for me on each run. >>> >>> I tried that. Hmm. Nope, not there. >>> >> >> do you happen to have installed subsurface with an administrator >> account, but run it as a regular user? > > I think that's the default on most systems these days. You elevate your > rights to admin in order to install software, but then you run it without > those admin rights. > >> if this is a permission issue, it can be verified if you try to just >> create a TXT file in the subsurface.exe folder with the regular user >> and see if it works. > > Correct, I get Access Denied - as I should. > >> a possible fix for that would be to always write in the user folder, >> although i think the problem here is something else. >> >> is antivirus software running? >> i've seen AVs blocking the creation of log files before. > > No, I don't think that's it. I think we should create the log file in > AppData\Local\Subsurface > ok, i will send a patch ASAP. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: auto creating a log file on Windows
On 3 September 2018 at 18:31, Dirk Hohndel wrote: > >> On Sep 3, 2018, at 8:26 AM, Lubomir I. Ivanov wrote: >> >> On 3 September 2018 at 18:12, Dirk Hohndel wrote: >>> Lubomir, >>> >>> In commit 0c74f7a2c8 you added a feature to automatically create a log file >>> on Windows when started from a shortcut. I was just going to ask a user to >>> send me that log file but realized that I didn't know where it was in the >>> file >>> system. So I tried this and I cannot find it... >>> >>> Can you help? >>> >> >> the log files should be written in the folder where subsurface.exe is. >> we install Subsurface in "C:\Program Files (x86)\Subsurface" by >> default and the log files are created there for me on each run. > > I tried that. Hmm. Nope, not there. > do you happen to have installed subsurface with an administrator account, but run it as a regular user? if this is a permission issue, it can be verified if you try to just create a TXT file in the subsurface.exe folder with the regular user and see if it works. a possible fix for that would be to always write in the user folder, although i think the problem here is something else. is antivirus software running? i've seen AVs blocking the creation of log files before. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: auto creating a log file on Windows
On 3 September 2018 at 18:12, Dirk Hohndel wrote: > Lubomir, > > In commit 0c74f7a2c8 you added a feature to automatically create a log file > on Windows when started from a shortcut. I was just going to ask a user to > send me that log file but realized that I didn't know where it was in the > file > system. So I tried this and I cannot find it... > > Can you help? > the log files should be written in the folder where subsurface.exe is. we install Subsurface in "C:\Program Files (x86)\Subsurface" by default and the log files are created there for me on each run. i can't seem to find this discussion with the user in the forum or the mailing list. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Subsurface map after filtering dives
On 16 August 2018 at 17:43, Willem Ferguson wrote: > > Attached a screendump using V4.8.1-249 (current version). I hope it is > finger trouble on my side! Only dives at one dive site selected (the one in > the middle of the map). Only these dives shown in dive list. All dives in > filtered list (one site only) selected, but all dive sites in the mapping > area are shown. If I zoom out, all my dive sites are shown on the map. The > same happens when I use any other key in the filter dialog (at least any > other key that I selected). > > Any suggestions? > > i don't think i have any. i tested this in a couple of different scenarios and it works for me. have a look: https://giphy.com/gifs/3j1bDoQvuvaWEQxq70/fullscreen if this still doesn't work for you better file an issue report and provide a minimal divelog with details how to reporduce, but i'm not sure when i'm going to be able to look at that. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Subsurface map after filtering dives
On 16 August 2018 at 16:47, Willem Ferguson wrote: >> > Not possible on my machine (Ubuntu 18.04 running Subsurface 4.8.1-29). > > Willem, i just tested this with the master branch from yesterday and it works. - i've added a "boat" tag to a couple of dives - filtered the list to only show "boat" tagged dives. - selected both dives in the filtered list and the map zoomed over them. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Subsurface map after filtering dives
On 16 August 2018 at 15:55, Willem Ferguson wrote: > Dear Lubomir, > > The interaction between the dive list and the map is pretty interesting. On > the map there is an option to highlight, in the dive list, only those dives > shown on the map. This is a great feature. > > There is the possibility to do the opposite: When the filter tool is used to > manipulate the dive list, only show the filtered dives on the map. This > would be extremely useful to rapidly answer questions such as "Where have I > dived with a drysuit?" or "Where have I dived with John Smith as my buddy?". > Since this is UI stuff I am wary of it and you are the most knowledgeable to > express an opinion on the issue. > isn't possible to filter the divelist and after the list is filtered, selecting the filtered dives which would result on the map focusing on the selection? lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Windows refuses to run Subsurface
On 15 July 2018 at 21:31, Robert Helling wrote: > > Hi, > > today, I was diving (yay!) with a new dive buddy who wasn’t aware of the many great features of Subsurface. So I could convince her to try it out but her Windows refuses to run it with an error message > > > that indicates some compatibility problem (thats what you get when you google the error message). Has anybody else seen this? > > I should mention she is a programmer with Qt experience and wasn’t too reluctant to contribute… > the subsystem responsible for running 32bit apps on 64bit Windows is called WoW64 and it's installed by default on modern versions. if WoW64 is not working there is something quite wrong with this OS setup. other possible causes: - the quality of the screenshot is not very good, but if that right there on the Desktop is the Subsurface installer, it does not have an icon, which could be caused by a partial download - try downloading the installer again? - antivirus software can block the installer - try disabling any AV temporarily? lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On 14 July 2018 at 07:30, Thiago Macieira wrote: > On Friday, 13 July 2018 21:21:32 PDT Lubomir I. Ivanov wrote: >> building qt on windows with mingw (can't look at the version number right >> now). >> >> i was getting a compiler error somewhere in the qmake source >> (something about a duplicate "escape path" method), when building the >> 5.11 branch of qtbase. >> cleaning object code didn't help. to solve this, i removed the qtbase >> submodule completely, initialized it again but this time built the >> 5.10 branch. > > qmake is special because it's not built with qmake (circular dependency). So > its Makefile is much simpler and is not as complete. > > When I have such an issue, I do: > rm -rf qmake > cmd \ /c config.status > > If you're in a regular DOS prompt, probably > > rd /s /q qmake > config.status > thanks, good to know. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On 14 July 2018 at 06:55, Thiago Macieira wrote: > On Friday, 13 July 2018 08:29:42 PDT Lubomir I. Ivanov wrote: >> ...and now i cannot build Qt because of a weird qmake issue which is >> present in 5.10 and 5.11. maybe it's my compiler. >> when i get this sorted i will deploy new test binaries for people to test. > > What's the issue? > building qt on windows with mingw (can't look at the version number right now). i was getting a compiler error somewhere in the qmake source (something about a duplicate "escape path" method), when building the 5.11 branch of qtbase. cleaning object code didn't help. to solve this, i removed the qtbase submodule completely, initialized it again but this time built the 5.10 branch. now it works. i'm getting these weird issues from time to time and the only thing that works consistently for me is to either nuke submodules or the whole local copy. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
the last tagged version is v4.7.8
master is at 52cc51f9061f for me and the last defined tag is: v4.7.8 did we stop using tags for v4.8.x? lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On 14 July 2018 at 02:52, Lubomir I. Ivanov wrote: > On 13 July 2018 at 18:29, Lubomir I. Ivanov wrote: >> On 25 June 2018 at 23:05, Dirk Hohndel wrote: >>> >>>> On Jun 25, 2018, at 10:43 PM, Lubomir I. Ivanov >>>> wrote: >>>> >>>> got a confirmation today that the only way to communicate with GATT >>>> services on Windows / Qt (native API, not the the UWP) is to first go >>>> to the Control Panel and ***manually pair the BLE devices via the >>>> UI***. >>>> there could be hacks for that, that we are not aware of, but Google >>>> shows nothing. >>>> >>>> this means that DC users that have not paired their devices will >>>> experience errors in Subsurface. >>>> >>>> if BLE is to be eventually supported on Windows, this has to be >>>> documented and/or possibly a message has to be shown in the "Download >>>> from DC" dialog in the lines of "please, pair your DC devices in >>>> Control Panel first". >>> >> >> so i was finally able to connect the OSTC+ (BLE) on Windows with Qt, >> but now a Win32 developer introduced new functionality in the windows >> branch for QtConnectivty and the moment i synced with the remote >> branch it required me to build against a newer version of qtbase, >> which completely messed up by Qt build. >> > > i'm able to get the dive download from the OSTC+ on Windows to start > going but early in the process it fails. > detailed log here: > https://pastebin.com/k4fCX13r > > is the OSTC+ download currently working on other platforms? > added Jan Mulder to CC on the above question. link for testing my latest test build for BLE on Win32: https://www.dropbox.com/s/zslq3ughx9ciehj/_deploy_win32_ble.zip?dl=0 maybe other DCs work. testing instructions in this email from before: http://lists.subsurface-divelog.org/pipermail/subsurface/2018-June/032171.html lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On 13 July 2018 at 18:29, Lubomir I. Ivanov wrote: > On 25 June 2018 at 23:05, Dirk Hohndel wrote: >> >>> On Jun 25, 2018, at 10:43 PM, Lubomir I. Ivanov wrote: >>> >>> got a confirmation today that the only way to communicate with GATT >>> services on Windows / Qt (native API, not the the UWP) is to first go >>> to the Control Panel and ***manually pair the BLE devices via the >>> UI***. >>> there could be hacks for that, that we are not aware of, but Google >>> shows nothing. >>> >>> this means that DC users that have not paired their devices will >>> experience errors in Subsurface. >>> >>> if BLE is to be eventually supported on Windows, this has to be >>> documented and/or possibly a message has to be shown in the "Download >>> from DC" dialog in the lines of "please, pair your DC devices in >>> Control Panel first". >> > > so i was finally able to connect the OSTC+ (BLE) on Windows with Qt, > but now a Win32 developer introduced new functionality in the windows > branch for QtConnectivty and the moment i synced with the remote > branch it required me to build against a newer version of qtbase, > which completely messed up by Qt build. > i'm able to get the dive download from the OSTC+ on Windows to start going but early in the process it fails. detailed log here: https://pastebin.com/k4fCX13r is the OSTC+ download currently working on other platforms? lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On 25 June 2018 at 23:05, Dirk Hohndel wrote: > >> On Jun 25, 2018, at 10:43 PM, Lubomir I. Ivanov wrote: >> >> got a confirmation today that the only way to communicate with GATT >> services on Windows / Qt (native API, not the the UWP) is to first go >> to the Control Panel and ***manually pair the BLE devices via the >> UI***. >> there could be hacks for that, that we are not aware of, but Google >> shows nothing. >> >> this means that DC users that have not paired their devices will >> experience errors in Subsurface. >> >> if BLE is to be eventually supported on Windows, this has to be >> documented and/or possibly a message has to be shown in the "Download >> from DC" dialog in the lines of "please, pair your DC devices in >> Control Panel first". > so i was finally able to connect the OSTC+ (BLE) on Windows with Qt, but now a Win32 developer introduced new functionality in the windows branch for QtConnectivty and the moment i synced with the remote branch it required me to build against a newer version of qtbase, which completely messed up by Qt build. ...and now i cannot build Qt because of a weird qmake issue which is present in 5.10 and 5.11. maybe it's my compiler. when i get this sorted i will deploy new test binaries for people to test. lubomir -- PS: i would like the point out that the qt build system is a peace of cra*p that only works in theory. ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [RFC] UI: Rename "photos"/"images" to a term covering videos as well
On 9 July 2018 at 23:33, Stefan Fuchs wrote: > Hello, > > thanks to Berthold we have the video "lite" support in master now. As a > reference please see: > https://github.com/Subsurface-divelog/subsurface/pull/1463 > > Now I think we should adapt the UI in a way that we rename almost every > occurrence of the term "photos" and "images" to s.th. which covers images > and videos. > What do you think? How should we adapt it? > photos, pictures, images, video, audio etc. falls under "media". lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: crashes when deleting dive computers
On 9 July 2018 at 05:44, Miika Turkia wrote: > On Mon, Jul 9, 2018 at 1:34 AM, Lubomir I. Ivanov > wrote: >> >> a couple of months ago we had this report about crashes when deleting >> dive computers: >> https://github.com/Subsurface-divelog/subsurface/issues/1278 >> >> can anyone reproduce this with the latest master? > > > I cannot reproduce it, not with current master, nor with 4.7.8 AppImage. I > don't have any machine that would work with our PPA provided packages so > cannot test the exact binary :( > thanks for checking. i'm going to close that issue for now. if anyone reproduces it somehow, please re-open. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
crashes when deleting dive computers
a couple of months ago we had this report about crashes when deleting dive computers: https://github.com/Subsurface-divelog/subsurface/issues/1278 can anyone reproduce this with the latest master? thanks lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: QMetaObject::invokeMethod
On 7 July 2018 at 22:36, Robert Helling wrote: > Thiago, > > On 7. Jul 2018, at 18:54, Thiago Macieira wrote: > > Usually, that function is used with Qt::QueuedConnection, which instead of > calling the method indicated right now, it posts an event to the event queue > with the arguments you supply. When the event loop gets to that event, the > method you listed gets finally called. > > Another way of doing the same is by using QTimer::singleShot() with a lambda > that carries your parameters. But this wasn't available before Qt 5.4, so > there's a lot of code (and muscle memory) using invokeMethod(). > > > but this doesn’t seem the application in the subsurface code. If you do > > git grep invokeMethod > > you will find the instances. > the image related calls that don't have a connection type and are technically using Qt::AutoConnection, which detects separate threads. invokeMethod() can be also used to call functions in QML objects. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: iPhone crash
On 7 July 2018 at 21:44, Miika Turkia wrote: >> On 7 Jul 2018, at 21.16, Lubomir I. Ivanov wrote: >> >> could be a good idea to try to crash it in offline mode (i.e. no >> WIFI), to narrow down the potential causes. > > How do I sync with cloud when offlone? :) > no, no. i wanted to check if it's our cloud code that's crashing (maybe the Qt network classes) or perhaps something else. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
