Steve Longerbeam writes:
> I think you misunderstood me. Of course there is a first and second
> field. By first I am referring to the first field transmitted, which could
> be top or bottom.
Right. I was thinking the fields are even and odd, but that's not
actually the case (I mean, the
On 06/03/2018 10:25 PM, Krzysztof Hałasa wrote:
Steve Longerbeam writes:
I think we should return to enforcing field order to userspace that
matches field order from the source, which is what I had implemented
previously. I agree with you that we should put off allowing inverting
field
On Mon, 2018-06-04 at 07:25 +0200, Krzysztof Hałasa wrote:
> Steve Longerbeam writes:
>
> > I think we should return to enforcing field order to userspace that
> > matches field order from the source, which is what I had implemented
> > previously. I agree with you that we should put off
Steve Longerbeam writes:
> I think we should return to enforcing field order to userspace that
> matches field order from the source, which is what I had implemented
> previously. I agree with you that we should put off allowing inverting
> field order.
There is no any particular field order at
On 06/01/2018 06:22 AM, Philipp Zabel wrote:
On Thu, 2018-05-31 at 17:30 -0700, Steve Longerbeam wrote:
The output pad's field type was being passed to ipu_csi_init_interface(),
in order to deal with field type 'alternate' at the sink pad, which
is not understood by ipu_csi_init_interface().
On Thu, 2018-05-31 at 17:30 -0700, Steve Longerbeam wrote:
> The output pad's field type was being passed to ipu_csi_init_interface(),
> in order to deal with field type 'alternate' at the sink pad, which
> is not understood by ipu_csi_init_interface().
>
> Remove that code and pass the sink pad
The output pad's field type was being passed to ipu_csi_init_interface(),
in order to deal with field type 'alternate' at the sink pad, which
is not understood by ipu_csi_init_interface().
Remove that code and pass the sink pad field to ipu_csi_init_interface().
The latter function will have to
