[MPlayer-dev-eng] [PATCH] Fix regression in v4l2 channel tuning on cx88 cards

[Jon Doe]

On Sat, Jun 9, 2012 at 12:42 PM, Reimar Döffinger
<Reimar.Doeffinger at gmx.de> wrote:
> On Sat, Jun 09, 2012 at 12:07:30PM +0200, Jon Doe wrote:
>> Can someone have a look at this? It's been bugging me for 4 years.
>> Used to work perfectly.
>
> One problem with the patch is that you are changing the behaviour
> for all tv:// protocols, not just v4l.
> I guess some of them could require the norm to be set every time.
> However the most obvious question is: Why not move exactly this code
> into the driver?
> Why should each single application have to duplicate the "do nothing
> when the new norm is the same as the old one" when the driver can
> do it trivially and probably more reliably for all of them?
> It probably could even be done in the common v4l layer.
> Another thing is that the patch does not fix what might
> be considered the real bug:
> it does not set the picture size at the right point it seems
> and neither does it even realize that it changed.
>
>> > The problem is that cx88 based cards will reset the picture size to
>> > 320x240 when changing norms, squashing the picture to a quarter size
>> > in the top left corner when changing channels in mplayer. The cx8800
>> > driver needs to reset the picture size due to a hardware filter
>> > recalculation requirement when changing norms. Others have also
>> > noticed this problem in the driver, but no comprehensive fix was found
>> > - see http://www.mail-archive.com/linux-media@vger.kernel.org/msg00157.html
>
> Besides what I mentioned above, that it could just do nothing at all
> when switching to the norm that is already selected, there is also
> the obvious question why the driver thinks it a good idea to switch
> to the minimum available size per default.
> _______________________________________________
> MPlayer-dev-eng mailing list
> MPlayer-dev-eng at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng

My thoughts on this:

1). The "do nothing on norm change to same norm" code should not be in
the kernel. Kernel should not contain policy. If user space asks for
the norm to be set, the norm should be set irrespective.

2). If the mplayer config file does not specify the norm, the norm
should not be set for each channel. Effectively the code is doing
something the user did not ask for.

3). I agree that the cx88 driver should be fixed. The problem is that
the pixel dimensions are stored in the cx8800 video structure and the
cx8800 core code (set_norm) does not have access to the cx8800 video
structure. So it's reset to 320x240. One of the proposed fixes was to
call set_norm with the current pixel dimensions as function
parameters.

4). Does the v4l spec even allow for setting the norm while a capture
is in progress? Should mplayer not restart capture on channel tuning?
For instance, would it be possible to set different aspect ratios for
different channels without restarting capture? On the other hand,
restarting capture would probably slow down channel tuning.