Re: Scubapro Aladin Square
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
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
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
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
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
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
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
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
Re: Scubapro Aladin Square
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Scubapro Aladin Square
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