Hi David, On Sat, 2002-06-08 at 14:12, David Lions wrote: > 1. How does the VIDIOCGMBUF ioctl call and the mmap call work together? How > does the driver/api know where to put the captured video data? First, I do mmap() is being done with the file descriptor of the driver as an argument - so you just mmap() it in the driver. The driver does all the mmap() work for you. > just asked how much it needed. I DID allocate memory, but I didn't tell the > driver/card where it is. How does it know? I hope you now see that you *did* teel the driver - by doing mmap() at all. > 2. Why can't I use malloc() instead of mmap()? What is the significance of > allocating memory after a special file? In the man page for mmap, it says > it allocates memory 'after' the file, why after it? Does it matter where > the memory is allocated as long as the relevant code knows where that is? In BTTV-0.8, you can actually use malloc() and then read(). In most drivers, this is not implemented because it's a major PITA. Consider it like this: if I use userspace memory, I cannot be sure that the memory is within the 32-bit boundaries of addressable memory. Also, I cannot be sure that the memory is (physically) contiguous, required by quite some drivers. Lastly, it complicates driver programming quite a bit to do read()s because you can't be sure that it's not swap (userspace != kernelspace), so you often need to capture to a second buffer, do a memcpy() and dismiss the first buffer - that sucks concerning performance. mmap() is just a lot easier for driver developers. > 3. My application wants to use all of the available physical memory, no > virtual memory. Has anyone every tried to malloc 200 Megabytes of RAM? > Does that work? Are there any tricks to doing this? It'd probably work in userspace, though you could expect a OOMkill pretty soon (out-of-memory-kill). > 4. Does the call ioctl(fd, VIDIOCSYNC, framenumber) block? Yes. > 4.5 How can I be sure that I won't be malloc'ed virtual memory? mmap() from the driver always returns physical memory, because otherwise, the driver can't capture to that video (DMA won't work). So it's always physical memory, not HD swap space or so. With malloc(), you can't be sure - it's userspace, so you're not supposed to care. :-). > 5. How can I find out how much physical (not virtual) memory is available > from: > a) the command line > b) from a C program /proc/meminfo > 6. Gcc produces a.out files. Apparently, a.out is redundant and some new > format called ELF does the same thing but in a newer way, thus making a.out > obsolete. As far as I am concerned, will I run in to trouble using these > a.out files? gcc produces elf files, but for backwards compatibility, their *name* is a.out. Their format, however, is ELF. Use -o <name> to give it a different name. > 7. How do I start a new thread (the POSIX standard way? can't remember what > it's called!) pthread_create(). > 8. If the video card and/or it's driver can capture directly into the frame > buffer of my video card, can I make it capture right into my buffers (which > are allocated with malloc)? malloc(): yes, if you use a rather new BTTV driver and read(). > 9. After each frame is captured, can I update the address of the buffer of > the next frame so that even if the card itself only supports two buffers, as > reported by VIDIOCGMBUF ioctl call, I could store to RAM as long as I got > there in time to change the vector before it started storing the data? Call read() in a loop. Using mmap(), see the insmod option gbuffers=num for using num instead of 2 buffers. Ronald -- - .-. - /V\ | Ronald Bultje <rbultje@xxxxxxxxxxxxxxxxxxx> - // \\ | Running: Linux 2.4.18 and OpenBSD 3.0 - /( )\ | http://ronald.bitfreak.net/ - ^^-^^
