Re: [Libusbx-devel] Bug in get_string_descriptor?
On Mon, Oct 29, 2012 at 3:27 PM, Stefano Di Martino wrote: > Sorry, this was the wrong attachment. > Here you find the right attachment... > Thanks. So this is a Logitech USB Headset, a USB composite device with Interface 3 to be the HID interface. Maybe there is a problem with libusbx HID backend to parse the HID descriptors. Pete may tell you more about how to debug the issue. Can you test under Linux to see if xusb works with this device? If you can please post "lsusb -vvv -d 046D:0A0B" output of the device under Linux. That should help. If you can not use Linux, try usbview under Windows first and post the descriptors. http://www.ftdichip.com/Support/Utilities.htm http://www.ftdichip.com/Support/Utilities/usbview.zip -- Xiaofan -- The Windows 8 Center - In partnership with Sourceforge Your idea - your app - 30 days. Get started! http://windows8center.sourceforge.net/ what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Help needed with deployment issues on Windows
On Mon, Oct 29, 2012 at 9:17 AM, therau2000 wrote: > On Mon, 2012-10-29 at 01:15 +0100, Peter Stuge wrote: > > Find out exactly how those commands get sent, and find a method to > send them which is outside the USB domain if possible, since that > will be both simpler for you to implement *and* will provide a > significantly better user experience. > > The "competing program" uses a .dll to communicate with the Device's > Firmware. By examining that .dll file, I just discovered that it is calling > "DeviceIoControl" in kernel32.dll. MS documentation about "DeviceIoControl" > states "An application can use the DeviceIoControl function to perform > direct input and output operations on, or retrieve information about, a > floppy disk drive, hard disk drive, tape drive, or CD-ROM drive.". Somewhere > else I read that "SCSI Pass Through" is implemented using "DeviceIoControl" > direct (meaning un-buffered). > > So I imagine this is how the "competing program's" .dll communicates with > the Device's Firmware. > > Writing Java and C code using the libusbx API is doable for me; I have done > it and it does work nicely. But I am afraid that writing code for > "DeviceIoControl" is beyond my capabilities. So unless someone helps in one > way or another I am afraid I will have to... give up. > The example here may help you for Windows. http://code.msdn.microsoft.com/windowshardware/SCSI-Pass-Through-a906ceef For Linux, sg3_utils (open source) should give you the hint. It is said that it may work under Windows as well. http://linux.die.net/man/8/sg3_utils http://sg.danny.cz/sg/sg3_utils.html -- Xiaofan -- The Windows 8 Center - In partnership with Sourceforge Your idea - your app - 30 days. Get started! http://windows8center.sourceforge.net/ what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Bug in get_string_descriptor?
Thanks for your reply! I have at work windows only. I have attached the descriptor which I get by usbview. I could test my code at home under Linux when I get home today... Best Regards Stefano Original-Nachricht > Datum: Mon, 29 Oct 2012 21:32:20 +0800 > Von: Xiaofan Chen > An: libusbx-devel@lists.sourceforge.net > Betreff: Re: [Libusbx-devel] Bug in get_string_descriptor? > On Mon, Oct 29, 2012 at 3:27 PM, Stefano Di Martino > wrote: > > Sorry, this was the wrong attachment. > > Here you find the right attachment... > > > > Thanks. So this is a Logitech USB Headset, a USB composite > device with Interface 3 to be the HID interface. Maybe there is > a problem with libusbx HID backend to parse the HID descriptors. > Pete may tell you more about how to debug the issue. > > Can you test under Linux to see if xusb works with this device? > If you can please post "lsusb -vvv -d 046D:0A0B" output of the > device under Linux. That should help. > > If you can not use Linux, try usbview under Windows first > and post the descriptors. > http://www.ftdichip.com/Support/Utilities.htm > http://www.ftdichip.com/Support/Utilities/usbview.zip > > > -- > Xiaofan > > -- > The Windows 8 Center - In partnership with Sourceforge > Your idea - your app - 30 days. > Get started! > http://windows8center.sourceforge.net/ > what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/ > ___ > libusbx-devel mailing list > libusbx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/libusbx-devel Device Descriptor: bcdUSB: 0x0200 bDeviceClass: 0x00 bDeviceSubClass: 0x00 bDeviceProtocol: 0x00 bMaxPacketSize0: 0x08 (8) idVendor: 0x046D (Logitech Inc.) idProduct: 0x0A0B bcdDevice: 0x1013 iManufacturer:0x01 0x0409: "Logitech" iProduct: 0x02 0x0409: "Logitech USB Headset" iSerialNumber:0x00 bNumConfigurations: 0x01 ConnectionStatus: DeviceConnected Current Config Value: 0x01 Device Bus Speed: Full Device Address: 0x02 Open Pipes: 1 Endpoint Descriptor: bEndpointAddress: 0x83 Transfer Type: Interrupt wMaxPacketSize: 0x0002 (2) bInterval:0x08 Configuration Descriptor: wTotalLength: 0x012B bNumInterfaces: 0x04 bConfigurationValue: 0x01 iConfiguration: 0x03 0x0409: "G8 v3.0.0.0" bmAttributes: 0x80 (Bus Powered ) MaxPower: 0x32 (100 Ma) Interface Descriptor: bInterfaceNumber: 0x00 bAlternateSetting:0x00 bNumEndpoints:0x00 bInterfaceClass: 0x01 (Audio) bInterfaceSubClass: 0x01 (Audio Control) bInterfaceProtocol: 0x00 iInterface: 0x00 Audio Control Interface Header Descriptor: bLength: 0x0A bDescriptorType: 0x24 bDescriptorSubtype: 0x01 bcdADC: 0x0100 wTotalLength: 0x0064 bInCollection:0x02 baInterfaceNr[1]: 0x01 baInterfaceNr[2]: 0x02 Audio Control Input Terminal Descriptor: bLength: 0x0C bDescriptorType: 0x24 bDescriptorSubtype: 0x02 bTerminalID: 0x0D wTerminalType: 0x0201 (Microphone) bAssocTerminal: 0x00 bNrChannels: 0x01 wChannelConfig: 0x iChannelNames:0x00 iTerminal:0x00 Audio Control Feature Unit Descriptor: bLength: 0x09 bDescriptorType: 0x24 bDescriptorSubtype: 0x06 bUnitID: 0x06 bSourceID:0x0D bControlSize: 0x01 bmaControls[0]: 03 bmaControls[1]: 00 iFeature: 0x00 Audio Control Input Terminal Descriptor: bLength: 0x0C bDescriptorType: 0x24 bDescriptorSubtype: 0x02 bTerminalID: 0x0C wTerminalType: 0x0101 (USB streaming) bAssocTerminal: 0x00 bNrChannels: 0x02 wChannelConfig: 0x0003 iChannelNames:0x00 iTerminal:0x00 Audio Control Mixer Unit Descriptor: bLength: 0x0D bDescriptorType: 0x24 bDescriptorSubtype: 0x04 bUnitID: 0x09 bNrInPins:0x02 baSourceID[1]:0x0C baSourceID[2]:0x06 bNrChannels: 0x02 wChannelConfig: 0x0003 iChannelNames:0x00 bmControls: 00 iMixer: 0x00 Audio Control Feature Unit Descriptor: bLength: 0x0A bDescriptorType: 0x24 bDescriptorSubtype: 0x06 bUnitID: 0x01 bSourceID:0x09 bControlSize: 0x01 bmaControls[0]: 01 bmaControls[1]: 02 bmaControls[2]: 02 iFeature: 0x00 Audio Control Output Terminal Descriptor: bLength: 0x09 bDescriptorType: 0x24 bDescriptorSubtype: 0x03 bTerminalID: 0x0E wTerminalType: 0x0301 (Speaker) bAssocTerminal: 0x00 bSoruceID:0x01 iTerminal:0x00 Audio Control Feature Unit Descriptor: bLength: 0x09
Re: [Libusbx-devel] Bug in get_string_descriptor?
Okay, I tested it now at home with Linux and the same usb device. It seems, that fetching the string descriptor is a Windows problem. First, I get the error "LIBUSB_ERROR_ACCESS", but then I run the example with root privilege and everything run fine. Just, for the record: On Windows I get an LIBUSB_ERROR_NO_MEM error. What now? My program has to run under windows. I attach again the descriptor of the usb device, but this time formated by lsusb. Best regards Stefano On 29.10.2012 14:32, Xiaofan Chen wrote: On Mon, Oct 29, 2012 at 3:27 PM, Stefano Di Martino wrote: Sorry, this was the wrong attachment. Here you find the right attachment... Thanks. So this is a Logitech USB Headset, a USB composite device with Interface 3 to be the HID interface. Maybe there is a problem with libusbx HID backend to parse the HID descriptors. Pete may tell you more about how to debug the issue. Can you test under Linux to see if xusb works with this device? If you can please post "lsusb -vvv -d 046D:0A0B" output of the device under Linux. That should help. If you can not use Linux, try usbview under Windows first and post the descriptors. http://www.ftdichip.com/Support/Utilities.htm http://www.ftdichip.com/Support/Utilities/usbview.zip Bus 002 Device 005: ID 046d:0a0b Logitech, Inc. ClearChat Pro USB Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x046d Logitech, Inc. idProduct 0x0a0b ClearChat Pro USB bcdDevice 10.13 iManufacturer 1 Logitech iProduct2 Logitech USB Headset iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 299 bNumInterfaces 4 bConfigurationValue 1 iConfiguration 3 G8 v3.0.0.0 bmAttributes 0x80 (Bus Powered) MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 1 Audio bInterfaceSubClass 1 Control Device bInterfaceProtocol 0 iInterface 0 AudioControl Interface Descriptor: bLength10 bDescriptorType36 bDescriptorSubtype 1 (HEADER) bcdADC 1.00 wTotalLength 100 bInCollection 2 baInterfaceNr( 0) 1 baInterfaceNr( 1) 2 AudioControl Interface Descriptor: bLength12 bDescriptorType36 bDescriptorSubtype 2 (INPUT_TERMINAL) bTerminalID13 wTerminalType 0x0201 Microphone bAssocTerminal 0 bNrChannels 1 wChannelConfig 0x iChannelNames 0 iTerminal 0 AudioControl Interface Descriptor: bLength 9 bDescriptorType36 bDescriptorSubtype 6 (FEATURE_UNIT) bUnitID 6 bSourceID 13 bControlSize1 bmaControls( 0) 0x03 Mute Control Volume Control bmaControls( 1) 0x00 iFeature0 AudioControl Interface Descriptor: bLength12 bDescriptorType36 bDescriptorSubtype 2 (INPUT_TERMINAL) bTerminalID12 wTerminalType 0x0101 USB Streaming bAssocTerminal 0 bNrChannels 2 wChannelConfig 0x0003 Left Front (L) Right Front (R) iChannelNames 0 iTerminal 0 AudioControl Interface Descriptor: bLength13 bDescriptorType36 bDescriptorSubtype 4 (MIXER_UNIT) bUnitID 9 bNrInPins 2 baSourceID( 0) 12 baSourceID( 1) 6 bNrChannels 2 wChannelConfig 0x0003 Left Front (L) Right Front (R) iChannelNames 0 bmControls 0x00 iMixer 0 AudioControl Interface Descriptor: bLength10 bDescriptorType36 bDescriptorSubtype 6 (FEATURE_UNIT) bUnitID 1 bSourceID 9 bControlSize1 bmaControls( 0) 0x01 Mute Control bmaControls( 1) 0x02 Volume Control bmaControls( 2) 0x02
Re: [Libusbx-devel] Bug in get_string_descriptor?
Can you please run 'xusb -d vid:pid' where vid:pid are the ones of your device and send the log you get? Regards, /Pete On 2012.10.29 17:51, Stefano Di Martino wrote: > Okay, I tested it now at home with Linux and the same usb device. It > seems, that fetching the string descriptor is a Windows problem. > First, I get the error "LIBUSB_ERROR_ACCESS", but then I run the example > with root privilege and everything run fine. Just, for the record: On > Windows I get an LIBUSB_ERROR_NO_MEM error. > What now? My program has to run under windows. > I attach again the descriptor of the usb device, but this time formated > by lsusb. > > Best regards > Stefano > > On 29.10.2012 14:32, Xiaofan Chen wrote: >> On Mon, Oct 29, 2012 at 3:27 PM, Stefano Di Martino >> wrote: >>> Sorry, this was the wrong attachment. >>> Here you find the right attachment... >>> >> Thanks. So this is a Logitech USB Headset, a USB composite >> device with Interface 3 to be the HID interface. Maybe there is >> a problem with libusbx HID backend to parse the HID descriptors. >> Pete may tell you more about how to debug the issue. >> >> Can you test under Linux to see if xusb works with this device? >> If you can please post "lsusb -vvv -d 046D:0A0B" output of the >> device under Linux. That should help. >> >> If you can not use Linux, try usbview under Windows first >> and post the descriptors. >> http://www.ftdichip.com/Support/Utilities.htm >> http://www.ftdichip.com/Support/Utilities/usbview.zip >> >> > > > > -- > The Windows 8 Center - In partnership with Sourceforge > Your idea - your app - 30 days. > Get started! > http://windows8center.sourceforge.net/ > what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/ > > > > ___ > libusbx-devel mailing list > libusbx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/libusbx-devel > -- The Windows 8 Center - In partnership with Sourceforge Your idea - your app - 30 days. Get started! http://windows8center.sourceforge.net/ what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Bug in get_string_descriptor?
You mean under Windows? I just did this today, but I'll attach it again.
Regards
Stefano
On 29.10.2012 18:57, Pete Batard wrote:
Can you please run 'xusb -d vid:pid' where vid:pid are the ones of your
device and send the log you get?
Regards,
/Pete
On 2012.10.29 17:51, Stefano Di Martino wrote:
Okay, I tested it now at home with Linux and the same usb device. It
seems, that fetching the string descriptor is a Windows problem.
First, I get the error "LIBUSB_ERROR_ACCESS", but then I run the example
with root privilege and everything run fine. Just, for the record: On
Windows I get an LIBUSB_ERROR_NO_MEM error.
What now? My program has to run under windows.
I attach again the descriptor of the usb device, but this time formated
by lsusb.
Best regards
Stefano
On 29.10.2012 14:32, Xiaofan Chen wrote:
On Mon, Oct 29, 2012 at 3:27 PM, Stefano Di Martino
wrote:
Sorry, this was the wrong attachment.
Here you find the right attachment...
Thanks. So this is a Logitech USB Headset, a USB composite
device with Interface 3 to be the HID interface. Maybe there is
a problem with libusbx HID backend to parse the HID descriptors.
Pete may tell you more about how to debug the issue.
Can you test under Linux to see if xusb works with this device?
If you can please post "lsusb -vvv -d 046D:0A0B" output of the
device under Linux. That should help.
If you can not use Linux, try usbview under Windows first
and post the descriptors.
http://www.ftdichip.com/Support/Utilities.htm
http://www.ftdichip.com/Support/Utilities/usbview.zip
--
The Windows 8 Center - In partnership with Sourceforge
Your idea - your app - 30 days.
Get started!
http://windows8center.sourceforge.net/
what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
--
The Windows 8 Center - In partnership with Sourceforge
Your idea - your app - 30 days.
Get started!
http://windows8center.sourceforge.net/
what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
C:\Documents and Settings\stdi3650\My
Documents\Downloads\libsubx-1.0.14\examples\source>t
est -di
Using libusbx v1.0.14.10576
Opening device 046D:0A0B...
[timestamp] [threadID] facility level [function call]
[ 0.015500] [0338] libusbx: debug [libusb_get_device_list]
[ 0.015500] [0338] libusbx: debug [windows_get_device_list] allocating new
device for
session [3C7]
[ 0.015500] [0338] libusbx: debug [windows_get_device_list] allocating new
device for
session [14B]
[ 0.015500] [0338] libusbx: debug [windows_get_device_list] allocating new
device for
session [2D3]
[ 0.015500] [0338] libusbx: debug [windows_get_device_list] allocating new
device for
session [24]
[ 0.015500] [0338] libusbx: debug [windows_get_device_list] allocating new
device for
session [211]
[ 0.015500] [0338] libusbx: debug [windows_get_device_list] allocating new
device for
session [392]
[ 0.015500] [0338] libusbx: debug [windows_get_device_list] allocating new
device for
session [AB]
[ 0.015500] [0338] libusbx: debug [windows_get_device_list] allocating new
device for
session [37B]
[ 0.015500] [0338] libusbx: debug [get_api_type] driver(s): usbhub
[ 0.015500] [0338] libusbx: debug [get_api_type] matched driver name
against HUB API A
PI
[ 0.031000] [0338] libusbx: debug [windows_get_device_list] allocating new
device for
session [1EF]
[ 0.031000] [0338] libusbx: debug [get_api_type] driver(s): usbhub
[ 0.031000] [0338] libusbx: debug [get_api_type] matched driver name
against HUB API A
PI
[ 0.031000] [0338] libusbx: debug [htab_hash] hash collision
('\\.\USB#ROOT_HUB#4&2BE1
97AD&0' vs '\\.\PCI#VEN_8086&DEV_3A65&SUBSYS_3048103C&REV_02#3&B1BFB68&0&E9')
[ 0.031000] [0338] libusbx: debug [windows_get_device_list] allocating new
device for
session [3FC]
[ 0.232500] [0338] libusbx: debug [get_api_type] driver(s): usbhub
[ 0.232500] [0338] libusbx: debug [get_api_type] matched driver name
against HUB API A
PI
[ 0.232500] [0338] libusbx: debug [windows_get_device_list] allocating new
device for
session [30B]
[ 0.434000] [0338] libusbx: debug [get_api_type] driver(s): usbhub
[ 0.434000] [0338] libusbx: debug [get_api_type] matched driver name
against HUB API A
PI
[ 0.434000] [0338] libusbx: debug [windows_get_device_list] allocating new
device for
session [A2]
[ 0.635500] [0338] libusbx: debug [get_api_type] driver(s
Re: [Libusbx-devel] Bug in get_string_descriptor?
Stefano Di Martino wrote: > What now? My program has to run under windows. If you want to communicate with the HID class interface then I suggest to try out HIDAPI. HIDAPI was created specifically to abstract OS-native HID class APIs on Linux, Windows, and Mac OS X. While the Windows-specific HID class code for emulating USB transfers over HID in libusbx does use the same OS-native API as HIDAPI (maybe even some code from HIDAPI?) it isn't (currently) as portable. I don't know what the longer-term plan in libusbx is regarding HID class support. One idea would be to integrate HIDAPI wholesale in order to emulate USB transfers over HID also on Linux and OS X. I don't believe there were suggestions in any direction so far, but I think using more of HIDAPI in libusbx would be a logical extension. //Peter -- The Windows 8 Center - In partnership with Sourceforge Your idea - your app - 30 days. Get started! http://windows8center.sourceforge.net/ what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Help needed with deployment issues on Windows
therau2000 wrote: > On Mon, 2012-10-29 at 01:15 +0100, Peter Stuge wrote: >> Find out exactly how those commands get sent, and find a method to >> send them which is outside the USB domain if possible, since that >> will be both simpler for you to implement *and* will provide a >> significantly better user experience. > The "competing program" uses a .dll to communicate with the Device's > Firmware. By examining that .dll file, I just discovered that it is > calling "DeviceIoControl" in kernel32.dll. MS documentation about > "DeviceIoControl" states "An application can use the DeviceIoControl > function to perform direct input and output operations on, or retrieve > information about, a floppy disk drive, hard disk drive, tape drive, > or CD-ROM drive.". Somewhere else I read that "SCSI Pass Through" is > implemented using "DeviceIoControl" direct (meaning un-buffered). There are exactly five fundamental I/O operations on Windows (copied from the original Unix model): open, close, read, write, and ioctl. (Linux adds mmap to that list.) The APIs for those operations happen to be spelled CreateFile, CloseHandle, ReadFile, WriteFile, and DeviceIoControl. DeviceIoControl does not necessarily mean unbuffered. It's just the general-purpose way to send requests to a driver. One key thing to remember here is that SCSI passthrough is a disk concept, not a USB concept. The ioctl is sent to disk drivers, not to USB drivers. They are at different layers of abstraction. Even SATA disk drives accept SCSI passthrough commands. > So I imagine this is how the "competing program's" .dll communicates > with the Device's Firmware. > > Writing Java and C code using the libusbx API is doable for me; I have > done it and it does work nicely. But I am afraid that writing code for > "DeviceIoControl" is beyond my capabilities. So unless someone helps > in one way or another I am afraid I will have to... give up. Ioctls are not conceptually difficult. A read has one buffer. A write has one buffer. An ioctl has a command code and two buffers. That is quite literally the only difference between the three operations. There are examples on the web showing how to open a disk device and send SCSI passthrough ioctls. However, just like with USB, you have to know what you're sending in the passthrough to achieve the results you want. You can discover that -- you have to have a reference. We don't know what commands the disk firmware expects, and there's no good way to find out. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- The Windows 8 Center - In partnership with Sourceforge Your idea - your app - 30 days. Get started! http://windows8center.sourceforge.net/ what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Bug in get_string_descriptor?
On 2012.10.29 18:47, Peter Stuge wrote: > While the Windows-specific HID class code for emulating USB transfers > over HID in libusbx does use the same OS-native API as HIDAPI (maybe > even some code from HIDAPI?) From the copyright notice: "HID Reports IOCTLs inspired from HIDAPI by Alan Ott". That's the only part of HIDAPI we "reused". Instead, the bulk of the HID code came from libusb-win32 v1, where Stephan Meyer had added support for the HID driver. > it isn't (currently) as portable. It's only meant for Windows, so of course it's not meant to be portable, even more so as it isn't needed on Linux. Windows adds a limitation for HID device access in libusbx so we work around it. As an OS specific workaround, portability is a non-issue. > I don't know what the longer-term plan in libusbx is regarding HID > class support. One idea would be to integrate HIDAPI wholesale in > order to emulate USB transfers over HID also on Linux and OS X. Except libusb/libusbx has no need to emulate USB transfer over HID on Linux. It can just perform generic USB transfers against the device. *This* is the behaviour we are bringing to Windows, because this is what we expect our users to want, and no matter how much HIDAPI is being promoted, past records indicate that it is indeed the case. > I > don't believe there were suggestions in any direction so far, but > I think using more of HIDAPI in libusbx would be a logical extension. Considering that libusbx is the lower level library here, theoretically, the most logical thing would be for HIDAPI to rely on libusbx rather than the opposite (though there are some challenges, but those will manifest themselves either way). Anyway, HID support for libusbx Windows, as a means of emulating generic USB access for HID devices, is here to stay. Just as we did in the past, we will fix issues as we discover them on the grounds that, unlike libusb, we don't see it as beneficial to force users to go through 2 libraries when one should do. Regards, /Pete -- The Windows 8 Center - In partnership with Sourceforge Your idea - your app - 30 days. Get started! http://windows8center.sourceforge.net/ what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Bug in get_string_descriptor?
On 2012.10.29 18:32, Stefano Di Martino wrote: > You mean under Windows? I just did this today, but I'll attach it again. Sorry, missed the first one (catching up on e-mail). Apart from the assertion warnings, I don't see much of anything wrong, and I'm not even sure that the assertion is an issue at this stage. I have a similar audio device and the first interfaces are hijacked by the Windows A/V subsystems so don't register as HID => only the 4th interface will. From what I can see, libusbx properly recognises that the first 3 interfaces are no go and therefore attempts to use the 4th. I can't see the NO_MEM yet (still looking at it), and I also can't see string descriptors from lsusb. Does your device actually have string descriptors? Regards, /Pete -- The Windows 8 Center - In partnership with Sourceforge Your idea - your app - 30 days. Get started! http://windows8center.sourceforge.net/ what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Bug in get_string_descriptor?
Pete Batard wrote: > > I don't believe there were suggestions in any direction so far, but > > I think using more of HIDAPI in libusbx would be a logical extension. > > Considering that libusbx is the lower level library here, theoretically, > the most logical thing would be for HIDAPI to rely on libusbx rather > than the opposite The theory in this case is just that, theory. Since libusbx replicates what HIDAPI (and libusb-win32) does, and then adds onto that, libusbx is indeed higher level than HIDAPI. > unlike libusb, we don't see it as beneficial to force users to go > through 2 libraries when one should do. That is confusing. HIDAPI doesn't depend on libusb. HIDAPI can optionally use libusb, but that's only useful on old Linux systems where the OS-native HID API was insufficient. //Peter -- The Windows 8 Center - In partnership with Sourceforge Your idea - your app - 30 days. Get started! http://windows8center.sourceforge.net/ what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Bug in get_string_descriptor?
On 2012.10.29 19:30, Peter Stuge wrote: > Since libusbx > replicates what HIDAPI (and libusb-win32) does, and then adds > onto that, libusbx is indeed higher level than HIDAPI. You can reverse the above. HIDAPI replicates what libusbx (and libusb-win32) does and then adds onto that. Only in your reality distortion field does HIDAPI seem to mimic the Windows HID API exactly. But if that is indeed the case, why use HIDAPI at all on Windows? >> unlike libusb, we don't see it as beneficial to force users to go >> through 2 libraries when one should do. > > That is confusing. Only if you fail to consider that some libusbx users may want their app to access BOTH HID and non HID USB devices. Or reuse more generic existing libusb/libusbx code. Or have provisions to switch away from HID for their device in the future, if HID was used as an easy means to solve the driver installation issue on Windows. Could probably add some more... > HIDAPI doesn't depend on libusb. > > HIDAPI can optionally use libusb, Now isn't that interesting? Then why on earth would we drop all that good stuff Alan Ott added to HIDAPI and do a 180 to have libusb/libusbx use HIDAPI? If anything we should try to leverage what exists. > but that's only useful on old > Linux systems where the OS-native HID API was insufficient. Still, that's something that could be reused, as opposed to something that doesn't exist and that we would have to code for from scratch. Anyway, we've been through that already and you're free to do whatever you please with libusb, as you did with HID. Don't take it personally if we choose not to follow your ways in a project that forked mostly so that we wouldn't have to. Regards, /Pete -- The Windows 8 Center - In partnership with Sourceforge Your idea - your app - 30 days. Get started! http://windows8center.sourceforge.net/ what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Bug in get_string_descriptor?
On 2012.10.29 19:25, Pete Batard wrote: > I can't see the NO_MEM yet (still looking at it) OK, I think I have reproduced the NO_MEM issue on my end. This seems to be generated from: https://github.com/libusbx/libusbx/blob/master/libusb/os/windows_usb.c#L3888 Regards, /Pete -- The Windows 8 Center - In partnership with Sourceforge Your idea - your app - 30 days. Get started! http://windows8center.sourceforge.net/ what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Bug in get_string_descriptor?
Yes, actually I get this error in listdev.c (I modified it). I'll attach the source and the debug file. Best regards Stefano On 29.10.2012 20:25, Pete Batard wrote: On 2012.10.29 18:32, Stefano Di Martino wrote: You mean under Windows? I just did this today, but I'll attach it again. Sorry, missed the first one (catching up on e-mail). Apart from the assertion warnings, I don't see much of anything wrong, and I'm not even sure that the assertion is an issue at this stage. I have a similar audio device and the first interfaces are hijacked by the Windows A/V subsystems so don't register as HID => only the 4th interface will. From what I can see, libusbx properly recognises that the first 3 interfaces are no go and therefore attempts to use the 4th. I can't see the NO_MEM yet (still looking at it), and I also can't see string descriptors from lsusb. Does your device actually have string descriptors? Regards, /Pete -- The Windows 8 Center - In partnership with Sourceforge Your idea - your app - 30 days. Get started! http://windows8center.sourceforge.net/ what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel debug-and-sourc.tar.gz Description: application/gzip -- The Windows 8 Center - In partnership with Sourceforge Your idea - your app - 30 days. Get started! http://windows8center.sourceforge.net/ what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Bug in get_string_descriptor?
My modified listdevs.c works under Linux, by the way. Best regards Stefano On 29.10.2012 21:17, Stefano Di Martino wrote: Yes, actually I get this error in listdev.c (I modified it). I'll attach the source and the debug file. Best regards Stefano On 29.10.2012 20:25, Pete Batard wrote: On 2012.10.29 18:32, Stefano Di Martino wrote: You mean under Windows? I just did this today, but I'll attach it again. Sorry, missed the first one (catching up on e-mail). Apart from the assertion warnings, I don't see much of anything wrong, and I'm not even sure that the assertion is an issue at this stage. I have a similar audio device and the first interfaces are hijacked by the Windows A/V subsystems so don't register as HID => only the 4th interface will. From what I can see, libusbx properly recognises that the first 3 interfaces are no go and therefore attempts to use the 4th. I can't see the NO_MEM yet (still looking at it), and I also can't see string descriptors from lsusb. Does your device actually have string descriptors? Regards, /Pete -- The Windows 8 Center - In partnership with Sourceforge Your idea - your app - 30 days. Get started! http://windows8center.sourceforge.net/ what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel -- The Windows 8 Center - In partnership with Sourceforge Your idea - your app - 30 days. Get started! http://windows8center.sourceforge.net/ what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel -- The Windows 8 Center - In partnership with Sourceforge Your idea - your app - 30 days. Get started! http://windows8center.sourceforge.net/ what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Bug in get_string_descriptor?
On 2012.10.29 20:27, Stefano Di Martino wrote: > My modified listdevs.c works under Linux, by the way. Yes, I've seen that. And I think I have identified the issue at hand: the code for composite devices does not issue a request to open the underlying HID interfaces when they are available, and therefore we fail to get a handle we can work with to access the device. I should have a fix later on today or tomorrow. I'll also change that NO_MEM error to NOT_FOUND, as the issue had nothing to do with memory access. Regards, /Pete /Pete -- The Windows 8 Center - In partnership with Sourceforge Your idea - your app - 30 days. Get started! http://windows8center.sourceforge.net/ what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Bug in get_string_descriptor?
That would be great. A big THANKS! :-) Best regards Stefano On 29.10.2012 21:39, Pete Batard wrote: > On 2012.10.29 20:27, Stefano Di Martino wrote: >> My modified listdevs.c works under Linux, by the way. > Yes, I've seen that. And I think I have identified the issue at hand: > the code for composite devices does not issue a request to open the > underlying HID interfaces when they are available, and therefore we fail > to get a handle we can work with to access the device. > > I should have a fix later on today or tomorrow. > > I'll also change that NO_MEM error to NOT_FOUND, as the issue had > nothing to do with memory access. > > Regards, > > /Pete > > /Pete > > > -- > The Windows 8 Center - In partnership with Sourceforge > Your idea - your app - 30 days. > Get started! > http://windows8center.sourceforge.net/ > what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/ > ___ > libusbx-devel mailing list > libusbx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/libusbx-devel > -- The Windows 8 Center - In partnership with Sourceforge Your idea - your app - 30 days. Get started! http://windows8center.sourceforge.net/ what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Bug in get_string_descriptor?
The latest commit [1] should fix access to composite HID interfaces. If you need help recompiling from latest git, please see https://github.com/libusbx/libusbx/wiki#wiki-Accessing_the_Source Alternatively, you can just download the github zipball from https://github.com/libusbx/libusbx/zipball/master Just to confirm that things work as they should, a debug output of xusb -d against your device would be nice. Regards, /Pete [1] https://github.com/libusbx/libusbx/commit/fdff665a44169eda702a1267a3bbb4501d6bb3ee -- The Windows 8 Center - In partnership with Sourceforge Your idea - your app - 30 days. Get started! http://windows8center.sourceforge.net/ what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Building git code on Mac; CMake support?
On 2012.10.26 09:18, Ludovic Rousseau wrote: > Regarding build using Xcode I added a config.h for Xcode. So it is now > possible to build using Xcode without using ./configure first. > Use my xcode branch at https://github.com/LudovicRousseau/libusbx/tree/xcode I haven't had a chance to follow closely on the Xcode support discussion but is your Xcode branch ready for integration? By the looks of it, I think I'll merge the commits in a single patch when integrating it. Regards, /Pete -- The Windows 8 Center - In partnership with Sourceforge Your idea - your app - 30 days. Get started! http://windows8center.sourceforge.net/ what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Building git code on Mac; CMake support?
On Mon, 29 Oct 2012 23:57:26 +, Pete Batard said: >> Regarding build using Xcode I added a config.h for Xcode. So it is now >> possible to build using Xcode without using ./configure first. >> Use my xcode branch at https://github.com/LudovicRousseau/libusbx/tree/xcode > >I haven't had a chance to follow closely on the Xcode support discussion >but is your Xcode branch ready for integration? Has anyone except the author (Ludovic) tried it? I have not yet. I'd argue it's not ready for integration yet. Since no one but me seems to like the CMake idea, I guess going with an Xcode project is the next best solution, but we then need to decide what versions of Xcode to support. I only looked quickly, but it looks like an Xcode 4 project; personally, I'd like to support back to Xcode 3.1.4 (the last version that supported Mac OS X 10.5). Cheers, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Building git code on Mac; CMake support?
On Tue, Oct 30, 2012 at 8:03 AM, Sean McBride wrote: > On Mon, 29 Oct 2012 23:57:26 +, Pete Batard said: > >>> Regarding build using Xcode I added a config.h for Xcode. So it is now >>> possible to build using Xcode without using ./configure first. >>> Use my xcode branch at https://github.com/LudovicRousseau/libusbx/tree/xcode >> >>I haven't had a chance to follow closely on the Xcode support discussion >>but is your Xcode branch ready for integration? > > Has anyone except the author (Ludovic) tried it? I have not yet. > I'd argue it's not ready for integration yet. I have tried it. I have to modified it since it is targeting Mac OS X Mountain Lion and my system is OS X Lion. So I agree it is not ready for integration. > > Since no one but me seems to like the CMake idea, I guess > going with an Xcode project is the next best solution, but we > then need to decide what versions of Xcode to support. I only looked > quickly, but it looks like an Xcode 4 project; personally, I'd like to > support back to Xcode 3.1.4 (the last version that supported Mac > OS X 10.5). If you can come out with a universal Xcode project working for Mac OS X 10.5 and later, that would be good. But I know next to nothing about Xcode myself. -- Xiaofan -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Bug in get_string_descriptor?
On Tue, Oct 30, 2012 at 3:30 AM, Peter Stuge wrote: > That is confusing. HIDAPI doesn't depend on libusb. > > HIDAPI can optionally use libusb, but that's only useful on old > Linux systems where the OS-native HID API was insufficient. That is true for Linux. HIDAPI also uses native HID API under Windows and Mac OS X. https://github.com/signal11/hidapi Take note HIDAPI depends on libusb (FreeBSD's own BSD licensed libusb-1.0 API implementation, on top of its own libusb20 library) under FreeBSD. I can see that HIDAPI will be used more an more often for generic HID device. On the other hand, there are existing libusb based application which use libusb-0.1 and 1.0 API under Linux and libusbx's Windows HID backend give them a nature migration path without changing to use HIDAPI. Moreover, I can see that there will be more features added to libusbx in the future which HIDAPI may take time to implement (eg: hotplug, cross-platform event handling). So in the end, for generic USB HID device, HIDAPI and libusbx will both be a viable option. It is always good to provide users the choices. So as Pete says, libusbx's Windows HID backend will be here to stay as it is beneficial to some users. -- Xiaofan -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
