> but going down the path of 'i hope people see this and don't buy products'
> seems a little... harsh?
How about Renesas then? Pretty much the same business model, except, and I
speak from experience here, users can actually reach out to their developers
when they encounter an issue.
I was abl
> Glad we could publicly establish that ASMedia doesn't seem to care about
> their actual customers. Hopefully this will help potential buyers of
> ASMedia-based hardware decide whether they want to use products from a
> company which, if your report is correct, appears to have little interest i
> Just want to copy the comments on top of enum.c here.
Yeah, I can read code and comments too, __when I have the time__.
I was simply hoping that you could speed up things by doing the analysis and
tell us exactly what process is used by usbview to compute the port number (NB:
the rest of the p
> Got a response from ASMedia, which used a lot of polite words to tell me 'We
> don't talk to end users, go away'
Glad we could __publicly__ establish that ASMedia doesn't seem to care about
their actual customers. Hopefully this will help potential buyers of
ASMedia-based hardware decide whe
Kano wrote:
> I didn't spot the obvious that an endpoint is unique across a device
> thus it also indirectly identifies the interface.
> i.e. all transfers do indeed infer the interface (via the endpoint)
This is an interesting philosophical point about USB that is important
but not well understoo
I noticed a memory leak after updating to libusb 1.0.16 which added hotplug
support, the leak is also present in the current git version. Basically I see
libusb_device object leaking and tracked this down an unhandled hotplug left
event that was created between my last call to libusb_handle_even
Got a response from ASMedia, which used a lot of polite words to tell me 'We
don't talk to end users, go away'
---
Reply to this email directly or view it on GitHub:
https://github.com/libusbx/libusbx/issues/147#issuecomment-25163074---
Same warning under MinGW-w64 gcc 4.8.1.
---
Reply to this email directly or view it on GitHub:
https://github.com/libusbx/libusbx/issues/149#issuecomment-25154654--
October Webinars: Code for Performance
Free Intel webinar
Under latest MinGW.org gcc (4.8.1), there is a warning for ezusb.c
ezusb.c: In function 'ezusb_load_ram':
ezusb.c:719:6: warning: 'ret' may be used uninitialized in this function [-Wmayb
e-uninitialized]
int ret;
---
Reply to this email directly or view it on GitHub:
https://github.com
Just want to copy the comments on top of enum.c here.
The enumeration process goes like this:
(1) Enumerate Host Controllers and Root Hubs
EnumerateHostControllers()
EnumerateHostController()
Host controllers currently have symbolic link names of the form HCDx,
wher
10 matches
Mail list logo
