Alan Cox wrote:
> > If I do that now, hell will break loose. To me, this course of action is
> > perfectly acceptable for 2.5; but not while 2.4.* is slowly making its way
> > to more and more distributions and desktop machines. It would instantly
> > break all USB webcams.
>
> We shall soon find out.
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
isn't supposed to be a war between kernel developers and app developers, with
the users caught in the crossfire.
If you wanted this code removed, you should have said something to myself and
the other V4L driver maintainers back in the 2.3.x series. I would have gladly
complied, as long as there would be enough time to notify the various app
authors that they screwed up by not supporting all possible formats (even though
the V4L spec is ambiguous about who is responsible for the various stages of
conversion).
There is no need to piss anyone off: just revise the V4L and V4L2 specs to be
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.
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?
--
Mark McClelland
Latest non-crippled ov511 driver is available at: http://alpha.dyndns.org/ov511/
[EMAIL PROTECTED]
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
