> I don't know if video_devdata() belong to the new API; however,
> since i would like the driver to be compatible with as many linux2.4.x
> versions as possible, i need to know:
> 1. which version of the kernel the struct file_operations* interface
> was introduced in;
> 2. which version of the kernel the video_devdata() function
> was introduced in;
both in 2.4.19 (and in 2.5.x the struct file_operations thing is the
_only_ available interface).
> frame[i].buffer = frame[0].buffer + i * SIZE_OF_BUFFER;
>
> The "active and ready" frame buffer may be one of those frame[i].buffer.
>
> So i can mmap all the buffers (ready or not) contiguously in a single,
> long virtual memory area.
>
> Now..Questions to the powers: is that a right way to implement mmap()?
> Are there any disadvantages to allocate memory that way?
Can be done that way. You should take care to page-align the buffers.
That will it make easier to implement the v4l2-way to map the buffers
later on (which is one mapping per buffer instead of one big mapping).
Gerd
--
Weil die sp�ten Diskussionen nicht mal mehr den Rotwein lohnen.
-- Wacholder in "Melanie"
--
video4linux-list mailing list
Unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe
https://listman.redhat.com/mailman/listinfo/video4linux-list
