> I don't think that the kernel should be involved at all. I only wanted to
> say that currently we have device-specific (usually YUV clone) format
> converted to RGB24. This is not good, but there isn't much we can do
> without breaking lots of clients. Some are already broken, by the way -
> Voxilla insists on planar YUV422 (which is rare among native camera
> streams). I made a patch to Voxilla (user-space, of course :)
Most clients are crap. Building the library will help them yes.
> As one of future problems I may mention one: a camera can change the
> data format when changing video size. This is not handled by V4L at all.
Actually V4L was specified to try and sort of allow for this. But you are
right we don't handle it neatly.
> break. Should we attempt this change now? Linus won't even accept such
> patch, probably. After 2.4 such work can be done safely, and it will
> probably involve transition to V4L2 as well.
Post 2.4 we are going somewhere. But that somewhere has to combine the extended
V4L1 (stradis style) , the nice mjpeg type handling (buz) and the rather
saner format handling and some of the other v4l2 bits. On top of that add
kiovecs and raw I/O to user space pages
Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
