Interest in helping support Garmin dive watches

[Kyle Brown]

Hello,

I wanted to introduce myself and express my interest in helping to improve subsurface. Specifically, I would like to help improve the integration with Garmin devices. This desire is a bit self-serving since I am a user of Garmin products. I also know from some basic web searching that I might not be able to actually accomplish much more than already exists. 

I have been in software for a bit, but I have never found an OSS project I felt strongly enough to support; the desire has been there. I mention this because I would like to first check whether your project is interested in patches related to the subsurfaces integration with Garmin. 

I am sure you are busy, and I need some time to get oriented to a working build and development environment. I also happen to be a Windows user, which may be helpful given what I see of the Windows build system, anyway. 

Please let me know if this is not the correct venue for such a message (very new to this side of software). 

Kind regards,

Kyle Brown

[Michael Keller]

Hi Kyle.

On 11/04/2026 14:26, Kyle Brown wrote:
> I wanted to introduce myself and express my interest in helping to
> improve subsurface. Specifically, I would like to help improve the
> integration with Garmin devices. This desire is a bit self-serving
> since I am a user of Garmin products. I also know from some basic web
> searching that I might not be able to actually accomplish much more
> than already exists.

Ok, can you be a bit more specific about what additional data that you
would like for the current Garmin importer to import?

> I have been in software for a bit, but I have never found an OSS
> project I felt strongly enough to support; the desire has been there.
> I mention this because I would like to first check whether your
> project is interested in patches related to the subsurfaces
> integration with Garmin.

Sure, help is always welcome.

> I am sure you are busy, and I need some time to get oriented to a
> working build and development environment. I also happen to be a
> Windows user, which may be helpful given what I see of the Windows
> build system, anyway.

Windows is kind of a 'second class citizen' in the Subsurface build
environment, and the MSVC based build is practically brand new. In the
past we used MXE (https://mxe.cc/) to build our Windows binaries on
linux, but this doesn't have support for the library versions that our
latest version requires, which has forced the move to MSVC.

So help with improving the MSVC build is always welcome.

> Please let me know if this is not the correct venue for such a message
> (very new to this side of software).

In here is fine, or if you have suggestions for code changes it will be
easiest if you open a pull request to allow people to try them out and
discuss.


Ngā mihi

  Michael Keller

[Dirk Hohndel]

Hi Kyle,

Welcome to Subsurface!

We have a developer mailing list I can add you to if you would like.

Yes, Windows is challenging. I just recently managed to get the MSVC build working, so I'm guessing there are some rough edges there. Previously our Windows builds were cross compiled...

Help is very welcome.

Garmin integration is a bit of a mixed bag. They changed the way the watches talk to computers a couple of times. Which model do you have?

Anyway, I'm happy to hear that you want to contribute and look forward to working with you.

If you need any help with getting things set up for building, please let me know. I think I'm the only one who has worked on the MSVC build

/D

[Kyle Brown]

Dirk,

> We have a developer mailing list I can add you to if you would like.

That sounds good. Please do.

> Garmin integration is a bit of a mixed bag. They changed how the watches communicate with computers a couple of times. Which model do you have?

I noticed some grumbling on here about them using MTP. I have also seen elsewhere that that has been problematic, so that makes sense. I am using a Garmin Descent MK 3i 51mm.

> Anyway, I'm happy to hear that you want to contribute and look forward to working with you.

>
> If you need any help with getting things set up for building, please let me know. I think I'm the only one who has worked on the MSVC build

Likewise! Will do, I am going to try to get things working myself first to see if I can learn by fire. 

[Kyle Brown]

I opened an issue after some investigation. https://github.com/subsurface/libdc/issues/110

Also, Michael, I thought I had responded to you, but I don't see my response. My apologies. 

> Ok, can you be a bit more specific about what additional data that you
> would like for the current Garmin importer to import?

I was unclear; there is no data problem once I have the fit files. I want the import button in Subsurface to "just work."

>  Windows is kind of a 'second class citizen' 

So I have seen. It took me most of the weekend to get a working build of libdc that I could debug locally. I wasn't actually using MSVC, though. I happen to like the JetBrains product line, so I was using Clion and just learning all about make and autoconfig in MYSYS2.

> In here is fine, or if you have suggestions for code changes it will be
> easiest if you open a pull request to allow people to try them out and
> discuss.

I opened an issue instead. I don't have a working poc yet. see above. 

[Dirk Hohndel]

Hi Kyle

On Apr 13, 2026, at 14:03, Kyle Brown wrote:

I opened an issue after some investigation. https://github.com/subsurface/libdc/issues/110

> Ok, can you be a bit more specific about what additional data that you
> would like for the current Garmin importer to import?

I was unclear; there is no data problem once I have the fit files. I want the import button in Subsurface to "just work."

Don't we all. However... that's far more complicated than might be obvious.

>  Windows is kind of a 'second class citizen' 

So I have seen. It took me most of the weekend to get a working build of libdc that I could debug locally. I wasn't actually using MSVC, though. I happen to like the JetBrains product line, so I was using Clion and just learning all about make and autoconfig in MYSYS2.

And there are some interesting differences here.

MSYS2 can only build the Qt 5 build -- and there we actually had (at least for a while) a working libmtp implementation. You can indeed cross-build libmtp for Windows and under certain circumstances that does work (and I have tested it with my own Descent Mk2i)

But: we are moving to the MSVC build specifically because you cannot build a working Qt 6 version of Subsurface. QtLocation from Qt 6 doesn't build with MSYS2, and the BLE implementation in uses with MSYS2 doesn't play nicely with Qt 6, either.

On the flip side, libmtp doesn't appear to have a working MSVC build.

(and may I pause for a moment and just silently scream into the void about just what a ridiculously painful and bad experience software development under Windows is???)

A lot of open source libraries can be compiled that way, and it appears that https://github.com/microsoft/vcpkg/ is a really good collection of them

One of the outliers is libmtp because that only has autotools configuration and that's something that does not work with MSVC.

I have started on a cmake based build configuration for libmtp, but got sidetracked and never managed to get this to work. Once we have that, a vcpkg port seems at least feasible, which might address your issue in the future (but I'm not sure if there are other underlying issues that will stop this from working in the end... my first step was to actually get a build working so that I could test this.

/D

[Kyle Brown]

Dirk,

> we are moving to the MSVC build specifically because you cannot build a working Qt 6 version of Subsurface

It sounds like I'm going to have to spend another weekend figuring out how to use MSVC. I would still prefer to use Clion, so I will just have to sort out how to make it play nicely. 

In my issue, I proposed that I could implement the connection using the Windows-specific MTP implementation. https://learn.microsoft.com/en-us/windows-hardware/drivers/portable . Looking at the current implementation, much of the build depends on things being present (not a native C dev, so this is new to me), or it is just macro'd away. I was thinking I could do the same. If the Windows library is detected (i.e., building on or for a Windows system), include the required transport adapter. 

It sounds like there might already be some existing work to use libmtp natively in some capacity that is incomplete. Do you have a strong opinion on which way I should pursue this? 

Regards,

Kyle Brown

(385)-888-6015

kam1...@gmail.com

--
You received this message because you are subscribed to the Google Groups "Subsurface Divelog" group.
To unsubscribe from this group and stop receiving emails from it, send an email to subsurface-dive...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/subsurface-divelog/128D6EDA-683F-4530-9CF8-1872C1F66BBA%40hohndel.org.