In message <1046331946.31070.13.camel@xxxxxxxxxxxxxxxxxxxxx>
Ronald Bultje <rbultje@xxxxxxxxxxxxxxxxxxx> wrote:
> On Wed, 2003-02-26 at 23:06, Miah Gregory wrote:
> > Absolutely right, if you have v4l2 available. Unfortunately, if you want
> > to provide backwards compatibility, there are very few options available
> > to you. It's not feasible to change all the existing v4l applications to
> > support an unofficial 'this is jpeg' type. That's one of the very reasons
> > why there is a new v4l API being developed.
> > We've had to do the above in the spca50x (spca50x.sourceforge.net)
> > driver. In summary, yes, it's evil. Yes, it should be done in userspace,
> > but in some situations, there is no realistic alternative.
> Isn't the fact that drivers provide backwards compatibility one of the
> very reason why application developers aren't in a hurry to provide v4l2
> with proper JPEG decoding support in their applications?
Could be one of the reasons, indeed. I would guess that another major reason
is that v4l2 is currently only realistically available in 2.5 series kernels,
and as such could be seen as 'unstable', 'development', or just 'subject to
change'. App developers, in my experience, like stable API's.
> Applications are currently just slow in following these new things,
> unfortunately... So yeah, you have a point (unfortunately).
Well, until 2.5 is ratified into 2.6, I wouldn't feel comfortable with a
v4l2 only driver, because it locks out the vast majority of our users. As a
kernel module developer, even I don't run 2.5 series on any of my machines,
as I'm just too wary of it's bleeding edge status.
Incidentally, I do realise that you can apply backported patches for v4l2 to
2.4 kernels, but in my estimation, that raises the bar for access to our
driver substantially.
I suppose, were v4l2 to be properly backported, and integrated into the
2.4 source tree, that might provide many with more of an incentive to
upgrade their apps/drivers.
Just my 2p.
--
Miah Gregory
