On Tue, 12 Oct 2004, Johannes M Zmoelnig wrote:
ok, i get it somehow:
dv1394.h does not define any interfaces to library-bindings. it merely defines one or 2 structures and a number of ioctl()-commands. since this is really an implementation detail of the kernel-driver, i understand why it has been deprecated by libdv.
i have checked a version of videoDV4L into the CVS that uses the header-file from the kernel. (some changes where necessary, as they have changed the ioctl-commands from DV1394_ to DV1394_IOC_) the videoDV4L.h therefore includes <ieee1394/dv1394.h>; so you have to add /usr/src/linux/drivers to the include-path is this the correct way to do it ??? or rather include <dv1394.h> and add /usr/src/linux/drivers/ieee1394 (or whatever)
so we just have to force people to have kernel-headers installed. i think we can assume, that most linux will have the current kernel-headers in /usr/src/linux (?)
If it would be that simple. Normally the interface to the kernel drivers get included into /usr/include/linux hierarchy if they are stable. Now, as the kernel is like a library and we don't know of the ioctl API changes, you have to compile gem against a special kernel version, and theoretically you would have to recompile everytime you upgrade the kernel.
In practice it might be that the interface doesn't change, and you can use the kernel header file. This means, in this case you sort of "inofficially freeze" the API (by including the corresponding header file in your sources, just for convenience). In this case you have to be aware that strange things could happen.
Then, as another wild guess, probably the libraw1394 can be used for the task ?
Sorry for the vague response, not really my field, this.
Guenter
There might be some need now and then to disable things (like the dv support example showed). I do not think it is considered bad style, I just had no use for it until now.
ok. i sometimes need to disable things, just for testing...
mfg.asd.r IOhannes