Interlaced output to progressive-only display?


#1

Hi all,

Got a small problem - I’ve a Vero 4K+ going via an Onkyo TR686 AVR to an old Sharp Aquos LCD panel, that only accepts 1080p@60Hz I think (as it has an external box for regular connections, but I’m connecting to the panel direct, not via its external box, as the external box doesn’t support 1080p but the panel does). This has worked fine for some months with the 4K+, and a while back I used a command from here Force resolution? to force the 4K+ to start in 1080p rather than going via 720p since 720p didn’t work. That all worked great.

Yesterday, I started getting a problem where the 4K+ would select 1080i for some reason - which displays as one shallow screen above the other - presumably because the TV is reading it as 1080p.

I’ve compared syslogs between a working and not-working startup, but whilst I can see differences, I can’t work out why they’re happening. I don’t think I’d changed anything. I tried the force resolution command again from the above post (this time choosing 1080p60hzforce rather than just 1080p60hz) - but no luck.

Logs are here https://paste.osmc.tv/abogucaxoy - I’d be most grateful for any suggestions!

Thanks in advance,
John


#2

Try this

cp /sys/class/amhdmitx/amhdmitx0/disp_cap ~/.kodi/userdata/
chmod +w ~/.kodi/userdata/disp_cap

Edit the file with

nano ~/.kodi/userdata/disp_cap

It will look like this

480p60hz
576p50hz
720p60hz
1080i60hz
1080i50hz

add the progressive modes (change the 'i’s to 'p’s)

480p60hz
576p50hz
720p60hz 
1080i60hz
1080i50hz
1080p24hz
1080p25hz
1080p30hz
1080p60hz
1080p50hz

Save the file and restart Kodi (Power->Exit).

If it doesn’t work, please post logs again.


#3

Thanks very much! For the sake of others, it seems I needed sudo to get to that file:

osmc@o1mc:~$ cp /sys/class/amhdmitx/amhdmitx0/disp_cap ~/.kodi/userdata/
cp: cannot create regular file ‘/home/osmc/.kodi/userdata/disp_cap’: Permission denied
osmc@o1mc:~$ sudo cp /sys/class/amhdmitx/amhdmitx0/disp_cap ~/.kodi/userdata/
osmc@o1mc:~$ chown osmc.osmc !$
chown osmc.osmc ~/.kodi/userdata/
osmc@o1mc:~$ chmod +w ~/.kodi/userdata/disp_cap
osmc@o1mc:~$ vi !$
vi ~/.kodi/userdata/disp_cap

I tried both your file, and just adding 1080p60hz since I believe that’s the only resolution/frequency my panel supports - but neither appeared to help.

New logs are here https://paste.osmc.tv/imararofub

Thanks again for your help.


#4

So what happens when you go to settings and try to select 1080p? (assuming you have enough of a picture to do this!)

Or what happens if you stop kodi, change the line in guisettings.xml like this

    <screenmode>00192001080060.00000pstd</screenmode>

and restart kodi?

Reason: I can’t see in the logs where an attempt is made to set 1080p which is failing.

Edit: 1080p could be failing because your EDID says 80MHz clock which is not enough. Are you sure you got 1080p60hz before or could it have been 1080p30hz?

Edit2: you shouldn’t need sudo to cat or cp disp_cap. Something wrong with your permissions in .kodi?


#5

Good question :slight_smile:
Previously when I went to Settings|System|Display, there was no 1080p option. Now (presumably thanks to your changes) there is - and selecting it expands the picture back to normal.
And when I reboot… it comes up correctly. I’m pretty certain it was at 60Hz before - he’s the latest post-reboot logs (run through grep -v -e /mnt/video/movies/… -e /mnt/video/short/… -e /mnt/music/…) for reference:
https://paste.osmc.tv/wonovoteso

Re disp_cap - curious. I log in via another account, then ran ‘sudo -iu osmc’, and then the commands you see. If I remove your ~/.kodi/userdata/disp_cap file, it fails - but whittling it down to just one line, 1080p60hz, everything works.

In case it’s of interest, here’s a syslog segment from a month ago, when it worked without disp_cap:
https://paste.osmc.tv/huyoweriyo
and here’s another from today, when it failed (with times removed for easier diffing)
https://paste.osmc.tv/xiqisajoku
And in case it’s of interest - here’s the same thing with your disp_cap file:
https://paste.osmc.tv/xaseyivipa

My only guess is that the monitor or AVR is for some reason sending different monitor (EDID?) info??

I’m curious what’s changed given I’ve not upgraded software for several weeks, but if the disp_cap file is required for my (kind of unusual, 1080p60hz only) system to work - so be it - and thank you very much!


#6

Thanks for all that. The EDID from the month ago log is that of the AVR alone. It contains only 1080p60hz. Now in October, we added a re-scan of the EDID on any HDMI hot-plug event so by rights it should have been failing then. With your weird screen it wouldn’t surprise me if was not sending hot-plug events (eg when you turn it on).

You updated on 1 Jan which again should have shaken things up, so I don’t know why it hasn’t surfaced until now.

But it’s been an interesting corner case!


#7

To explain my screen a bit more… (which I really should replace, except it still, usually, works and I don’t like making rubbish unnecessarily) - it was the first 1080p LCD TV I could find, back in 2003, and I pre-ordered it 6 months before even the manual was available. I knew it had a DVI port (on its external box), and I assumed that would support 1080p given it was a 1080p panel - but when I finally got it, it didn’t! I was livid (as it wasn’t cheap). But the wonderful internet said that the link between the external-box and panel was just 1080p DVI - all good! EXCEPT - that if you just connect to the panel like that, bypassing the external box - it turns off after about 15 minutes. To prevent that - you have to ensure that when the panel is turned on, it’s connected to its external box (via an HDMI (or DVI) switch say) - wait about 10 seconds for… some kind of handshake(?) - and then you can switch in another 1080p source direct to the panel, and all will work fine. Hence I’ve a Harmony Remote to manage the complicated startup process (and a very understanding wife).
I’ve no idea if that handshake is relevant to anything - and given the panel is only meant to connect to its own known box it no doubt skips most protocol niceties.
But thanks to awesome support from your good self it lives to entertain another day! (despite two five-year-olds being most unimpressed that it didn’t work today!)
Cheers!!
John