RFC: howto handle driver changes which require libv4l > x.y ?

RFC: howto handle driver changes which require libv4l > x.y ?

[Hans de Goede]

Hi All,

So recently I've hit 2 issues where kernel side fixes need
to go hand in hand with libv4l updates to not cause regressions.

First lets discuss the 2 cases:
1) The pac207 driver currently limits the framerate (and thus
    the minimum exposure time) because at higher framerate the
    cam starts using a higher compression and we could not
    decompress this. Thanks to Bertrik Sikken we can now handle
    the higher decompression.

    So no I really want to enable the higher framerates as those
    are needed to make the cam work properly in full daylight.

    But if I do this, things will regress for people with an
    older libv4l, as that won't be able to decompress the frames

2) Several zc3xxx cams have a timing issue between the bridge and
    the sensor (the windows drivers have the same issue) which
    makes them do only 320x236 instead of 320x240. Currently
    we report their resolution to userspace as 320x240, leading to
    a bar of noise at the bottom of the screen.

    The fix here obviously is to report the real effective resoltion
    to userspace, but this will cause regressions for apps which blindly
    assume 320x240 is available (such as skype). The latest libv4l will
    make the apps happy again by giving them 320x240 by adding small
    black borders.


Now I see 2 solutions here:

a) Just make the changes, seen from the kernel side these are most
    certainly bugfixes. I tend towards this for case 2)

b) Come up with an API to tell the libv4l version to the kernel and
    make these changes in the drivers conditional on the libv4l version


So this is my dilemma, your input is greatly appreciated.

Regards,

Hans

Re: RFC: howto handle driver changes which require libv4l > x.y ?

[Erik Andrén]

2009/7/7 Hans de Goede <hdegoede@redhat.com>:
> Hi All,
>
> So recently I've hit 2 issues where kernel side fixes need
> to go hand in hand with libv4l updates to not cause regressions.
>
> First lets discuss the 2 cases:
> 1) The pac207 driver currently limits the framerate (and thus
>   the minimum exposure time) because at higher framerate the
>   cam starts using a higher compression and we could not
>   decompress this. Thanks to Bertrik Sikken we can now handle
>   the higher decompression.
>
>   So no I really want to enable the higher framerates as those
>   are needed to make the cam work properly in full daylight.
>
>   But if I do this, things will regress for people with an
>   older libv4l, as that won't be able to decompress the frames
>
> 2) Several zc3xxx cams have a timing issue between the bridge and
>   the sensor (the windows drivers have the same issue) which
>   makes them do only 320x236 instead of 320x240. Currently
>   we report their resolution to userspace as 320x240, leading to
>   a bar of noise at the bottom of the screen.
>
>   The fix here obviously is to report the real effective resoltion
>   to userspace, but this will cause regressions for apps which blindly
>   assume 320x240 is available (such as skype). The latest libv4l will
>   make the apps happy again by giving them 320x240 by adding small
>   black borders.
>
>
> Now I see 2 solutions here:
>
> a) Just make the changes, seen from the kernel side these are most
>   certainly bugfixes. I tend towards this for case 2)
>
> b) Come up with an API to tell the libv4l version to the kernel and
>   make these changes in the drivers conditional on the libv4l version
>
>
Solution b) sounds messy and will probably lead to a lot of error
prone glue code in the kernel.
Fast-forward a couple of libv4l releases and you will have a nightmare
maintainability scenario.

If people run an old libv4l with a new kernel and run into problem,
just tell them to upgrade their libv4l version.

My 2 cents,
Erik


> So this is my dilemma, your input is greatly appreciated.
>
> Regards,
>
> Hans
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: RFC: howto handle driver changes which require libv4l > x.y ?

[Mauro Carvalho Chehab]

Em Tue, 7 Jul 2009 15:55:59 +0200
Erik Andrén <erik.andren@gmail.com> escreveu:

