Re: libv4l: Possibility of changing the current pixelformat on the fly

["Erik Andrén" <erik.andren@gmail.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Hans de Goede wrote:
> On 04/05/2009 01:26 PM, Erik Andrén wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>>
>> Hans de Goede wrote:
>>> On 04/04/2009 10:22 PM, Erik Andrén wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> Hi,
>>>>
>>>> While trying to get hflip and vflip working for the stv06xx webcam
>>>> bridge coupled to the vv6410 sensor I've come across the following
>>>> problem.
>>>>
>>>> When flipping the image horizontally, vertically or both, the sensor
>>>> pixel ordering changes. In the m5602 driver I was able to compensate
>>>> for this in the bridge code. In the stv06xx I don't have this
>>>> option. One way of solving this problem is by changing the
>>>> pixelformat on the fly, i. e V4L2_PIX_FMT_SGRB8 is the normal
>>>> format. When a vertical flip is required, change the format to
>>>> V4L2_SBGGR8.
>>>>
>>>> My current understanding of libv4l is that it probes the pixelformat
>>>>     upon device open. In order for this to work we would need either
>>>> poll the current pixelformat regularly or implement some kind of
>>>> notification mechanism upon a flipping request.
>>>>
>>>> What do you think is this the right way to go or is there another
>>>> alternative.
>>>>
>>> The changing of the pixelformat only happens when you flip the data
>>> before conversion. If you look at the current upside down handling
>>> code you will see it does the rotate 180 degrees after conversion.
>>>
>>> This is how the vflip / hflip should be handled too. We only have
>>> 4 (2 really since we don't care about r versus b / u versus v while
>>> flippiing) destination formats for which we then need to write flipping
>>> code. Otherwise we need to write flipping code for *all* supported input
>>> formats, not to mention flipping some input formats is close to
>>> impossible
>>> (JPEG for example).
>>>
>>
>> So you mean we should do the vflip/hflip in software, just exposing
>> one native format?
>>
> 
> Erm, yes that is what I was saying, but that is because I was confusing
> things with the sq905 driver some other people are working on.
> 

Glad that you were confused as I couldn't really make out the
meaning of your answer. :)

> Now I understand what you were trying to ask. So the problem is that
> the vv6410 sensor can do flipping in hardware, and then the order in
> which it sends out the pixels changes from gbgbgb (for example)
> to bgbgbg, for the lines which have blue, effectively changing the
> pixelformat, right?

Correct.

> 
> In that case I think the only solution is to simply return -EBUSY when
> the vflip / hflip controls are changed while a stream is active.
> 

So this effectively forces a reprobe of the hardware?

> As for the race window with one application querying the format (or even
> setting it) and then another app changing the flip before the application
> which just set the format starts the stream, we already have that wrt 2
> applications doing this:
> app a: setformat x
> app b: setformat y
> app a: start stream (thinking format is x)
> 
> Which is something which normally (luckily) never happens.
> 

If this ever becomes a real issue, shouldn't some kind of user-space
master program aquire the device and then handle format requests for
all client programs?

> Does that sound like a plan ?
> 

Yes, I'll try this ASAP.

> Note that this is a solution at the driver level, which IMHO is the only
> way as we cannot assume libv4l is always being used.
> 

If it works this sounds like the most clean and elegant solution.
The weak point being that the application must try to renegotiate
the format upon the -EBUSY signal.

Thanks for the help!

Regards,
Erik


> Regards,
> 
> Hans
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAknYqtwACgkQN7qBt+4UG0FBgACggwgmVfMKj2bQAj/UVSL/vHSH
Ss0Anj/8xoRpXiIzBg3HdtDa0SXK6WK2
=yIxz
-----END PGP SIGNATURE-----