Thread: [libdc] USB PtGrey Flea3 on OSX patch
Capture and control API for IIDC compliant cameras
Brought to you by:
ddouxchamps,
gordp
From: Robin B. <de...@be...> - 2015-03-16 17:48:07
|
diff --git a/libdc1394/dc1394/usb/capture.c b/libdc1394/dc1394/usb/capture.c index 75d9572..3ce7e68 100644 --- a/libdc1394/dc1394/usb/capture.c +++ b/libdc1394/dc1394/usb/capture.c @@ -107,6 +107,44 @@ capture_thread (void * arg) return NULL; } +static int +find_interface (libusb_device * usb_dev, uint8_t endpoint_address) +{ + struct libusb_device_descriptor usb_desc; + struct libusb_config_descriptor * config_desc; + int ret; + int i, a, e; + uint8_t ea; + + ret = libusb_get_device_descriptor(usb_dev, &usb_desc); + + if (ret < 0) { + dc1394_log_error ("usb: Failed to get device descriptor"); + return DC1394_FAILURE; + } + + if (usbdesc.bNumConfigurations) { + ret = libusb_get_active_config_descriptor (usb_dev, &config_desc); + if(ret) { + dc1394_log_error ("usb: Failed to get config descriptor"); + return DC1394_FAILURE; + } + + for (i = 0; i < config_desc->bNumInterfaces; i++) { + for (a = 0; a < config_desc->interface[i].num_altsetting; a++) { + for (e = 0; e < config_desc->interface[i].altsetting[a].bNumEndpoints; e++) { + ea = configDesc->interface[i].altsetting[a].endpoint[e].bEndpointAddress; + //return the interface number for the first suitable interface + if (ea == endpoint_address) + return i; + } + } + } + } + + return DC1394_FAILURE; +} + static dc1394error_t init_frame(platform_camera_t *craw, int index, dc1394video_frame_t *proto) { @@ -226,7 +264,14 @@ dc1394_usb_capture_setup(platform_camera_t *craw, uint32_t num_dma_buffers, } libusb_free_device_list (list, 1); - if (libusb_claim_interface (craw->thread_handle, 0) < 0) { + int usb_interface = find_interface (libusb_get_device(craw->thread_handle), + 0x81); + if(usb_interface == DC1394_FAILURE){ + dc1394_log_error ("usb: capture thread failed to find suitable interface on device"); + dc1394_usb_capture_stop (craw); + return DC1394_FAILURE; + } + if (libusb_claim_interface (craw->thread_handle, usb_interface) < 0) { dc1394_log_error ("usb: capture thread failed to claim interface"); dc1394_usb_capture_stop (craw); return DC1394_FAILURE; |
From: Robin B. <de...@be...> - 2015-03-16 22:43:34
Attachments:
flea3osx.diff
|
It seems my message body was treated as an attachment by mailman (lol?!). Here it is again in plain text. > > Dear maintainers, There was some discussion last year about getting a > Point Grey Flea 3 working with OSX. Unfortunately I cannot easily > reply to that thread, so I apologise for starting a new one! > > To summarize the issue again, the Flea3 presents the 0x81 endpoint on > interface 2, but usb/capture.c currently always looks at interface > 0. > > Rodolphe Pineau posted some code to fix this here > http://sourceforge.net/p/libdc1394/mailman/message/31958001/ . This > fix finds the interface with endpoint 0x81 and uses that to allow the > Flea3 to work. > > I took some time recently to test this and tidy it up. I can confirm > that this approach does work with the monochrome Flea 3 > FL3-U3-13S2M-CS with firmware version 2.7.3 (this camera appears with > the same product id 0x3006 as the color equivalent FL3-U3-13S2C) when > connected to a usb2 port, and also when connected to a usb3 port via > a usb2 hub. This works on both OSX 10.9 and 10.10. > > There remains an issue with usb3 on OSX if the camera is connected > directly to a usb3 port. The transfer will fail, as noted by Jim > Cassidy here: > http://sourceforge.net/p/libdc1394/mailman/message/32063018/ . > > I have attached a patch to apply against the current git head (commit > 335594c). It modifies usb/capture.c as Rodolphe suggested, fixed, > tidied, and with some additional error logging. > > > Regards, Robin |
From: Damien D. <dd...@do...> - 2015-03-21 08:40:30
|
Hi Robin, On Mon, 2015-03-16 at 17:31 +0000, Robin Beitra wrote: > Dear maintainers, > > There was some discussion last year about getting a Point Grey Flea 3 > working with OSX. Unfortunately I cannot easily reply to that thread, > so I apologise for starting a new one! > > > To summarize the issue again, the Flea3 presents the 0x81 endpoint on > interface 2, but usb/capture.c currently always looks at interface 0. > > Rodolphe Pineau posted some code to fix this here > http://sourceforge.net/p/libdc1394/mailman/message/31958001/ . This > fix finds the interface with endpoint 0x81 and uses that to allow the > Flea3 to work. I'm a bit clueless here, but is there a reason for this particular value 0x81? Is it Point Grey specific, or maybe depends on the device? I'd like to add a little comment about it in the code... > I took some time recently to test this and tidy it up. I can confirm > that this approach does work with the monochrome Flea 3 > FL3-U3-13S2M-CS with firmware version 2.7.3 (this camera appears with > the same product id 0x3006 as the color equivalent FL3-U3-13S2C) when > connected to a usb2 port, and also when connected to a usb3 port via a > usb2 hub. This works on both OSX 10.9 and 10.10. > > There remains an issue with usb3 on OSX if the camera is connected > directly to a usb3 port. The transfer will fail, as noted by Jim > Cassidy here: > http://sourceforge.net/p/libdc1394/mailman/message/32063018/ . > > > I have attached a patch to apply against the current git head (commit > 335594c). It modifies usb/capture.c as Rodolphe suggested, fixed, > tidied, and with some additional error logging. Thanks, I'll push it soon Damien -- Damien 高原 Douxchamps http://damien.douxchamps.net/ |
From: Rodolphe P. <pi...@rt...> - 2015-03-21 16:21:30
|
On Fri 3/20/15, at 23:13, Damien Douxchamps <dd...@do...> wrote: > Hi Robin, > > On Mon, 2015-03-16 at 17:31 +0000, Robin Beitra wrote: >> Dear maintainers, >> >> There was some discussion last year about getting a Point Grey Flea 3 >> working with OSX. Unfortunately I cannot easily reply to that thread, >> so I apologise for starting a new one! >> >> >> To summarize the issue again, the Flea3 presents the 0x81 endpoint on >> interface 2, but usb/capture.c currently always looks at interface 0. >> >> Rodolphe Pineau posted some code to fix this here >> http://sourceforge.net/p/libdc1394/mailman/message/31958001/ . This >> fix finds the interface with endpoint 0x81 and uses that to allow the >> Flea3 to work. > > I'm a bit clueless here, but is there a reason for this particular value > 0x81? Is it Point Grey specific, or maybe depends on the device? I'd > like to add a little comment about it in the code… > Endpoint address are encoded like this : Bits 0..3 Endpoint Number. Bits 4..6 Reserved. Set to Zero Bits 7 Direction 0 = Out, 1 = In (Ignored for Control Endpoints) So 0x81 is a In endpoint and is endpoint number 1 If a vendor decide to have different endpoint they can use a different address. Usually vendor start at 0 and go up for the number… may be PGR decided on a different endpoint for some internal reason but we can’t assume this will be the case for any vendor. Rodolphe -- | Rodolphe Pineau RTI-Zone | | http://www.rti-zone.org/ | | Robotics / Unix / Mac OS X / Astronomy | |
From: Damien D. <dd...@do...> - 2015-03-22 18:40:36
|
On Sat, 2015-03-21 at 09:06 -0700, Rodolphe Pineau wrote: [snip] > Endpoint address are encoded like this : > > Bits 0..3 Endpoint Number. > Bits 4..6 Reserved. Set to Zero > Bits 7 Direction 0 = Out, 1 = In (Ignored for Control Endpoints) > > So 0x81 is a In endpoint and is endpoint number 1 > If a vendor decide to have different endpoint they can use a different address. > Usually vendor start at 0 and go up for the number… may be PGR decided on a different endpoint for some internal reason but we can’t assume this will be the case for any vendor. Thanks for the info. Comment written and update pushed. -- Damien 高原 Douxchamps http://damien.douxchamps.net/ |
From: Robin B. <de...@be...> - 2015-03-24 04:04:10
|
> Thanks for the info. Comment written and update pushed. Great, thanks! > So 0x81 is a In endpoint and is endpoint number 1 That is interesting. So endpoint 0x81 is not specific to the PGR Flea 3? Are the other endpoints (0x80, 0x82, etc?) in use for other cameras? (I am not currently able to test this with any other cameras). Cheers, Robin On 23 March 2015 at 00:01, Damien Douxchamps <dd...@do...> wrote: > On Sat, 2015-03-21 at 09:06 -0700, Rodolphe Pineau wrote: > > [snip] > >> Endpoint address are encoded like this : >> >> Bits 0..3 Endpoint Number. >> Bits 4..6 Reserved. Set to Zero >> Bits 7 Direction 0 = Out, 1 = In (Ignored for Control Endpoints) >> >> So 0x81 is a In endpoint and is endpoint number 1 >> If a vendor decide to have different endpoint they can use a different address. >> Usually vendor start at 0 and go up for the number… may be PGR decided on a different endpoint for some internal reason but we can’t assume this will be the case for any vendor. > > Thanks for the info. Comment written and update pushed. > > -- > Damien 高原 Douxchamps http://damien.douxchamps.net/ > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel Website, sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for all > things parallel software development, from weekly thought leadership blogs to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > Mailing list for libdc1394-devel > lib...@li... > https://lists.sourceforge.net/lists/listinfo/libdc1394-devel |
From: Rodolphe P. <pi...@rt...> - 2015-03-24 15:40:36
|
On Mon 3/23/15, at 21:03, Robin Beitra <de...@be...> wrote: >> Thanks for the info. Comment written and update pushed. > > Great, thanks! > > >> So 0x81 is a In endpoint and is endpoint number 1 > > That is interesting. > > So endpoint 0x81 is not specific to the PGR Flea 3? Are the other > endpoints (0x80, 0x82, etc?) in use for other cameras? (I am not > currently able to test this with any other cameras). > > Cheers, > Robin > The endpoint address are specified by a bitfield in the USB specification, so they are not random. So yes a lot of vendors will use the same endpoint address independently of the type of device. Input endpoint start a 0x80 , output endpoint start at 0x00 as bit 7 defines the direction of the endpoint. The bit 0 through 3 define the endpoint number (so 16 possible address per direction). The differentiation between usb device is done using the VPI and VCI and the device class. Rodolphe > On 23 March 2015 at 00:01, Damien Douxchamps <dd...@do...> wrote: >> On Sat, 2015-03-21 at 09:06 -0700, Rodolphe Pineau wrote: >> >> [snip] >> >>> Endpoint address are encoded like this : >>> >>> Bits 0..3 Endpoint Number. >>> Bits 4..6 Reserved. Set to Zero >>> Bits 7 Direction 0 = Out, 1 = In (Ignored for Control Endpoints) >>> >>> So 0x81 is a In endpoint and is endpoint number 1 >>> If a vendor decide to have different endpoint they can use a different address. >>> Usually vendor start at 0 and go up for the number… may be PGR decided on a different endpoint for some internal reason but we can’t assume this will be the case for any vendor. >> >> Thanks for the info. Comment written and update pushed. >> >> -- >> Damien 高原 Douxchamps http://damien.douxchamps.net/ >> >> >> ------------------------------------------------------------------------------ >> Dive into the World of Parallel Programming The Go Parallel Website, sponsored >> by Intel and developed in partnership with Slashdot Media, is your hub for all >> things parallel software development, from weekly thought leadership blogs to >> news, videos, case studies, tutorials and more. Take a look and join the >> conversation now. http://goparallel.sourceforge.net/ >> _______________________________________________ >> Mailing list for libdc1394-devel >> lib...@li... >> https://lists.sourceforge.net/lists/listinfo/libdc1394-devel > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel Website, sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for all > things parallel software development, from weekly thought leadership blogs to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > Mailing list for libdc1394-devel > lib...@li... > https://lists.sourceforge.net/lists/listinfo/libdc1394-devel -- | Rodolphe Pineau RTI-Zone | | http://www.rti-zone.org/ | | Robotics / Unix / Mac OS X / Astronomy | |