Interlaced modes don't work

[warped-rudi]

Any of the interlaced modes enabled via 7b45e80 (here S:1440x576i-50, S:1440x480i-60, S:1440x576i-50, S:1920x1080i-60 and S:1920x1080i-50) makes my TV screen go blank/blue which indicates a bad input signal.

[linux4kix]

Yes, this patch was accepted and merged into the upstream yocto kernel repo. We are working to sort out the validity of this patch and either drop or fix it.

[mk01]

@warped-rudi

regarding this and http://forum.solid-run.com/cubox-i-hardware-lab-f16/power-but-no-picture-t2798.html#p19769, have you retested with the patches (FSL) added later ?

there is one limitation though, interlaced modes do work ONLY with the timings specified in ./mxc_edid.c (so any DMT modes parsed from EDID do not work - never found why).

[warped-rudi]

I only use code from this repository. Just re-tested and no change. No idea if other patches exist and where to find them. About mxc_edid.c: Do you have any idea why left_margin/right_margin and upper_margin/lower_margin are swapped when comparing progressive and interlaced modes of the same resolution?

[mk01]

@warped-rudi
no, there are no more patches (afaik).

(I assume) swapped values (and this is also why DMT-i modes do not work) is because IPU registers have different meaning for progressive/interlaced signal - and this would be stu*id but fast way.
this would mean wrong videoinfo frames with swapped margins. could be your monitor/tv has issue with it.
I have some other theories - for instance fbdev having support functions not considering vmode (or storing/restoring structures where vmode is lost) or where refresh(Hz) is back calculated from pixclock. the latter case would make for example modes 1920x1080p30 and 1920x1080i60 indistinguishable.

I don't know if wrong infoframe can lead to completely not working mode on output, but try it with swapped margins for interlaced modes - http://sprunge.us/iFba . for me it still works.

[warped-rudi]

I tried quite a lot of things, including your patch. But no avail. When using a PC monitor (Philips 239C4QHSB) instead of the TV, I get some garbled content that shows up for a few seconds, then blanks and comes back again repeatedly. Could it be it's working on DVI only? I'm using HDMI here...

[mk01]

@warped-rudi
and you also have ac17eb1 and b6eaaf2 , do you ?

the Interlaced support is independent of DVI/HDMI, only difference is that in DVI mode it can add modes / timings different from those in mxc_edid::mxc_cea_mode[] .

[warped-rudi]

@mk01
Yes, I'm using c3cae44 (Nov 7 commit). But with a different kernel config...

[mk01]

@warped-rudi
wanted to check with your build, but the geekbox pkg has no interlaced allowed.

[warped-rudi]

Find both - a plain zImage as well as a full kernel package - here. They are of the same version level as the 201512145 snapshot, but allow to select interlaced modes. Normally it should be sufficient to replace zImage...

[warped-rudi]

Looks like I've found the problem. See #32.
BTW, I've started a bigger overhaul of the mode settings stuff here. Currently modes that require double clocking (i.e. 720x480i, 720x576i, 720x240p and 720x288p) do not work and some others (1440x480p) show a few lines from the bottom on the top. But otherwise it seems O.K. Fractional support uses the (n-1) approach. I.e. S:1920x1080p-59 refers to 59.96Hz while S:1920x1080p-60 - as expected - to 60Hz. Note that this is WIP...

[mk01]

@warped-rudi

worked as expected on both TVs (original image you sent).

1440x576i-50
1440x480i-60
1920x1080i-50
1920x1080i-60

only those are supported (reported in EDID)

[mk01]

@warped-rudi

regarding fractional modes - the kernel internally supports them already as is. this was assured by previous commits. only thing missing was/is the 'interface' to user space to trigger them - which is here 9b71359

(there is /sys/class/graphics/fb0/ntsc_mode created, if set to 1, configured modes will have ntsc timing, 0 pal)

[warped-rudi]

@mk01

worked as expected on both TVs (original image you sent)

Obviously some TVs are more forgiving than others. Without #32 I get no picture at all.

only thing missing was/is the 'interface' to user space to trigger them
...
/sys/class/graphics/fb0/ntsc_mode created

Hmm, while this approach requires less messing with the Freescale code, I'm a bit reluctant when it comes to introducing a new userspace APIs and changing common kernel modules. BTW, did you notice that some of the entries in mxc_cea_mode[] already describe the NTSC timings while others do not?

[linux4kix]

Rudi, the fbdev subsystem is dead. We need to figure out what works until
we switch to kms.

On Wed, Dec 30, 2015, 7:46 PM Rudi Ihle notifications@github.com wrote:

@mk01 https://github.com/mk01

worked as expected on both TVs (original image you sent)

Obviously some TVs are more forgiving than others. Without #32
#32 I get no picture at all.

only thing missing was/is the 'interface' to user space to trigger them

...
/sys/class/graphics/fb0/ntsc_mode created

Hmm, while this approach requires less messing with the Freescale code,
I'm a bit reluctant when it comes to introducing a new userspace APIs and
changing common kernel modules. BTW, did you notice that some of the
entries in mxc_cea_mode[] already describe the NTSC timings while others do
not?

—
Reply to this email directly or view it on GitHub
#25 (comment).