> While I agree that in-kernel format conversion code (between standard V4L
> formats) should be removed *eventually*, tearing it out in the middle of a
> stable kernel series without warning does a great disservice to many users. This
I didnt "tear it out". I vetoed it going in
> clear about this, and post a message on the V4L list saying "App developers: you
> have until 2.4.8 to get your shit together". That is good and fair project
> management; use of heavy-handed quasi-punitive measures just to prove a point
> isn't.
I've explained this repeatedly on the list going back years.
> On a somewhat related issue, why does V4L have two methods getting the data to
> user-space, i.e. mmap() and read()? If you look at this issue like the format
> conversion one, shouldn't all V4L apps be required to support both interfaces?
> Should drivers only support one?
Not all hardware can sanely support mmap interfaces, but mmap can be a lot
faster. The sane answer is probably that we should all be using kiovecs
for the read and getting mmap like performance
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
