You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
(2) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(4) |
Feb
(19) |
Mar
(5) |
Apr
(5) |
May
|
Jun
(3) |
Jul
(21) |
Aug
(27) |
Sep
|
Oct
(5) |
Nov
(4) |
Dec
(3) |
2002 |
Jan
(27) |
Feb
(33) |
Mar
(25) |
Apr
(40) |
May
(58) |
Jun
(25) |
Jul
(39) |
Aug
(23) |
Sep
(15) |
Oct
(26) |
Nov
(75) |
Dec
(35) |
2003 |
Jan
(29) |
Feb
(13) |
Mar
(24) |
Apr
(58) |
May
(27) |
Jun
(21) |
Jul
(11) |
Aug
(24) |
Sep
(6) |
Oct
(6) |
Nov
(30) |
Dec
(71) |
2004 |
Jan
(125) |
Feb
(47) |
Mar
(31) |
Apr
(29) |
May
(53) |
Jun
(29) |
Jul
(43) |
Aug
(19) |
Sep
(69) |
Oct
(38) |
Nov
(38) |
Dec
(37) |
2005 |
Jan
(59) |
Feb
(92) |
Mar
(32) |
Apr
(54) |
May
(29) |
Jun
(27) |
Jul
(34) |
Aug
(46) |
Sep
(47) |
Oct
(43) |
Nov
(63) |
Dec
(112) |
2006 |
Jan
(99) |
Feb
(117) |
Mar
(68) |
Apr
(59) |
May
(66) |
Jun
(32) |
Jul
(65) |
Aug
(85) |
Sep
(44) |
Oct
(113) |
Nov
(334) |
Dec
(42) |
2007 |
Jan
(64) |
Feb
(147) |
Mar
(245) |
Apr
(427) |
May
(229) |
Jun
(66) |
Jul
(56) |
Aug
(58) |
Sep
(82) |
Oct
(109) |
Nov
(196) |
Dec
(78) |
2008 |
Jan
(143) |
Feb
(79) |
Mar
(85) |
Apr
(126) |
May
(405) |
Jun
(259) |
Jul
(218) |
Aug
(118) |
Sep
(116) |
Oct
(135) |
Nov
(105) |
Dec
(79) |
2009 |
Jan
(196) |
Feb
(146) |
Mar
(60) |
Apr
(180) |
May
(229) |
Jun
(206) |
Jul
(126) |
Aug
(155) |
Sep
(276) |
Oct
(160) |
Nov
(120) |
Dec
(185) |
2010 |
Jan
(685) |
Feb
(581) |
Mar
(460) |
Apr
(650) |
May
(495) |
Jun
(567) |
Jul
(375) |
Aug
(518) |
Sep
(531) |
Oct
(487) |
Nov
(269) |
Dec
(461) |
2011 |
Jan
(524) |
Feb
(457) |
Mar
(385) |
Apr
(316) |
May
(229) |
Jun
(480) |
Jul
(302) |
Aug
(243) |
Sep
(411) |
Oct
(158) |
Nov
(171) |
Dec
(269) |
2012 |
Jan
(117) |
Feb
(177) |
Mar
(225) |
Apr
(251) |
May
(150) |
Jun
(228) |
Jul
(127) |
Aug
(74) |
Sep
(128) |
Oct
(106) |
Nov
(47) |
Dec
(73) |
2013 |
Jan
(83) |
Feb
(224) |
Mar
(69) |
Apr
(182) |
May
(118) |
Jun
(52) |
Jul
(180) |
Aug
(43) |
Sep
(43) |
Oct
(54) |
Nov
(18) |
Dec
(43) |
2014 |
Jan
(40) |
Feb
(78) |
Mar
(138) |
Apr
(85) |
May
(65) |
Jun
(81) |
Jul
(56) |
Aug
(116) |
Sep
(123) |
Oct
(60) |
Nov
(74) |
Dec
(99) |
2015 |
Jan
(120) |
Feb
(126) |
Mar
(176) |
Apr
(133) |
May
(124) |
Jun
(60) |
Jul
(54) |
Aug
(92) |
Sep
(134) |
Oct
(75) |
Nov
(48) |
Dec
(78) |
2016 |
Jan
(94) |
Feb
(89) |
Mar
(109) |
Apr
(33) |
May
(25) |
Jun
(64) |
Jul
(54) |
Aug
(26) |
Sep
(59) |
Oct
(30) |
Nov
(77) |
Dec
(16) |
2017 |
Jan
(37) |
Feb
(22) |
Mar
(25) |
Apr
(7) |
May
(36) |
Jun
(10) |
Jul
(64) |
Aug
(39) |
Sep
(22) |
Oct
(26) |
Nov
(27) |
Dec
(14) |
2018 |
Jan
(10) |
Feb
(31) |
Mar
(15) |
Apr
(35) |
May
(20) |
Jun
(13) |
Jul
(10) |
Aug
(6) |
Sep
(22) |
Oct
(13) |
Nov
(52) |
Dec
(23) |
2019 |
Jan
(25) |
Feb
(17) |
Mar
(30) |
Apr
(34) |
May
(12) |
Jun
(10) |
Jul
(26) |
Aug
(13) |
Sep
(24) |
Oct
(12) |
Nov
(9) |
Dec
(5) |
2020 |
Jan
(24) |
Feb
(12) |
Mar
(40) |
Apr
(20) |
May
(12) |
Jun
(10) |
Jul
(41) |
Aug
(20) |
Sep
(24) |
Oct
(4) |
Nov
(6) |
Dec
(38) |
2021 |
Jan
(34) |
Feb
(33) |
Mar
(10) |
Apr
(12) |
May
(10) |
Jun
(49) |
Jul
(49) |
Aug
(17) |
Sep
(43) |
Oct
(11) |
Nov
(2) |
Dec
(13) |
2022 |
Jan
(14) |
Feb
(14) |
Mar
(1) |
Apr
(6) |
May
(6) |
Jun
(10) |
Jul
|
Aug
(3) |
Sep
(6) |
Oct
(19) |
Nov
(9) |
Dec
(5) |
2023 |
Jan
(4) |
Feb
(9) |
Mar
(30) |
Apr
(17) |
May
(5) |
Jun
|
Jul
(39) |
Aug
(7) |
Sep
(3) |
Oct
(6) |
Nov
|
Dec
(3) |
2024 |
Jan
(2) |
Feb
|
Mar
(17) |
Apr
(16) |
May
(14) |
Jun
(13) |
Jul
(7) |
Aug
(3) |
Sep
(7) |
Oct
|
Nov
|
Dec
|
From: Stephan M. <ste...@we...> - 2004-05-26 13:22:49
|
> I can think of two possible changes that could occur: > > 1) Require the endpoint to always be 4 bits with no direction bit. The > various ports would set the direction bit as needed. > 2) Allow the direction bit to be set for usb_bulk_read, but it must be > clear for usb_bulk_write. This would allow applications to use the > endpoint address as is from the descriptors. > > Any opinions? > I would prefer the second option. It would be the easiest and simplest to implement and to use. And it would be compatible with the descriptors, the kernel, and the specification. One tiny drawback would be that a minority of libusb based projects won't work anymore, but I think that is acceptable. Stephan _____________________________________________________________________ Endlich SMS mit Bildern versenden! Das Bild selbst ist dabei gratis, Sie bezahlen lediglich den Versand. http://freemail.web.de/?mc=021195 |
From: Peter S. <stu...@cd...> - 2004-05-26 00:40:24
|
On Tue, May 25, 2004 at 11:54:30AM -0700, Paul Klissner wrote: > Johannes Erdfelt wrote: > >> libusb does not seem to provide a callback mechanism for device > >> hotplug event notification. I hope I can pursuade the committee > > > >It has been brought up in the past and I certainly would like to add > >that sort of functionality. > > > >Are you looking for a simple asynchronous callback? > > > >If so, out of a thread context or signal context? [..] > I think that signal context is the least stable and prone to mishap > among various UNIX-like OS's. I disagree, I like signals for simple programs. Signals are also available everywhere, whereas threads often introduce extra dependencies. If the application already uses threads on the other hand, a thread context is obviously much prefered. I would like to have both those possibilities. > Therefore I think I am suggesting thread context, which delivers a > simple asynchronous callback, passing a bus and device identifier as > and a flag as to whether the device is being connected or > disconnected. Also relevant is coldplugging. I.e. what happens on application start-up when devices are already attached. Currently I have to find devices. If libusb threw a bunch of callbacks at me for each connected device on startup, I would only have to maintain a single infrastructure for handling of devices. And it would be event driven. Nice. :) > Potentially an quasi-aggregate events will occur where a hub is > connected which physically fans out to many devices, thus, many > devices get hotplugged 'at once'. Perhaps the safest thing in that > case would be to simply convert each device to a separate hotplug > callback event, but I can see an argument made for passing a > pointer to an array of device/bus/event descriptors as a callback > parameter. USB attaches the hub, configures the hub, and then proceedes to evaluate what, if anything, is connected to each of the hub's ports. The stack itself handles it all as separate events, per the standard, and so should we, IMHO. > I haven't reviewed the API in great detail yet nor the > implementations, but if we are definitely moving forward with > this, I will. > > What do you think? I think it will benefit user experience of any application. Plug-and-play and high usability is one of the major design goals of USB and since they've really done a good job with it at the lower levels, adding the final piece to the application puzzle is a very good thing. I also think that it will add certain complexity to applications not currently asynchronously designed, and that could scare some developers off, but hopefully we can come up with a ridiculously simple interface that will be even better than the current bus scanning! :) Something that bothers me in any case is the matter of the application having to deal with topology - it should be quite easy to just take interest in a certain VID/PID regardless of topology - but there are also instances where the application _needs_ to know about topology, e.g. isochronous devices that are too far away for usable throughput, or bus-powered devices that are too far away for their power requirement. //Peter |
From: Peter S. <stu...@cd...> - 2004-05-26 00:14:27
|
On Tue, May 25, 2004 at 11:48:49AM -0700, Johannes Erdfelt wrote: > I could be convinced that usb_bulk_write clearing the direction > bit is a mistake. > > I can think of two possible changes that could occur: > > 1) Require the endpoint to always be 4 bits with no direction bit. The > various ports would set the direction bit as needed. > 2) Allow the direction bit to be set for usb_bulk_read, but it must be > clear for usb_bulk_write. This would allow applications to use the > endpoint address as is from the descriptors. > > Any opinions? I vote for 2! As little massaging of data as possible is good. A (small) bonus is better forward compatibility. //Peter |
From: Paul K. <Paul.Klissner@Sun.COM> - 2004-05-25 18:54:39
|
Johannes Erdfelt wrote: >> However the libusb API appears to be lacking an essential feature, >> at least from the standpoint of it's Java counterpart, javax.usb: >> libusb does not seem to provide a callback mechanism for device >> hotplug event notification. I hope I can pursuade the committee >> or owner of the libusb API to extend the libusb API with such an >> interface, and I am willing to contribute effort into helping that >> happen as well as in assisting with the implementation of it it on >> the supported platforms, as necessary and as feasible. >> >> Unfortunately, the SourceForget site doesn't seem to indicate there >> has been any recent activity with libusb; the online docs indicates >> there were once plans to evolve quickly toward 1.0. >> >> Where does all of this stand? What can I do to extend the API in >> the way hoped? I am ready to invest proactive effort and follow >> through on fairly short notice. > > It has been brought up in the past and I certainly would like to add > that sort of functionality. > > Are you looking for a simple asynchronous callback? > > If so, out of a thread context or signal context? > > JE Thanks, it's really good to hear you are open to this idea. Between thread and signal context, I'm sure each is potentially fraught with peril, depending on implementation, but of the two, I think that signal context is the least stable and prone to mishap among various UNIX-like OS's. Due to the archaic origins of signals, who's complexity outgrew their initial design, complications in signal masking and layering, with even further complexity when signals interact with multithreaded applications, I believe signals should not be relied upon for heavy lifting. There is an old joke that on UNIX's tombstone will be engraved "It was the signals". From the standpoint of Java, and the JNI (Java Native Interface), there is some risk of unpleasant signal interaction and unpredictable side-effects, and the JVM is something that can evolve in directions libusb developers have no control over, and itself has multiple implementations. Therefore I think I am suggesting thread context, which delivers a simple asynchronous callback, passing a bus and device identifier as and a flag as to whether the device is being connected or disconnected. Potentially an quasi-aggregate events will occur where a hub is connected which physically fans out to many devices, thus, many devices get hotplugged 'at once'. Perhaps the safest thing in that case would be to simply convert each device to a separate hotplug callback event, but I can see an argument made for passing a pointer to an array of device/bus/event descriptors as a callback parameter. I haven't reviewed the API in great detail yet nor the implementations, but if we are definitely moving forward with this, I will. What do you think? Paul |
From: Johannes E. <joh...@er...> - 2004-05-25 18:50:19
|
On Tue, May 25, 2004, Joseph Roback <jo...@ro...> wrote: > /proc/bus/usb/devices > > E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms > E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms > > Device only has 1 configuration / 1 interface. > > dev->config[0].interface[0].altsetting[0].endpoint[0].bEndpointAddress == 0x81 > dev->config[0].interface[0].altsetting[0].endpoint[1].bEndpointAddress == 0x01 > > I also printed all the fields in "struct usb_endpoint_descriptor" for > endpoint[0] and endpoint[1], but I cannot see how to distingish between one > endpoint and the other. I wouldn't think one would assume Input/Output, > Input/Output, etc, always in that order... > > thanks. please include jo...@ro... in reply, as I am not a normal subscriber. Never assume that order means anything. The high bit is what tells you if the endpoint is an input endpoint or not. So 0x81 is input, 0x01 is output. JE |
From: Johannes E. <joh...@er...> - 2004-05-25 18:48:50
|
On Tue, May 25, 2004, Stephan Meyer <ste...@we...> wrote: > > If the problem is that libusb-win32 doesn't like the direction bit, then > > I think libusb-win32 should be fixed. > > Libusb-win32 likes the direction bit. It likes it even that much that it doesn't touch it > and passes it down to the kernel fully unmodified. But in contrast to the Linux > version that bit has to be set or cleared correctly. Otherwise the function calls won't > succeed. I could be convinced that usb_bulk_write clearing the direction bit is a mistake. I can think of two possible changes that could occur: 1) Require the endpoint to always be 4 bits with no direction bit. The various ports would set the direction bit as needed. 2) Allow the direction bit to be set for usb_bulk_read, but it must be clear for usb_bulk_write. This would allow applications to use the endpoint address as is from the descriptors. Any opinions? JE |
From: Joseph R. <jo...@ro...> - 2004-05-25 11:54:07
|
/proc/bus/usb/devices E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms Device only has 1 configuration / 1 interface. dev->config[0].interface[0].altsetting[0].endpoint[0].bEndpointAddress == 0x81 dev->config[0].interface[0].altsetting[0].endpoint[1].bEndpointAddress == 0x01 I also printed all the fields in "struct usb_endpoint_descriptor" for endpoint[0] and endpoint[1], but I cannot see how to distingish between one endpoint and the other. I wouldn't think one would assume Input/Output, Input/Output, etc, always in that order... thanks. please include jo...@ro... in reply, as I am not a normal subscriber. cheers, joe |
From: martin f k. <ma...@ma...> - 2004-05-25 11:48:15
|
also sprach Rui Rom=E3o <r....@ma...> [2004.05.25.1302 +0200]: > I'm testing libusb, and the library is completly new for me, so > excuse me if my question is too stupid. >=20 > What I pretend to do is catching mouse signal by "clicking" in > some button. I have already try it, by with no sucess. The mouse is, to my knowledge, a HID device. Thus, you may want to look further than libusb: libhid is implemented atop of libusb and gives you an abstraction for the HID protocol. However, I am not sure that the functionality you need is implemented. I would assume it has to do with interrupt endpoints. Once you figured this out, please let me know. You can get libhid here: cvs -d :pserver:an...@cv...:/home/cvs/external login [empty password] cvs -z3 -d :pserver:an...@cv...:/home/cvs/external co libhid --=20 martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck =20 invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver! spamtraps: kra...@ai... mad...@ma... =20 i'd give my right arm to be ambidextrous. |
From: Rui R. <r....@ma...> - 2004-05-25 11:02:53
|
Hello: I'm testing libusb, and the library is completly new for me, so excuse me if my question is too stupid. What I pretend to do is catching mouse signal by "clicking" in some button. I have already try it, by with no sucess. Someone could help me? Thank you RR -- Adira já ao Net Dialup Light. Acesso profissional gratuito. NovisNet, a Internet de quem trabalha. http://www.novisnet.pt |
From: Stephan M. <ste...@we...> - 2004-05-25 06:05:42
|
> If the problem is that libusb-win32 doesn't like the direction bit, then > I think libusb-win32 should be fixed. Libusb-win32 likes the direction bit. It likes it even that much that it doesn't touch it and passes it down to the kernel fully unmodified. But in contrast to the Linux version that bit has to be set or cleared correctly. Otherwise the function calls won't succeed. _____________________________________________________________________ Endlich SMS mit Bildern versenden! Das Bild selbst ist dabei gratis, Sie bezahlen lediglich den Versand. http://freemail.web.de/?mc=021195 |
From: Geoff O. <g...@mb...> - 2004-05-24 20:49:39
|
Hi There, I'm looking into probablems that appear to be cropping up with linux 2.6.x and ifp-driver [the iRiver music player driver] project. Has anyone else had problems using libusb on 2.6.x kernels? I'm just trying to get an idea of the scope of the problem. Your input would be most helpful.. thanks in advance, Geoff -- PGP fingerprint: 8ADC 92E1 6782 D034 E0E3 8EF4 EA4D 25E3 C17C 48D2 "If you want to learn more about guns, get a job at [an American] convenience store or visit our website at ... " --Michael Moore |
From: Johannes E. <joh...@er...> - 2004-05-24 18:54:51
|
On Sat, May 22, 2004, Paul Klissner <Paul.Klissner@Sun.COM> wrote: > I was a participant in javax.usb expert group while JSR-80 was evolving, > and developed an implementation based on that for a thin client > platform, at Sun. > I moved on to other projects for awhile, but now I am moving forward > with > the previous work with javax.usb, and would like to base Sun's > implementations > on the optimal platform-independent architecture defined in the > libusb standard. > > However the libusb API appears to be lacking an essential feature, > at least from > the standpoint of it's Java counterpart, javax.usb: libusb does not > seem to provide > a callback mechanism for device hotplug event notification. I hope > I can > pursuade the committee or owner of the libusb API to extend the > libusb API > with such an interface, and I am willing to contribute effort into > helping that happen > as well as in assisting with the implementation of it it on the > supported platforms, > as necessary and as feasible. > > Unfortunately, the SourceForget site doesn't seem to indicate there > has been > any recent activity with libusb; the online docs indicates there > were once plans > to evolve quickly toward 1.0. > > Where does all of this stand? What can I do to extend the API in > the way > hoped? I am ready to invest proactive effort and follow through on > fairly > short notice. It has been brought up in the past and I certainly would like to add that sort of functionality. Are you looking for a simple asynchronous callback? If so, out of a thread context or signal context? JE |
From: Paul K. <Paul.Klissner@Sun.COM> - 2004-05-22 10:01:50
|
Hello libusb development community, I was a participant in javax.usb expert group while JSR-80 was evolving, and developed an implementation based on that for a thin client platform, at Sun. I moved on to other projects for awhile, but now I am moving forward with the previous work with javax.usb, and would like to base Sun's implementations on the optimal platform-independent architecture defined in the libusb standard. However the libusb API appears to be lacking an essential feature, at least from the standpoint of it's Java counterpart, javax.usb: libusb does not seem to provide a callback mechanism for device hotplug event notification. I hope I can pursuade the committee or owner of the libusb API to extend the libusb API with such an interface, and I am willing to contribute effort into helping that happen as well as in assisting with the implementation of it it on the supported platforms, as necessary and as feasible. Unfortunately, the SourceForget site doesn't seem to indicate there has been any recent activity with libusb; the online docs indicates there were once plans to evolve quickly toward 1.0. Where does all of this stand? What can I do to extend the API in the way hoped? I am ready to invest proactive effort and follow through on fairly short notice. Thanks, Paul Klissner (Pau...@su...) Staff Engineer Sun One Desktop, Sun Ray Sun Microsystems, Inc. |
From: Johannes E. <joh...@er...> - 2004-05-21 21:00:57
|
On Fri, May 21, 2004, Charles Lepple <cl...@gh...> wrote: > Stephan Meyer said: > > This behavior is actually confusing because the user will think that he is > > doing everything right although it's completely wrong. And there are some > > users out there who call these bulk functions the wrong way. > > Agreed. IMHO the "principle of least surprise" says that libusb should > either pass everything (and potentially yield kernel error messages) or > block wrong requests. It's easy to generate improper code when you're > cutting and pasting, so it's nice to have either the library or the kernel > doing some sanity checks. But this exactly is the principle of least suprise. They can use the endpoint address as it is given in the descriptor. Why make it more difficult for the developer? If the problem is that libusb-win32 doesn't like the direction bit, then I think libusb-win32 should be fixed. JE |
From: Johannes E. <joh...@er...> - 2004-05-21 20:59:45
|
On Fri, May 21, 2004, Stephan Meyer <ste...@we...> wrote: > > > > > > Firmware bug? I don't think so because both bulk functions convert their ep argument > > > into something they like (at least on Linux): > > > > > > bulk_write: ep &= ~USB_ENDPOINT_IN; > > > bulk_read: ep |= USB_ENDPOINT_IN; > > > > > > To repeat Joseph's question: why is this done? I think that these parameter > > > modifications produce more confusion than actually helping the user. > > > Wouldn't it be much better to validate the ep addresses in both functions and > > > return an error if they are not correct? > > > > Wouldn't it be even better if the hardware did it? That's where it > > really matters. > > > > The descriptors said endpoint 1 is an input pipe, but it accepts writes > > to it. > > The input pipe doesn't accept writes because the data is redirected to > the output pipe: > > E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms > E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms > > Consider the following function calls: > > Correct way: > usb_bulk_read(...,0x81,..); // should be successful > usb_bulk_write(...,0x01,..); // should be successful > > Wrong way: > usb_bulk_read(...,0x01,..); // will be successful because of > // ep |= USB_ENDPOINT_IN => ep = 0x81 !!! > usb_bulk_write(...,0x81,..); // will be successful because of > // ep &= ~USB_ENDPOINT_IN => ep = 0x01 !!! > > This behavior is actually confusing because the user will think that he is > doing everything right although it's completely wrong. And there are some > users out there who call these bulk functions the wrong way. I know this because > of my libusb-win32 project. I often get support requests from users who want > to port their Linux programs to Windows and they are just wondering why their > USB code isn't working any more. In most cases they're just communication with the > wrong endpoints but they don't realize the problem because the code is working > correctly on Linux due to these endpoint parameter modifications. libusb sets those bits because the Linux USB code requires the direction bit to be correct. Since only 4 bits of the endpoint are valid, then the rest of the bits are undefined. I guess if you really want to get pedantic, then usb_bulk_read with an endpoint of 0x81 should fail since that's not a valid endpoint number. I coded it that way because it's easier for the developer. JE |
From: Charles L. <cl...@gh...> - 2004-05-21 18:28:19
|
Stephan Meyer said: > This behavior is actually confusing because the user will think that he= is > doing everything right although it's completely wrong. And there are so= me > users out there who call these bulk functions the wrong way. Agreed. IMHO the "principle of least surprise" says that libusb should either pass everything (and potentially yield kernel error messages) or block wrong requests. It's easy to generate improper code when you're cutting and pasting, so it's nice to have either the library or the kerne= l doing some sanity checks. --=20 Charles Lepple cl...@gh... |
From: Stephan M. <ste...@we...> - 2004-05-21 18:14:40
|
> > > > Firmware bug? I don't think so because both bulk functions convert their ep argument > > into something they like (at least on Linux): > > > > bulk_write: ep &= ~USB_ENDPOINT_IN; > > bulk_read: ep |= USB_ENDPOINT_IN; > > > > To repeat Joseph's question: why is this done? I think that these parameter > > modifications produce more confusion than actually helping the user. > > Wouldn't it be much better to validate the ep addresses in both functions and > > return an error if they are not correct? > > Wouldn't it be even better if the hardware did it? That's where it > really matters. > > The descriptors said endpoint 1 is an input pipe, but it accepts writes > to it. > The input pipe doesn't accept writes because the data is redirected to the output pipe: E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms Consider the following function calls: Correct way: usb_bulk_read(...,0x81,..); // should be successful usb_bulk_write(...,0x01,..); // should be successful Wrong way: usb_bulk_read(...,0x01,..); // will be successful because of // ep |= USB_ENDPOINT_IN => ep = 0x81 !!! usb_bulk_write(...,0x81,..); // will be successful because of // ep &= ~USB_ENDPOINT_IN => ep = 0x01 !!! This behavior is actually confusing because the user will think that he is doing everything right although it's completely wrong. And there are some users out there who call these bulk functions the wrong way. I know this because of my libusb-win32 project. I often get support requests from users who want to port their Linux programs to Windows and they are just wondering why their USB code isn't working any more. In most cases they're just communication with the wrong endpoints but they don't realize the problem because the code is working correctly on Linux due to these endpoint parameter modifications. Stephan > > libusb is just trying to be nice here. It's lean in this respect on > purpose. There is no security concern if the programmer tries to do > something stupid like this, so why make it more complicated by > preventing it, when the hardware should do it anyway? > > JE > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: Oracle 10g > Get certified on the hottest thing ever to hit the market... Oracle 10g. > Take an Oracle 10g class now, and we'll give you the exam FREE. > http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click > _______________________________________________ > Libusb-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libusb-devel _______________________________________________________________________ Moechten Sie Ihre SMS noch ausdrucksstaerker und emotionaler gestalten? Fuegen Sie einfach ein Bild hinzu! http://freemail.web.de/?mc=021194 |
From: Johannes E. <joh...@er...> - 2004-05-21 16:04:09
|
On Fri, May 21, 2004, Stephan Meyer <ste...@we...> wrote: > > > Why does usb_bulk_read OR the endpoint passed as an argument with > > > USB_ENDPOINT_IN and cause the usb_bulk_read actually use 0x81 as the endpoint. > > > > > > usb_strerror() returns this: > > > error reading from bulk endpoint 0x81: Connection timed out > > > > > > usb_bulk_write() seems to work ok, no errors when writing to endpoint 0x81 or > > > 0x01. > > > > > > I am modifying the ifp.sf.net iRiver drivers to work with the newest iRiver > > > series (iFP-7XX). I could seem to do everything a usb_bulk_read(). > > > > > > I don't think I know enough about USB to go one any further. > > > > Because 0x81 is an input pipe. You can only read from it. > > > > The fact you can write to it indicates a bug in your hardware. > > > > Firmware bug? I don't think so because both bulk functions convert their ep argument > into something they like (at least on Linux): > > bulk_write: ep &= ~USB_ENDPOINT_IN; > bulk_read: ep |= USB_ENDPOINT_IN; > > To repeat Joseph's question: why is this done? I think that these parameter > modifications produce more confusion than actually helping the user. > Wouldn't it be much better to validate the ep addresses in both functions and > return an error if they are not correct? Wouldn't it be even better if the hardware did it? That's where it really matters. The descriptors said endpoint 1 is an input pipe, but it accepts writes to it. libusb is just trying to be nice here. It's lean in this respect on purpose. There is no security concern if the programmer tries to do something stupid like this, so why make it more complicated by preventing it, when the hardware should do it anyway? JE |
From: Stephan M. <ste...@we...> - 2004-05-21 09:40:01
|
> > Why does usb_bulk_read OR the endpoint passed as an argument with > > USB_ENDPOINT_IN and cause the usb_bulk_read actually use 0x81 as the endpoint. > > > > usb_strerror() returns this: > > error reading from bulk endpoint 0x81: Connection timed out > > > > usb_bulk_write() seems to work ok, no errors when writing to endpoint 0x81 or > > 0x01. > > > > I am modifying the ifp.sf.net iRiver drivers to work with the newest iRiver > > series (iFP-7XX). I could seem to do everything a usb_bulk_read(). > > > > I don't think I know enough about USB to go one any further. > > Because 0x81 is an input pipe. You can only read from it. > > The fact you can write to it indicates a bug in your hardware. > Firmware bug? I don't think so because both bulk functions convert their ep argument into something they like (at least on Linux): bulk_write: ep &= ~USB_ENDPOINT_IN; bulk_read: ep |= USB_ENDPOINT_IN; To repeat Joseph's question: why is this done? I think that these parameter modifications produce more confusion than actually helping the user. Wouldn't it be much better to validate the ep addresses in both functions and return an error if they are not correct? Stephan > Take a look a the USB specs for more information. > > JE > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: Oracle 10g > Get certified on the hottest thing ever to hit the market... Oracle 10g. > Take an Oracle 10g class now, and we'll give you the exam FREE. > http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click > _______________________________________________ > Libusb-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libusb-devel ________________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt neu bei WEB.DE FreeMail: http://freemail.web.de/?mc=021193 |
From: Johannes E. <joh...@er...> - 2004-05-20 17:55:37
|
On Thu, May 20, 2004, Joseph Roback <jo...@ro...> wrote: > > my /proc/bus/usb/devices > > T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 36 Spd=12 MxCh= 0 > D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 > P: Vendor=4102 ProdID=1007 Rev= 1.00 > S: Manufacturer=iRiver Limited. > S: Product=iRiver Internet Audio Player IFP-700 > C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA > I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) > E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms > E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms > > Why does usb_bulk_read OR the endpoint passed as an argument with > USB_ENDPOINT_IN and cause the usb_bulk_read actually use 0x81 as the endpoint. > > usb_strerror() returns this: > error reading from bulk endpoint 0x81: Connection timed out > > usb_bulk_write() seems to work ok, no errors when writing to endpoint 0x81 or > 0x01. > > I am modifying the ifp.sf.net iRiver drivers to work with the newest iRiver > series (iFP-7XX). I could seem to do everything a usb_bulk_read(). > > I don't think I know enough about USB to go one any further. Because 0x81 is an input pipe. You can only read from it. The fact you can write to it indicates a bug in your hardware. Take a look a the USB specs for more information. JE |
From: Joseph R. <jo...@ro...> - 2004-05-20 06:08:33
|
my /proc/bus/usb/devices T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 36 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=4102 ProdID=1007 Rev= 1.00 S: Manufacturer=iRiver Limited. S: Product=iRiver Internet Audio Player IFP-700 C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms Why does usb_bulk_read OR the endpoint passed as an argument with USB_ENDPOINT_IN and cause the usb_bulk_read actually use 0x81 as the endpoint. usb_strerror() returns this: error reading from bulk endpoint 0x81: Connection timed out usb_bulk_write() seems to work ok, no errors when writing to endpoint 0x81 or 0x01. I am modifying the ifp.sf.net iRiver drivers to work with the newest iRiver series (iFP-7XX). I could seem to do everything a usb_bulk_read(). I don't think I know enough about USB to go one any further. thanks for any help. -joe http://roback.cc |
From: Johannes E. <joh...@er...> - 2004-05-19 18:02:51
|
Are you running the same version of gcc on both systems? JE On Tue, May 18, 2004, Nagarajan, Haripriyax <har...@in...> wrote: > Actually I am using libusb-0.1.7 on both systems :-(.I am running Linux OS kernel 2.4.9 for USB 1.1 amd 2.4.18 on 2.0 system. > > -----Original Message----- > From: lib...@li... [mailto:lib...@li...] On Behalf Of Charles Lepple > Sent: Tuesday, May 18, 2004 3:03 PM > To: Nagarajan, Haripriyax > Cc: lib...@li... > Subject: Re: [Libusb-devel] LibUSB for USB 1.1 and 2.0 > > > On May 18, 2004, at 4:36 PM, Nagarajan, Haripriyax wrote: > > > I am using libusb interface to work with a USB based debugging device > > from Intel. I want to use the same .so files of my program on both USB > > 1.1 and 2.0 systems, assuming libusb will shield the kernel layer. > > It usually does shield you from those sorts of differences. > > > But a rebuild of my program is required while switching between 1.1 > > and 2.0 systems. Otherwise, my program crashes when it tries to get > > the dev->descriptor.idProduct and other related information becaz > > usb_device struct is corrupted.?(usb_get_busses call doesn't seem > > to?update the usb_busses properly).Am I missing anything? > > What OS are you using? (Distribution, kernel, etc.) > > Is it possible that both systems are using slightly different versions > of libusb, and are not properly versioning the libraries. > > -- > Charles Lepple > cl...@gh... > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: SourceForge.net Broadband > Sign-up now for SourceForge Broadband and get the fastest > 6.0/768 connection for only $19.95/mo for the first 3 months! > http://ads.osdn.com/?ad_id%62&alloc_ida84&op=ick > _______________________________________________ > Libusb-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libusb-devel > > > ------------------------------------------------------- > This SF.Net email is sponsored by: SourceForge.net Broadband > Sign-up now for SourceForge Broadband and get the fastest > 6.0/768 connection for only $19.95/mo for the first 3 months! > http://ads.osdn.com/?ad_id%62&alloc_ida84&op=click > _______________________________________________ > Libusb-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libusb-devel > |
From: Nagarajan, H. <har...@in...> - 2004-05-19 00:24:35
|
Actually I am using libusb-0.1.7 on both systems :-(.I am running Linux = OS kernel 2.4.9 for USB 1.1 amd 2.4.18 on 2.0 system. -----Original Message----- From: lib...@li... = [mailto:lib...@li...] On Behalf Of Charles = Lepple Sent: Tuesday, May 18, 2004 3:03 PM To: Nagarajan, Haripriyax Cc: lib...@li... Subject: Re: [Libusb-devel] LibUSB for USB 1.1 and 2.0 On May 18, 2004, at 4:36 PM, Nagarajan, Haripriyax wrote: > I am using libusb interface to work with a USB based debugging device=20 > from Intel. I want to use the same .so files of my program on both USB = > 1.1 and 2.0 systems, assuming libusb will shield the kernel layer. It usually does shield you from those sorts of differences. > But a rebuild of my program is required while switching between 1.1=20 > and 2.0 systems. Otherwise, my program crashes when it tries to get=20 > the dev->descriptor.idProduct and other related information becaz=20 > usb_device struct is corrupted.=A0(usb_get_busses call doesn't seem=20 > to=A0update the usb_busses properly).Am I missing anything? What OS are you using? (Distribution, kernel, etc.) Is it possible that both systems are using slightly different versions=20 of libusb, and are not properly versioning the libraries. --=20 Charles Lepple cl...@gh... ------------------------------------------------------- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id%62&alloc_ida84&op=3Dick _______________________________________________ Libusb-devel mailing list Lib...@li... https://lists.sourceforge.net/lists/listinfo/libusb-devel |
From: Charles L. <cl...@gh...> - 2004-05-18 22:03:22
|
On May 18, 2004, at 4:36 PM, Nagarajan, Haripriyax wrote: > I am using libusb interface to work with a USB based debugging device=20= > from Intel. I want to use the same .so files of my program on both USB=20= > 1.1 and 2.0 systems, assuming libusb will shield the kernel layer. It usually does shield you from those sorts of differences. > But a rebuild of my program is required while switching between 1.1=20= > and 2.0 systems. Otherwise, my program crashes when it tries to get=20 > the dev->descriptor.idProduct and other related information becaz=20 > usb_device struct is corrupted.=A0(usb_get_busses call doesn't seem=20 > to=A0update the usb_busses properly).Am I missing anything? What OS are you using? (Distribution, kernel, etc.) Is it possible that both systems are using slightly different versions=20= of libusb, and are not properly versioning the libraries. --=20 Charles Lepple cl...@gh... |
From: Johannes E. <joh...@er...> - 2004-05-18 21:14:04
|
Recompiling shouldn't change anything. That's why I'm asking you what you are changing when you are recompiling? JE On Tue, May 18, 2004, Nagarajan, Haripriyax <har...@in...> wrote: > Well, I haven't changed anything. That is why I am surprised that it > segmentation faults. I just expect a faster performance.That happens, > but only that it requires a recompile. > > -----Original Message----- > From: lib...@li... > [mailto:lib...@li...] On Behalf Of Johannes > Erdfelt > Sent: Tuesday, May 18, 2004 2:03 PM > To: Nagarajan, Haripriyax > Cc: lib...@li... > Subject: Re: [Libusb-devel] LibUSB for USB 1.1 and 2.0 > > > On Tue, May 18, 2004, Nagarajan, Haripriyax > <har...@in...> wrote: > > I am using libusb interface to work with a USB based debugging device > > from Intel. I want to use the same .so files of my program on both USB > > 1.1 and 2.0 systems, assuming libusb will shield the kernel layer. But > a > > rebuild of my program is required while switching between 1.1 and 2.0 > > systems. Otherwise, my program crashes when it tries to get the > > dev->descriptor.idProduct and other related information becaz > usb_device > > struct is corrupted. (usb_get_busses call doesn't seem to update the > > usb_busses properly).Am I missing anything? > > I'm missing something. > > What are you changing when you are compiling for a "1.1 device" and a > "2.0 device". > > There is no logic in libusb that differentiates between the two, so I'm > at what kind of change you are making that does differentiate. > > JE > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: SourceForge.net Broadband > Sign-up now for SourceForge Broadband and get the fastest > 6.0/768 connection for only $19.95/mo for the first 3 months! > http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click > _______________________________________________ > Libusb-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libusb-devel > |