Closed #161.
---
Reply to this email directly or view it on GitHub:
https://github.com/libusbx/libusbx/issues/161--
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download
Ok. Thanks for the clarafication.
I will close the issue.
---
Reply to this email directly or view it on GitHub:
https://github.com/libusbx/libusbx/issues/161#issuecomment-30203608--
Sponsored by Intel(R) XDK
Develop, tes
Indeed, the upgrade from VS2012 is simple, and in fact the VS2013 files can be
loaded in VS2012 as they are backwards compatible. The main difference is which
runtime each one targets, which is a simple change.
My motivation for creating the separate files was so that I could compile for
the VS
Pete,
I took a quick look at the WinUSB isoc calls and they are similar in concept
but have a different structure and signature. There is also a semantic
different in that WinUSB requires an extra call to WinUsb_RegisterIsochBuffer()
and WinUsb_UnregisterIsochBuffer() while to my knowledge libu
I think that makes sense. Unless there are any objections, I'll try to
integrate this when I get a chance (can't let all of your efforts seem to go
wasted after all ;))
/Pete
---
Reply to this email directly or view it on GitHub:
https://github.com/libusbx/libusbx/pull/163#issuecomment-30194212
Thanks, but is there any possibility you could see how this fits with the
[WinUSB isochronous support that was added by Microsoft for the WinUSB driver
of Windows
8.1](http://msdn.microsoft.com/en-us/library/windows/hardware/dn303354%28v=vs.85%29.aspx#usb_wdk)?
Ideally, we want to avoid adding
Hi Josh,
Thanks for the files, but the current policy is that we only add solution and
project files for the dev env that active libusbx maintainers are using, and
right now, I'm not aware of any of us using VS2013 or planning to upgrade to
2013 anytime soon.
This policy stems from libusb/libu
This pull request wires up isochronous support for the Windows backend via the
libusbk sub api. It continues to return UNSUPPORTED for non-libusbk sub APIs.
There are a few //TODO comments on places that need further plumbing or I am
unsure about the flow, but this works enough to receive data f
This pull request adds handling for super-speed isochronous packet size to
libusb_get_max_iso_packet_size. It checks the superspeed endpoint companion
descriptor for the recommended packet length, per
http://msdn.microsoft.com/en-us/library/windows/hardware/hh406225(v=vs.85).aspx:
> For SuperSp
This pull request adds Visual Studio 2013 solution and project files. The 2013
project files are set to use the VS2013 runtime (v120). It also adds sdf and
opensdf to the .gitignore.
Benefits:
* Can use latest VS2013 development environment for compiling libusbx
* Can use latest VC++ runtime, i
ccier wrote:
>
> And libusbx handles this situation differently if libusbK is used?
>
libusbx does not handle the situation at all. That's the issue. This
is a WinUSB "feature" that libusbK does not have and libusbx did not
anticipate.
--
Tim Roberts, t...@probo.com
Providenza & Boekelheide, I
Ok.
And libusbx handles this situation differently if libusbK is used?
---
Reply to this email directly or view it on GitHub:
https://github.com/libusbx/libusbx/issues/161#issuecomment-30165267--
Sponsored by Intel(R) XDK
ccier wrote:
>
> Ok, thanks for the info.
>
> Yes, i am claiming interface 0 and interface 3 on the same handle.
> It is a Huawei USB modem. The driver is installed on the parent
> device. In this way I would assume that I have total control over the
> device using libusbx.
>
Yes, this is a subtle
I am trying to send a class specific request to interface 3, namely an
encapsulated command for the modem (CDC ECM).
It is already working with libusbK, but not with WinUSB.
---
Reply to this email directly or view it on GitHub:
https://github.com/libusbx/libusbx/issues/161#issuecomment-30163782-
Ok, thanks for the info.
Yes, i am claiming interface 0 and interface 3 on the same handle.
It is a Huawei USB modem. The driver is installed on the parent device. In this
way I would assume that I have total control over the device using libusbx.
---
Reply to this email directly or view it on G
Please let's come back to the topic.
Are you familiar with the internals of the Windows backend code in libusbx?
Do you have any explanation why it works with libusbK, but not with WinUSB?
---
Reply to this email directly or view it on GitHub:
https://github.com/libusbx/libusbx/issues/161#issueco
ccier wrote:
>
> I want to send the following control transfer:
>
> |r = libusb_control_transfer(handle,
> LIBUSB_REQUEST_TYPE_CLASS | LIBUSB_RECIPIENT_INTERFACE |
> LIBUSB_ENDPOINT_OUT,
> 0, 0, 3, packet, size, 2000);
> |
>
> However, the USB sniffer always shows the field wIndex as 0 ins
Kerdo Link wrote:
>
> Shouldn't 3 be 0x03? because of uint16_t?
>
You don't honestly think there is any difference between 3 and 0x03, do you?
--
Tim Roberts, t...@probo.com
Providenza & Boekelheide, Inc.
--
Sponsored
I tried 3, 0x03, (uint16_t) 0x0003 and so on.
I got it working though. The problem is related to the Windows backend that is
used. Here it is WinUSB.sys.
I have used Zadig to switch to libusbK (v3.0.5.16) and now the wIndex field on
the bus is working for the setup packet.
---
Reply to this emai
Shouldn't 3 be 0x03? because of uint16_t?
---
Reply to this email directly or view it on GitHub:
https://github.com/libusbx/libusbx/issues/161#issuecomment-30138164--
Sponsored by Intel(R) XDK
Develop, test and display we
I want to send the following control transfer:
r = libusb_control_transfer(handle,
LIBUSB_REQUEST_TYPE_CLASS | LIBUSB_RECIPIENT_INTERFACE |
LIBUSB_ENDPOINT_OUT,
0, 0, 3, packet, size, 2000);
However, the USB sniffer always shows the field wIndex as 0 instead of 3.
The other f
Update:
It is only the lower byte which always becomes 0. The upper byte works ok.
---
Reply to this email directly or view it on GitHub:
https://github.com/libusbx/libusbx/issues/161#issuecomment-30136981--
Sponsored by
22 matches
Mail list logo
