subject:"Re\: Scubapro Aladin Square"

Re: Scubapro Aladin Square

2017-11-16 Thread Linus Torvalds

On Thu, Nov 16, 2017 at 3:05 PM, Linus Torvalds
 wrote:
>
> Very good. I will try to come up with a better model for the whole USB
> ID selection (because I suspect we'll have a few more models show up
> eventually), but that should be trivial. I'll probably just make it an
> array of "model, vendor, device" entries.

Ok, I pushed out something that *may* work for you into the
Subsurface-branch of libdivecomputer.

It has the USB vendor/device selection array, and the model checks for
the Aladin Square.

It does *not* have the extra "Read the model number" code in the
handshake, so it's not exactly what you tested, but I suspect that was
just leftovers from earlier testing and isn't actually necessary.

But I could easily be wrong, considering how nit-picky that dive
computer was with the whole USB HID packet format.

So could you test current Subsurface-branch with no other patches?

Oh, and I just noticed that Jef had actually pushed out his changes to
his branch. I should have checked before I made my changes.

Jef had picked a different name in uwatec_smart_parser.c from that
"SQUARE" (and I agree - and like Jef, I had used ALADINSQUARE in
scubapro_g2.c).

But I kept my USB ID array.

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

Re: Scubapro Aladin Square

2017-11-16 Thread Linus Torvalds

On Thu, Nov 16, 2017 at 2:44 PM, vavincavent  wrote:
>
> In my local files it's ok for downloading and analysing of the dives!
>
> You'll find attached the files i've change.

Very good. I will try to come up with a better model for the whole USB
ID selection (because I suspect we'll have a few more models show up
eventually), but that should be trivial. I'll probably just make it an
array of "model, vendor, device" entries.

One more question: does the Square actually need that model number
query for handshaking, or is that just leftovers? IOW, what happens if
you remove these lines

// Read the model number.
unsigned char cmd_model[1] = {0x10};
unsigned char res_model[1] = {0};
status = scubapro_g2_transfer (device, cmd_model, sizeof
(cmd_model), res_model, sizeof (res_model));
if (status != DC_STATUS_SUCCESS)
goto error_free;

from scubapro_g2_device_open()? I suspect that change shouldn't
matter, and is just left-overs from the other trials..

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

Re: Scubapro Aladin Square

2017-11-16 Thread Linus Torvalds

On Wed, Nov 15, 2017 at 10:20 PM, vavincavent  wrote:
>
> In libdivecomputer library, we have 2 branches (libdivecomputer and
> libdc). One is with uwatec_g2.c and the other with scubapro_g2.c.
> Can you explain me the difference and wich one is the better for me?

The only one that works with subsurface is the subsurface branch.

The reason is that we use a string interface extension that Jef has
never merged despite several attempts from our side to get it
upstream. It's required for sane handling of "misc" things, like
modern events that don't match the libdivecomputer enumeration model,
or things like getting proper serial numbers and battery level
information etc.

Similarly, the subsurface branch has support for custom IO interfaces,
which we use for Bluetooth LE.

