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