Replace libusb 0.1 usage with libusb 1.0 #396
Conversation
TODO: flow with configure flow with cmake test on macos test on linux are include paths consistent for libusb.h? better way to find endpoint addresses than search all interfaces, altsettings and endpoints?
This has mac/libusb/config.h that was generated on 10.14.6 by configure. It is not clear a fixed config.h will be viable.
configure builds on macos don't work yet, but qmake or cmake does.
configure is linking via a static lib we create. this removes the conflict between the gpsbabel configure created config.h and the libusb config.h. use the libusb-1.0 supplied hardcoded config.h from for Xcode. qmake/cmake are still linking the individual libusb objects.
this was the traditional behavior. add -lobjc on mac for libusb. while this doesn't seem necessary it is what libusb does.
Now that we have the dependencies correct we generate and find the included library with the standard name.
libusb_exit should be called IFF libusb_init succeded. atexit should only be called once to register gusb_atexit_teardown, its effects are cumulative and irreversible.
delete obsolete comment in README. don't log each file the macos linker loads with -t.
|
I believe this is a fair translation, but it may not be correct: The value is used in gusb_cmd_send. It seems to pertain to the garmin spec:
|
|
Regarding the concern about bMaxPacketSize0 vs. wMaxPacketSize, on the etrex vista cx it is irrelevant because they are all equal on this device. From a modified testlibusb.c (verbose=1, and printf(..., desc.bMaxPacketSize0)) we can see that bMaxPacketSize0 and wMaxPacketSize for all endpoints have a value of 64. Of course, we don't know if this is true in general.
|
|
Catching up. Synchronized to 80015bc
60CS still fails in the same way.
Edge 305 still fails.
There is some trait that is shared by this first generation (like messages
bouncing between control and bulk pipes - or vice versa) that was changed
with the second generation (SP 2720, 60CSx) that required changes some 13
years ago when these came out.
I'll dig around in code and message archives to see if I can find what
separated these 2004-ish generations from their 2006-ish successors and
then see if I can find it in the code. It's been a Very Long Time since
I've been in this code.
…On Sun, Oct 6, 2019 at 5:22 PM tsteven4 ***@***.***> wrote:
Regarding the concern about bMaxPacketSize0 vs. wMaxPacketSize, on the
etrex vista cx it is irrelevant because they are all equal on this device.
From a modified testlibusb.c (verbose=1, and printf(...,
desc.bMaxPacketSize0)) we can see that bMaxPacketSize0 and wMaxPacketSize
for all endpoints have a value of 64. Of course, we don't know if this is
true in general.
Dev (bus 2, device 4): 091E - 0003
BMaxPacketSize0 64
Configuration:
wTotalLength: 39
bNumInterfaces: 1
bConfigurationValue: 1
iConfiguration: 0
bmAttributes: 80h
MaxPower: 150
Interface:
bInterfaceNumber: 0
bAlternateSetting: 0
bNumEndpoints: 3
bInterfaceClass: 255
bInterfaceSubClass: 255
bInterfaceProtocol: 255
iInterface: 0
Endpoint:
bEndpointAddress: 81h
bmAttributes: 02h
wMaxPacketSize: 64
bInterval: 0
bRefresh: 0
bSynchAddress: 0
Endpoint:
bEndpointAddress: 82h
bmAttributes: 03h
wMaxPacketSize: 64
bInterval: 1
bRefresh: 0
bSynchAddress: 0
Endpoint:
bEndpointAddress: 03h
bmAttributes: 02h
wMaxPacketSize: 64
bInterval: 0
bRefresh: 0
bSynchAddress: 0
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#396>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACCSD33DAYNAPE5PEZFB7ZDQNJQJLANCNFSM4IO2CZDA>
.
|
|
Do the edge 305 and 60CS work with 1.6.0 (libusb 0.1), or do they fail like 80015bc? |
To debug set environmental variable LIBUSB_DEBUG to a value >= 2. Look for a message "transfer error:"
|
|
Issues
======
+ Solved 1
See the complete overview on Codacy |
Replace our modified libusb 0.1.12 with libusb 1.0.22 on macos. On macos we statically link to our inclcuded libusb.
Use libusb 1.0 instead of libusb 0.1 on linux. On linux we dynamically link to a distribution provided libusb, or optionally build without libusb support.
This fixes #381
This resolves #25 as requested (albeit 3.5 years later)