barry-devel Mailing List for Barry (Page 159)
Status: Beta
Brought to you by:
ndprojects
Menu
▾
▴
barry-devel — Development discussion mailing list
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(29) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
(20) |
Jul
(13) |
Aug
|
Sep
(4) |
Oct
(16) |
Nov
(4) |
Dec
(11) |
| 2007 |
Jan
(57) |
Feb
(40) |
Mar
(78) |
Apr
(20) |
May
(70) |
Jun
(50) |
Jul
(41) |
Aug
(81) |
Sep
(62) |
Oct
(20) |
Nov
(106) |
Dec
(115) |
| 2008 |
Jan
(14) |
Feb
(29) |
Mar
(32) |
Apr
(74) |
May
(75) |
Jun
(63) |
Jul
(77) |
Aug
(105) |
Sep
(62) |
Oct
(93) |
Nov
(130) |
Dec
(51) |
| 2009 |
Jan
(247) |
Feb
(238) |
Mar
(164) |
Apr
(82) |
May
(81) |
Jun
(106) |
Jul
(118) |
Aug
(52) |
Sep
(102) |
Oct
(24) |
Nov
(54) |
Dec
(97) |
| 2010 |
Jan
(31) |
Feb
(41) |
Mar
(38) |
Apr
(9) |
May
(43) |
Jun
(7) |
Jul
(30) |
Aug
(62) |
Sep
(42) |
Oct
(84) |
Nov
(15) |
Dec
(55) |
| 2011 |
Jan
(74) |
Feb
(53) |
Mar
(30) |
Apr
(14) |
May
(22) |
Jun
(34) |
Jul
(22) |
Aug
(6) |
Sep
(23) |
Oct
(19) |
Nov
(42) |
Dec
(12) |
| 2012 |
Jan
(31) |
Feb
(6) |
Mar
(4) |
Apr
(2) |
May
(17) |
Jun
(5) |
Jul
(20) |
Aug
(13) |
Sep
(5) |
Oct
(13) |
Nov
(8) |
Dec
|
| 2013 |
Jan
(3) |
Feb
(5) |
Mar
(5) |
Apr
(11) |
May
(6) |
Jun
(2) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
| 2014 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
(2) |
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(10) |
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Steve Paras-C. <st...@fa...> - 2005-12-31 05:50:12
|
Sounds great! I'm having some difficulties with CVS, though... root@yu:/usr/src # cvs -d:pserver:ano...@cv...:/cvsroot/barry login Logging in to :pserver:ano...@cv...:2401/cvsroot/barry CVS password: cvs [login aborted]: end of file from server (consult above messages if any) I'll try again in the morning in case it's a transient problem... Steve Quoting Chris Frey <cd...@fo...>: > Hi, > > Here's a brief update for the folks following the CVS tree. > > The latest Barry CVS tree contains: > > - Important! Updated to latest libusb V1_0_DEVEL CVS tree > (as of 2005/12/30) > > - basic support for uploading contacts and calendar records > (incomplete) > > - compiler fixes for g++ 4.0.x > > - fix in probe.cc for Ron Gage's "device or resource busy" error... > Ron will have to test this, since I haven't see the same error > > - probe.cc now does dynamic discovery of endpoints > > - optional dependency on Boost, using the serialization library > Be sure to update your Makefile.conf files, even if just to > turn off Boost support. If you don't include Boost, you > won't be able to experiment with upload very easily. > > Enjoy, and Happy New Year, > - Chris > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > Barry-devel mailing list > Bar...@li... > https://lists.sourceforge.net/lists/listinfo/barry-devel > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
|
From: Chris F. <cd...@fo...> - 2005-12-30 22:55:37
|
Hi, Here's a brief update for the folks following the CVS tree. The latest Barry CVS tree contains: - Important! Updated to latest libusb V1_0_DEVEL CVS tree (as of 2005/12/30) - basic support for uploading contacts and calendar records (incomplete) - compiler fixes for g++ 4.0.x - fix in probe.cc for Ron Gage's "device or resource busy" error... Ron will have to test this, since I haven't see the same error - probe.cc now does dynamic discovery of endpoints - optional dependency on Boost, using the serialization library Be sure to update your Makefile.conf files, even if just to turn off Boost support. If you don't include Boost, you won't be able to experiment with upload very easily. Enjoy, and Happy New Year, - Chris |
|
From: Chris F. <cd...@fo...> - 2005-12-30 19:29:29
|
On Thu, Dec 29, 2005 at 07:37:55PM -0800, Steve Paras-Charlton wrote: > Do we have a cvs tree or when changes are needed should I just > submit patches here? There is a CVS tree on sourceforge, and I've just updated it with my latest changes. I'm currently doing work in NetDirect's CVS, which I know will always be available, but I'll try to keep sourceforge's CVS updated regularly, so everyone can follow the changes. If anyone has changes to submit, patches are probably the best way at the moment. I've tested the latest CVS tree on g++ 4.0.0, and it compiles. CVS will of course be a work in progress until the next release. :-) Thanks, - Chris |
|
From: Chris F. <cd...@fo...> - 2005-12-30 04:42:16
|
On Thu, Dec 29, 2005 at 08:29:37PM -0800, Steve Paras-Charlton wrote: > Aha! I changed to endpoints 0x04 and 0x83 (the second set listed for the 8700r) > and got the databases listing just fine. I don't know what the first 2 > endpoints are for, but it works fine for now... Thanks for posting this! This is extremely interesting to me. I'm working on detecting the endpoints dynamically, and have most of the code in place, but I don't know what the difference is between the endpoints... Obviously it matters! But I haven't figured out why yet. If you look through probe.cc you'll notice that a lot of the command data is hard coded. In my captures, the opening command sequence never changed, so I did it that way to get to the meat of the protocol quicker. This section could use some cleaning up, and isn't too complicated. If you want to dive in, this would be a great spot. - Chris |
|
From: Chris F. <cd...@fo...> - 2005-12-30 04:37:12
|
On Thu, Dec 29, 2005 at 07:37:55PM -0800, Steve Paras-Charlton wrote: > Hmm... retried with CXX=g++-3.4 in Makefile.conf with identical results... > > AHA!! g++-3.3 worked. We'll probably need to patch the source to handle > compiler variants (or fix it to work everywhere). Do we have a cvs tree or > when changes are needed should I just submit patches here? Yes, that needs to be compilable everywhere. Please post patches here for now, although I should be able to fix this easily. I have access to g++-4.0.x, and I should have compiled it there before release. :-) Thanks for the sanity check! I'm hoping to release 0.0.2 soon with some upload support. - Chris |
|
From: Steve Paras-C. <st...@fa...> - 2005-12-30 04:29:41
|
Aha! I changed to endpoints 0x04 and 0x83 (the second set listed for the 8700r) and got the databases listing just fine. I don't know what the first 2 endpoints are for, but it works fine for now... I'll play for a bit and read through the code now to see where I can help out the project (my C++ is a tad rusty). If there's anything someone wants me to test or something pressing I can work on, let me know! Steve Quoting Steve Paras-Charlton <st...@fa...>: > > > Here's the results I get from btool on the 8700r. Looks like it may be > confused > by previous incarnations (I plug and unplug alot). > > root@yu:/usr/src/barry-0.0.1 # src/btool -t > libusb: setting debugging level to 9 (on) > libusb: [usb_os_init:879] found USB VFS at /proc/bus/usb > libusb: [usbi_os_find_busses:469] found bus dir /proc/bus/usb/007 > libusb: [usbi_os_find_busses:469] found bus dir /proc/bus/usb/006 > libusb: [usbi_os_find_busses:469] found bus dir /proc/bus/usb/005 > libusb: [usbi_os_find_busses:469] found bus dir /proc/bus/usb/004 > libusb: [usbi_os_find_busses:469] found bus dir /proc/bus/usb/003 > libusb: [usbi_os_find_busses:469] found bus dir /proc/bus/usb/002 > libusb: [usbi_os_find_busses:469] found bus dir /proc/bus/usb/001 > libusb: [usbi_os_find_busses:450] skipping non bus dir devices > libusb: [usbi_os_find_busses:469] found bus dir /proc/bus/usb/007 > libusb: [usbi_os_find_busses:469] found bus dir /proc/bus/usb/006 > libusb: [usbi_os_find_busses:469] found bus dir /proc/bus/usb/005 > libusb: [usbi_os_find_busses:469] found bus dir /proc/bus/usb/004 > libusb: [usbi_os_find_busses:469] found bus dir /proc/bus/usb/003 > libusb: [usbi_os_find_busses:469] found bus dir /proc/bus/usb/002 > libusb: [usbi_os_find_busses:469] found bus dir /proc/bus/usb/001 > libusb: [usbi_os_find_busses:450] skipping non bus dir devices > libusb: [create_new_device:558] found device 001 on /proc/bus/usb/007 > libusb: [create_new_device:558] found device 001 on /proc/bus/usb/006 > libusb: [create_new_device:558] found device 001 on /proc/bus/usb/005 > libusb: [create_new_device:558] found device 001 on /proc/bus/usb/004 > libusb: [create_new_device:558] found device 004 on /proc/bus/usb/004 > libusb: [create_new_device:558] found device 001 on /proc/bus/usb/003 > libusb: [create_new_device:558] found device 001 on /proc/bus/usb/002 > libusb: [create_new_device:558] found device 001 on /proc/bus/usb/001 > libusb: [device_is_new:498] device /proc/bus/usb/007/001 previously existed, > but > mtime has changed > libusb: [device_is_new:498] device /proc/bus/usb/006/001 previously existed, > but > mtime has changed > libusb: [device_is_new:498] device /proc/bus/usb/005/001 previously existed, > but > mtime has changed > libusb: [device_is_new:498] device /proc/bus/usb/004/001 previously existed, > but > mtime has changed > libusb: [device_is_new:498] device /proc/bus/usb/004/004 previously existed, > but > mtime has changed > libusb: [device_is_new:498] device /proc/bus/usb/003/001 previously existed, > but > mtime has changed > libusb: [device_is_new:498] device /proc/bus/usb/002/001 previously existed, > but > mtime has changed > libusb: [device_is_new:498] device /proc/bus/usb/001/001 previously existed, > but > mtime has changed > BError caught: Probe: Unexpected reponse data in parse > > > And here's the messages entries (looks ok to me; a plug in and two btool > runs) > > Dec 29 19:40:43 localhost kernel: usb 4-2: new full speed USB device using > ohci_hcd and address 4 > Dec 29 19:59:51 localhost kernel: atkbd.c: Keyboard on isa0060/serio0 reports > too many keys pressed. > Dec 29 20:01:18 localhost kernel: usb 4-2: reset full speed USB device using > ohci_hcd and address 4 > Dec 29 20:01:23 localhost kernel: usb 4-2: usbfs: interface 0 claimed while > 'btool' sets config #1 > Dec 29 20:03:08 localhost kernel: usb 4-2: reset full speed USB device using > ohci_hcd and address 4 > Dec 29 20:03:13 localhost kernel: usb 4-2: usbfs: interface 0 claimed while > 'btool' sets config #1 > > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > Barry-devel mailing list > Bar...@li... > https://lists.sourceforge.net/lists/listinfo/barry-devel > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
|
From: Steve Paras-C. <st...@fa...> - 2005-12-30 04:06:57
|
Here's the results I get from btool on the 8700r. Looks like it may be confused by previous incarnations (I plug and unplug alot). root@yu:/usr/src/barry-0.0.1 # src/btool -t libusb: setting debugging level to 9 (on) libusb: [usb_os_init:879] found USB VFS at /proc/bus/usb libusb: [usbi_os_find_busses:469] found bus dir /proc/bus/usb/007 libusb: [usbi_os_find_busses:469] found bus dir /proc/bus/usb/006 libusb: [usbi_os_find_busses:469] found bus dir /proc/bus/usb/005 libusb: [usbi_os_find_busses:469] found bus dir /proc/bus/usb/004 libusb: [usbi_os_find_busses:469] found bus dir /proc/bus/usb/003 libusb: [usbi_os_find_busses:469] found bus dir /proc/bus/usb/002 libusb: [usbi_os_find_busses:469] found bus dir /proc/bus/usb/001 libusb: [usbi_os_find_busses:450] skipping non bus dir devices libusb: [usbi_os_find_busses:469] found bus dir /proc/bus/usb/007 libusb: [usbi_os_find_busses:469] found bus dir /proc/bus/usb/006 libusb: [usbi_os_find_busses:469] found bus dir /proc/bus/usb/005 libusb: [usbi_os_find_busses:469] found bus dir /proc/bus/usb/004 libusb: [usbi_os_find_busses:469] found bus dir /proc/bus/usb/003 libusb: [usbi_os_find_busses:469] found bus dir /proc/bus/usb/002 libusb: [usbi_os_find_busses:469] found bus dir /proc/bus/usb/001 libusb: [usbi_os_find_busses:450] skipping non bus dir devices libusb: [create_new_device:558] found device 001 on /proc/bus/usb/007 libusb: [create_new_device:558] found device 001 on /proc/bus/usb/006 libusb: [create_new_device:558] found device 001 on /proc/bus/usb/005 libusb: [create_new_device:558] found device 001 on /proc/bus/usb/004 libusb: [create_new_device:558] found device 004 on /proc/bus/usb/004 libusb: [create_new_device:558] found device 001 on /proc/bus/usb/003 libusb: [create_new_device:558] found device 001 on /proc/bus/usb/002 libusb: [create_new_device:558] found device 001 on /proc/bus/usb/001 libusb: [device_is_new:498] device /proc/bus/usb/007/001 previously existed, but mtime has changed libusb: [device_is_new:498] device /proc/bus/usb/006/001 previously existed, but mtime has changed libusb: [device_is_new:498] device /proc/bus/usb/005/001 previously existed, but mtime has changed libusb: [device_is_new:498] device /proc/bus/usb/004/001 previously existed, but mtime has changed libusb: [device_is_new:498] device /proc/bus/usb/004/004 previously existed, but mtime has changed libusb: [device_is_new:498] device /proc/bus/usb/003/001 previously existed, but mtime has changed libusb: [device_is_new:498] device /proc/bus/usb/002/001 previously existed, but mtime has changed libusb: [device_is_new:498] device /proc/bus/usb/001/001 previously existed, but mtime has changed BError caught: Probe: Unexpected reponse data in parse And here's the messages entries (looks ok to me; a plug in and two btool runs) Dec 29 19:40:43 localhost kernel: usb 4-2: new full speed USB device using ohci_hcd and address 4 Dec 29 19:59:51 localhost kernel: atkbd.c: Keyboard on isa0060/serio0 reports too many keys pressed. Dec 29 20:01:18 localhost kernel: usb 4-2: reset full speed USB device using ohci_hcd and address 4 Dec 29 20:01:23 localhost kernel: usb 4-2: usbfs: interface 0 claimed while 'btool' sets config #1 Dec 29 20:03:08 localhost kernel: usb 4-2: reset full speed USB device using ohci_hcd and address 4 Dec 29 20:03:13 localhost kernel: usb 4-2: usbfs: interface 0 claimed while 'btool' sets config #1 ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
|
From: Steve Paras-C. <st...@fa...> - 2005-12-30 03:53:35
|
Ok, here's an lsusb -v of an 8700r for the record. I'll make the same endpoint
changes suggested earlier and see what I can get from the device...
Steve
Bus 004 Device 004: ID 0fca:0001 Research In Motion, Ltd. Blackberry Handheld
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 255 Vendor Specific Subclass
bDeviceProtocol 255 Vendor Specific Protocol
bMaxPacketSize0 16
idVendor 0x0fca Research In Motion, Ltd.
idProduct 0x0001 Blackberry Handheld
bcdDevice 1.04
iManufacturer 1 Research In Motion
iProduct 2 BlackBerry Device
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 46
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 4
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Quoting Steve Paras-Charlton <st...@fa...>:
> Hmm... retried with CXX=g++-3.4 in Makefile.conf with identical results...
>
> AHA!! g++-3.3 worked. We'll probably need to patch the source to handle
> compiler variants (or fix it to work everywhere). Do we have a cvs tree or
> when changes are needed should I just submit patches here?
>
> Steve
>
> Quoting Steve Paras-Charlton <st...@fa...>:
>
> > Again, thanks Chris for the pointer and date of the libusb devel tree. I'm
> > now
> > getting what appear to be C++ syntax issues. Perhaps I'm using a different
> > version of g++?
> >
> > g++ -ansi -Wall -I/usr/src/libusb/src -g -c -o btool.o btool.cc
> > parser.h: In member function 'bool Barry::RecordParser<Record,
> > Storage>::CheckHeaderSize(const Data&, unsigned int) [with Record =
> > Barry::Contact, Storage = Contact2Ldif]':
> > btool.cc:232: instantiated from here
> > parser.h:115: error: dependent-name 'Record::ProtocolRecordType' is parsed
> as
> > a
> > non-type, but instantiation yields a type
> > parser.h:115: note: say 'typename Record::ProtocolRecordType' if a type is
> > meant
> > parser.h:120: error: dependent-name 'Record::OldProtocolRecordType' is
> parsed
> > as
> > a non-type, but instantiation yields a type
> > parser.h:120: note: say 'typename Record::OldProtocolRecordType' if a type
> is
> > meant
> > parser.h: In member function 'bool Barry::RecordParser<Record,
> > Storage>::CheckHeaderSize(const Data&, unsigned int) [with Record =
> > Barry::Calendar, Storage = Store<Barry::Calendar>]':
> >
> >
> > This repeats for several places in this file...
> >
> > Here's my g++ info...
> >
> > root@yu:/usr/src/barry-0.0.1/src # g++ --v
> > Using built-in specs.
> > Target: i486-linux-gnu
> > Configured with: ../src/configure -v
> > --enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
> > --with-gxx-include-dir=/usr/include/c++/4.0.2 --enable-shared
> > --with-system-zlib --libexecdir=/usr/lib --enable-nls
> > --without-included-gettext --enable-threads=posix --program-suffix=-4.0
> > --enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu
> > --enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk
> > --enable-gtk-cairo
> > --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre
> > --enable-mpfr --disable-werror --enable-checking=release i486-linux-gnu
> > Thread model: posix
> > gcc version 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9)
> >
> >
> > Steve
> >
> > Quoting Chris Frey <cd...@fo...>:
> >
> > > On Thu, Dec 29, 2005 at 01:02:20PM -0800, Steve Paras-Charlton wrote:
> > > > I'm having issues compiling barry. I've got the DEVEL libusb built
> (not
> > > > installed) and I'v edited the Makefile.conf to point at the build tree
> > and
> > > > built lib, but I get the following compile errors... (this is the head
> of
> > > them,
> > > > there's lots more simmilar stuff). It looks kinda like I've got the
> > wrong
> > > > headers or something, any hints?
> > >
> > > Make sure you have the DEVEL tree from 2005/11/26, which you can get
> with:
> > >
> > > cvs -d :pserver:ano...@cv...:/cvsroot/libusb \
> > > co -r V1_0_DEVEL -d libusb-1_0_devel libusb
> > > cd libusb-1_0_devel
> > > cvs update -Pd -r V1_0_DEVEL -D 2005/11/26
> > >
> > > Barry 0.0.1 still uses the old new tree. :-) And libusb DEVEL is going
> > > through
> > > an API change.
> > >
> > > More info here on compiling Barry:
> > >
> >
> http://sourceforge.net/mailarchive/forum.php?thread_id=9267343&forum_id=47045
> > >
> > > Please join the Barry mailing list so we don't get too off-topic for the
> > > good libusb folks.
> > >
> > > - Chris
> > >
> > >
> >
> >
> >
> >
> > ----------------------------------------------------------------
> > This message was sent using IMP, the Internet Messaging Program.
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> > for problems? Stop! Download the new AJAX search engine that makes
> > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> > _______________________________________________
> > Barry-devel mailing list
> > Bar...@li...
> > https://lists.sourceforge.net/lists/listinfo/barry-devel
> >
>
>
>
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
|
|
From: Steve Paras-C. <st...@fa...> - 2005-12-30 03:37:59
|
Hmm... retried with CXX=g++-3.4 in Makefile.conf with identical results... AHA!! g++-3.3 worked. We'll probably need to patch the source to handle compiler variants (or fix it to work everywhere). Do we have a cvs tree or when changes are needed should I just submit patches here? Steve Quoting Steve Paras-Charlton <st...@fa...>: > Again, thanks Chris for the pointer and date of the libusb devel tree. I'm > now > getting what appear to be C++ syntax issues. Perhaps I'm using a different > version of g++? > > g++ -ansi -Wall -I/usr/src/libusb/src -g -c -o btool.o btool.cc > parser.h: In member function 'bool Barry::RecordParser<Record, > Storage>::CheckHeaderSize(const Data&, unsigned int) [with Record = > Barry::Contact, Storage = Contact2Ldif]': > btool.cc:232: instantiated from here > parser.h:115: error: dependent-name 'Record::ProtocolRecordType' is parsed as > a > non-type, but instantiation yields a type > parser.h:115: note: say 'typename Record::ProtocolRecordType' if a type is > meant > parser.h:120: error: dependent-name 'Record::OldProtocolRecordType' is parsed > as > a non-type, but instantiation yields a type > parser.h:120: note: say 'typename Record::OldProtocolRecordType' if a type is > meant > parser.h: In member function 'bool Barry::RecordParser<Record, > Storage>::CheckHeaderSize(const Data&, unsigned int) [with Record = > Barry::Calendar, Storage = Store<Barry::Calendar>]': > > > This repeats for several places in this file... > > Here's my g++ info... > > root@yu:/usr/src/barry-0.0.1/src # g++ --v > Using built-in specs. > Target: i486-linux-gnu > Configured with: ../src/configure -v > --enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr > --with-gxx-include-dir=/usr/include/c++/4.0.2 --enable-shared > --with-system-zlib --libexecdir=/usr/lib --enable-nls > --without-included-gettext --enable-threads=posix --program-suffix=-4.0 > --enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu > --enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk > --enable-gtk-cairo > --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre > --enable-mpfr --disable-werror --enable-checking=release i486-linux-gnu > Thread model: posix > gcc version 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9) > > > Steve > > Quoting Chris Frey <cd...@fo...>: > > > On Thu, Dec 29, 2005 at 01:02:20PM -0800, Steve Paras-Charlton wrote: > > > I'm having issues compiling barry. I've got the DEVEL libusb built (not > > > installed) and I'v edited the Makefile.conf to point at the build tree > and > > > built lib, but I get the following compile errors... (this is the head of > > them, > > > there's lots more simmilar stuff). It looks kinda like I've got the > wrong > > > headers or something, any hints? > > > > Make sure you have the DEVEL tree from 2005/11/26, which you can get with: > > > > cvs -d :pserver:ano...@cv...:/cvsroot/libusb \ > > co -r V1_0_DEVEL -d libusb-1_0_devel libusb > > cd libusb-1_0_devel > > cvs update -Pd -r V1_0_DEVEL -D 2005/11/26 > > > > Barry 0.0.1 still uses the old new tree. :-) And libusb DEVEL is going > > through > > an API change. > > > > More info here on compiling Barry: > > > http://sourceforge.net/mailarchive/forum.php?thread_id=9267343&forum_id=47045 > > > > Please join the Barry mailing list so we don't get too off-topic for the > > good libusb folks. > > > > - Chris > > > > > > > > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > Barry-devel mailing list > Bar...@li... > https://lists.sourceforge.net/lists/listinfo/barry-devel > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
|
From: Steve Paras-C. <st...@fa...> - 2005-12-30 03:33:50
|
Again, thanks Chris for the pointer and date of the libusb devel tree. I'm now getting what appear to be C++ syntax issues. Perhaps I'm using a different version of g++? g++ -ansi -Wall -I/usr/src/libusb/src -g -c -o btool.o btool.cc parser.h: In member function 'bool Barry::RecordParser<Record, Storage>::CheckHeaderSize(const Data&, unsigned int) [with Record = Barry::Contact, Storage = Contact2Ldif]': btool.cc:232: instantiated from here parser.h:115: error: dependent-name 'Record::ProtocolRecordType' is parsed as a non-type, but instantiation yields a type parser.h:115: note: say 'typename Record::ProtocolRecordType' if a type is meant parser.h:120: error: dependent-name 'Record::OldProtocolRecordType' is parsed as a non-type, but instantiation yields a type parser.h:120: note: say 'typename Record::OldProtocolRecordType' if a type is meant parser.h: In member function 'bool Barry::RecordParser<Record, Storage>::CheckHeaderSize(const Data&, unsigned int) [with Record = Barry::Calendar, Storage = Store<Barry::Calendar>]': This repeats for several places in this file... Here's my g++ info... root@yu:/usr/src/barry-0.0.1/src # g++ --v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr --with-gxx-include-dir=/usr/include/c++/4.0.2 --enable-shared --with-system-zlib --libexecdir=/usr/lib --enable-nls --without-included-gettext --enable-threads=posix --program-suffix=-4.0 --enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr --disable-werror --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9) Steve Quoting Chris Frey <cd...@fo...>: > On Thu, Dec 29, 2005 at 01:02:20PM -0800, Steve Paras-Charlton wrote: > > I'm having issues compiling barry. I've got the DEVEL libusb built (not > > installed) and I'v edited the Makefile.conf to point at the build tree and > > built lib, but I get the following compile errors... (this is the head of > them, > > there's lots more simmilar stuff). It looks kinda like I've got the wrong > > headers or something, any hints? > > Make sure you have the DEVEL tree from 2005/11/26, which you can get with: > > cvs -d :pserver:ano...@cv...:/cvsroot/libusb \ > co -r V1_0_DEVEL -d libusb-1_0_devel libusb > cd libusb-1_0_devel > cvs update -Pd -r V1_0_DEVEL -D 2005/11/26 > > Barry 0.0.1 still uses the old new tree. :-) And libusb DEVEL is going > through > an API change. > > More info here on compiling Barry: > http://sourceforge.net/mailarchive/forum.php?thread_id=9267343&forum_id=47045 > > Please join the Barry mailing list so we don't get too off-topic for the > good libusb folks. > > - Chris > > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
|
From: Chris F. <cd...@fo...> - 2005-12-29 20:16:18
|
Hi, I received the following bug report on a call to libusb_set_configuration(): Libusb: [libusb_set_configuration:82] could not set config 1: Device or resource busy This happens after a successful call to libusb_claim_interface(). On searching the web I came across this bug report: https://alioth.debian.org/tracker/index.php?func=detail&aid=302207&group_id=30186&atid=410366 ... which states that the programmer ignores EBUSY errors from a usb_set_configuration() call. The assumption being that the kernel or some other module has already set the configuration. Is this the correct fix? Thanks, - Chris |
|
From: Chris F. <cd...@fo...> - 2005-12-29 19:19:30
|
On Thu, Dec 29, 2005 at 07:37:18AM -0500, Ron Gage wrote: > Dmesg shows the following at plugin of my 7290: > > Usb 1-1: new full speed USB device using uhci_hcd and address 2 > Usb 1-1: reset full speed USB device using uhci_hcd and address 2 > Usb 1-1: usbfs: interface 0 claimed by usbfs while 'btool' sets config > #1 Interesting... I get the same messages, but it works for me. The error message you posted is a failure coming straight from the kernel inside libusb, so it has to be something basic. > I tried your changes to src/common.h and that made no difference. Those changes only matter after the configuration is set. That was a preemptive bugfix. :-) - Chris |
|
From: Ron G. <ron...@al...> - 2005-12-29 12:37:24
|
Chris: Dmesg shows the following at plugin of my 7290: Usb 1-1: new full speed USB device using uhci_hcd and address 2 Usb 1-1: reset full speed USB device using uhci_hcd and address 2 Usb 1-1: usbfs: interface 0 claimed by usbfs while 'btool' sets config #1 Lsmod shows the following modules loaded: Vmnet Vmmon Ehci_hcd Uhci_hcd Usbcore Joydev Evdev Vmnet and vmmon are modules associated with VMWare. I tried your changes to src/common.h and that made no difference. RON GAGE Network Administrator Wise Solutions, Inc. T > +1 734 456 2202 M > +1 248 343 2431 www.altiris.com =20 Security. Compliance. Patch management. IT service management. Altiris solves your most pressing IT issues. www.altiris.com -----Original Message----- From: Chris Frey [mailto:cd...@fo...]=20 Sent: Wednesday, December 28, 2005 4:44 PM To: Ron Gage Cc: bar...@li... Subject: Re: Barry On Wed, Dec 28, 2005 at 03:46:14PM -0500, Ron Gage wrote: > Configuration Descriptor: > bLength 9 > bDescriptorType 2 > wTotalLength 46 > bNumInterfaces 1 > bConfigurationValue 1 > iConfiguration 0=20 > bmAttributes 0x80 > MaxPower 100mA > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 0 > bAlternateSetting 0 These are the same as the devices I have to test with. The "device or resource busy" error you are getting may be due to a USB module loaded in the kernel. Check lsmod and see if there is anything loaded that might conflict. libusb only needs usbcore, which might not be a module. Check dmesg too... it might have useful error messages. > bNumEndpoints 4 > bInterfaceClass 255 Vendor Specific Class > bInterfaceSubClass 255 Vendor Specific Subclass > bInterfaceProtocol 255 Vendor Specific Protocol > iInterface 0=20 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x81 EP 1 IN > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0040 bytes 64 once > bInterval 0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x02 EP 2 OUT > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0040 bytes 64 once > bInterval 0 Your endpoints are different than mine, which is not really a surprise, but Barry can't handle that yet. Edit src/common.h and set the WRITE_ENDPOINT to 0x02 and READ_ENDPOINT to 0x81. - Chris |
|
From: Chris F. <cd...@fo...> - 2005-12-28 22:14:18
|
Hi, For those of you who are trying to compile Barry, and finding it hard to get the needed libusb from SourceForge CVS, I've put the following file in the Barry downloads section: libusb-devel-20051126.tar.bz2 http://sourceforge.net/project/showfiles.php?group_id=153722 Be sure to have this installed somewhere (it doesn't have to be /usr or /usr/local... in fact it probably shouldn't be), before trying to compile Barry. Good luck, - Chris |
|
From: Chris F. <cd...@fo...> - 2005-12-28 21:52:49
|
On Wed, Dec 28, 2005 at 04:44:03PM -0500, Chris Frey wrote: > On Wed, Dec 28, 2005 at 03:46:14PM -0500, Ron Gage wrote: > > Configuration Descriptor: > > bLength 9 > > bDescriptorType 2 > > wTotalLength 46 > > bNumInterfaces 1 > > bConfigurationValue 1 > > iConfiguration 0 > > bmAttributes 0x80 > > MaxPower 100mA > > Interface Descriptor: > > bLength 9 > > bDescriptorType 4 > > bInterfaceNumber 0 > > bAlternateSetting 0 > > These are the same as the devices I have to test with. The "device or > resource busy" error you are getting may be due to a USB module loaded in > the kernel. > > Check lsmod and see if there is anything loaded that might conflict. > libusb only needs usbcore, which might not be a module. Check dmesg too... > it might have useful error messages. Quoting from: http://if2a.free.fr/documentation/FAQWTO.html#AEN339 2.4.2. I get the annoying message 'Device or resource busy' ! This happens under Linux with some distributions that include the usbtest module in the kernel configuration. This module is automatically loaded by hotplug when the linker renumerates, and prevents if2a from using the cable. The error message looks like this: usb_set_configuration: could not set config 1: Device or resource busy To check if it is really usbtest that messes things up, try the command dmesg|tail, here it says: usb 1-2.4: usbfs: interface 0 claimed by usbtest while 'if2a' sets config #1 This module can be unloaded (as root) with the command rmmod usbest then if2a can be restarted. For future use, you can add the word usbtest at the end of the file /etc/hotplug/blacklist, this will prevent hotplug from loading this module. - Chris |
|
From: Chris F. <cd...@fo...> - 2005-12-28 21:44:12
|
On Wed, Dec 28, 2005 at 03:46:14PM -0500, Ron Gage wrote: > Configuration Descriptor: > bLength 9 > bDescriptorType 2 > wTotalLength 46 > bNumInterfaces 1 > bConfigurationValue 1 > iConfiguration 0 > bmAttributes 0x80 > MaxPower 100mA > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 0 > bAlternateSetting 0 These are the same as the devices I have to test with. The "device or resource busy" error you are getting may be due to a USB module loaded in the kernel. Check lsmod and see if there is anything loaded that might conflict. libusb only needs usbcore, which might not be a module. Check dmesg too... it might have useful error messages. > bNumEndpoints 4 > bInterfaceClass 255 Vendor Specific Class > bInterfaceSubClass 255 Vendor Specific Subclass > bInterfaceProtocol 255 Vendor Specific Protocol > iInterface 0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x81 EP 1 IN > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0040 bytes 64 once > bInterval 0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x02 EP 2 OUT > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0040 bytes 64 once > bInterval 0 Your endpoints are different than mine, which is not really a surprise, but Barry can't handle that yet. Edit src/common.h and set the WRITE_ENDPOINT to 0x02 and READ_ENDPOINT to 0x81. - Chris |
|
From: Ron G. <ron...@al...> - 2005-12-28 20:52:35
|
Here is the lsusb dump from a 7100g
Bus 002 Device 001: ID 0000:0000 =20
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 0=20
bMaxPacketSize0 8
idVendor 0x0000=20
idProduct 0x0000=20
bcdDevice 2.06
iManufacturer 3 Linux 2.6.13.2 uhci_hcd
iProduct 2 Intel Corporation 82801CA/CAM USB (Hub #3)
iSerial 1 0000:00:1d.2
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0=20
bmAttributes 0xc0
Self Powered
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0=20
iInterface 0=20
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0002 bytes 2 twice
bInterval 255
Bus 001 Device 008: ID 0fca:0001 Research In Motion, Ltd. Blackberry
Handheld
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 255 Vendor Specific Subclass
bDeviceProtocol 255 Vendor Specific Protocol
bMaxPacketSize0 64
idVendor 0x0fca Research In Motion, Ltd.
idProduct 0x0001 Blackberry Handheld
bcdDevice 1.04
iManufacturer 1 Research In Motion
iProduct 2 Terminal mobile RIM
iSerial 0=20
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 46
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0=20
bmAttributes 0x80
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 4
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 0=20
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 bytes 64 once
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 bytes 64 once
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 bytes 64 once
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 bytes 64 once
bInterval 0
Bus 001 Device 001: ID 0000:0000 =20
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 0=20
bMaxPacketSize0 8
idVendor 0x0000=20
idProduct 0x0000=20
bcdDevice 2.06
iManufacturer 3 Linux 2.6.13.2 uhci_hcd
iProduct 2 Intel Corporation 82801CA/CAM USB (Hub #1)
iSerial 1 0000:00:1d.0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0=20
bmAttributes 0xc0
Self Powered
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0=20
iInterface 0=20
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0002 bytes 2 twice
bInterval 255
RON GAGE
Network Administrator
Wise Solutions, Inc.
T > +1 734 456 2202
M > +1 248 343 2431
www.altiris.com
=20
Security. Compliance. Patch management. IT service management.
Altiris solves your most pressing IT issues.
www.altiris.com
-----Original Message-----
From: Chris Frey [mailto:cd...@fo...]=20
Sent: Wednesday, December 28, 2005 3:33 PM
To: bar...@li...
Subject: Re: Barry
Hi,
I'm going to CC the mailing list so there is a record of these items
if you don't mind.
On Wed, Dec 28, 2005 at 08:29:44AM -0500, Ron Gage wrote:
> Finally got barry compiled.
Excellent!
> I tried it on both a 7290 and a 7100g. In both cases, I get the
> following:
>=20
> Libusb: [libusb_set_configuration:82] could not set config 1: Device
or
> resource busy
>=20
> BError caught: (-1, Operation not permitted): Probe:SetConfiguration
> failed
>=20
> I'm running as root so permissions should be a non-issue.
There are a couple places where the USB config are hardcoded in the
setup
code. I was eager to get to the protocol part, and didn't make the
discovery code dynamic (you'll see that's a Todo list item).
This might be the problem. Could you send me the output of "/sbin/lsusb
-v"?
Thanks,
- Chris
|
|
From: Ron G. <ron...@al...> - 2005-12-28 20:46:21
|
Chris:
Don't mind at all - anything to help!
Here is the output of lspci -v with my 7290 attached...
Bus 002 Device 001: ID 0000:0000 =20
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 0=20
bMaxPacketSize0 8
idVendor 0x0000=20
idProduct 0x0000=20
bcdDevice 2.06
iManufacturer 3 Linux 2.6.13.2 uhci_hcd
iProduct 2 Intel Corporation 82801CA/CAM USB (Hub #3)
iSerial 1 0000:00:1d.2
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0=20
bmAttributes 0xc0
Self Powered
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0=20
iInterface 0=20
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0002 bytes 2 twice
bInterval 255
Bus 001 Device 007: ID 0fca:0001 Research In Motion, Ltd. Blackberry
Handheld
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.01
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 255 Vendor Specific Subclass
bDeviceProtocol 255 Vendor Specific Protocol
bMaxPacketSize0 64
idVendor 0x0fca Research In Motion, Ltd.
idProduct 0x0001 Blackberry Handheld
bcdDevice 0.02
iManufacturer 1 Research In Motion
iProduct 2 Terminal mobile RIM
iSerial 0=20
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 46
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0=20
bmAttributes 0x80
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 4
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 0=20
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 bytes 64 once
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 bytes 64 once
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 bytes 64 once
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 bytes 64 once
bInterval 0
Bus 001 Device 001: ID 0000:0000 =20
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 0=20
bMaxPacketSize0 8
idVendor 0x0000=20
idProduct 0x0000=20
bcdDevice 2.06
iManufacturer 3 Linux 2.6.13.2 uhci_hcd
iProduct 2 Intel Corporation 82801CA/CAM USB (Hub #1)
iSerial 1 0000:00:1d.0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0=20
bmAttributes 0xc0
Self Powered
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0=20
iInterface 0=20
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0002 bytes 2 twice
bInterval 255
I'll see if I can get the 7100g and will post that config asap.
RON GAGE
Network Administrator
Wise Solutions, Inc.
T > +1 734 456 2202
M > +1 248 343 2431
www.altiris.com
=20
Security. Compliance. Patch management. IT service management.
Altiris solves your most pressing IT issues.
www.altiris.com
-----Original Message-----
From: Chris Frey [mailto:cd...@fo...]=20
Sent: Wednesday, December 28, 2005 3:33 PM
To: bar...@li...
Subject: Re: Barry
Hi,
I'm going to CC the mailing list so there is a record of these items
if you don't mind.
On Wed, Dec 28, 2005 at 08:29:44AM -0500, Ron Gage wrote:
> Finally got barry compiled.
Excellent!
> I tried it on both a 7290 and a 7100g. In both cases, I get the
> following:
>=20
> Libusb: [libusb_set_configuration:82] could not set config 1: Device
or
> resource busy
>=20
> BError caught: (-1, Operation not permitted): Probe:SetConfiguration
> failed
>=20
> I'm running as root so permissions should be a non-issue.
There are a couple places where the USB config are hardcoded in the
setup
code. I was eager to get to the protocol part, and didn't make the
discovery code dynamic (you'll see that's a Todo list item).
This might be the problem. Could you send me the output of "/sbin/lsusb
-v"?
Thanks,
- Chris
|
|
From: Chris F. <cd...@fo...> - 2005-12-28 20:33:24
|
Hi, I'm going to CC the mailing list so there is a record of these items if you don't mind. On Wed, Dec 28, 2005 at 08:29:44AM -0500, Ron Gage wrote: > Finally got barry compiled. Excellent! > I tried it on both a 7290 and a 7100g. In both cases, I get the > following: > > Libusb: [libusb_set_configuration:82] could not set config 1: Device or > resource busy > > BError caught: (-1, Operation not permitted): Probe:SetConfiguration > failed > > I'm running as root so permissions should be a non-issue. There are a couple places where the USB config are hardcoded in the setup code. I was eager to get to the protocol part, and didn't make the discovery code dynamic (you'll see that's a Todo list item). This might be the problem. Could you send me the output of "/sbin/lsusb -v"? Thanks, - Chris |
|
From: Chris F. <cd...@fo...> - 2005-12-18 23:11:03
|
On Sun, Dec 18, 2005 at 10:16:27AM +0100, Thomas Maul wrote: > Next instruction you are providing is "Enter the source directory and type > 'make'" which is not a problem at all but I'm confused becuase there is > no "./configure" neccessary before. I haven't done the autoconf stuff yet, so there is no ./configure step. It's on the todo list, for whoever gets to it first. :-) For now, we're just using the src/Makefile and Makefile.conf system. - Chris |
|
From: Chris F. <cd...@fo...> - 2005-12-18 21:04:44
|
On Sun, Dec 18, 2005 at 10:16:27AM +0100, Thomas Maul wrote: > You need to help me getting it configured in the right way. > See the Makefile.conf reduced "to the max": > > ***************************************************************** > DEBUG = -g > LDDEBUG = > > LIBUSBINC = ../../external/rootdir/libusb/include > INCLUDE = -I$(LIBUSBINC) > > OPTFLAGS = > > WARNFLAGS = -ansi -Wall > > CXX = g++ > CXXFLAGS = $(WARNFLAGS) $(OPTFLAGS) $(INCLUDE) $(SPECIAL) $(DEBUG) > LDFLAGS = ../../external/rootdir/libusb/lib/libusb.a -lpthread $(LDDEBUG) > > ***************************************************************** > > I took everything away which is commented(#) to see whats happen > following "less is more". This is fine. There's a lot of extra comments in there that are not really necessary but for my own documentation. > As I understood from your README.file I need to make sure a "libusb" > is available on my site and I need to point to the location for libusb > (headers and library files) which is for my machine /usr/lib/libusb.a > There is no /libusb/include directors on my system. I could'nt find more > then this at the moment. Yes, this is correct. You don't have to install it in the official system directories. You'll see that my path names are relative to the Barry/src/ directory. This is intentional so I don't have to install a devel version of libusb in /usr/lib And you do need the devel branch of libusb! Please make sure you have it. You can grab it this way, using a two-step CVS process: Check out the V1_0_DEVEL branch: cvs -d :pserver:ano...@cv...:/cvsroot/libusb \ co -r V1_0_DEVEL -d libusb-1_0_devel libusb Then update that branch to a point in time: cd libusb-1_0_devel cvs update -Pd -r V1_0_DEVEL -D 2005/11/26 This will get you the libusb source tree that I had tested Barry 0.0.1 with. This is the configure command line I use for libusb, which you might find useful: cd libusb-1_0_devel ./autogen.sh ./configure --prefix=/home/cdfrey/cvs/external/rootdir/libusb make make install The autogen script in libusb's CVS tree assumes you have automake/autoconf tools installed on your system. Once you have a spot you've installed libusb, plug those paths into Makefile.conf. > Next instruction you are providing is "Enter the source directory and type > 'make'" which is not a problem at all but I'm confused becuase there is > no "./configure" neccessary before. > > Finaly I tried once without any configuration changes and it reports > "No Targets specified and no ?make?-control file found". Sounds like you're typing 'make' from inside the Barry source tree, but not inside the Barry/src/ directory. Try: cd src make > I know I didn't configure it in the right way. Please provide some > more instruction details. What else do I need (files etc.) > > I will be waiting your next reply. Let's assume you installed libusb in /home/thomas/rootdir with "--prefix=/home/thomas/rootdir" passed to libusb's configure. You'd edit Makefile.conf to be: ***************************************************************** DEBUG = -g LDDEBUG = LIBUSBINC = /home/thomas/rootdir/include INCLUDE = -I$(LIBUSBINC) OPTFLAGS = WARNFLAGS = -ansi -Wall CXX = g++ CXXFLAGS = $(WARNFLAGS) $(OPTFLAGS) $(INCLUDE) $(SPECIAL) $(DEBUG) LDFLAGS = /home/thomas/rootdir/lib/libusb.a -lpthread $(LDDEBUG) ***************************************************************** Then you'd change to the src/ directory, and type make. Hope that helps, - Chris |
|
From: Thomas M. <tho...@sa...> - 2005-12-18 09:16:42
|
Hi Chris, There is unfortunatly not to much to report. I tried it despite not 100% understanding what I need to=20 configure in the Makefile.conf You need to help me getting it configured in the right way. See the Makefile.conf reduced "to the max": ***************************************************************** DEBUG =3D -g LDDEBUG =3D LIBUSBINC =3D ../../external/rootdir/libusb/include INCLUDE =3D -I$(LIBUSBINC) OPTFLAGS =3D WARNFLAGS =3D -ansi -Wall CXX =3D g++ CXXFLAGS =3D $(WARNFLAGS) $(OPTFLAGS) $(INCLUDE) $(SPECIAL) $(DEBUG) LDFLAGS =3D ../../external/rootdir/libusb/lib/libusb.a -lpthread $(LDDEBUG) ***************************************************************** I took everything away which is commented(#) to see whats happen following "less is more". As I understood from your README.file I need to make sure a "libusb" is available on my site and I need to point to the location for libusb (headers and library files) which is for my machine /usr/lib/libusb.a There is no /libusb/include directors on my system. I could'nt find more=20 then this at the moment. Next instruction you are providing is "Enter the source directory and type= =20 'make'" which is not a problem at all but I'm confused becuase there is no "./configure" neccessary before. =46inaly I tried once without any configuration changes and it reports "No Targets specified and no =BBmake=AB-control file found". I know I didn't configure it in the right way. Please provide some more instruction details. What else do I need (files etc.)=20 I will be waiting your next reply.=20 ***************************************************************** DEBUG =3D -g LDDEBUG =3D LIBUSBINC =3D ?? / ?? / ?????????? /rootdir/libusb/include(?) INCLUDE =3D -I$(LIBUSBINC) OPTFLAGS =3D WARNFLAGS =3D -ansi -Wall CXX =3D g++ CXXFLAGS =3D $(WARNFLAGS) $(OPTFLAGS) $(INCLUDE) $(SPECIAL) $(DEBUG) LDFLAGS =3D /usr/lib/libusb.a -lpthread $(LDDEBUG) ***************************************************************** The config above is what I would do incl. my worries (?) =20 Thomas=20 |
|
From: Chris F. <cd...@fo...> - 2005-12-15 03:32:34
|
On Wed, Dec 14, 2005 at 09:42:05PM +0100, Thomas Maul wrote: > A welcome to everybody joining this list ! Come one, come all! Good to see you made it... how did the compile go? - Chris |
|
From: Thomas M. <tho...@sa...> - 2005-12-14 20:41:55
|
A welcome to everybody joining this list ! Thomas |
|
From: Chris F. <cd...@fo...> - 2005-11-25 21:30:38
|
hello world... |
31 messages has been excluded from this view by a project administrator.
×
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