Alle 16:05, sabato 13 gennaio 2007, Vojtech Pavlik ha scritto: > On Sat, Jan 13, 2007 at 01:07:33PM > > Consider that many applications are still based on the old V4L1. > > In one way or the other they would have to be rewritten... > > Consider how long V4L2 exists. The obvious answer is: They will not be > rewritten any soon.
Your point is questionable. even If the process of passing from V4L1 to V4L2 requires time, I do not think it's a good reason to implement decoders in the kernel. IMHO, a solution to reduce this time is to _force_ the users/developers to adopt V4L2 only. A simple example is to remove the V4L1 compat layer from the actual V4L2 drivers at least. I am sure that the fact that the UVC driver is based on the V4L2 API only will bear fruit with regard to the V4L2 support in userspace, So let people complain about "my v4l2 driver does not work with my app" in the first place. Personally, for this reason, I also always refused to provide support for V4L1 in my V4L2 drivers through the compat layer. > > Exactly. One more reason why you can't map the ISOC transfer buffers > > directly is that ISOC transfers does not garantuee a fixed number of > > video bytes per frame. > > I don't think that'd be a problem per se, we could still make the USB > subsystem to put all the frame data into a virtually contiguous buffer, > regardles of how long the individual transfers are. I was talking about the lenghts of single USB _frames_ after ISOC transfers terminate, as described by the "myurb->iso_frame_desc[i].actual_length" field. You can't know these values until the submitted URB actually returns and the IRQ handler is called by the USB subsystem. So, apart from the headers in each frame, I still do not see how it's possible to map the data in the frames to a contiguous buffer. Luca _______________________________________________ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
