List: linux-video Subject: [video4linux] API From: Alan Cox < alan () cymru ! net> Date: 1998-05-16 15:04:20 I've added a draft API definition to the video4linux web page (http://roadrunner.swansea.uk.linux.org/v4l.shtml). It doesnt yet define the innards of the mmap API. There are two things I need to add to the API that I can see 1. VIDIOCGMMAPINFO Return a structure giving the number of buffered frames, the mmap area size to use and the offset of each frame. 2. VIDIOCGDEVS So for any device you can say 'ok so which teletext/vbi/radio/mixer' are the same piece of equipment as the device Im talking to now. Alan ------------ To unsubscribe from this list send mail to majordomo@phunk.org with the line "unsubscribe video4linux" without the quotes in the body of the message.
List: linux-video Subject: Re: [video4linux] API From: Gerd Knorr <kraxel () goldbach ! isdn ! cs ! tu-berlin ! de> Date: 1998-05-28 19:23:12 In lists.linux.video4linux you write: >I've added a draft API definition to the video4linux web page >(http://roadrunner.swansea.uk.linux.org/v4l.shtml). It doesnt yet define >the innards of the mmap API. >There are two things I need to add to the API that I can see >1. VIDIOCGMMAPINFO > Return a structure giving the number of buffered frames, the > mmap area size to use and the offset of each frame. Is'nt just the size and number of frames enouth? Or we return max. number of frames and max. mmap area size and allow the application to set the buffer size per frame. That way one can have many small or a few large buffers. Another problem: The current VIDEOCSYNC handling is IMHO not very good at the moment. How about adding a argument to the ioctl? The frame number (the same as in video_mmap.frame)? That way it is very easy for the driver to decide whever this frame... ... is already available => return ... is'nt available yet (bt848 still busy) => block until it is available ... was'nt asked for (using capture ioctl) => -EINVAL That would make the whole thing more robust. Currently both the driver and application have to count the (successful) capture and sync ioctls. And if one does a mistake, you might get gibbish becauce they ar'nt in sync any more. Comments? Gerd >(http://roadrunner.swansea.uk.linux.org/v4l.shtml). It doesnt yet define >the innards of the mmap API. >There are two things I need to add to the API that I can see >1. VIDIOCGMMAPINFO > Return a structure giving the number of buffered frames, the > mmap area size to use and the offset of each frame. >2. VIDIOCGDEVS > So for any device you can say 'ok so which teletext/vbi/radio/mixer' > are the same piece of equipment as the device Im talking to now. >Alan >------------ >To unsubscribe from this list send mail to majordomo@phunk.org with the >line "unsubscribe video4linux" without the quotes in the body of the >message. -- Gerd Knorr <kraxel@cs.tu-berlin.de> ------------ To unsubscribe from this list send mail to majordomo@phunk.org with the line "unsubscribe video4linux" without the quotes in the body of the message.
List: linux-video Subject: Re: [video4linux] API From: Alan Cox <alan () cymru ! net> Date: 1998-06-01 15:40:56 > Is'nt just the size and number of frames enouth? Or we return max. > number of frames and max. mmap area size and allow the application > to set the buffer size per frame. That way one can have many small > or a few large buffers. That isnt a bad idea. However some cards of constraints on alignment to page or multipage boundaries, so we need some flexibility > and application have to count the (successful) capture and sync ioctls. > And if one does a mistake, you might get gibbish becauce they ar'nt in > sync any more. Sounds great to me - got a patch for this ? ------------ To unsubscribe from this list send mail to majordomo@phunk.org with the line "unsubscribe video4linux" without the quotes in the body of the message.
List: linux-video Subject: Re: [video4linux] API From: Gerd Knorr < kraxel () goldbach ! isdn ! cs ! tu-berlin ! de> Date: 1998-06-01 21:40:20 [Download message RAW] On Mon, 1 Jun 1998, Alan Cox wrote: > > Is'nt just the size and number of frames enouth? Or we return max. > > number of frames and max. mmap area size and allow the application > > to set the buffer size per frame. That way one can have many small > > or a few large buffers. > > That isnt a bad idea. However some cards of constraints on alignment > to page or multipage boundaries, so we need some flexibility I like the OSS way to handle this: If some application change some parameters, the driver returns the value really used. That way the driver can round up to page boundaries or whatever without problems. > > and application have to count the (successful) capture and sync ioctls. > > And if one does a mistake, you might get gibbish becauce they ar'nt in > > sync any more. > > Sounds great to me - got a patch for this ? Hacked up one today. patch against 0.5.8. Started to move the tv norm to video_channel too. The #ifdef'ed out code in ioctl VIDIOCSCHAN oopses for some reason I hav'nt tracked down yet. Gerd Patch ------------ To unsubscribe from this list send mail to majordomo@phunk.org with the line "unsubscribe video4linux" without the quotes in the body of the message.