Interlaced modes don't work

[warped-rudi]

Any of the interlaced modes enabled via 7b45e808bbdcbad05fd862d1c532a17a814ea44c (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 ac17eb11699d9bb27a99db2ffc120a12a67b8a33 and b6eaaf23eea84f19f3866f09e187834c5d7d8242 , 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 c3cae448b862d6bc21acbfa1f935ea3650ea7ac3 (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 9b7135930eddede6380c207bcd2ba43af746f8a1

(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 https://github.com/SolidRun/linux-fslc/pull/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 https://github.com/SolidRun/linux-fslc/issues/25#issuecomment-168054168.

[mk01]

@warped-rudi

https://github.com/SolidRun/linux-fslc/pull/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 https://github.com/xbianonpi/xbian-sources-kernel/commit/14a3f90465af428c8fe9843606eac19412ba56eb .

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

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