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).

[mk01]

@warped-rudi

#32 improved displaying text.

ad the timings - yes, I have seen your commits. Mine TVs do not list those modes as supported so I never realised the timings are wrong. But they all work (as I tested now).
The changes on PS clk are OK, but 1440x240. You changed the clock to "correct" 27000kHz, but with this mode and clk the timing is 59.940. 60 is with 37070ps.

ad fract - initially I had implemented similar as you did. Only I didn't use '59', but lowercase letter -

s:1920x1080p-24 - was 23.967 

don't have the backport to 3.14 anymore but it can be seen here before this commit xbianonpi/xbian-sources-kernel@14a3f90 .

it's breakage of vanilla code was just single line added to fbsys.c.
btw: in Kodi I kept support of both xbianonpi/xbian-sources-xbmc@a8ca74e

For more reasons I liked the cloning of modes (as fract) more, as without touching fbdev at all everything was transparent trough fbdev chain. @jnettlet's wish was a PAL/NTSC switch (as per KMS way).

[warped-rudi]

@mk01
According to the CEA table 1440x240p (vic 8 and 9) should use 27027kHz for 60Hz and 27000kHz for 59.94Hz. That's what I do. Interestingly, both 22 or 23 vertical blanking lines are allowed (we use 22) and there is always a deviation from the ideal refresh rate. The same applies to 2880x240p (vic 12 and 13), which we do not implement. However, at the moment none of the x240p, x288p, x480i and x576i modes work. They require double clocking which is not set up. I'm unsure how much effort to spend on that. Looks like it needs more work than just specifying the proper output repeat rate to the packetizer. If it gets too complicated, I would tend to disable these modes...

ad fract - initially I had implemented similar as you did. Only I didn't use '59', but lowercase letter -

Hmm, not much different, indeed. The only thing that could happen is that some really stupid program might get crazy about the unexpected letter.

[tomlohave]

Pull request #32 fixes my problem