The particular issue of the Scubapro G2 file is that I did the code to
download from USB and bluetooth, and felt that it should be called
"Scubapro", because that's what the dive computers are sold as. Jef
took _that_ part of our subsurface work, but wanted to call it Uwatek
(that's the subsidiary that designs the dive computers).

But the code is largely in sync. I say "largely", because since Jef
hasn't taken our custom IO layer changes, the actual low-level packet
handling code isn't the same. I try to generally keep the differences
fairly minimal, just to make it easier to merge.

I have offered Jef to send a clean patch-series to merge all the
features we need and try to get back to a unified code base, but Jef
has not accepted. And I don't have the inclination or time to fight
about it. So I'm just passively-aggressively pointing out that
upstream libdivecomputer isn't good enough for us.

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

Re: Scubapro Aladin Square

2017-11-16 Thread Dirk Hohndel

On Thu, Nov 16, 2017 at 07:20:40AM +0100, vavincavent wrote:
> 
> In libdivecomputer library, we have 2 branches (libdivecomputer and
> libdc). One is with uwatec_g2.c and the other with scubapro_g2.c.
> Can you explain me the difference and wich one is the better for me?

libdivecomputer at http://git.libdivecomputer.org/libdivecomputer.git
is the libdivecomputer upstream project that Jef is maintaining.

Because of a fair number of changes that the Subsurface team has proposed
over time and that Jef didn't want in his project, we ended up with our
own branch of libdivecomputer which we try to keep in sync with his on a
fairly frequent basis. You can find our version (which all Subsurface
binaries are built against) at https://github.com/Subsurface-divelog/libdc

That second repository only has a Subsurface-branch branch (to make it
even more obvious that this is our own flavor).

/D

> Le mardi 14 novembre 2017 à 23:12 +0100, Jef Driesen a écrit :
> > On 14-11-17 23:04, Linus Torvalds wrote:
> > > On Tue, Nov 14, 2017 at 2:00 PM, vavincavent  > > > wrote:
> > > > 
> > > > Now i think it's the analysis of the datas???
> > > 
> > > Oh, I thought it already worked?
> > > 
> > > When  you ask subsurface to generate a dump file, it will not
> > > actually
> > > import the dives at all.
> > > 
> > > But now that the communication is working, uncheck that, and see if
> > > the download just works and the dives get imported..
> > 
> > The parsing needs some changes too for the new model number. The
> > attached patch 
> > is what I have so far.
> > 
> > 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: Scubapro Aladin Square

2017-11-15 Thread vavincavent

Jef, Linus,

In libdivecomputer library, we have 2 branches (libdivecomputer and
libdc). One is with uwatec_g2.c and the other with scubapro_g2.c.
Can you explain me the difference and wich one is the better for me?

Vincent.

Le mardi 14 novembre 2017 à 23:12 +0100, Jef Driesen a écrit :
> On 14-11-17 23:04, Linus Torvalds wrote:
> > On Tue, Nov 14, 2017 at 2:00 PM, vavincavent  > > wrote:
> > > 
> > > Now i think it's the analysis of the datas???
> > 
> > Oh, I thought it already worked?
> > 
> > When  you ask subsurface to generate a dump file, it will not
> > actually
> > import the dives at all.
> > 
> > But now that the communication is working, uncheck that, and see if
> > the download just works and the dives get imported..
> 
> The parsing needs some changes too for the new model number. The
> attached patch 
> is what I have so far.
> 
> Jef
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Scubapro Aladin Square

2017-11-14 Thread vavincavent

Sorry, but i'm not a programmer, how to use this patch?
Do i need to download from git?

Vincent.

Le mardi 14 novembre 2017 à 23:12 +0100, Jef Driesen a écrit :
> On 14-11-17 23:04, Linus Torvalds wrote:
> > On Tue, Nov 14, 2017 at 2:00 PM, vavincavent  > > wrote:
> > > 
> > > Now i think it's the analysis of the datas???
> > 
> > Oh, I thought it already worked?
> > 
> > When  you ask subsurface to generate a dump file, it will not
> > actually
> > import the dives at all.
> > 
> > But now that the communication is working, uncheck that, and see if
> > the download just works and the dives get imported..
> 
> The parsing needs some changes too for the new model number. The
> attached patch 
> is what I have so far.
> 
> Jef
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Scubapro Aladin Square

2017-11-14 Thread vavincavent

The download works, but the dives are not imported.

Vincent.

Le mardi 14 novembre 2017 à 14:04 -0800, Linus Torvalds a écrit :
> On Tue, Nov 14, 2017 at 2:00 PM, vavincavent 
> wrote:
> > 
> > Now i think it's the analysis of the datas???
> 
> Oh, I thought it already worked?
> 
> When  you ask subsurface to generate a dump file, it will not
> actually
> import the dives at all.
> 
> But now that the communication is working, uncheck that, and see if
> the download just works and the dives get imported..
> 
>  Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Scubapro Aladin Square

2017-11-14 Thread Jef Driesen


On 14-11-17 23:04, Linus Torvalds wrote:

On Tue, Nov 14, 2017 at 2:00 PM, vavincavent  wrote:


Now i think it's the analysis of the datas???


Oh, I thought it already worked?

When  you ask subsurface to generate a dump file, it will not actually
import the dives at all.

But now that the communication is working, uncheck that, and see if
the download just works and the dives get imported..


The parsing needs some changes too for the new model number. The attached patch 
is what I have so far.


Jef
>From 9f18c74c1c576b34ee25591f5c6e999592e1e7ae Mon Sep 17 00:00:00 2001
From: Jef Driesen 
Date: Mon, 13 Nov 2017 09:30:41 +0100
Subject: [PATCH] Add support for the Scubapro Aladin Square

---
 src/descriptor.c  |  1 +
 src/device.c  |  2 +-
 src/uwatec_g2.c   | 14 --
 src/uwatec_g2.h   |  2 +-
 src/uwatec_smart_parser.c |  8 ++--
 5 files changed, 21 insertions(+), 6 deletions(-)

diff --git a/src/descriptor.c b/src/descriptor.c
index 6a2d6959..52186f44 100644
--- a/src/descriptor.c
+++ b/src/descriptor.c
@@ -139,6 +139,7 @@ static const dc_descriptor_t g_descriptors[] = {
 	/* Scubapro G2 */
 #ifdef USBHID
 	{"Scubapro", "Aladin Sport Matrix", DC_FAMILY_UWATEC_G2, 0x17},
+	{"Scubapro", "Aladin Square",   DC_FAMILY_UWATEC_G2, 0x22},
 	{"Scubapro", "G2",  DC_FAMILY_UWATEC_G2, 0x32},
 #endif
 	/* Reefnet */
diff --git a/src/device.c b/src/device.c
index 6277c900..349ed1d6 100644
--- a/src/device.c
+++ b/src/device.c
@@ -140,7 +140,7 @@ dc_device_open (dc_device_t **out, dc_context_t *context, dc_descriptor_t *descr
 		rc = uwatec_meridian_device_open (&device, context, name);
 		break;
 	case DC_FAMILY_UWATEC_G2:
-		rc = uwatec_g2_device_open (&device, context);
+		rc = uwatec_g2_device_open (&device, context, dc_descriptor_get_model (descriptor));
 		break;
 	case DC_FAMILY_REEFNET_SENSUS:
 		rc = reefnet_sensus_device_open (&device, context, name);
diff --git a/src/uwatec_g2.c b/src/uwatec_g2.c
index 4ef949fa..a30c7bda 100644
--- a/src/uwatec_g2.c
+++ b/src/uwatec_g2.c
@@ -35,6 +35,8 @@
 #define RX_PACKET_SIZE 64
 #define TX_PACKET_SIZE 32
 
+#define SQUARE0x22
+
 typedef struct uwatec_g2_device_t {
 	dc_device_t base;
 	dc_usbhid_t *usbhid;
@@ -178,7 +180,7 @@ uwatec_g2_handshake (uwatec_g2_device_t *device)
 
 
 dc_status_t
-uwatec_g2_device_open (dc_device_t **out, dc_context_t *context)
+uwatec_g2_device_open (dc_device_t **out, dc_context_t *context, unsigned int model)
 {
 	dc_status_t status = DC_STATUS_SUCCESS;
 	uwatec_g2_device_t *device = NULL;
@@ -200,7 +202,15 @@ uwatec_g2_device_open (dc_device_t **out, dc_context_t *context)
 	device->devtime = 0;
 
 	// Open the irda socket.
-	status = dc_usbhid_open (&device->usbhid, context, 0x2e6c, 0x3201);
+	unsigned int vid = 0, pid = 0;
+	if (model == SQUARE) {
+		vid = 0xc251;
+		pid = 0x2006;
+	} else {
+		vid = 0x2e6c;
+		pid = 0x3201;
+	}
+	status = dc_usbhid_open (&device->usbhid, context, vid, pid);
 	if (status != DC_STATUS_SUCCESS) {
 		ERROR (context, "Failed to open USB device");
 		goto error_free;
diff --git a/src/uwatec_g2.h b/src/uwatec_g2.h
index c7ac7ca3..801e15d3 100644
--- a/src/uwatec_g2.h
+++ b/src/uwatec_g2.h
@@ -31,7 +31,7 @@ extern "C" {
 #endif /* __cplusplus */
 
 dc_status_t
-uwatec_g2_device_open (dc_device_t **device, dc_context_t *context);
+uwatec_g2_device_open (dc_device_t **device, dc_context_t *context, unsigned int model);
 
 #ifdef __cplusplus
 }
diff --git a/src/uwatec_smart_parser.c b/src/uwatec_smart_parser.c
index e0726e41..e47320c5 100644
--- a/src/uwatec_smart_parser.c
+++ b/src/uwatec_smart_parser.c
@@ -46,6 +46,7 @@
 #define GALILEOTRIMIX 0x19
 #define SMARTZ0x1C
 #define MERIDIAN  0x20
+#define SQUARE0x22
 #define CHROMIS   0x24
 #define MANTIS2   0x26
 #define G20x32
@@ -522,7 +523,8 @@ uwatec_smart_parser_cache (uwatec_smart_parser_t *parser)
 if (parser->model == GALILEO || parser->model == GALILEOTRIMIX ||
 	parser->model == ALADIN2G || parser->model == MERIDIAN ||
 	parser->model == CHROMIS || parser->model == MANTIS2 ||
-	parser->model == G2 || parser->model == ALADINSPORTMATRIX) {
+	parser->model == G2 || parser->model == ALADINSPORTMATRIX ||
+	parser->model == SQUARE) {
 	unsigned int offset = header->tankpressure + 2 * i;
 	endpressure   = array_uint16_le(data + offset);
 	beginpressure = array_uint16_le(data + offset + 2 * header->ngases);
@@ -600,6 +602,7 @@ uwatec_smart_parser_create (dc_parser_t **out, dc_context_t *context, unsigned i
 	case MERIDIAN:
 	case CHROMIS:
 	case MANTIS2:
+	case SQUARE:
 		parser->headersize = 152;
 		parser->header = &uwatec_smart_galileo_header;
 		parser->samples = uwatec_smart_galileo_samples;
@@ -952,7 +955,8 @@ uwatec_smart_parse (uwatec_smart_parser_t *parser, dc_sample_callback_t callback
 		if (parser->model == GALILEO || parser->model == GALILEOTRIMIX ||
 			parser->mod

Re: Scubapro Aladin Square

2017-11-14 Thread vavincavent

Download ok, but after i have an error message.
"impossible de créer un analyseur pour Scubapro
G2"

Serial number of the& dive computer is ok, but after...


Vincent.

Le mardi 14 novembre 2017 à 14:04 -0800, Linus Torvalds a écrit :
> On Tue, Nov 14, 2017 at 2:00 PM, vavincavent 
> wrote:
> > 
> > Now i think it's the analysis of the datas???
> 
> Oh, I thought it already worked?
> 
> When  you ask subsurface to generate a dump file, it will not
> actually
> import the dives at all.
> 
> But now that the communication is working, uncheck that, and see if
> the download just works and the dives get imported..
> 
>  Linus___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Scubapro Aladin Square

2017-11-14 Thread Linus Torvalds

On Tue, Nov 14, 2017 at 2:00 PM, vavincavent  wrote:
>
> Now i think it's the analysis of the datas???

Oh, I thought it already worked?

When  you ask subsurface to generate a dump file, it will not actually
import the dives at all.

But now that the communication is working, uncheck that, and see if
the download just works and the dives get imported..

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

Re: Scubapro Aladin Square

2017-11-14 Thread vavincavent

Thanks a lot Linus for your help to pass the step, thanks to Jef too!

Now i think it's the analysis of the datas???

Berthold?

Vincent.

Le mardi 14 novembre 2017 à 13:50 -0800, Linus Torvalds a écrit :
> On Tue, Nov 14, 2017 at 1:44 PM, vavincavent 
> wrote:
> > YES!!
> > a step passed!
> 
> Ok. So it really was that "I want 32-byte only packets".
> 
> Will do it in upstream libdivecomputer, I've got some other things
> pending too. I'm just _also_ in the middle of the kernel merge
> window.
> 
> We'll have to figure out how to sanely do that USB ID thing sanely. I
> haven't looked at that yet. I think I saw Berthold comment on it, but
> as I mentioned, I've been busy..
> 
> Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Scubapro Aladin Square

2017-11-14 Thread Linus Torvalds

On Tue, Nov 14, 2017 at 1:44 PM, vavincavent  wrote:
> YES!!
> a step passed!

Ok. So it really was that "I want 32-byte only packets".

Will do it in upstream libdivecomputer, I've got some other things
pending too. I'm just _also_ in the middle of the kernel merge window.

We'll have to figure out how to sanely do that USB ID thing sanely. I
haven't looked at that yet. I think I saw Berthold comment on it, but
as I mentioned, I've been busy..

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

Re: Scubapro Aladin Square

2017-11-14 Thread Linus Torvalds

On Tue, Nov 14, 2017 at 1:21 PM, vavincavent  wrote:
> Sorry, where and what do i change?

This:

  --- a/src/scubapro_g2.c
  +++ b/src/scubapro_g2.c
  @@ -113,7 +113,7 @@ static dc_status_t
   scubapro_g2_transfer(scubapro_g2_device_t *g2, const unsigned char
command[], unsigned int csize, unsigned char answer[], unsigned $
   {
  dc_custom_io_t *io = _dc_context_custom_io(g2->base.context);
  -   unsigned char buf[TX_PACKET_SIZE] = { 0 };
  +   unsigned char buf[TX_PACKET_SIZE+1] = { 0 };
  dc_status_t status = DC_STATUS_SUCCESS;
  size_t transferred = 0;

(yeah, it's whitespace-damaged, but you get the idea).

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

Re: Scubapro Aladin Square

2017-11-14 Thread vavincavent

Sorry, where and what do i change?

Vincent.


Le mardi 14 novembre 2017 à 13:13 -0800, Linus Torvalds a écrit :
> On Tue, Nov 14, 2017 at 1:08 PM, vavincavent 
> wrote:
> > Linus,
> > 
> > i change back
> > if (1) {
> > to
> > if (io->packet_size <64) {
> > 
> > here is the usb.pcap
> 
> Ok, good, everything looks as expected and matches my G2 behavior.
> Except for the lack of reply.
> 
> Try making the buffer size be "TX_PACKET_SIZE + 1" instead of
> TX_PACKET_SIZE. Maybe it really is that URB data length of 31 vs 32
> that matters.
> 
> The G2 clearly doesn't care, but maybe the Aladin Square _really_
> wants just 32-byte packets to even recognize them.
> 
>  Linus.
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Scubapro Aladin Square

2017-11-14 Thread Linus Torvalds

On Tue, Nov 14, 2017 at 1:08 PM, vavincavent  wrote:
> Linus,
>
> i change back
> if (1) {
> to
> if (io->packet_size <64) {
>
> here is the usb.pcap

Ok, good, everything looks as expected and matches my G2 behavior.
Except for the lack of reply.

Try making the buffer size be "TX_PACKET_SIZE + 1" instead of
TX_PACKET_SIZE. Maybe it really is that URB data length of 31 vs 32
that matters.

The G2 clearly doesn't care, but maybe the Aladin Square _really_
wants just 32-byte packets to even recognize them.

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

Re: Scubapro Aladin Square

2017-11-14 Thread vavincavent

Jef, the result with windows and your files.

Vincent

Le mardi 14 novembre 2017 à 21:28 +0100, Jef Driesen a écrit :
> On 14-11-17 21:15, Jef Driesen wrote:
> > On 14-11-17 21:04, Linus Torvalds wrote:
> > > On Tue, Nov 14, 2017 at 11:57 AM, Jef Driesen  > > r.org> wrote:
> > > > 
> > > > I suspect this is not caused by a difference in the libusb
> > > > version, but a
> > > > difference in the subsurface branch of libdivecomputer. If you
> > > > look at the
> > > > g2.log of the successful download on Windows, then you can
> > > > clearly see
> > > > libdivecomputer is sending out 33 byte packets (1 byte report
> > > > id and 32
> > > > bytes payload).
> > > 
> > > .. but that's _exactly_ the usb library difference. On Windows,
> > > it's
> > > using hidapi instead. Just a library difference.
> > 
> > Ah ok, you are referring to libusb vs hidapi. I thought you were
> > talking about a
> > difference in the libusb version.
> > 
> > Give me a couple of minutes to build a libusb based windows
> > version.
> 
> It's available here:
> 
> http://libdivecomputer.org/builds/experimental/windows/libdivecompute
> r-0.dll.libusb
> 
> (remove the .libusb suffix after downloading)
> 
> You'll need the following files as well:
> 
> http://libdivecomputer.org/builds/experimental/windows/g2.cmd
> http://libdivecomputer.org/builds/divinglog/dctool.exe
> http://libdivecomputer.org/builds/divinglog/libusb-1.0.dll
> 
> @Vincent: Can you give this build a try?
> 
> Jef[0.19] DATETIME 2017-11-14T20:42:27Z (1510692147)
[0.000201] VERSION 0.6.0-devel (5bf260ce7be4acb769e6e318dc3c2a8ca2a7f5ca)
[0.000326] Opening the device (Scubapro Aladin Sport Matrix, null).
[0.000431] INFO: Open: vid=c251, pid=2006
[0.039911] INFO: Open: interface=0, endpoints=81,02
[0.127004] WARNING: Number of bytes exceeds the buffer size (34 > 33)! [in usbhid.c:521 (dc_usbhid_write)]
[0.127383] INFO: Write: size=33, data=00011B
[0.326018] INFO: Read: size=64, data=0101
[0.326933] WARNING: Number of bytes exceeds the buffer size (34 > 33)! [in usbhid.c:521 (dc_usbhid_write)]
[0.327210] INFO: Write: size=33, data=00051C1027
[0.422014] INFO: Read: size=64, data=0101
[0.422368] Registering the event handler.
[0.422520] Registering the cancellation handler.
[0.422670] Downloading the memory dump.
[0.422816] Event: progress 0.00% (0/4294967295)
[0.431010] WARNING: Number of bytes exceeds the buffer size (34 > 33)! [in usbhid.c:521 (dc_usbhid_write)]
[0.432424] INFO: Write: size=33, data=000110
[0.454015] INFO: Read: size=64, data=0122
[0.462926] WARNING: Number of bytes exceeds the buffer size (34 > 33)! [in usbhid.c:521 (dc_usbhid_write)]
[0.463249] INFO: Write: size=33, data=000114
[0.517942] INFO: Read: size=64, data=04A6E31C0400
[0.518912] WARNING: Number of bytes exceeds the buffer size (34 > 33)! [in usbhid.c:521 (dc_usbhid_write)]
[0.519182] INFO: Write: size=33, data=00011A
[0.541953] INFO: Read: size=64, data=04CE243C4300
[0.542846] Event: progress 0.00% (9/4294967295)
[0.543559] Event: systime=1510692148, devtime=1128015054
[0.544394] Event: model=34 (0x0022), firmware=0 (0x), serial=69002150 (0x041ce3a6)
[0.550925] WARNING: Number of bytes exceeds the buffer size (34 > 33)! [in usbhid.c:521 (dc_usbhid_write)]
[0.551216] INFO: Write: size=33, data=0009C61027
[0.853943] INFO: Read: size=64, data=046C5900
[0.854241] Event: progress 0.06% (13/22909)
[0.862922] WARNING: Number of bytes exceeds the buffer size (34 > 33)! [in usbhid.c:521 (dc_usbhid_write)]
[0.863196] INFO: Write: size=33, data=0009C41027
[1.213972] INFO: Read: size=64, data=04705900
[1.214259] Event: progress 0.07% (17/22909)
[1.317980] INFO: Read: size=64, data=3FA5A55A5AED0348391B389001080100040202CA070E0527003C012C01000

Re: Scubapro Aladin Square

2017-11-14 Thread Jef Driesen


On 14-11-17 21:33, Linus Torvalds wrote:

On Tue, Nov 14, 2017 at 12:15 PM, Jef Driesen  wrote:

Ah that explains the difference. In upstream libdivecomputer the buffer is
one byte larger:

unsigned char buf[TX_PACKET_SIZE + 1];


And that may actually end up being relevant.

It makes no sense that the receiver cares about the number of padding
bytes, but the code originally always padded out to the full USB HID
packet size of 64 bytes.

The whole confusion between 32/33 is all kinds of crazy, but yes,
maybe some broken other end really wants to see 32 bytes plus report
byte.


For the G2 on windows, the output packet size is 32 bytes, not 64 bytes. The 
input size is indeed 64 bytes. At least that's what the Windows api tells us. (I 
confirmed that by patched hidapi to log those numbers.) And since it wants the 
report id prepended, the total input packet size is 33 bytes. Anything else 
results in an invalid parameter error.


I don't know for sure for the Square, but since it worked, I assume it's the 
same there.


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

Re: Scubapro Aladin Square

2017-11-14 Thread Linus Torvalds

On Tue, Nov 14, 2017 at 12:15 PM, Jef Driesen  wrote:
>
> In of you previous emails, you asked Vincent to patch the
>
> if (io->packet_size < 64) {
>
> to a
>
> if (1) {

Oh, my bad.

That was actually an earlier "let's try to avoid the report byte", and
I'd forgotten entirely about that (and it was pointless, since the
hidusb.c code actually removes the report byte anyway for libusb).

But yes, if Vincent has that code, then that explains why he might get
the smaller size.

Vincent, please remove that particular broken test patch if you have it.

> Ah that explains the difference. In upstream libdivecomputer the buffer is
> one byte larger:
>
> unsigned char buf[TX_PACKET_SIZE + 1];

And that may actually end up being relevant.

It makes no sense that the receiver cares about the number of padding
bytes, but the code originally always padded out to the full USB HID
packet size of 64 bytes.

The whole confusion between 32/33 is all kinds of crazy, but yes,
maybe some broken other end really wants to see 32 bytes plus report
byte.

So Vincent, also do change that

unsigned char buf[TX_PACKET_SIZE];

in src/scubapro_g2.c to have the "+1" while you're at it, and see if
that matters..

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

Re: Scubapro Aladin Square

2017-11-14 Thread Jef Driesen


On 14-11-17 21:15, Jef Driesen wrote:

On 14-11-17 21:04, Linus Torvalds wrote:

On Tue, Nov 14, 2017 at 11:57 AM, Jef Driesen  wrote:


I suspect this is not caused by a difference in the libusb version, but a
difference in the subsurface branch of libdivecomputer. If you look at the
g2.log of the successful download on Windows, then you can clearly see
libdivecomputer is sending out 33 byte packets (1 byte report id and 32
bytes payload).


.. but that's _exactly_ the usb library difference. On Windows, it's
using hidapi instead. Just a library difference.


Ah ok, you are referring to libusb vs hidapi. I thought you were talking about a
difference in the libusb version.

Give me a couple of minutes to build a libusb based windows version.


It's available here:

http://libdivecomputer.org/builds/experimental/windows/libdivecomputer-0.dll.libusb

(remove the .libusb suffix after downloading)

You'll need the following files as well:

http://libdivecomputer.org/builds/experimental/windows/g2.cmd
http://libdivecomputer.org/builds/divinglog/dctool.exe
http://libdivecomputer.org/builds/divinglog/libusb-1.0.dll

@Vincent: Can you give this build a try?

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

Re: Scubapro Aladin Square

2017-11-14 Thread Jef Driesen


On 14-11-17 21:04, Linus Torvalds wrote:

On Tue, Nov 14, 2017 at 11:57 AM, Jef Driesen  wrote:


I suspect this is not caused by a difference in the libusb version, but a
difference in the subsurface branch of libdivecomputer. If you look at the
g2.log of the successful download on Windows, then you can clearly see
libdivecomputer is sending out 33 byte packets (1 byte report id and 32
bytes payload).


.. but that's _exactly_ the usb library difference. On Windows, it's
using hidapi instead. Just a library difference.


Ah ok, you are referring to libusb vs hidapi. I thought you were talking about a 
difference in the libusb version.


Give me a couple of minutes to build a libusb based windows version.


So somehow the subsurface branch doesn't use the right size.
It's probably the csize+1 in this code:


That "+1" should only trigger for GATT, since packet_size is 64 for usbhid, see

 static dc_custom_io_t custom = {
 .packet_size = 64,
 .packet_close = usbhid_packet_close,
 .packet_read  = usbhid_packet_read,
 .packet_write = usbhid_packet_write,
 };

in dc_usbhid_custom_io().

That said, the part that *should* trigger:


 status = io->packet_write(io, buf, sizeof(buf), &transferred);


In of you previous emails, you asked Vincent to patch the

if (io->packet_size < 64) {

to a

if (1) {

So I assumed he did exactly that and in that case the code always takes that 
branch and thus also the csize+1!



Already has that "sizeof(buf)", which is TX_PACKET_SIZE.

The reason it is then turned into 31 is because of this in src/usbhid.c:

 // Skip a report id of zero.
 unsigned char report = buffer[0];
 if (report == 0) {
 buffer++;
 length--;
 }

and that's because at least _my_ usblib doesn't need/want that extra
report byte.

I'm not sure if it hurts, though. So maybe that code could be disabled.


Ah that explains the difference. In upstream libdivecomputer the buffer is one 
byte larger:


unsigned char buf[TX_PACKET_SIZE + 1];

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

Re: Scubapro Aladin Square

2017-11-14 Thread Linus Torvalds

On Tue, Nov 14, 2017 at 12:02 PM, vavincavent  wrote:
> I do : vincent@ASUS-R558UV:~/src/subsurface/build$ sudo tshark -i
> usbmon1 -s 256 -w /tmp/usb.pcap
> Running as user "root" and group "root". This could be dangerous.
> Capturing on 'usbmon1'
> 3794 ^C
>
> then connecting the square
> then testing download
> then : vincent@ASUS-R558UV:~/src/subsurface/build$ sudo udevadm control
> --reload-rules
> then : testing downlod
> then stop tshark

Thanks.

And now I see:

  Frame 2637: 95 bytes on wire (760 bits), 95 bytes captured (760
bits) on interface 0
  USB URB
  [Source: host]
  [Destination: 1.62.2]
  URB id: 0x97a01200d3c0
  URB type: URB_SUBMIT ('S')
  URB transfer type: URB_INTERRUPT (0x01)
  Endpoint: 0x02, Direction: OUT
  Device: 62
  URB bus id: 1
  Device setup request: not relevant ('-')
  Data: present (0)
  URB sec: 1510689518
  URB usec: 339270
  URB status: Operation now in progress (-EINPROGRESS) (-115)
  URB length [bytes]: 31
  Data length [bytes]: 31
  [Response in: 2638]
  [bInterfaceClass: HID (0x03)]
  Unused Setup Header
  Interval: 8
  Start frame: 0
  Copy of Transfer Flags: 0x
  Number of ISO descriptors: 0
  Leftover Capture Data: 0110...

which is what I see with my G2 too. Thanks to getting the earlier
packets, it shows that bInterfaceClass etc correctly, and I see the
endpoints too (they are in the opposite order from the G2 - your IN
endpoint is #1, and out is #2)

But still no actual reply.

How about you disable that report byte code removal that I pointed out
to Jef, in src/usbhid.c:

// Skip a report id of zero.
unsigned char report = buffer[0];
if (report == 0) {
buffer++;
length--;
}

and basically disable the report byte games by doing

unsigned char report = 1;

instead of reading "buffer[0]".

(or alternatively, just remove the code, but then remember to also
remove this part:

if (report == 0) {
nbytes++;
}

which fakes out nbytes).

Maybe your version of libusb really wants that zero report byte like
hidapi does. Or maybe it's that the device really really wants to see
at least 32 bytes of data (the odd Windows thing sends out 33 bytes,
which is really odd, but whatever).

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

Re: Scubapro Aladin Square

2017-11-14 Thread Linus Torvalds

On Tue, Nov 14, 2017 at 11:57 AM, Jef Driesen  wrote:
>
> I suspect this is not caused by a difference in the libusb version, but a
> difference in the subsurface branch of libdivecomputer. If you look at the
> g2.log of the successful download on Windows, then you can clearly see
> libdivecomputer is sending out 33 byte packets (1 byte report id and 32
> bytes payload).

.. but that's _exactly_ the usb library difference. On Windows, it's
using hidapi instead. Just a library difference.

> So somehow the subsurface branch doesn't use the right size.
> It's probably the csize+1 in this code:

That "+1" should only trigger for GATT, since packet_size is 64 for usbhid, see

static dc_custom_io_t custom = {
.packet_size = 64,
.packet_close = usbhid_packet_close,
.packet_read  = usbhid_packet_read,
.packet_write = usbhid_packet_write,
};

in dc_usbhid_custom_io().

That said, the part that *should* trigger:

> status = io->packet_write(io, buf, sizeof(buf), &transferred);

Already has that "sizeof(buf)", which is TX_PACKET_SIZE.

The reason it is then turned into 31 is because of this in src/usbhid.c:

// Skip a report id of zero.
unsigned char report = buffer[0];
if (report == 0) {
buffer++;
length--;
}

and that's because at least _my_ usblib doesn't need/want that extra
report byte.

I'm not sure if it hurts, though. So maybe that code could be disabled.

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

Re: Scubapro Aladin Square

2017-11-14 Thread Jef Driesen


On 14-11-17 20:29, Linus Torvalds wrote:

On Tue, Nov 14, 2017 at 11:17 AM, Linus Torvalds
 wrote:

On Tue, Nov 14, 2017 at 10:52 AM, vavincavent  wrote:

and ... i join usb.pcap file!


Ok, that's a good dump. I see

  - device 1: root hub (1d6b:0002)
  - device 2: logitech LX710 (046d:c517)
  - device 3: RealTek RTS5129 card reader (0bda:0129)
  - device 4: Realtek something (0bda:57de) Wifi?
  - device 59: Lite-On bluetooth donge (04ca:3018)
  - device 60: c251:2006

I assume that matches what you'd expect on that bus?

So it's that device 60.

And the only traffic I see there is (apart from the two empty reads)
is that one URB_INTERRUPT write packet with data 0110.

Very odd.

Also, for some reason wireshark is not showing it as a USB HID
protocol thing. That's odd. I was pretty sure wireshark should do
that.


Oh, it only does that for the setup packets that aren't there.

And I do notice a big difference to what I get when I do a similar dump.

Your dump shows:

   Frame 1573: 66 bytes on wire (528 bits), 66 bytes captured (528
bits) on interface 0
   USB URB
   [Source: host]
   [Destination: 1.60.2]
   URB id: 0x97a01200de40
   URB type: URB_SUBMIT ('S')
   URB transfer type: URB_INTERRUPT (0x01)
   Endpoint: 0x02, Direction: OUT
   Device: 60
   URB bus id: 1
   Device setup request: not relevant ('-')
   Data: present (0)
   URB sec: 1510685037
   URB usec: 39850
   URB status: Operation now in progress (-EINPROGRESS) (-115)
   URB length [bytes]: 2
   Data length [bytes]: 2
   [Response in: 1574]
   [bInterfaceClass: Unknown (0x)]
   Unused Setup Header
   Interval: 8
   Start frame: 0
   Copy of Transfer Flags: 0x
   Number of ISO descriptors: 0
   Leftover Capture Data: 0110

for that 0110 command packet.

When I do it, I get:

   Frame 579: 95 bytes on wire (760 bits), 95 bytes captured (760 bits)
on interface 0
   USB URB
   [Source: host]
   [Destination: 3.6.1]
   URB id: 0x914c372596c0
   URB type: URB_SUBMIT ('S')
   URB transfer type: URB_INTERRUPT (0x01)
   Endpoint: 0x01, Direction: OUT
   Device: 6
   URB bus id: 3
   Device setup request: not relevant ('-')
   Data: present (0)
   URB sec: 1510686848
   URB usec: 546665
   URB status: Operation now in progress (-EINPROGRESS) (-115)
   URB length [bytes]: 31
   Data length [bytes]: 31
   [Response in: 580]
   [bInterfaceClass: HID (0x03)]
   Unused Setup Header
   Interval: 4
   Start frame: 0
   Copy of Transfer Flags: 0x
   Number of ISO descriptors: 0
   Leftover Capture Data: 011b...

Notice the different in Data length and padding.

So I think what's going on here is that different versions of libusb
end up padding things differently, and your dive computer doesn't like
the short packets that your version of libusb creates.

I dunno. Maybe it's some other thing that results in this difference.

Anyway, let's just hack around it and test, See that
"libusb_interrupt_transfer()" call in the function dc_usbhid_write()
in src/usbhit.c?

Add something like

  if (length < 31)
   length = 31;

to just before it. It will send garbage padding, but the dive computer
sends _us_ garbage padding, so that's probably ok.

It's a horrible hack, but it's just for testing.


I suspect this is not caused by a difference in the libusb version, but a 
difference in the subsurface branch of libdivecomputer. If you look at the 
g2.log of the successful download on Windows, then you can clearly see 
libdivecomputer is sending out 33 byte packets (1 byte report id and 32 bytes 
payload). So somehow the subsurface branch doesn't use the right size. It's 
probably the csize+1 in this code:


// BLE GATT protocol?
if (io->packet_size < 64) {
// No report type byte
status = io->packet_write(io, buf+1, csize+1, &transferred);
} else {
status = io->packet_write(io, buf, sizeof(buf), &transferred);
}

I don't have an explanation for the 32 vs 31 bytes.

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

Re: Scubapro Aladin Square

2017-11-14 Thread vavincavent

new usb.pcap file following 

 if (length < 31)
  length = 31;

Vincent

Le mardi 14 novembre 2017 à 11:29 -0800, Linus Torvalds a écrit :
> On Tue, Nov 14, 2017 at 11:17 AM, Linus Torvalds
>  wrote:
> > On Tue, Nov 14, 2017 at 10:52 AM, vavincavent  > m> wrote:
> > > and ... i join usb.pcap file!
> > 
> > Ok, that's a good dump. I see
> > 
> >  - device 1: root hub (1d6b:0002)
> >  - device 2: logitech LX710 (046d:c517)
> >  - device 3: RealTek RTS5129 card reader (0bda:0129)
> >  - device 4: Realtek something (0bda:57de) Wifi?
> >  - device 59: Lite-On bluetooth donge (04ca:3018)
> >  - device 60: c251:2006
> > 
> > I assume that matches what you'd expect on that bus?
> > 
> > So it's that device 60.
> > 
> > And the only traffic I see there is (apart from the two empty
> > reads)
> > is that one URB_INTERRUPT write packet with data 0110.
> > 
> > Very odd.
> > 
> > Also, for some reason wireshark is not showing it as a USB HID
> > protocol thing. That's odd. I was pretty sure wireshark should do
> > that.
> 
> Oh, it only does that for the setup packets that aren't there.
> 
> And I do notice a big difference to what I get when I do a similar
> dump.
> 
> Your dump shows:
> 
>   Frame 1573: 66 bytes on wire (528 bits), 66 bytes captured (528
> bits) on interface 0
>   USB URB
>   [Source: host]
>   [Destination: 1.60.2]
>   URB id: 0x97a01200de40
>   URB type: URB_SUBMIT ('S')
>   URB transfer type: URB_INTERRUPT (0x01)
>   Endpoint: 0x02, Direction: OUT
>   Device: 60
>   URB bus id: 1
>   Device setup request: not relevant ('-')
>   Data: present (0)
>   URB sec: 1510685037
>   URB usec: 39850
>   URB status: Operation now in progress (-EINPROGRESS) (-115)
>   URB length [bytes]: 2
>   Data length [bytes]: 2
>   [Response in: 1574]
>   [bInterfaceClass: Unknown (0x)]
>   Unused Setup Header
>   Interval: 8
>   Start frame: 0
>   Copy of Transfer Flags: 0x
>   Number of ISO descriptors: 0
>   Leftover Capture Data: 0110
> 
> for that 0110 command packet.
> 
> When I do it, I get:
> 
>   Frame 579: 95 bytes on wire (760 bits), 95 bytes captured (760
> bits)
> on interface 0
>   USB URB
>   [Source: host]
>   [Destination: 3.6.1]
>   URB id: 0x914c372596c0
>   URB type: URB_SUBMIT ('S')
>   URB transfer type: URB_INTERRUPT (0x01)
>   Endpoint: 0x01, Direction: OUT
>   Device: 6
>   URB bus id: 3
>   Device setup request: not relevant ('-')
>   Data: present (0)
>   URB sec: 1510686848
>   URB usec: 546665
>   URB status: Operation now in progress (-EINPROGRESS) (-115)
>   URB length [bytes]: 31
>   Data length [bytes]: 31
>   [Response in: 580]
>   [bInterfaceClass: HID (0x03)]
>   Unused Setup Header
>   Interval: 4
>   Start frame: 0
>   Copy of Transfer Flags: 0x
>   Number of ISO descriptors: 0
>   Leftover Capture Data:
> 011b...
> 
> Notice the different in Data length and padding.
> 
> So I think what's going on here is that different versions of libusb
> end up padding things differently, and your dive computer doesn't
> like
> the short packets that your version of libusb creates.
> 
> I dunno. Maybe it's some other thing that results in this difference.
> 
> Anyway, let's just hack around it and test, See that
> "libusb_interrupt_transfer()" call in the function dc_usbhid_write()
> in src/usbhit.c?
> 
> Add something like
> 
>  if (length < 31)
>   length = 31;
> 
> to just before it. It will send garbage padding, but the dive
> computer
> sends _us_ garbage padding, so that's probably ok.
> 
> It's a horrible hack, but it's just for testing.
> 
> Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Scubapro Aladin Square

2017-11-14 Thread Linus Torvalds

On Tue, Nov 14, 2017 at 11:29 AM, Linus Torvalds
 wrote:
>
> Oh, it only does that for the setup packets that aren't there.

Btw, can I get a log with the whole "plug device in" sequence too, so
that I can see that part. I didn't think I'd want it, but it turns out
that I do. Your endpoint numbering is different from the G2 too, so I
think I'd like to see not just the IO part, but the whole "plug in
device and then try to do IO on it".

But do the off "length" hack first. Because maybe that just magically
fixes things.

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

Re: Scubapro Aladin Square

2017-11-14 Thread vavincavent

vincent@ASUS-R558UV:~/src/subsurface/build$ ldd subsurface | grep -i
usb
libusb-1.0.so.0 => /lib/x86_64-linux-gnu/libusb-1.0.so.0
(0x7fcc8d8e2000)

Vincent


Le mardi 14 novembre 2017 à 11:17 -0800, Linus Torvalds a écrit :
> On Tue, Nov 14, 2017 at 10:52 AM, vavincavent 
> wrote:
> > and ... i join usb.pcap file!
> 
> Ok, that's a good dump. I see
> 
>  - device 1: root hub (1d6b:0002)
>  - device 2: logitech LX710 (046d:c517)
>  - device 3: RealTek RTS5129 card reader (0bda:0129)
>  - device 4: Realtek something (0bda:57de) Wifi?
>  - device 59: Lite-On bluetooth donge (04ca:3018)
>  - device 60: c251:2006
> 
> I assume that matches what you'd expect on that bus?
> 
> So it's that device 60.
> 
> And the only traffic I see there is (apart from the two empty reads)
> is that one URB_INTERRUPT write packet with data 0110.
> 
> Very odd.
> 
> Also, for some reason wireshark is not showing it as a USB HID
> protocol thing. That's odd. I was pretty sure wireshark should do
> that.
> 
> What does
> 
> ldd subsurface | grep -i usb
> 
> report for you?
> 
>   Linud
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Scubapro Aladin Square

2017-11-14 Thread Linus Torvalds

On Tue, Nov 14, 2017 at 11:17 AM, Linus Torvalds
 wrote:
> On Tue, Nov 14, 2017 at 10:52 AM, vavincavent  wrote:
>> and ... i join usb.pcap file!
>
> Ok, that's a good dump. I see
>
>  - device 1: root hub (1d6b:0002)
>  - device 2: logitech LX710 (046d:c517)
>  - device 3: RealTek RTS5129 card reader (0bda:0129)
>  - device 4: Realtek something (0bda:57de) Wifi?
>  - device 59: Lite-On bluetooth donge (04ca:3018)
>  - device 60: c251:2006
>
> I assume that matches what you'd expect on that bus?
>
> So it's that device 60.
>
> And the only traffic I see there is (apart from the two empty reads)
> is that one URB_INTERRUPT write packet with data 0110.
>
> Very odd.
>
> Also, for some reason wireshark is not showing it as a USB HID
> protocol thing. That's odd. I was pretty sure wireshark should do
> that.

Oh, it only does that for the setup packets that aren't there.

And I do notice a big difference to what I get when I do a similar dump.

Your dump shows:

  Frame 1573: 66 bytes on wire (528 bits), 66 bytes captured (528
bits) on interface 0
  USB URB
  [Source: host]
  [Destination: 1.60.2]
  URB id: 0x97a01200de40
  URB type: URB_SUBMIT ('S')
  URB transfer type: URB_INTERRUPT (0x01)
  Endpoint: 0x02, Direction: OUT
  Device: 60
  URB bus id: 1
  Device setup request: not relevant ('-')
  Data: present (0)
  URB sec: 1510685037
  URB usec: 39850
  URB status: Operation now in progress (-EINPROGRESS) (-115)
  URB length [bytes]: 2
  Data length [bytes]: 2
  [Response in: 1574]
  [bInterfaceClass: Unknown (0x)]
  Unused Setup Header
  Interval: 8
  Start frame: 0
  Copy of Transfer Flags: 0x
  Number of ISO descriptors: 0
  Leftover Capture Data: 0110

for that 0110 command packet.

When I do it, I get:

  Frame 579: 95 bytes on wire (760 bits), 95 bytes captured (760 bits)
on interface 0
  USB URB
  [Source: host]
  [Destination: 3.6.1]
  URB id: 0x914c372596c0
  URB type: URB_SUBMIT ('S')
  URB transfer type: URB_INTERRUPT (0x01)
  Endpoint: 0x01, Direction: OUT
  Device: 6
  URB bus id: 3
  Device setup request: not relevant ('-')
  Data: present (0)
  URB sec: 1510686848
  URB usec: 546665
  URB status: Operation now in progress (-EINPROGRESS) (-115)
  URB length [bytes]: 31
  Data length [bytes]: 31
  [Response in: 580]
  [bInterfaceClass: HID (0x03)]
  Unused Setup Header
  Interval: 4
  Start frame: 0
  Copy of Transfer Flags: 0x
  Number of ISO descriptors: 0
  Leftover Capture Data: 011b...

Notice the different in Data length and padding.

So I think what's going on here is that different versions of libusb
end up padding things differently, and your dive computer doesn't like
the short packets that your version of libusb creates.

I dunno. Maybe it's some other thing that results in this difference.

Anyway, let's just hack around it and test, See that
"libusb_interrupt_transfer()" call in the function dc_usbhid_write()
in src/usbhit.c?

Add something like

 if (length < 31)
  length = 31;

to just before it. It will send garbage padding, but the dive computer
sends _us_ garbage padding, so that's probably ok.

It's a horrible hack, but it's just for testing.

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

Re: Scubapro Aladin Square

2017-11-14 Thread Linus Torvalds

On Tue, Nov 14, 2017 at 10:52 AM, vavincavent  wrote:
> and ... i join usb.pcap file!

Ok, that's a good dump. I see

 - device 1: root hub (1d6b:0002)
 - device 2: logitech LX710 (046d:c517)
 - device 3: RealTek RTS5129 card reader (0bda:0129)
 - device 4: Realtek something (0bda:57de) Wifi?
 - device 59: Lite-On bluetooth donge (04ca:3018)
 - device 60: c251:2006

I assume that matches what you'd expect on that bus?

So it's that device 60.

And the only traffic I see there is (apart from the two empty reads)
is that one URB_INTERRUPT write packet with data 0110.

Very odd.

Also, for some reason wireshark is not showing it as a USB HID
protocol thing. That's odd. I was pretty sure wireshark should do
that.

What does

ldd subsurface | grep -i usb

report for you?

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

Re: Scubapro Aladin Square

2017-11-13 Thread Anton Lundin

On 13 November, 2017 - Linus Torvalds wrote:

> On Mon, Nov 13, 2017 at 1:45 PM, vavincavent  wrote:
> >
> > sudo tshark -i usbmon1 -s 256 -w usb.pcap
> > tshark: The file to which the capture would be saved ("usb.pcap") could
> > not be opened: Permission denied.
> 
> WTF? You're running as root, and it can't create that file due to
> permission issues?
> 
> I have no idea what is wrong with your setup.

Could be that fuse is involved. Anyway, just dump to /tmp instead of
cwd, where root most definitely can write, and you can read.


//Anton


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

Re: Scubapro Aladin Square

2017-11-13 Thread Linus Torvalds

On Mon, Nov 13, 2017 at 1:45 PM, vavincavent  wrote:
>
> sudo tshark -i usbmon1 -s 256 -w usb.pcap
> tshark: The file to which the capture would be saved ("usb.pcap") could
> not be opened: Permission denied.

WTF? You're running as root, and it can't create that file due to
permission issues?

I have no idea what is wrong with your setup.

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

Re: Scubapro Aladin Square

2017-11-13 Thread vavincavent

vincent@ASUS-R558UV:~/src/subsurface/build$ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 006: ID 04ca:3018 Lite-On Technology Corp. 
Bus 001 Device 004: ID 0bda:57de Realtek Semiconductor Corp. 
Bus 001 Device 003: ID 0bda:0129 Realtek Semiconductor Corp. RTS5129
Card Reader Controller
Bus 001 Device 002: ID 046d:c517 Logitech, Inc. LX710 Cordless Desktop
Laser
Bus 001 Device 054: ID c251:2006 Keil Software, Inc. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

So, Bus 1...

I plug the square, put in download mode...

vincent@ASUS-R558UV:~/src/subsurface/build$ sudo tshark -i usbmon1 -s
256 -w usb.pcap
Running as user "root" and group "root". This could be dangerous.
Capturing on 'usbmon1'
tshark: The file to which the capture would be saved ("usb.pcap") could
not be opened: Permission denied.

vincent@ASUS-R558UV:~/src/subsurface/build$ 

tshark don't stay open...

Vincent



Le lundi 13 novembre 2017 à 13:36 -0800, Linus Torvalds a écrit :
> On Mon, Nov 13, 2017 at 1:28 PM, vavincavent 
> wrote:
> > vincent@ASUS-R558UV:~/src/subsurface/build$ sudo tshark -D
> > Running as user "root" and group "root". This could be dangerous.
> > 1. enp2s0
> > 2. wlp3s0
> > 3. any
> > 4. lo (Loopback)
> > 5. bluetooth0
> > 6. usbmon0
> > 7. nflog
> > 8. nfqueue
> > 9. usbmon1
> > 10. usbmon2
> > 11. cisco (Cisco remote capture)
> > 12. randpkt (Random packet generator)
> > 13. ssh (SSH remote capture)
> 
> Ok, so what does lsusb say when the device is connected? For my
> scubapro, it looks like this:
> 
>   Bus 003 Device 005: ID 2e6c:3201
> 
> so it's on bus 3.
> 
> Depending on the bus, pick the right "usbmonX" device, and then:
> 
>  - plug the device in, and put it in download mode
> 
>  - do "sudo tshark -i usbmonX -s 256 -w usb.pcap" in one terminal
> 
>  - and finally, start subsurface and try to download
> 
> after the download failed, just kill tshark, and send me the pcap
> file.
> 
> (You can look at it with 'wireshark' of course)
> 
>   Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Scubapro Aladin Square

2017-11-13 Thread Linus Torvalds

On Mon, Nov 13, 2017 at 1:28 PM, vavincavent  wrote:
> vincent@ASUS-R558UV:~/src/subsurface/build$ sudo tshark -D
> Running as user "root" and group "root". This could be dangerous.
> 1. enp2s0
> 2. wlp3s0
> 3. any
> 4. lo (Loopback)
> 5. bluetooth0
> 6. usbmon0
> 7. nflog
> 8. nfqueue
> 9. usbmon1
> 10. usbmon2
> 11. cisco (Cisco remote capture)
> 12. randpkt (Random packet generator)
> 13. ssh (SSH remote capture)

Ok, so what does lsusb say when the device is connected? For my
scubapro, it looks like this:

  Bus 003 Device 005: ID 2e6c:3201

so it's on bus 3.

Depending on the bus, pick the right "usbmonX" device, and then:

 - plug the device in, and put it in download mode

 - do "sudo tshark -i usbmonX -s 256 -w usb.pcap" in one terminal

 - and finally, start subsurface and try to download

after the download failed, just kill tshark, and send me the pcap file.

(You can look at it with 'wireshark' of course)

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

Re: Scubapro Aladin Square

2017-11-13 Thread vavincavent

vincent@ASUS-R558UV:~/src/subsurface/build$ sudo tshark -D
Running as user "root" and group "root". This could be dangerous.
1. enp2s0
2. wlp3s0
3. any
4. lo (Loopback)
5. bluetooth0
6. usbmon0
7. nflog
8. nfqueue
9. usbmon1
10. usbmon2
11. cisco (Cisco remote capture)
12. randpkt (Random packet generator)
13. ssh (SSH remote capture)

Vincent


Le lundi 13 novembre 2017 à 13:00 -0800, Linus Torvalds a écrit :
> On Mon, Nov 13, 2017 at 12:10 PM, vavincavent 
> wrote:
> > I'm so sorry, nothing append..
> > 
> > i've made : tshark -i any -w out.pcap
> > but nothing seems to be from usb.
> > 
> > what is the problem??
> 
> What does
> 
> sudo tshark -D
> 
> print?
> 
> It should say something like
> 
>   1. enp5s0
>   2. any
>   3. lo (Loopback)
>   4. virbr0
>   5. bluetooth0
>   6. bluetooth-monitor
>   7. usbmon0
>   8. nflog
>   9. nfqueue
>   10. usbmon1
>   11. usbmon2
>   12. usbmon3
>   13. usbmon4
> 
> and if those usbmon entries don't show up, do
> 
> sudo modprobe usbmon
> 
> to make sure the usbmon module is loaded.
> 
>  Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Scubapro Aladin Square

2017-11-13 Thread Linus Torvalds

On Mon, Nov 13, 2017 at 12:10 PM, vavincavent  wrote:
> I'm so sorry, nothing append..
>
> i've made : tshark -i any -w out.pcap
> but nothing seems to be from usb.
>
> what is the problem??

What does

sudo tshark -D

print?

It should say something like

  1. enp5s0
  2. any
  3. lo (Loopback)
  4. virbr0
  5. bluetooth0
  6. bluetooth-monitor
  7. usbmon0
  8. nflog
  9. nfqueue
  10. usbmon1
  11. usbmon2
  12. usbmon3
  13. usbmon4

and if those usbmon entries don't show up, do

sudo modprobe usbmon

to make sure the usbmon module is loaded.

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

Re: Scubapro Aladin Square

2017-11-13 Thread vavincavent

I'm so sorry, nothing append..

i've made : tshark -i any -w out.pcap
but nothing seems to be from usb.

what is the problem??

Vincent

Le lundi 13 novembre 2017 à 11:38 -0800, Linus Torvalds a écrit :
> On Mon, Nov 13, 2017 at 11:33 AM, vavincavent 
> wrote:
> > tshark problem :
> > 
> > vincent@ASUS-R558UV:~/src/subsurface/build$ tshark -i /dev/ttyUSB0
> > -w
> > out.pcap
> 
> It's not /dev/ttyUSB0.
> 
> It's "usbmonX" (where X is the USB bus number that the device is on).
> 
> You do need to have the "usbmon" kernel module inserted - I think it
> should happen automatically, but you may have to do a "modprobe
> usbmon" if debian requires manual intervention.
> 
>    Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Scubapro Aladin Square

2017-11-13 Thread Linus Torvalds

On Mon, Nov 13, 2017 at 11:33 AM, vavincavent  wrote:
> tshark problem :
>
> vincent@ASUS-R558UV:~/src/subsurface/build$ tshark -i /dev/ttyUSB0 -w
> out.pcap

It's not /dev/ttyUSB0.

It's "usbmonX" (where X is the USB bus number that the device is on).

You do need to have the "usbmon" kernel module inserted - I think it
should happen automatically, but you may have to do a "modprobe
usbmon" if debian requires manual intervention.

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

Re: Scubapro Aladin Square

2017-11-13 Thread vavincavent

tshark problem :

vincent@ASUS-R558UV:~/src/subsurface/build$ tshark -i /dev/ttyUSB0 -w
out.pcap
Capturing on '/dev/ttyUSB0'
tshark: The capture session could not be initiated on interface
'/dev/ttyUSB0' (No such device exists).
Please check to make sure you have sufficient permissions, and that you
have the proper interface or pipe specified.

Vincent


Le lundi 13 novembre 2017 à 11:18 -0800, Linus Torvalds a écrit :
> On Mon, Nov 13, 2017 at 10:47 AM, vavincavent 
> wrote:
> > A little better?? (/etc/udev/rules.d):
> 
> So now you can actually do the IO:
> 
> > The log file :
> > Subsurface: v4.7.4-1-g4d04f74312dc, built with libdivecomputer
> > v0.6.0-
> > devel-Subsurface-branch (7de3a549ee588fef4702ee9d894e390aca43950d)
> > INFO: Open: vid=c251, pid=2006
> > INFO: Open: interface=0, endpoints=81,02
> > INFO: Timeout: value=10
> > ERROR: Usb read interrupt transfer failed (LIBUSB_ERROR_TIMEOUT).
> > [in ../../src/usbhid.c:518 (dc_usbhid_read)]
> > INFO: Read: size=0, data=
> 
> This first one is normal - it comes from the open trying to flush any
> possible previous data, and it normally fails (note the short timeout
> too).
> 
> > INFO: Timeout: value=5000
> > DEBUG: cmd: size=1, data=10
> > INFO: Write: size=2, data=0110
> 
> Here we wrote the one-byte command.
> 
> And then:
> 
> > ERROR: Usb read interrupt transfer failed (LIBUSB_ERROR_TIMEOUT).
> > [in ../../src/usbhid.c:518 (dc_usbhid_read)]
> > INFO: Read: size=0, data=
> > ERROR: read interrupt transfer failed [in
> > ../../src/scubapro_g2.c:78 (receive_data)]
> > ERROR: Failed to receive the answer. [in
> > ../../src/scubapro_g2.c:145 (scubapro_g2_transfer)]
> 
> But the aboive is where we fail to get the expected reply.
> 
> I think I'd really like to see the actual packet trace from this
> failure.
> 
>   Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Scubapro Aladin Square

2017-11-13 Thread Linus Torvalds

On Mon, Nov 13, 2017 at 10:47 AM, vavincavent  wrote:
> A little better?? (/etc/udev/rules.d):

So now you can actually do the IO:

> The log file :
> Subsurface: v4.7.4-1-g4d04f74312dc, built with libdivecomputer v0.6.0-
> devel-Subsurface-branch (7de3a549ee588fef4702ee9d894e390aca43950d)
> INFO: Open: vid=c251, pid=2006
> INFO: Open: interface=0, endpoints=81,02
> INFO: Timeout: value=10
> ERROR: Usb read interrupt transfer failed (LIBUSB_ERROR_TIMEOUT). [in 
> ../../src/usbhid.c:518 (dc_usbhid_read)]
> INFO: Read: size=0, data=

This first one is normal - it comes from the open trying to flush any
possible previous data, and it normally fails (note the short timeout
too).

> INFO: Timeout: value=5000
> DEBUG: cmd: size=1, data=10
> INFO: Write: size=2, data=0110

Here we wrote the one-byte command.

And then:

> ERROR: Usb read interrupt transfer failed (LIBUSB_ERROR_TIMEOUT). [in 
> ../../src/usbhid.c:518 (dc_usbhid_read)]
> INFO: Read: size=0, data=
> ERROR: read interrupt transfer failed [in ../../src/scubapro_g2.c:78 
> (receive_data)]
> ERROR: Failed to receive the answer. [in ../../src/scubapro_g2.c:145 
> (scubapro_g2_transfer)]

But the aboive is where we fail to get the expected reply.

I think I'd really like to see the actual packet trace from this failure.

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

Re: Scubapro Aladin Square

2017-11-13 Thread vavincavent

A little better?? (/etc/udev/rules.d):

The log file :
Subsurface: v4.7.4-1-g4d04f74312dc, built with libdivecomputer v0.6.0-
devel-Subsurface-branch (7de3a549ee588fef4702ee9d894e390aca43950d)
INFO: Open: vid=c251, pid=2006
INFO: Open: interface=0, endpoints=81,02
INFO: Timeout: value=10
ERROR: Usb read interrupt transfer failed (LIBUSB_ERROR_TIMEOUT). [in
../../src/usbhid.c:518 (dc_usbhid_read)]
INFO: Read: size=0, data=
INFO: Timeout: value=5000
DEBUG: cmd: size=1, data=10
INFO: Write: size=2, data=0110
ERROR: Usb read interrupt transfer failed (LIBUSB_ERROR_TIMEOUT). [in
../../src/usbhid.c:518 (dc_usbhid_read)]
INFO: Read: size=0, data=
ERROR: read interrupt transfer failed [in ../../src/scubapro_g2.c:78
(receive_data)]
ERROR: Failed to receive the answer. [in ../../src/scubapro_g2.c:145
(scubapro_g2_transfer)]

Vincent

Le lundi 13 novembre 2017 à 10:28 -0800, Linus Torvalds a écrit :
> On Mon, Nov 13, 2017 at 9:51 AM, vavincavent 
> wrote:
> > I have used scubapro_g2.c joined and this is the log :
> 
> This is the same udev rule problem:
> 
> > Subsurface: v4.7.4-1-g4d04f74312dc, built with libdivecomputer
> > v0.6.0-
> > devel-Subsurface-branch (7de3a549ee588fef4702ee9d894e390aca43950d)
> > INFO: Open: vid=c251, pid=2006
> > INFO: Open: interface=0, endpoints=81,02
> > ERROR: Failed to open the usb device (LIBUSB_ERROR_ACCESS). [in
> > ../../src/usbhid.c:392 (dc_usbhid_open)]
> 
> You simply don't have permissions to access that device.
> 
> So I have this for my G2 to make it world readable and writable:
> 
>   [torvalds@i7 ~]$ cat /usr/lib/udev/rules.d/91-scubapro-g2.rules
> 
>   SUBSYSTEM=="usb",ATTR{idVendor}=="2e6c",ATTR{idProduct}=="3201",
> MODE="0666"
> 
> (NOTE! That udev rule is _one_ line, maybe this email breaks it up).
> 
> You'll obviously have to update the ID to match the Aladin Square,
> and
> you may have to make sure udev rules are reloaded and then plug in
> the
> device again.
> 
>    udevadm control --reload-rules
> 
> Also, I'm not sure where Debian stretch puts the udev rules. I'm
> running Fedora 26, so that /ust/lib/udev/rules.d/ directory is what I
> use. But I think Debian may be using /lib/udev/rules.d, so you need
> to
> check that.
> 
> Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Scubapro Aladin Square

2017-11-13 Thread Linus Torvalds

On Mon, Nov 13, 2017 at 9:51 AM, vavincavent  wrote:
> I have used scubapro_g2.c joined and this is the log :

This is the same udev rule problem:

> Subsurface: v4.7.4-1-g4d04f74312dc, built with libdivecomputer v0.6.0-
> devel-Subsurface-branch (7de3a549ee588fef4702ee9d894e390aca43950d)
> INFO: Open: vid=c251, pid=2006
> INFO: Open: interface=0, endpoints=81,02
> ERROR: Failed to open the usb device (LIBUSB_ERROR_ACCESS). [in 
> ../../src/usbhid.c:392 (dc_usbhid_open)]

You simply don't have permissions to access that device.

So I have this for my G2 to make it world readable and writable:

  [torvalds@i7 ~]$ cat /usr/lib/udev/rules.d/91-scubapro-g2.rules

  SUBSYSTEM=="usb",ATTR{idVendor}=="2e6c",ATTR{idProduct}=="3201", MODE="0666"

(NOTE! That udev rule is _one_ line, maybe this email breaks it up).

You'll obviously have to update the ID to match the Aladin Square, and
you may have to make sure udev rules are reloaded and then plug in the
device again.

   udevadm control --reload-rules

Also, I'm not sure where Debian stretch puts the udev rules. I'm
running Fedora 26, so that /ust/lib/udev/rules.d/ directory is what I
use. But I think Debian may be using /lib/udev/rules.d, so you need to
check that.

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

Re: Scubapro Aladin Square

2017-11-13 Thread vavincavent

I have used scubapro_g2.c joined and this is the log :

Subsurface: v4.7.4-1-g4d04f74312dc, built with libdivecomputer v0.6.0-
devel-Subsurface-branch (7de3a549ee588fef4702ee9d894e390aca43950d)
INFO: Open: vid=c251, pid=2006
INFO: Open: interface=0, endpoints=81,02
ERROR: Failed to open the usb device (LIBUSB_ERROR_ACCESS). [in
../../src/usbhid.c:392 (dc_usbhid_open)]
ERROR: Failed to open Scubapro G2 device [in
../../src/scubapro_g2.c:224 (scubapro_g2_device_open)]

Vincent

Le lundi 13 novembre 2017 à 09:34 -0800, Linus Torvalds a écrit :
> On Mon, Nov 13, 2017 at 9:29 AM, vavincavent 
> wrote:
> > I have little problem with tshark or wireshark. But I try to test
> > this
> > !
> > The result with windows give me hope for the same with DEBIAN!
> 
> Well, you can also just test out the "maybe it's the extra zero byte
> for hidusb" directly, without capturing any packet trace.
> 
> In scubapro_g2_transfer(), see how it does that:
> 
> // BLE GATT protocol?
> if (io->packet_size < 64) {
> // No report type byte
> status = io->packet_write(io, buf+1, csize+1,
> &transferred);
> } else {
> status = io->packet_write(io, buf, sizeof(buf),
> &transferred);
> }
> 
> and the difference is exactly that the BLE GATT stuff does _not_ want
> that silly report type byte.
> 
> libusb doesn't really either - it was added just for hidapi.
> 
> So try just changing that
> 
> if (io->packet_size < 64) {
> 
> to a
> 
> if (1) {
> 
> and see if your Debian case magically works.
> 
> (Of course, this is in _addition_ to all the USB ID hackery to make
> it
> use the right device ID)
> 
> Linus/*
 * libdivecomputer
 *
 * Copyright (C) 2008 Jef Driesen
 *   (C) 2017 Linus Torvalds
 *
 * This library is free software; you can redistribute it and/or
 * modify it under the terms of the GNU Lesser General Public
 * License as published by the Free Software Foundation; either
 * version 2.1 of the License, or (at your option) any later version.
 *
 * This library is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 * Lesser General Public License for more details.
 *
 * You should have received a copy of the GNU Lesser General Public
 * License along with this library; if not, write to the Free Software
 * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
 * MA 02110-1301 USA
 */

#include  // malloc, free
#include 	// strncmp, strstr

#include "scubapro_g2.h"
#include "context-private.h"
#include "device-private.h"
#include "usbhid.h"
#include "array.h"
#include "platform.h"

#define ISINSTANCE(device) dc_device_isinstance((device), &scubapro_g2_device_vtable)

#define RX_PACKET_SIZE 64
#define TX_PACKET_SIZE 32

#define ALADINSPORTMATRIX 0x17

typedef struct scubapro_g2_device_t {
	dc_device_t base;
	unsigned int timestamp;
	unsigned int devtime;
	dc_ticks_t systime;
} scubapro_g2_device_t;

static dc_status_t scubapro_g2_device_set_fingerprint (dc_device_t *device, const unsigned char data[], unsigned int size);
static dc_status_t scubapro_g2_device_dump (dc_device_t *abstract, dc_buffer_t *buffer);
static dc_status_t scubapro_g2_device_foreach (dc_device_t *abstract, dc_dive_callback_t callback, void *userdata);
static dc_status_t scubapro_g2_device_close (dc_device_t *abstract);

static const dc_device_vtable_t scubapro_g2_device_vtable = {
	sizeof(scubapro_g2_device_t),
	DC_FAMILY_UWATEC_G2,
	scubapro_g2_device_set_fingerprint, /* set_fingerprint */
	NULL, /* read */
	NULL, /* write */
	scubapro_g2_device_dump, /* dump */
	scubapro_g2_device_foreach, /* foreach */
	NULL, /* timesync */
	scubapro_g2_device_close /* close */
};

static dc_status_t
scubapro_g2_extract_dives (dc_device_t *device, const unsigned char data[], unsigned int size, dc_dive_callback_t callback, void *userdata);

static int receive_data(scubapro_g2_device_t *g2, unsigned char *buffer, int size, dc_event_progress_t *progress)
{
	dc_custom_io_t *io = _dc_context_custom_io(g2->base.context);
	while (size) {
		unsigned char buf[RX_PACKET_SIZE] = { 0 };
		size_t transferred = 0;
		dc_status_t rc;
		int len;

		rc = io->packet_read(io, buf, sizeof(buf), &transferred);
		if (rc != DC_STATUS_SUCCESS) {
			ERROR(g2->base.context, "read interrupt transfer failed");
			return -1;
		}
		if (transferred < 1) {
			ERROR(g2->base.context, "incomplete read interrupt transfer (got empty packet)");
			return -1;
		}
		len = buf[0];
		if (transferred < len + 1) {
			ERROR(g2->base.context, "small packet read (got %zu, expected at least %d)", transferred, len + 1);
			return -1;
		}
		if (len >= sizeof(buf)) {
			ERROR(g2->base.context, "read interrupt transfer returns impossible packet size (%d)", len);
			return -1;
		}
		HEXDUMP (g2->base.context, DC_LOGLEVEL_DEBUG, "rcv", buf+1, len);
		if (len > size) {
			ERROR(g

Re: Scubapro Aladin Square

2017-11-13 Thread Linus Torvalds

On Mon, Nov 13, 2017 at 9:29 AM, vavincavent  wrote:
> I have little problem with tshark or wireshark. But I try to test this
> !
> The result with windows give me hope for the same with DEBIAN!

Well, you can also just test out the "maybe it's the extra zero byte
for hidusb" directly, without capturing any packet trace.

In scubapro_g2_transfer(), see how it does that:

// BLE GATT protocol?
if (io->packet_size < 64) {
// No report type byte
status = io->packet_write(io, buf+1, csize+1, &transferred);
} else {
status = io->packet_write(io, buf, sizeof(buf), &transferred);
}

and the difference is exactly that the BLE GATT stuff does _not_ want
that silly report type byte.

libusb doesn't really either - it was added just for hidapi.

So try just changing that

if (io->packet_size < 64) {

to a

if (1) {

and see if your Debian case magically works.

(Of course, this is in _addition_ to all the USB ID hackery to make it
use the right device ID)

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

Re: Scubapro Aladin Square

2017-11-13 Thread vavincavent

I have little problem with tshark or wireshark. But I try to test this
!
The result with windows give me hope for the same with DEBIAN!

Vincent.


Le lundi 13 novembre 2017 à 09:17 -0800, Linus Torvalds a écrit :
> On Mon, Nov 13, 2017 at 9:11 AM, vavincavent 
> wrote:
> > 
> > With your method, download works.
> > You'll find attached files g2.bin and g2.log.
> 
> So this was on Windows using usbhid?
> 
> I really am starting to believe that it's the extra zero with libusb,
> and your Debian machine actually considers that an _extra_ zero.
> 
> So I'd like to see the USB capture on your Debian machine of the
> failing case.
> 
> Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Scubapro Aladin Square

2017-11-13 Thread Linus Torvalds

On Mon, Nov 13, 2017 at 9:11 AM, vavincavent  wrote:
>
> With your method, download works.
> You'll find attached files g2.bin and g2.log.

So this was on Windows using usbhid?

I really am starting to believe that it's the extra zero with libusb,
and your Debian machine actually considers that an _extra_ zero.

So I'd like to see the USB capture on your Debian machine of the failing case.

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

Re: Scubapro Aladin Square

2017-11-13 Thread vavincavent

Jef,

With your method, download works.
You'll find attached files g2.bin and g2.log.

I hope it will be usefull.

Vincent.

Le lundi 13 novembre 2017 à 08:43 +0100, Jef Driesen a écrit :
> On 12-11-17 19:09, Linus Torvalds wrote:
> > On Sun, Nov 12, 2017 at 5:16 AM, vavincavent  > > wrote:
> > > 
> > > I try with joined file scubapro_g2.c to download from scubapro
> > > square.
> > 
> > Hmm. Can I see what the packets on the wire are, just in case we
> > have
> > some odd libusb issue or something? We added an initial zero byte
> > for
> > the report type to make hidapi happy, and *my* version of usblib
> > certainly didn't care, but...
> 
> The zero report id should be stripped in our usbhid backend when
> using libusb, 
> so I doubt that's the problem.
> 
> Logtrak is using hidapi, so it might be worth trying to build
> libdivecomputer 
> with hidapi instead of libusb (./configure --without-libusb). That
> will already 
> rule out one difference. And maybe also try
> libdivecomputer/subsurface on 
> windows too, because we know for sure downloading there works. If we
> can confirm 
> it works on windows, then we can move one step at a time, and try to
> identify 
> which step is the culprit (hidapi vs libusb, windows vs linux, etc).
> 
> I have prepared a hidapi based windows build for you. Just download
> these files:
> 
> http://libdivecomputer.org/builds/experimental/windows/g2.cmd
> http://libdivecomputer.org/builds/experimental/windows/libdivecompute
> r-0.dll
> http://libdivecomputer.org/builds/divinglog/libhidapi-0.dll
> http://libdivecomputer.org/builds/divinglog/dctool.exe
> 
> Place everything in the same directory, and start the download by 
> double-clicking the g2 batch file. When done, email us the g2.log
> file, and if 
> present also the g2.bin file.
> 
> (I also patched the g2 backend with the VID/PID of the aladin square
> in this build.)
> 
> > I think you said this is on debian. Use 'tshark -i usbmon1 -w
> > out.pcap" (replace 'usbmon1' with whatever bus the device is on) to
> > capture a packet trace.
> > 
> > You can use wireshark as a GUI tool of course. Usually I find it's
> > nicer to first capture on the command line, and then use wireshark
> > to
> > look at things, but whatever works for you...
> 
> Yes, this is indeed something worth trying.
> 
> Jef

g2.bin
Description: Binary data
[0.16] DATETIME 2017-11-13T17:01:05Z (1510592465)
[0.000203] VERSION 0.6.0-devel (5bf260ce7be4acb769e6e318dc3c2a8ca2a7f5ca)
[0.000325] Opening the device (Scubapro Aladin Sport Matrix, null).
[0.000412] INFO: Open: vid=c251, pid=2006
[0.090610] INFO: Write: size=33, data=00011B
[0.289625] INFO: Read: size=64, data=0101
[0.290605] INFO: Write: size=33, data=00051C1027
[0.393626] INFO: Read: size=64, data=0101
[0.393837] Registering the event handler.
[0.393909] Registering the cancellation handler.
[0.393970] Downloading the memory dump.
[0.394160] Event: progress 0.00% (0/4294967295)
[0.394588] INFO: Write: size=33, data=000110
[0.417628] INFO: Read: size=64, data=0122
[0.418589] INFO: Write: size=33, data=000114
[0.481646] INFO: Read: size=64, data=04A6E31C0400
[0.482632] INFO: Write: size=33, data=00011A
[0.505653] INFO: Read: size=64, data=04041A394300
[0.505932] Event: progress 0.00% (9/4294967295)
[0.517632] Event: systime=1510592465, devtime=1127815684
[0.518069] Event: model=34 (0x0022), firmware=0 (0x), serial=69002150 (0x041ce3a6)
[0.522609] INFO: Write: size=33, data=0009C61027
[0.825625] INFO: Read: size=64, data=046C5900
[0.825901] Event: progress 0.06% (13/22909)
[0.826585] INFO: Write: size=33, data=0009C41027
[1.185654] INFO: Read: size=64, data=04705900
[1.185943] Event: progress 0.07% (17/22909)
[1.241659] INFO: Read: size=64, data=3FA5

Re: Scubapro Aladin Square

2017-11-12 Thread Jef Driesen


On 12-11-17 19:09, Linus Torvalds wrote:

On Sun, Nov 12, 2017 at 5:16 AM, vavincavent  wrote:


I try with joined file scubapro_g2.c to download from scubapro square.


Hmm. Can I see what the packets on the wire are, just in case we have
some odd libusb issue or something? We added an initial zero byte for
the report type to make hidapi happy, and *my* version of usblib
certainly didn't care, but...


The zero report id should be stripped in our usbhid backend when using libusb, 
so I doubt that's the problem.


Logtrak is using hidapi, so it might be worth trying to build libdivecomputer 
with hidapi instead of libusb (./configure --without-libusb). That will already 
rule out one difference. And maybe also try libdivecomputer/subsurface on 
windows too, because we know for sure downloading there works. If we can confirm 
it works on windows, then we can move one step at a time, and try to identify 
which step is the culprit (hidapi vs libusb, windows vs linux, etc).


I have prepared a hidapi based windows build for you. Just download these files:

http://libdivecomputer.org/builds/experimental/windows/g2.cmd
http://libdivecomputer.org/builds/experimental/windows/libdivecomputer-0.dll
http://libdivecomputer.org/builds/divinglog/libhidapi-0.dll
http://libdivecomputer.org/builds/divinglog/dctool.exe

Place everything in the same directory, and start the download by 
double-clicking the g2 batch file. When done, email us the g2.log file, and if 
present also the g2.bin file.


(I also patched the g2 backend with the VID/PID of the aladin square in this 
build.)


I think you said this is on debian. Use 'tshark -i usbmon1 -w
out.pcap" (replace 'usbmon1' with whatever bus the device is on) to
capture a packet trace.

You can use wireshark as a GUI tool of course. Usually I find it's
nicer to first capture on the command line, and then use wireshark to
look at things, but whatever works for you...


Yes, this is indeed something worth trying.

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

Re: Scubapro Aladin Square

2017-11-12 Thread Linus Torvalds

On Sun, Nov 12, 2017 at 5:16 AM, vavincavent  wrote:
>
> I try with joined file scubapro_g2.c to download from scubapro square.

Hmm. Can I see what the packets on the wire are, just in case we have
some odd libusb issue or something? We added an initial zero byte for
the report type to make hidapi happy, and *my* version of usblib
certainly didn't care, but...

I think you said this is on debian. Use 'tshark -i usbmon1 -w
out.pcap" (replace 'usbmon1' with whatever bus the device is on) to
capture a packet trace.

You can use wireshark as a GUI tool of course. Usually I find it's
nicer to first capture on the command line, and then use wireshark to
look at things, but whatever works for you...

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

Re: Scubapro Aladin Square

2017-11-11 Thread Berthold Stoeger

Hi Vincent,

On Samstag, 11. November 2017 09:26:55 CET vavincavent wrote:
> Can we begin to make a new entry for this computer in libdivecomputer
> library? (scubapro_square.c and scubapro_square.h but i think it's not
> just this...)

Actually it's much simpler. You'd add an entry to the descriptor.c file. But 
this does not seem to be your problem anyway.

To test Linus' stupid-firmware theory (which sounds unlikely to me), you could 
try to apply the attached (and completely untested) patch to the 
libdivecomputer source that is automatically downloaded when building 
subsurface from github. Note that you have to "make install" libdivecomputer 
and than make subsurface. Then try again downloading as Scubapro G2 and 
inspect the log.

Bertholddiff --git a/src/scubapro_g2.c b/src/scubapro_g2.c
index 04a83a2..d4ca2b2 100644
--- a/src/scubapro_g2.c
+++ b/src/scubapro_g2.c
@@ -225,6 +225,13 @@ scubapro_g2_device_open(dc_device_t **out, dc_context_t *context, const char *na
 		goto error_free;
 	}

+	// Read the model number.
+	unsigned char cmd_model[1] = {0x10};
+	unsigned char res_model[1] = {0};
+	status = scubapro_g2_transfer (device, cmd_model, sizeof (cmd_model), res_model, sizeof (res_model));
+	if (status != DC_STATUS_SUCCESS)
+		goto error_free;
+
 	// Perform the handshaking.
 	status = scubapro_g2_handshake(device, model);
 	if (status != DC_STATUS_SUCCESS) {
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Scubapro Aladin Square

2017-11-11 Thread vavincavent

Can we begin to make a new entry for this computer in libdivecomputer
library? (scubapro_square.c and scubapro_square.h but i think it's not
just this...)

I can't program this, but i can do the test with my divecomputer and
Debian. I have android smartphone too with OTG.

Actually i use divemate for downloading my data and after export to
subsurface. It's not the best way for my mind!

Regards,
Vincent

Le vendredi 10 novembre 2017 à 18:53 -0800, Linus Torvalds a écrit :
> On Fri, Nov 10, 2017 at 4:33 PM, vavincavent 
> wrote:
> > Linus, Jef,
> > 
> > I've made dump file report with USBlyser.
> > I've attach the file in this message.
> 
> From a quick look, i tdoes look like the standard Uwatec thing
> (without a handshake):
> 
> LogTrak sends: 01 10 to query the model.
> 
> Dive computer responds:
> 
>   01 22 7F 7F BF C1 C4 B1 C1 FB 0E 03 00 00 00
> 00  ."..
> 0010  FE FE FE 01 00 00 00 00 C1 7D 7E 7C 04 7F 7C
> BF  .}~|..|.
> 0020  C1 BF C1 12 7E 7F B1 0F 62 C1 03 B1 7E 0B 75
> 04  ~...b...~.u.
> 0030  7D BF 7E B1 09 7D 7D BF 7D B1 C1 7E 01 01 BF
> 02  }.~..}}.}..~
> 
> where only that "01 22" is actually valid (the rest is just garbage
> from the dive computer memory - it seems to be quite common that the
> USB HID stack uses a static buffer and sends garbage padding).
> 
> So the model is 0x22.
> 
> Then LogTrak does that 0x1b thing (that we use as a handshake, but it
> clearly means something): 01 1B
> 
> And the dive computer responds with
> 
>   01 01 7F 7F BF C1 C4 B1 C1 FB 0E 03 00 00 00
> 00  
> 0010  FE FE FE 01 00 00 00 00 C1 7D 7E 7C 04 7F 7C
> BF  .}~|..|.
> 0020  C1 BF C1 12 7E 7F B1 0F 62 C1 03 B1 7E 0B 75
> 04  ~...b...~.u.
> 0030  7D BF 7E B1 09 7D 7D BF 7D B1 C1 7E 01 01 BF
> 02  }.~..}}.}..~
> 
> which is just "01 01" and the same garbage padding.
> 
> Then it does that "05 1C 10 27 00 00" thing that we do as part of the
> handshake, and we get 01 01 back (with garbage padding).
> 
> And then LogTrak asks for devtime, and gets "04 D6 FD 31 43" (and
> garbage padding) back.
> 
> So everything looks very much like the G2 should work.
> 
> So I don't know why it subsurface gets that
> 
>   ERROR: Usb read interrupt transfer failed (LIBUSB_ERROR_TIMEOUT).
> [in ../../src/usbhid.c:518 (dc_usbhid_read)]
> 
> error.  Maybe the Aladin Square has a fairly stupid firmware, and
> really needs the commands to be in one particular order, and wants
> that "model query" first.
> 
> Does anybody else see anything odd?
> 
> Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Scubapro Aladin Square

2017-11-10 Thread Linus Torvalds

On Fri, Nov 10, 2017 at 4:33 PM, vavincavent  wrote:
> Linus, Jef,
>
> I've made dump file report with USBlyser.
> I've attach the file in this message.

From a quick look, i tdoes look like the standard Uwatec thing
(without a handshake):

LogTrak sends: 01 10 to query the model.

Dive computer responds:

  01 22 7F 7F BF C1 C4 B1 C1 FB 0E 03 00 00 00 00  ."..
0010  FE FE FE 01 00 00 00 00 C1 7D 7E 7C 04 7F 7C BF  .}~|..|.
0020  C1 BF C1 12 7E 7F B1 0F 62 C1 03 B1 7E 0B 75 04  ~...b...~.u.
0030  7D BF 7E B1 09 7D 7D BF 7D B1 C1 7E 01 01 BF 02  }.~..}}.}..~

where only that "01 22" is actually valid (the rest is just garbage
from the dive computer memory - it seems to be quite common that the
USB HID stack uses a static buffer and sends garbage padding).

So the model is 0x22.

Then LogTrak does that 0x1b thing (that we use as a handshake, but it
clearly means something): 01 1B

And the dive computer responds with

  01 01 7F 7F BF C1 C4 B1 C1 FB 0E 03 00 00 00 00  
0010  FE FE FE 01 00 00 00 00 C1 7D 7E 7C 04 7F 7C BF  .}~|..|.
0020  C1 BF C1 12 7E 7F B1 0F 62 C1 03 B1 7E 0B 75 04  ~...b...~.u.
0030  7D BF 7E B1 09 7D 7D BF 7D B1 C1 7E 01 01 BF 02  }.~..}}.}..~

which is just "01 01" and the same garbage padding.

Then it does that "05 1C 10 27 00 00" thing that we do as part of the
handshake, and we get 01 01 back (with garbage padding).

And then LogTrak asks for devtime, and gets "04 D6 FD 31 43" (and
garbage padding) back.

So everything looks very much like the G2 should work.

So I don't know why it subsurface gets that

  ERROR: Usb read interrupt transfer failed (LIBUSB_ERROR_TIMEOUT).
[in ../../src/usbhid.c:518 (dc_usbhid_read)]

error.  Maybe the Aladin Square has a fairly stupid firmware, and
really needs the commands to be in one particular order, and wants
that "model query" first.

Does anybody else see anything odd?

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

Re: Scubapro Aladin Square

2017-11-10 Thread Berthold Stoeger

On Freitag, 10. November 2017 22:32:14 CET Linus Torvalds wrote:
> On Fri, Nov 10, 2017 at 1:21 PM, vavincavent  wrote:
> > After udev rules with Jef recommandation, the subsurface.log :
> Ok, so it doesn't work like the G2.
> 
> That 011B thing is the hanshake (01 = one byte command, 1b is the
> handshake byte) and you don't get any answer.
> 
> Now, the Aladin Sport Matrix didn't want the handshake either, so you
> could just try without it

Note that the Aladin Sport Matrix did reply to the 1b and 1c... commands. It 
just returned 00 instead if 01. But LogTrak doesn't do any handshaking in this 
case.

And in Vincent's log you clearly see the handshake:

7fe0  00 00 00 00 00 00 00 00  00 00 00 01 1b 00 00 00  ||
7ff0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||

8300  00 00 00 00 00 00 00 00  00 00 00 05 1c 10 27 00  |..'.|
8310  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||

8f80  00 00 00 00 00 00 00 00  00 00 00 09 c6 00 00 00  ||
8f90  00 10 27 00 00 00 00 00  00 00 00 00 00 00 00 00  |..'.|

92a0  00 00 00 00 00 00 00 00  00 00 00 09 c4 00 00 00  ||
92b0  00 10 27 00 00 00 00 00  00 00 00 00 00 00 00 00  |..'.|

So perhaps a different problem?

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

Re: Scubapro Aladin Square

2017-11-10 Thread Linus Torvalds

On Fri, Nov 10, 2017 at 1:21 PM, vavincavent  wrote:
> After udev rules with Jef recommandation, the subsurface.log :

Ok, so it doesn't work like the G2.

That 011B thing is the hanshake (01 = one byte command, 1b is the
handshake byte) and you don't get any answer.

Now, the Aladin Sport Matrix didn't want the handshake either, so you
could just try without it (see scubapro_g2_handshake(), where it
currently does:

if (model == ALADINSPORTMATRIX)
return DC_STATUS_SUCCESS;

and you could just try returning success unconditionally.

But it might be a totally different protocol.

> When i try with Logtrak, i've try to sniff USB. So i have some results,
> but i can't understand this...

Feel free to send your packet dump to me and Jef, maybe we can see
"yes, looks like the same protocol, with just a small tweak" or we go
"Oh, that doesn't look anything at all like what we've seen before".

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

Re: Scubapro Aladin Square

2017-11-10 Thread vavincavent

After udev rules with Jef recommandation, the subsurface.log :

Subsurface: v4.7.2-54-g97712559192c, built with libdivecomputer v0.6.0-
devel-Subsurface-branch (7de3a549ee588fef4702ee9d894e390aca43950d)
INFO: Open: vid=c251, pid=2006
INFO: Open: interface=0, endpoints=81,02
INFO: Timeout: value=10
ERROR: Usb read interrupt transfer failed (LIBUSB_ERROR_TIMEOUT). [in
../../src/usbhid.c:518 (dc_usbhid_read)]
INFO: Read: size=0, data=
INFO: Timeout: value=5000
DEBUG: cmd: size=1, data=1B
INFO: Write: size=32,
data=00011B00
ERROR: Usb read interrupt transfer failed (LIBUSB_ERROR_TIMEOUT). [in
../../src/usbhid.c:518 (dc_usbhid_read)]
INFO: Read: size=0, data=
ERROR: read interrupt transfer failed [in scubapro_g2.c:78
(receive_data)]
ERROR: Failed to receive the answer. [in scubapro_g2.c:145
(scubapro_g2_transfer)]
ERROR: Failed to handshake with the device. [in scubapro_g2.c:231
(scubapro_g2_device_open)]

When i try with Logtrak, i've try to sniff USB. So i have some results,
but i can't understand this...

Please, help me ... 

Vincent

Le vendredi 10 novembre 2017 à 09:58 -0800, Linus Torvalds a écrit :
> On Thu, Nov 9, 2017 at 2:39 PM, vavincavent 
> wrote:
> > 
> > ERROR: Failed to open the usb device (LIBUSB_ERROR_ACCESS). [in
> > ../../src/usbhid.c:392 (dc_usbhid_open)]
> 
> As Jef says, this is a USB permission issue. The regular udev rules
> do
> not grant normal users access to random USB devices that it doesn't
> know about, which is good for security, but it's inconvenient for
> dive
> computers.
> 
>   Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Scubapro Aladin Square

2017-11-10 Thread Linus Torvalds

On Thu, Nov 9, 2017 at 2:39 PM, vavincavent  wrote:
>
> ERROR: Failed to open the usb device (LIBUSB_ERROR_ACCESS). [in
> ../../src/usbhid.c:392 (dc_usbhid_open)]

As Jef says, this is a USB permission issue. The regular udev rules do
not grant normal users access to random USB devices that it doesn't
know about, which is good for security, but it's inconvenient for dive
computers.

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

Re: Scubapro Aladin Square

2017-11-10 Thread Jef Driesen


On 2017-11-10 14:52, vavincavent wrote:

It was the libdivecomputer log file, from subsurface :

Subsurface: v4.7.2-54-g97712559192c, built with libdivecomputer v0.6.0-
devel-Subsurface-branch (7de3a549ee588fef4702ee9d894e390aca43950d)
INFO: Open: vid=c251, pid=2006
INFO: Open: interface=0, endpoints=81,02
ERROR: Failed to open the usb device (LIBUSB_ERROR_ACCESS). [in
../../src/usbhid.c:392 (dc_usbhid_open)]
ERROR: Failed to open Scubapro G2 device [in scubapro_g2.c:224
(scubapro_g2_device_open)]

vid=c251, pid=2006 is the informations of the square after i've made
changes like Linus tell me.


You don't have permission to open the usb device. You'll need to add a 
udev rule for your dive computer. For example:


echo 'SUBSYSTEM=="usb", ACTION=="add", ATTR{idVendor}=="c251", 
ATTR{idProduct}=="2006", GROUP="plugdev"' | sudo tee 
/etc/udev/rules.d/99-divecomputer.rules


(This assumes you are part of the "plugdev" group. On debian/ubuntu 
based systems that's normally the case.)


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

Re: Scubapro Aladin Square

2017-11-10 Thread vavincavent

It was the libdivecomputer log file, from subsurface :

Subsurface: v4.7.2-54-g97712559192c, built with libdivecomputer v0.6.0-
devel-Subsurface-branch (7de3a549ee588fef4702ee9d894e390aca43950d)
INFO: Open: vid=c251, pid=2006
INFO: Open: interface=0, endpoints=81,02
ERROR: Failed to open the usb device (LIBUSB_ERROR_ACCESS). [in
../../src/usbhid.c:392 (dc_usbhid_open)]
ERROR: Failed to open Scubapro G2 device [in scubapro_g2.c:224
(scubapro_g2_device_open)]

vid=c251, pid=2006 is the informations of the square after i've made
changes like Linus tell me.

Vincent


Le vendredi 10 novembre 2017 à 06:52 +0200, Miika Turkia a écrit :
> Can you enable libdivecomputer log file on download dialog when you
> re-try download. This log should produce a lot more information about
> the download process and might tell us what is going wrong. And if
> the
> communication with divecomputer works some way, then also
> libdivecomputer dumpfile might be of use to us.
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Scubapro Aladin Square

2017-11-09 Thread Miika Turkia

Can you enable libdivecomputer log file on download dialog when you
re-try download. This log should produce a lot more information about
the download process and might tell us what is going wrong. And if the
communication with divecomputer works some way, then also
libdivecomputer dumpfile might be of use to us.
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Scubapro Aladin Square

2017-11-09 Thread vavincavent

Linus,

i think i have successs in compiling with new pid (not easy for me
...), but no success for connecting aladin square :

subsurface.log :

Subsurface: v4.7.2-54-g97712559192c, built with libdivecomputer v0.6.0-
devel-Subsurface-branch (7de3a549ee588fef4702ee9d894e390aca43950d)
INFO: Open: vid=c251, pid=2006
INFO: Open: interface=0, endpoints=81,02
ERROR: Failed to open the usb device (LIBUSB_ERROR_ACCESS). [in
../../src/usbhid.c:392 (dc_usbhid_open)]
ERROR: Failed to open Scubapro G2 device [in scubapro_g2.c:224
(scubapro_g2_device_open)]

Vincent


Le mercredi 08 novembre 2017 à 13:16 -0800, Linus Torvalds a écrit :
> On Wed, Nov 8, 2017 at 1:02 PM, vavincavent 
> wrote:
> > 
> > : USB HID v1.00 Device [Uwatec AG Square] on usb-:00:14.0-
> > 1/input0
> 
> Ok, so this is one of the "native USB" devices, not one of the
> "serial
> device, using a USB-to-serial cable" devices.
> 
> That means that you need to use the actual native USB access.
> 
> We don't have any way to set the USB device ID's, but it is
> *possible*
> that it works the same way the Scubapro G2 does (which also shows up
> as a USB HID device).
> 
> If you can build your own subsurface, you could try this:
> 
> -   status = dc_usbhid_custom_io(context, 0x2e6c,
> 0x3201);
> +   status = dc_usbhid_custom_io(context, 0xc251,
> 0x2006);
> 
> in libdifvecomputer's src/scubapro_g2.c and then say "download from
> Scubapro G2".
> 
> It would be good to have some way to let people test USB ID's like
> this without having to build things specifically for it, but I can't
> think of a sane way.
> 
>    Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Scubapro Aladin Square

2017-11-08 Thread Linus Torvalds

On Wed, Nov 8, 2017 at 1:02 PM, vavincavent  wrote:
>
>: USB HID v1.00 Device [Uwatec AG Square] on usb-:00:14.0-1/input0

Ok, so this is one of the "native USB" devices, not one of the "serial
device, using a USB-to-serial cable" devices.

That means that you need to use the actual native USB access.

We don't have any way to set the USB device ID's, but it is *possible*
that it works the same way the Scubapro G2 does (which also shows up
as a USB HID device).

If you can build your own subsurface, you could try this:

-   status = dc_usbhid_custom_io(context, 0x2e6c, 0x3201);
+   status = dc_usbhid_custom_io(context, 0xc251, 0x2006);

in libdifvecomputer's src/scubapro_g2.c and then say "download from
Scubapro G2".

It would be good to have some way to let people test USB ID's like
this without having to build things specifically for it, but I can't
think of a sane way.

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

Re: Scubapro Aladin Square

2017-11-08 Thread vavincavent

I'mwith debian stretch.

With dmesg :

[51221.241299] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[51221.245073] ata1.00: configured for UDMA/100
[51221.580422] IPv6: ADDRCONF(NETDEV_UP): enp2s0: link is not ready
[51221.595293] r8169 :02:00.0 enp2s0: link down
[51221.595334] r8169 :02:00.0 enp2s0: link down
[51221.595424] IPv6: ADDRCONF(NETDEV_UP): enp2s0: link is not ready
[51221.598295] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[51221.614434] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[51221.634939] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[51221.709568] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[51222.728450] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[51222.774768] wlp3s0: authenticate with 30:7e:cb:e5:ea:2c
[51222.786691] wlp3s0: send auth to 30:7e:cb:e5:ea:2c (try 1/3)
[51222.788699] wlp3s0: authenticated
[51222.789135] wlp3s0: associate with 30:7e:cb:e5:ea:2c (try 1/3)
[51222.792878] wlp3s0: RX AssocResp from 30:7e:cb:e5:ea:2c (capab=0x411
status=0 aid=5)
[51222.792975] wlp3s0: associated
[51222.793020] IPv6: ADDRCONF(NETDEV_CHANGE): wlp3s0: link becomes
ready
[51223.177978] r8169 :02:00.0 enp2s0: link up
[51223.177985] IPv6: ADDRCONF(NETDEV_CHANGE): enp2s0: link becomes
ready
[51226.238052] usb 1-8: New USB device found, idVendor=04ca,
idProduct=3018
[51226.238054] usb 1-8: New USB device strings: Mfr=0, Product=0,
SerialNumber=0
[51228.710451] wlp3s0: authenticate with 30:7e:cb:e5:ea:2c
[51228.723752] wlp3s0: send auth to 30:7e:cb:e5:ea:2c (try 1/3)
[51228.729079] wlp3s0: authenticated
[51228.733108] wlp3s0: associate with 30:7e:cb:e5:ea:2c (try 1/3)
[51228.737851] wlp3s0: RX AssocResp from 30:7e:cb:e5:ea:2c (capab=0x411
status=0 aid=5)
[51228.737955] wlp3s0: associated
[69166.461691] usb 1-1: new full-speed USB device number 10 using
xhci_hcd
[69166.603936] usb 1-1: New USB device found, idVendor=c251,
idProduct=2006
[69166.603938] usb 1-1: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[69166.603939] usb 1-1: Product: Square
[69166.603941] usb 1-1: Manufacturer: Uwatec AG
[69166.603942] usb 1-1: SerialNumber: r120A
[69176.778073] hid-generic 0003:C251:2006.0004: usb_submit_urb(ctrl)
failed: -1
[69176.778109] hid-generic 0003:C251:2006.0004: timeout initializing
reports
[69176.778850] hid-generic 0003:C251:2006.0004: hiddev0,hidraw3: USB
HID v1.00 Device [Uwatec AG Square] on usb-:00:14.0-1/input0
[69263.297351] usb 1-1: USB disconnect, device number 10
[69307.726333] usb 1-1: new full-speed USB device number 11 using
xhci_hcd
[69307.870369] usb 1-1: New USB device found, idVendor=c251,
idProduct=2006
[69307.870379] usb 1-1: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[69307.870385] usb 1-1: Product: Square
[69307.870390] usb 1-1: Manufacturer: Uwatec AG
[69307.870394] usb 1-1: SerialNumber: r120A

And i can't connect with USB like Aladin pro for example.

Vincent.

Le mercredi 08 novembre 2017 à 21:38 +0200, Willem Ferguson a écrit :
> On 08/11/2017 20:29, vavincavent wrote:
> > hi,
> > 
> > I dive with the scubapro Aladin square dive computer.
> > Unfortunatly not supported for download by subsurface.
> > Is it planned? How can i help?
> > 
> > Vincent.
> > ___
> > subsurface mailing list
> > subsurface@subsurface-divelog.org
> > http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsur
> > face
> 
> I see the Square has a USB interface, just like the Aladin Sport.
> What 
> happens if you specify any of the Uwatec or Scubapro dive computers
> that 
> also use USB?
> 
> Kind regards,
> 
> willem
> 
> 
> 
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Scubapro Aladin Square

2017-11-08 Thread Willem Ferguson


On 08/11/2017 20:29, vavincavent wrote:

hi,

I dive with the scubapro Aladin square dive computer.
Unfortunatly not supported for download by subsurface.
Is it planned? How can i help?

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


I see the Square has a USB interface, just like the Aladin Sport. What 
happens if you specify any of the Uwatec or Scubapro dive computers that 
also use USB?


Kind regards,

willem



--
This message and attachments are subject to a disclaimer.
Please refer to 
http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf for full 
details.

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

61 matches

Mail list logo