proposed changes to libdc

[Anton Lundin]

On 22 June, 2017 - Dirk Hohndel wrote:

> On Thu, Jun 22, 2017 at 10:22:54PM -0700, Linus Torvalds wrote:
>
> > .. except to be useful, most of those transports should also describe
> > the "device pattern" so that you can actually do sane things.
> > 
> > For example, DC_TRANSPORT_USB_HID on its own is *not* very useful knowledge.
> > 
> > But DC_TRANSPORT_USB_HID, *together* with the USB vendor/device ID
> > information, would be very useful indeed.
> > 
> > Similarly, DC_TRANSPORT_{BT,BLE} is not very useful on its own, but if
> > it comes with a way to match the actual devices in question, it would
> > make a huge difference.
> > 
> > For BLE, we *may* end up wanting secondary information too (ie it may
> > turn out that we'd want to have an enumeration of the UUID's for the
> > sending/receiving service for that dive computer. I'm not entirely
> > sure of that yet, but it may be that we'll need per-backend knowledge
> > like that to make a "generic" GATT interface work.
> 
> That sounds cool. We could pack in a union for each of the transports that
> provides transport specific data like that. I know that Anton wanted
> something like this to detect various FTDI dive computers by their vendor
> and device ID combination. That way we could automatically pick a
> connected device :-)

It's just not VID / PID, but more importantly the Product and
Manufacturer fields. VID / PID will just tell me this is a ftdi device,
but if we can match to things like:
Product: HeinrichsWeikamp OSTC3
Manufacturer: HW

We can just do the right thing.


Best would be if we can use that information on desktop os'es to, to map
whats actually connected to which virtual serial port. It's a bit work,
but it would be cool.


The question is if we should pack this information into our
libdivecomputer branch, or we just should keep this in subsurface. If
we can upstream this, it should go into libdivecomputer, but if Jef
doesn't want it we should just keep it in subsurface and steer clear
from the potential merge hell.


//Anton


-- 
Anton Lundin	+46702-161604