Hi,
Just stumbled over this when trying to do the Debian package. The header file libdv/dv1394.h does not exist anymore in the libdv package. I had to disable libdv support.
Otherwise I hope I have fixed the problem the Debian package had with FTGL support.
Guenter
guenter geiger wrote:
Hi,
Just stumbled over this when trying to do the Debian package. The header file libdv/dv1394.h does not exist anymore in the libdv package. I had to disable libdv support.
i know.
what would be the best + simplest way to handle this ?
include the dv1394.h with gem (i've seen some other apps that do it like this) ???
i see that the dv1394.h is included in the kernel-source, however it does not get installed in /usr/include/. what is the clean way to handle this ??
or do we have to re-write dv-support from scratch ?
Otherwise I hope I have fixed the problem the Debian package had with FTGL support.
is there any reason that configure *only* autodetects installed things ? i mean, is it generally bad style to enable/disable and with/without things via the configure ? or should we add this again to the new and cleaner script ?
mfg.asd.r IOhannes
On Tue, 12 Oct 2004, Johannes M Zmoelnig wrote:
libdv package. I had to disable libdv support.
i know.
what would be the best + simplest way to handle this ?
include the dv1394.h with gem (i've seen some other apps that do it like this) ???
i see that the dv1394.h is included in the kernel-source, however it does not get installed in /usr/include/. what is the clean way to handle this ??
or do we have to re-write dv-support from scratch ?
The simplest way is to include the header, the cleanest way is to rewrite DV support. Now that they are removing the interface definition we do not know how long the library will have the bindings.
Otherwise I hope I have fixed the problem the Debian package had with FTGL support.
is there any reason that configure *only* autodetects installed things ? i mean, is it generally bad style to enable/disable and with/without things via the configure ? or should we add this again to the new and cleaner script ?
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.
There are other things that are still missing in order to make the configure.ac from the Debian package a general replacement, like the /usr/local stuff and header detection, the -D__NEW__ (although this should probably be set by default).
Guenter
mfg.asd.r IOhannes
guenter geiger wrote:
On Tue, 12 Oct 2004, Johannes M Zmoelnig wrote:
The simplest way is to include the header, the cleanest way is to rewrite DV support. Now that they are removing the interface definition we do not know how long the library will have the bindings.
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 (?)
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
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
guenter geiger wrote:
On Tue, 12 Oct 2004, Johannes M Zmoelnig wrote:
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.
correct me if i am wrong (i don't know anything about this) ioctl()-commands are defined(!) numbers that tell the driver (which *is* kernel-dependant) to do something. if we do "ioctl(DV1394_IOC_WAIT_FRAMES, ...)" this is the same as doing "ioctl(8969, ...)" so if the API changes, the ioctl() will fail!
thus compiling against dv1394.h (either from a special kernel or provided with Gem) could always break when upgrading the kernel! but using the kernel-headers will at least enable us to compile against the current kernel (which a gem-included file will not!) and make it work again.
however, if they really change the API (e.g. rename DV1394_WAIT_FRAMES to DV1394_IOC_WAIT_FRAMES) we will have a problem. is this likely to change ??
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.
ah, i think this is, what i have just tried to explain.
the official stable kernel-headers (/usr/include/linux) are versioned (on debian) as 2.5.99 this does not look very "stable" to me as i read the /usr/share/doc/kernel-source-2.6.7/README.headers.gz file, the /usr/include/linux is mainly for libc6
Then, as another wild guess, probably the libraw1394 can be used for the task ?
maybe (??)
but why do we have a kernel-module for dv1394 if we cannot/mustnot use it ?
mfg.as.dr IOhannes
On Tue, 12 Oct 2004, Johannes M Zmoelnig wrote:
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.
ah, i think this is, what i have just tried to explain.
the official stable kernel-headers (/usr/include/linux) are versioned (on debian) as 2.5.99 this does not look very "stable" to me as i read the /usr/share/doc/kernel-source-2.6.7/README.headers.gz file, the /usr/include/linux is mainly for libc6
yes, and for you to compile against. When you use the video device, you use /usr/include/linux/video.h the stable video4linux 2 kernel API.
Then, as another wild guess, probably the libraw1394 can be used for the task ?
maybe (??)
but why do we have a kernel-module for dv1394 if we cannot/mustnot use it ?
Good question. Some answers: 1) The API is stable, but its not in the general kernel header files because no one was missing it up to now, and noone complained about it missing.
2) The API is terribly unstable (this is unlikely)
3) Someone looked at the API and decided that it is stupid to have an API for video capture that is specific to a device (e.g differs from video4linux), because then people have to write a separate frontend to use it (our problem).
4) ...
I think the best thing to do would be to include the header file for now in gem, and try to figure out how the things will evolve by contacting the author(s) of the module and the debian kernel headers maintainer or by surfing on the net.
Guenter
-
guenter geiger -
Johannes M Zmoelnig