e > 0x4000, I'd also be happy
for any hint towards how to reproduce this behaviour.
Thanks in advance,
/Markus
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's securi
}
> > As I don't have any known-good device where I could meaningfully
> > test a control transfer with wValue > 0x4000, I'd also be happy
> > for any hint towards how to reproduce this behaviour.
>
> I have certainly done vendor device requests with wValue
On Wed, 13 10:36 , Pete Batard wrote:
> > I don't see any debug messages (though I enabled the libusbx debug
> > facility in my code, level 3).
>
> Try level 4. 4 is the level to set for debug, not 3.
Thanks for the reminder... My bad. I' running the RC from yesterday
BTW.
Here's the log of th
apture USB on Windows, it
looks as I'll have to resort to a proprietary tool.
Can you (or somebody else reading the list) recommend something worthwhile in a
price range < 500$ ?
Regards,
/Markus
--
Live Secu
mething more
meaningful than writing code for a platform-agnostic firmware
flashing tool ...
I'll post a bus dump tomorrow. Maybe there's something unusual
showing up there.
Regards,
/Markus
--
Live Security Virtua
ontrolTransfer failed. Win32Error=%u(0x%08X)\n", errorCode,
errorCode);
goto Done;
}
memOffset += 0x40;
}
Thanks in advance,
/Markus
>
>
>
> --
> Live Security Virtual Conference
> Excl
gly and will let you know if I
have something working.
Thanks for your help so far. Even though it might not have
solved the problem, I'm aware of quite some pitfalls now one can
step into.
All the best,
/Markus
--
Li
developing with the FX3 and libusbx should be
fairly straightforward on all supported platforms with this
addition.
All the best,
/Markus
--
Live Security Virtual Conference
Exclusive live event will cover all the ways
ild on a variety of platforms without any major hassle.
A port of fxload as a libusbx example would certainly be a good
thing to have though.
Regards,
/Markus
--
Live Security Virtual Conference
Exclusive live event wil
inst the 1.0.13 milestone,
> in one form or another. Feel free to add more to that enhancement if you
> feel like it. And thanks for the patch.
>
Thanks for submitting it. BTW, I spotted a few indentation glitches.
Thanks,
/Markus
--
re is coming up as
a USB 2.0 device.
I don't see a difference whether I'm running it on a USB 2.0 or
USB 3.0 port, as long as I don't run firmware that exposes USB
3.0 specific descriptors.
If you like to see some particular things with the board, I
might be able t
s the case, then there are device addresses 0 to 126 +
255 (the root hub), correct?
Thanks in advance,
/Markus
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threa
Sorry, I have to correct myself:
> If this is the case, then there are device addresses 0 to 126 +
> 255 (the root hub), correct?
As 0 is the setup address, it most probably is 0 to 127 + 255.
Regards,
/
thing being able to retrieve
this information in the same way on all supported operating
systems BTW.
All the best,
/Markus
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today
2load posted to the
Cypress FX3 forum (amongst others). See this URL for reference:
http://comments.gmane.org/gmane.linux.hotplug.devel/17427
All the best,
/Markus
--
Live Security Virtual Conference
Exclusive live e
pproach this one. However there might be some other libusbx
users interested in implementing this.
Regards,
/Markus
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security
ay to tell which host controller model runs a given bus except
for Windows.
Do you see a chance to get such a matching done in libusbx or do
you consider that outside its scope?
All the best,
/Markus
--
Live Securi
quot; device, where eyeballing might not
be possible at all in the short term.
However, this would be more easily solved in software, if there
is a way to retrieve which device are on a common bus.
It will also be helpful to know the manufacturer and model of a
HC in those cases
> way to tell which host controller model runs a given bus except
> > for Windows.
>
> Not true at all. It's certainly possible to find out that information
> in Linux.
Of course it is. But not with libusbx currently.
All the best,
/Markus
-
t be exposed as USB devices,
> because they are not USB devices.
As for the root hubs, I agree with Pete; however, the VID/PID
assignment has to be thought through since it won't be correct
in most cases (i.e. if the PCI and USB VID are not identical for
a given manufacturer)
All the bes
ends to
prefer download when flashing firmware to a device.
All the best,
/Markus
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed a
the data transfer executes on the PC
> (or, in a more general manner, if the environment where the end user
> is going to actively perform actions is not the target), then, as
> far as I'm concerned, it should logically be labelled as an upload.
I don't have much of a preferen
atter of fact, it is now included as a full fledged sample in the
> 0K branch [3].
>
> For now support is only for FX2 and earlier, so we need to re-apply an
> FX3 patch. I'll try to take care of that, but Markus, if you feel like
> you want to go for it, don't hesitate.
rselves (which is not very realistic);
this way, we'd know the entry address.
Otherwise we might make the entry address an optional
argument to the FX3 upload call and leave it to the user to
retrieve it.
As this is not mission-critical, I dare say that I can take over
this.
All t
On 21 Aug 2012 14:17 , Markus wrote:
> It even looks as if they just added a simple SDK helper function,
> while the functionality was always available. You first have to
> retrieve the entry point of course.
Sorry, got it wrong. While the above mentioned things are valid,
the
m I missing something? If not, would you be willing to change
this, as it would enable a lot more applications with libusbX.
Thanks in advance,
/Markus
--
Everyone hates slow websites. So do we.
Make your web apps fast
xisting for handling usbK devices.
Is it a misconception on my side, that it suffices to have a
driver registered for interface 0x0 of the device?
If I can supply more information, let me know.
Thanks in advance,
/Markus
---
Also add #include directives since this is a complete program including
main().
---
I'm not sure about the #include directives. If not desired, they can be
discarded along with the corresponding sentence in the patch description.
libusb/hotplug.c | 8 +++-
1 file changed, 7 insertions(+), 1
For example:
libusbx: debug [get_api_type] matched driver name against HUB API API
---
libusb/os/windows_usb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libusb/os/windows_usb.c b/libusb/os/windows_usb.c
index aa4c0f4..3018d90 100644
--- a/libusb/os/windows_usb.c
+++ b/lib
This change makes examples/listdevs.exe work for the affected USB ports,
which before failed with the following warning:
[..] was only detected in late pass (newly connected device?) - ignoring
The driver has to be updated, version 1.0.0.66 (2011-10-25) worked.
With version 1.0.0.52 (2011-03-17
30 matches
Mail list logo