> 2009/7/7 Hans de Goede <hdegoede@redhat.com>:
> > Hi All,
> >
> > So recently I've hit 2 issues where kernel side fixes need
> > to go hand in hand with libv4l updates to not cause regressions.
> >
> > First lets discuss the 2 cases:
> > 1) The pac207 driver currently limits the framerate (and thus
> >   the minimum exposure time) because at higher framerate the
> >   cam starts using a higher compression and we could not
> >   decompress this. Thanks to Bertrik Sikken we can now handle
> >   the higher decompression.
> >
> >   So no I really want to enable the higher framerates as those
> >   are needed to make the cam work properly in full daylight.
> >
> >   But if I do this, things will regress for people with an
> >   older libv4l, as that won't be able to decompress the frames
> >
> > 2) Several zc3xxx cams have a timing issue between the bridge and
> >   the sensor (the windows drivers have the same issue) which
> >   makes them do only 320x236 instead of 320x240. Currently
> >   we report their resolution to userspace as 320x240, leading to
> >   a bar of noise at the bottom of the screen.
> >
> >   The fix here obviously is to report the real effective resoltion
> >   to userspace, but this will cause regressions for apps which blindly
> >   assume 320x240 is available (such as skype). The latest libv4l will
> >   make the apps happy again by giving them 320x240 by adding small
> >   black borders.
> >
> >
> > Now I see 2 solutions here:
> >
> > a) Just make the changes, seen from the kernel side these are most
> >   certainly bugfixes. I tend towards this for case 2)
> >
> > b) Come up with an API to tell the libv4l version to the kernel and
> >   make these changes in the drivers conditional on the libv4l version
> >
> >
> Solution b) sounds messy and will probably lead to a lot of error
> prone glue code in the kernel.
> Fast-forward a couple of libv4l releases and you will have a nightmare
> maintainability scenario.
> 
> If people run an old libv4l with a new kernel and run into problem,
> just tell them to upgrade their libv4l version.

(b) seems a very bad hack, IMO. Between the two, I choose (a).

Another alternative would be to make liv4l to check (with querycap) the driver
version and adjust libv4l correspondingly. 

For example, in the example (1), pac207 will default to use the lower
compression rate. A newer libv4l can adjust the pac207 to a higher compression
rate, if running a newer driver that driver supports it.

In the case of (2), I couldn't see what should be the expected behavior.



Cheers,
Mauro

Re: RFC: howto handle driver changes which require libv4l > x.y ?

[Hans de Goede]

Hi,

On 07/07/2009 04:35 PM, Mauro Carvalho Chehab wrote:
> Em Tue, 7 Jul 2009 15:55:59 +0200
> Erik Andrén<erik.andren@gmail.com>  escreveu:
>
>> 2009/7/7 Hans de Goede<hdegoede@redhat.com>:
>>> Hi All,
>>>
>>> So recently I've hit 2 issues where kernel side fixes need
>>> to go hand in hand with libv4l updates to not cause regressions.
>>>
>>> First lets discuss the 2 cases:
>>> 1) The pac207 driver currently limits the framerate (and thus
>>>    the minimum exposure time) because at higher framerate the
>>>    cam starts using a higher compression and we could not
>>>    decompress this. Thanks to Bertrik Sikken we can now handle
>>>    the higher decompression.
>>>
>>>    So no I really want to enable the higher framerates as those
>>>    are needed to make the cam work properly in full daylight.
>>>
>>>    But if I do this, things will regress for people with an
>>>    older libv4l, as that won't be able to decompress the frames
>>>
>>> 2) Several zc3xxx cams have a timing issue between the bridge and
>>>    the sensor (the windows drivers have the same issue) which
>>>    makes them do only 320x236 instead of 320x240. Currently
>>>    we report their resolution to userspace as 320x240, leading to
>>>    a bar of noise at the bottom of the screen.
>>>
>>>    The fix here obviously is to report the real effective resoltion
>>>    to userspace, but this will cause regressions for apps which blindly
>>>    assume 320x240 is available (such as skype). The latest libv4l will
>>>    make the apps happy again by giving them 320x240 by adding small
>>>    black borders.
>>>
>>>
>>> Now I see 2 solutions here:
>>>
>>> a) Just make the changes, seen from the kernel side these are most
>>>    certainly bugfixes. I tend towards this for case 2)
>>>
>>> b) Come up with an API to tell the libv4l version to the kernel and
>>>    make these changes in the drivers conditional on the libv4l version
>>>
>>>
>> Solution b) sounds messy and will probably lead to a lot of error
>> prone glue code in the kernel.
>> Fast-forward a couple of libv4l releases and you will have a nightmare
>> maintainability scenario.
>>
>> If people run an old libv4l with a new kernel and run into problem,
>> just tell them to upgrade their libv4l version.
>
> (b) seems a very bad hack, IMO. Between the two, I choose (a).
>

Ok,

So (a) it is then, I'll do a libv4l-0.6.0 release today. And put the changes
depend upon libv4l-0.6.0 in my tree then as time permits, they will then go
into 2.6.32 eventually which should put enough time between the libv4l release
and the kernel release for most people to have the newer libv4l.

Regards,

Hans