Menu
▾
▴
libusb-devel
|
From: Rodney D. <do...@fr...> - 2003-04-09 02:54:17
|
Hi, What is up with libusb? It looks like there haven't been any commits since the beginning of December, and pretty much no activity otherwise, aside from users posting to the lists to ask questions. libusb also seems to be missing a lot of features I would like to have in a device detection library like this. I was about to start using it, until I discovered that I can't seem to do what I want, and the project hasn't been touched for 4 months. Should I just go off and create a system for doing all of this, that is more device-independent, but somewhat less portable? Thanks. -- dobey |
|
From: Johannes E. <joh...@er...> - 2003-04-09 18:11:22
|
On Tue, Apr 08, 2003, Rodney Dawes <do...@fr...> wrote: > What is up with libusb? It looks like there haven't been any commits > since the beginning of December, and pretty much no activity otherwise, > aside from users posting to the lists to ask questions. libusb also > seems to be missing a lot of features I would like to have in a device > detection library like this. I was about to start using it, until I > discovered that I can't seem to do what I want, and the project hasn't > been touched for 4 months. Should I just go off and create a system for > doing all of this, that is more device-independent, but somewhat less > portable? Thanks. The problem is that all of the work has been done by me. That was never the intent. I wholeheartedly encourage anyone and everyone to help not only define the direction of libusb, but also code. I suspect part of the problem is that people think they have no say. For instance, you mentioned creating an entirely different project. Why do you think that is better than adding the functionality you require into libusb? JE |
|
From: Johannes E. <joh...@er...> - 2003-04-09 18:16:42
|
On Wed, Apr 09, 2003, Johannes Erdfelt <joh...@er...> wrote: > On Tue, Apr 08, 2003, Rodney Dawes <do...@fr...> wrote: > > What is up with libusb? It looks like there haven't been any commits > > since the beginning of December, and pretty much no activity otherwise, > > aside from users posting to the lists to ask questions. libusb also > > seems to be missing a lot of features I would like to have in a device > > detection library like this. I was about to start using it, until I > > discovered that I can't seem to do what I want, and the project hasn't > > been touched for 4 months. Should I just go off and create a system for > > doing all of this, that is more device-independent, but somewhat less > > portable? Thanks. > > The problem is that all of the work has been done by me. I should clarify this. Pretty much all of the direction has been done by me. The BSD and MacOS ports were done almost completely be other people. I've been very busy for a while and I haven't been able to put the effort into libusb as I would like. FWIW, there were some CVS checkins recently for the prorotype support of Interrupt transfers. It needs some more work as well as adding support for the other supported operating systems. JE |
|
From: Pete B. <pe...@so...> - 2003-04-10 09:09:43
|
On Wed, Apr 09, 2003 at 02:11:19PM -0400, Johannes Erdfelt wrote: > I suspect part of the problem is that people think they have no say. Actually, I think part of the problem is that libusb is already good enough for quite a few applications (eg mine). So whilst I have been motivated to help find/fix OSX bugs, right now I don't have much need for extra functionality... Oh, apart from maybe a cross-platform way of detecting when devices are plugged in or unplugged that's cheaper than periodically rescanning the whole bus.... Any plans for that? Pete. |
|
From: Rodney D. <do...@fr...> - 2003-04-12 02:59:31
|
On Wed, 2003-04-09 at 14:11, Johannes Erdfelt wrote: > The problem is that all of the work has been done by me. I can relate to that problem. :) > That was never the intent. I wholeheartedly encourage anyone and > everyone to help not only define the direction of libusb, but also code. Great. I'll try to figure out what libusb actually does and hopefully give you some patches. > I suspect part of the problem is that people think they have no say. For > instance, you mentioned creating an entirely different project. Why do > you think that is better than adding the functionality you require into > libusb? I mentioned creating an entirely different project, because the more I thought about it, the more entirely different it would become, and libusb would just not be an appropriate name for it. However, if libusb is in fact still alive and I can use it, I see no reason why I couldn't use it for the usb backend of the stuff I want to do. There are a few bugs it seems. The one that really sticks out and annoys me, is that in 0.1.7, it seems that getting the product/mfg/etc... strings from the device doesn't work. There are definately strings coming from somewhere, as "cat /proc/bus/usb/devices|grep ^S" shows the stuff that I have plugged in, as well as the root hub devices. I don't think it's better to re-invent the wheel. However, it seemed as if the project was dead, so I sent an e-mail expressing my concerns. If I can get what I need out of libusb and a simple wrapper to give me signals when interesting things happen, I would be glad to use it. Thanks. -- dobey |
|
From: Johannes E. <joh...@er...> - 2003-04-12 16:36:01
|
On Fri, Apr 11, 2003, Rodney Dawes <do...@fr...> wrote: > On Wed, 2003-04-09 at 14:11, Johannes Erdfelt wrote: > > I suspect part of the problem is that people think they have no say. For > > instance, you mentioned creating an entirely different project. Why do > > you think that is better than adding the functionality you require into > > libusb? > > I mentioned creating an entirely different project, because the more I > thought about it, the more entirely different it would become, and > libusb would just not be an appropriate name for it. However, if libusb > is in fact still alive and I can use it, I see no reason why I couldn't > use it for the usb backend of the stuff I want to do. If you can let us know what you want to do, I can let you know if libusb can do it, or there have been other interest to do the same thing. > There are a few > bugs it seems. The one that really sticks out and annoys me, is that in > 0.1.7, it seems that getting the product/mfg/etc... strings from the > device doesn't work. There are definately strings coming from somewhere, > as "cat /proc/bus/usb/devices|grep ^S" shows the stuff that I have > plugged in, as well as the root hub devices. Are you sure it isn't a permissions problem? The code in libusb was copied (but modified slightly) from the Linux kernel. > I don't think it's better > to re-invent the wheel. However, it seemed as if the project was dead, > so I sent an e-mail expressing my concerns. If I can get what I need out > of libusb and a simple wrapper to give me signals when interesting > things happen, I would be glad to use it. Thanks. Could you explain why you are looking for a signals based interface? JE |
|
From: Rodney D. <do...@fr...> - 2003-04-12 16:54:44
|
On Sat, 2003-04-12 at 12:35, Johannes Erdfelt wrote: > On Fri, Apr 11, 2003, Rodney Dawes <do...@fr...> wrote: > > On Wed, 2003-04-09 at 14:11, Johannes Erdfelt wrote: > > > I suspect part of the problem is that people think they have no say. For > > > instance, you mentioned creating an entirely different project. Why do > > > you think that is better than adding the functionality you require into > > > libusb? > > > > I mentioned creating an entirely different project, because the more I > > thought about it, the more entirely different it would become, and > > libusb would just not be an appropriate name for it. However, if libusb > > is in fact still alive and I can use it, I see no reason why I couldn't > > use it for the usb backend of the stuff I want to do. > > If you can let us know what you want to do, I can let you know if libusb > can do it, or there have been other interest to do the same thing. Yeah, I'll try to let you know of things that come up. I played a bit more with libusb last night and found out what some of my problems were. I don't know if libusb can do this or not, but is there someway to get a class for the device? Something like "camera", "hub", etc...? It would be really useful for any UI I write that uses usb stuff, as I could have the proper icons show up for devices. > > There are a few > > bugs it seems. The one that really sticks out and annoys me, is that in > > 0.1.7, it seems that getting the product/mfg/etc... strings from the > > device doesn't work. There are definately strings coming from somewhere, > > as "cat /proc/bus/usb/devices|grep ^S" shows the stuff that I have > > plugged in, as well as the root hub devices. > > Are you sure it isn't a permissions problem? The code in libusb was copied > (but modified slightly) from the Linux kernel. It is, but I got no indication that it was until I added extra printf() calls to tell me what errno was doing. I guess there is some compile flag that I have to build with to make the error printing actually print. > > I don't think it's better > > to re-invent the wheel. However, it seemed as if the project was dead, > > so I sent an e-mail expressing my concerns. If I can get what I need out > > of libusb and a simple wrapper to give me signals when interesting > > things happen, I would be glad to use it. Thanks. > > Could you explain why you are looking for a signals based interface? I want to have a nice simple (usability-wise) interface for being able to install drivers for new devices. So when something gets plugged in, I want to notify the user of what the device is, and give them the option to install a driver (like windows does). Thanks. -- dobey |
|
From: Hubert F. <hfi...@te...> - 2003-04-14 09:43:50
|
On samedi, avr 12, 2003, at 18:54 Europe/Paris, Rodney Dawes wrote: > I don't know if libusb can do this or not, but is there someway to get > a class for the device? Something like "camera", "hub", etc...? It > would > be really useful for any UI I write that uses usb stuff, as I could > have > the proper icons show up for devices. > Each USB Interface has a protocol class. While hubs, mices and a few other standard devices seems to give the correct class, digital cameras are a little be funkier. Most of the recent models uses USB Mass Storage (stor. device class), another bunch of them use still Image device class (PTP protocol), and the other just say "unknown" just to implement their own protocol. You can still attempt to work on that, but surely you may have to show "disk" or "unknown" for lot of digital camera devices. Hub |
|
From: Boris D. <Mar...@st...> - 2003-04-14 12:58:11
|
Hi,
Looking at the code I see this:
/*
* Device and/or Interface Class codes
*/
#define USB_CLASS_PER_INTERFACE=09=090=09/* for DeviceClass */
#define USB_CLASS_AUDIO=09=09=091
#define USB_CLASS_COMM=09=09=092
#define USB_CLASS_HID=09=09=093
#define USB_CLASS_PRINTER=09=097
#define USB_CLASS_MASS_STORAGE=09=098
#define USB_CLASS_HUB=09=09=099
#define USB_CLASS_DATA=09=09=0910
#define USB_CLASS_VENDOR_SPEC=09=090xff
Just wondering if anybody knows whether that is complete? (4-6 are missin=
g)
I simply translate the ints with a switch to a class name and it seems to=
=20
work fine. Output attatched. However I found that some devices do not hav=
e a=20
manufacturer (descriptor.iManufacturer) string or a product=20
(descriptor.iProduct) string, so what I do is to get both and concatenate=
=20
them. Maybe there is a better way to find the devicename?
Also I havent found a way to get the IRQ for a usb device. Is that=20
implemented yet?
Output:
x USB Hub: =20
x USB UHCI Root Hub =20
x IRQ: Driver: hub Bus: USB ID 0000/0000 =
=20
x
x =
=20
x
x USB Interface controller: =20
x Prolific Technology Inc. =20
x IRQ: Driver: usbnet Bus: USB ID 067b/0000=20
regrads,
Marc
On Monday 14 April 2003 10:43, you wrote:
> On samedi, avr 12, 2003, at 18:54 Europe/Paris, Rodney Dawes wrote:
> > I don't know if libusb can do this or not, but is there someway to ge=
t
> > a class for the device? Something like "camera", "hub", etc...? It
> > would
> > be really useful for any UI I write that uses usb stuff, as I could
> > have
> > the proper icons show up for devices.
>
> Each USB Interface has a protocol class. While hubs, mices and a few
> other standard devices seems to give the correct class, digital cameras
> are a little be funkier. Most of the recent models uses USB Mass
> Storage (stor. device class), another bunch of them use still Image
> device class (PTP protocol), and the other just say "unknown" just to
> implement their own protocol.
>
> You can still attempt to work on that, but surely you may have to show
> "disk" or "unknown" for lot of digital camera devices.
>
>
> Hub
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Libusb-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusb-devel
|
|
From: Hubert F. <hfi...@te...> - 2003-04-14 13:14:42
|
On lundi, avr 14, 2003, at 14:58 Europe/Paris, Boris Duerner wrote: > Just wondering if anybody knows whether that is complete? (4-6 are > missing) > 0x6 is Still Image Camera... So it is missing. Hub |
|
From: Brad H. <bh...@bi...> - 2003-04-14 13:41:05
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 14 Apr 2003 22:58 pm, Boris Duerner wrote: > Hi, > Looking at the code I see this: > > /* > * Device and/or Interface Class codes > */ > #define USB_CLASS_PER_INTERFACE 0 /* for DeviceClass */ > #define USB_CLASS_AUDIO 1 > #define USB_CLASS_COMM 2 > #define USB_CLASS_HID 3 > #define USB_CLASS_PRINTER 7 > #define USB_CLASS_MASS_STORAGE 8 > #define USB_CLASS_HUB 9 > #define USB_CLASS_DATA 10 > #define USB_CLASS_VENDOR_SPEC 0xff =2D From the kernel source: #define USB_CLASS_PER_INTERFACE 0 /* for DeviceClass */ #define USB_CLASS_AUDIO 1 #define USB_CLASS_COMM 2 #define USB_CLASS_HID 3 #define USB_CLASS_PHYSICAL 5 #define USB_CLASS_STILL_IMAGE 6 #define USB_CLASS_PRINTER 7 #define USB_CLASS_MASS_STORAGE 8 #define USB_CLASS_HUB 9 #define USB_CLASS_CDC_DATA 0x0a #define USB_CLASS_CSCID 0x0b /* chip+ smart card */ #define USB_CLASS_CONTENT_SEC 0x0d /* content security */ #define USB_CLASS_APP_SPEC 0xfe #define USB_CLASS_VENDOR_SPEC 0xff Missing from that list are 0xdc (diagnostics device) and 0xe0 (wireless=20 controller). > Just wondering if anybody knows whether that is complete? (4-6 are missin= g) > I simply translate the ints with a switch to a class name and it seems to > work fine. Output attatched. However I found that some devices do not have > a manufacturer (descriptor.iManufacturer) string or a product > (descriptor.iProduct) string, so what I do is to get both and concatenate > them. Maybe there is a better way to find the devicename? Strings are optional. Some devices have neither. However you can fake up th= e=20 name using the method in usbutils (basically vendor/product tuple lookup=20 against a flat file, see http://www.linux-usb.org/usb.ids) > Also I havent found a way to get the IRQ for a usb device. Is that > implemented yet? What do you mean by "IRQ"? Do you understand how USB works? > Output: > x USB Hub: > x USB UHCI Root Hub > x IRQ: Driver: hub Bus: USB ID 0000/0000 > x > x > x > x USB Interface controller: > x Prolific Technology Inc. > x IRQ: Driver: usbnet Bus: USB ID 067b/0000 Looks like usbutils is being re-invented. What doesn't: http://usb.in.tum.de/download/ do that you need? Brad =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+mrncW6pHgIdAuOMRAtweAKDDwvdJC6CRibO8k1lzXLnWF97UqgCgvKAp QbAMZ4asAv8a5Z0vQ9COX9I=3D =3Dpp7Y =2D----END PGP SIGNATURE----- |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X