Re: [Linux1394-devel] Announce: SDPAVC

[Manfred W. <e95...@st...>]

"Timothy M. Shead" wrote:
> 
> After much playing around, I figured it out ... thanks!  So, without
> further ado, anyone interested in a C++ library for controlling devices
> through AV/C (the protocol-of-choice for DV camcorders) should check-out
> SDPAVC, located at my website: http://www.k-3d.com.  The library, which

Are you sure that this works. I neither compiled nor tested it, but I
had a look at the code, and I see the following problem:

Let's inspect the function sdpAvcSubUnit::RawCommand in
sdpavcsubunit.cpp, especially line 105:
	raw1394_set_fcp_handler(m_Handle, FCPHandler);

You try to register a handler, which has (ragarding to raw1394.h) to be
of the type int (*)(raw1394handle_t, nodeid_t nodeid, int response
size_t length, unsigned char *data).

But according to line 134, your handler has the type int
(sdpAvcSubUnit::*) (raw1394handle_t Handle, ... , unsigned char* Data).
It is no ordinary function, but a member function of a class and
incompatible to the type, raw1394_set_fcp_handler expects (because C++
adds a pointer to the object [the instance of the class] it belongs to
as a "hidden" argument to the argument list of the function, which
therefore has one parameter too many.

I have the same problem. It is not possible to register a member
function of a class as handler; it must be an ordinary C-function (which
of course cannot access the member variable of the object [because it
does not get that hidden pointer to that object]). One can work-around
this by using global variables for everything the handler must access as
long as there is only one object, but if there are two (or more)
instances, there will be troubles (especially, if the application is
multithreaded), because the handler wants to hand over things to one
particular object, but the global variables are common to all objects.
The objects can get individual raw-handles, but the fcp_handler (and the
same applies to the iso_handlers) cannot find out, which object did the
raw1394_loop_iterate (btw: you should replace raw1394_read in line 113
with a raw1394_loop_iterate-loop until the response-frame arrived) and
thus cause it to be called.

I do not know a "clean" solution to that problem (as long as we want to
use libraw1394). I think, the only way would be to create a new
object-oriented version of libraw.
One quick solution might be to add a field "private" or something like
that to struct raw1394_handle, which we could use to store a pointer to
our object. Then we could declare the handler as a friend function of
the class and via the pointer (because the handler has the raw-handle as
first argument, and therefore would get that pointer) we could access
the member variables of the object.


Manfred Weihs