erences are shared between a parent and a child,
there should be no problem.
Alan Stern
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Cri
s
will still be sent at the right times. With interrupt transfers, an
error will cause up to two retries, delaying not just the one piece of
data but also everything following it.
Of course, this usually doesn't matter. T
end of
section 5.6.3 in the USB-2.0 spec, it says:
All device default interface settings must not include any
isochronous endpoints with non-zero data payload sizes
(specified via wMaxPacketSize in the endpoint descriptor).
Alternate interface settings may spec
s
> improved enormously with successive Raspbian releases. I'll buy a couple of
> other hubs and see if they're any better, but as to my original fear that
> this is some systemic problem with my code that will affect other platforms
> in time: I suspect those fears are unfou
//github.com/makestuff/flcli/tree/20131026
> https://github.com/makestuff/libfpgalink/tree/20131026
> https://github.com/makestuff/libusbwrap/tree/20131026
>
> My main goal is to eliminate the possibility that it's me doing something
> si
On Mon, 9 Sep 2013, Xiaofan Chen wrote:
> On Sat, Sep 7, 2013 at 11:36 PM, Alan Stern wrote:
> > Slightly off the original topic but perhaps still relevant...
> >
> > There are several Linux programs using libusb-0.1 that don't work with
> > libusb-compat. The
uding
the underlying file descriptor -- these programs might suddenly start
working. (Note that doing this would require adding a function to the
libusb-1.0 API for retrieving the low-level file descriptor.)
Anybody feel like implementing this?
Alan Stern
he "flaming-curses" variety favored by certain people.
> long it may take for them to have any kind of effect, if any.
I doubt most of them will ever have any effect. But who knows?
Alan Stern
--
Get
I added a blanket
quirk for _all_ devices with those vendor IDs. (The vendors in
question were Nokia, Nikon, Pentax, and Motorola, and the bug was that
the devices would return the total number of data blocks they contained
when
On Wed, 7 Aug 2013, Pete Batard wrote:
> On 2013.08.06 14:57, Alan Stern wrote:
> > I agree, it does need to change. This means putting more pressure on
> > manufacturers, not on the users.
>
> And how else are you going to put pressure on manufacturers?
I wish I knew.
at's not the kind of world I want to live in.
> As long as no one asks for change, nothing will ever change.
Go ahead and complain. I'll support you, and no doubt a bunch of other
people will to.
But I'm not willing to stop adding support for hardware that people
already own
; favour in the long run, because it basically tells manufacturers that
> it's perfectly fine to ignore Linux altogether.
That kind of attitude doesn't work out in the real world. It only
leads to people ignoring you. You can afford to do that sort of thing
if you have Microsoft
rward to telling users: "Libusb doesn't work
with your device because it crashes when we send it this request for
information which we don't really need"?
Alan Stern
--
Get your SQL database under ve
On Sat, 3 Aug 2013, Pete Batard wrote:
> On 2013.08.03 21:18, Alan Stern wrote:
> > I agree with Hans. In-library caching should be done on-demand, not
> > whenever a new device is enumerated.
> >
> > If the program asks the library for a string descriptor, t
henever a new device is enumerated.
If the program asks the library for a string descriptor, the back end
can get the descriptor from the OS's cache, if one is available. Or it
can talk to the device. That's up to the back end. But if the program
doesn't ask for a string descrip
x27;t accept any more transfers
for that device. Maybe the code already does this; I haven't looked.
Alan Stern
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with ap
On Sun, 21 Jul 2013, Nathan Hjelm wrote:
> On Jul 21, 2013, at 8:11 PM, Alan Stern wrote:
>
> > On Sun, 21 Jul 2013, Nathan Hjelm wrote:
> >
> >> A little more detail about what is happening in this case. When the
> >> device gets di
ceived, but leave the transfers intact. They will soon fail all by
themselves, and the OS completion callbacks can be handled in the usual
way. After all the transfers are gone, then it will be safe to finish
the disconnection procedure.
Alan Stern
to your
program as soon as the first KB has been sent out. Then it would
require two more IN transfers on the bus: one for the programs second
IN request and one to buffer for later. This would explain what you
observe.
Alan Stern
--
On Sun, 19 May 2013, Hans de Goede wrote:
> Hi, Greg, Alan, All,
>
> On 05/18/2013 06:17 PM, Greg KH wrote:
> > On Sat, May 18, 2013 at 12:14:08PM -0400, Alan Stern wrote:
> >> On Sat, 18 May 2013, Hans de Goede wrote:
> >>> But the sysfs descriptors file will
.wTotalLength, where as
> userspace only sees the length advertised by
> the rawdescriptors, which may be different, and when
> it is userspace will this have no idea where the next
> descriptor starts.
>
> I believe the proper way to fix this is to make the
> sysfs code de
On Sat, 30 Mar 2013, Wander Lairson Costa wrote:
> 2013/3/29 Alan Stern :
> > On Fri, 29 Mar 2013, Wander Lairson Costa wrote:
> >
> >> Dear all,
> >>
> >> I have a (kind of dumb) question regarding libusb_bulk_transfer and
> >> libusb_interrup
ace
> they will send/receive data to/from?
They _do_ receive interface-related information in their parameters:
the endpoint address. Each endpoint belongs to a single interface.
Alan Stern
--
Own the Future-Inte
71 generally means that the device failed to respond. Perhaps
the USB cable was disconnected, or the firmware crashed.
Alan Stern
--
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Wave(TM): En
ffering the data sent by the device
(which can be longer than the requested amount), and then giving the
remaining data to the client in response to the next read request.
This feature is not available on Linux, or presumably on other
platforms. I don't see any reason why libusb or libusbx should s
On Tue, 25 Dec 2012, Xiaofan Chen wrote:
> On Tue, Dec 25, 2012 at 12:28 AM, Alan Stern
> wrote:
> > (Although I don't believe Apple uses
> > UHCI components in their machines.)
>
> Supposedly Apple uses Intel chipsets now and will have UHCI along with
> th
s
> / second.
On the other hand, it doesn't require much agility to move a mouse
faster than 16 pixels/second. But I agree that HID devices do not
need to e polled 1000 times per second, as a general rule. In fact,
many HID devices run at low speed rather than full speed, and USB
dema
ever that may be).
It is the Realtek RTL28xxU DVB USB kernel driver.
At any rate, you should be able to use your program easily enough if
you add a call to libusb_detach_kernel_driver() before claiming the
interface.
Alan Stern
ble to explain this.
If you want to find out more about what's going on, compare the
/sys/kernel/debug/usb/devices file with one stick plugged in to the
same file with the other stick plugged in.
Alan Stern
--
under
> Windows (the software is Mingw-64 cross compiled with libusbx).
>
> Any suggestion on what is happening would be nice
-6 is LIBUSB_ERROR_BUSY. It means that another driver has already
claimed the inte
r; they are totally different. One cannot be used
as a substitute for the other. It would be like trying to use "ls" as
a substitute for "dd".
Alan Stern
--
WINDOWS 8 is here.
Mill
driver) to carry out the command.
Does Windows provide this sort of "raw SCSI" interface?
Alan Stern
--
WINDOWS 8 is here.
Millions of people. Your app in 30 days.
Visit The Windows 8 Center at Sourceforge for
tances. If the
bRequestType doesn't indicate a vendor-specific type, and if the
recipient is an interface or an endpoint belonging to an interface,
then the request won't be accepted if someone else has already claimed
that interface. And if nobody has claimed the interface, it will
automati
e Number: 1
> Number of endpoints: 0
>
> What I don't get is how to write to the second interface.
>
> Using anything other than an index of 1 for libusb_claim_interface()
> returns LIBUSB_ERROR_NOT_SUPPORTED.
The first interface is index 0, the second is index 1.
> I
ollowing string (i.e., the part following the
comma) to the linker as a command-line option.
Alan Stern
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance managemen
will just act like the
> regular claim-interface ioctl, this is by design, as returning an error for
> this condition would open a new bag of race-conditions.
>
> Changes in v2:
> -Fix indentation of if blocks where the condition spans mu
packet value;
that also wouldn't be so bad.)
Then the RAW_IO flag could always be used and the other options would
be irrelevant. It's kind of a shame that Windows goes to such lengths
to provide the illusion of a continuous data stream instead of the
packetized stream that USB
o do with short
packets, as Hans assumed. Instead, it means the WinUSB will allow the
driver to read less data than the device sends, without generating a
Babble error.
Alan Stern
--
Live Security Virtual Conference
Exclusive
SY;
If you prefer something else, that's okay. Just don't put the
"strncmp" in the same column as the "return".
> Before I respin the patch, any other remarks from you?
No, everything else seems okay.
Alan Stern
-
B
descriptors), but that's not true here. The only requirement is that
the compilers used to build the kernel and the application agree on the
size of unsigned int. If they didn't then things like struct dirent
wouldn't work (it contains an unsigned short).
Now if the type were unsig
rovide any valid driver name, and let NULL mean usbfs.
No, let NULL mean "always detach". "usbfs" can mean usbfs. :-)
Alan Stern
--
Live Security Virtual Conference
Exclusive live event will cover all th
r remaining possibility is a race between two
libusb programs, in which case we don't care very much which one wins.
Alan Stern
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today&
of a
> HC in those cases.
I agree. However, host controllers aren't USB devices. That is, they
don't attach to a USB bus; they attach to some other sort of bus, such
as PCI. Hence to learn the manufacturer and model of a host controller
you would nee
r a root hub, the values returned by other operating systems
are just as valid as the values returned by Windows.
> So it looks as if there is no possible
> way to tell which host controller model runs a given bus except
> for Windows.
Not true at all. I
n enumerated.
> However, our querying of the hub is tied to already having identified a
> device instantiated by Windows, and trying to populate some of its data.
> Thus that DeviceAddress 0 entry we see should be an extra entry that
> will be dropped, as failing to m
On Mon, 16 Jul 2012, Pete Batard wrote:
> On 2012.07.16 20:09, Alan Stern wrote:
> > The device address is the actual value used on the USB bus to identify
> > the device. It is a 7-bit number, and it can take on any value from 0
> > to 127. However 0 is reserved for newly-
e value currently used by libusbx is always 255. The
actual value is rather arbitrary, since it never appears on the USB
bus.
Alan Stern
--
Live Security Virtual Conference
Exclusive live event will cover all the ways
gain ...
True. And it doesn't help in situations where usbfs doesn't own all of
the interfaces.
> > Repeat the unbind and try again if the reclaim fails. Two iterations
> > should be sufficient.
by this patch.
>
> This still leaves a theoretical race window where the driver registration
> finishes between our driver-unbind and interface-reclaim, I'm afraid there
> is nothing we can against this.
Repeat the unbind and try again if the reclaim fails. Two iterations
sho
read "The UNIX-HATERS Handbook" by Garfinkel, Weise,
and Strassmann? It has a section on the ">From" problem on p.79.
The book is very funny and a lot of fun to read. And it's freely
available
tor_by_value().
0 is not a valid configuration _value_ but it is a valid configuration
_index_.
Alan Stern
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
t
dy pointed out in my previous mail in this thread, it seems
> that devio too assumes that the controller will clear the halt it self after
> a short bulk in packet.
>
> Would it be possible to first let the completion handler of the short packet
> run before clearing the halt? And cou
controller. That is, the hardware is supposed to recognize it as an
exceptional case and stop the endpoint queue.
Sarah knows the answers; she's the xhci-hcd maintainer. Anything I
said about it would just be speculation.
Alan Stern
---
within devio.c.
> Regards,
>
> Hans
>
> p.s.
>
> To verify my theory, I've tried raising the packet splitting limit in
> libusb to 32k and that (unsurprisingly) fixes things, but that is just
> a bandaid and not a proper fix for the issue at hand IMHO. Also
>
pecify a driver name, and have USBDEVFS_DISCONNECT do nothing if
the current driver isn't the one specified.
Alan Stern
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today&#x
55 matches
Mail list logo
