[AML] read display modes optionally from file

[peak3d]

[AML] read display modes optionally from file

Description

AML often looses the settings in /sys/class/amhdmitx/amhdmitx0/disp_cap.
In case of failure they are either empty or contain only 720p and 1080p (on my odroid)
This PR looks first for the existance of a file, if present it uses the values in there, otherwise the information is used from /sys/class/amhdmitx/amhdmitx0/disp_cap

Motivation and Context

1.) Loosing EDID information is annoying because no framerate adjustment occurs
2.) My EDID information does not contain 24hz, Using this file let me force the monitor to it.

Types of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

[codesnake]

@peak3d In your case does the monitor provide wrong EDID, or just AML kernel interprets it incorrectly?

[peak3d]

@codesnake from syslog its wrong EDID (parse errors) and it leads to a 2 liner (720p + 1080p).
If the EDID can be parsed correctly (~10 lines), the 24HZ are missing / not available.

I know that it could be an issue of cable, but sometimes I start device with monitor off. This leads to missing modes as well. With the file I'm happy now :-)

Pls refer to this discussion here:

6c48936

[codesnake]

I just mean that if this is an HDMI driver issue, then it should be fixed there, not in Kodi. If you start your device with monitor off, the driver should (and it is) read the EDID when you turn on the monitor.

[peak3d]

I don't know what kind of issue it is, but regarding the other PR it seems to be an issue I'm not alone with.
Beside this: I need the 24Hz for testing.

This PR is not a fix of anything, beside the fact that I (and others) have issues with EDID and / or missing modes its a feature PR here.

[fritsch]

+1 Am 13.12.2016 12:58 nachm. schrieb "Markus Pfau" <notifications@github.com>:

…

I don't know what kind of issue it is, but regarding the other PR it seems to be an issue I'm not alone with. Beside this: I need the 24Hz for testing. This PR is not a fix of anything, beside the fact that I (and others) have issues with EDID and / or missing modes its a feature PR here. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#11159 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABCfHYAbCjPDL0MtKR-qwvLHh6S96gLSks5rHohggaJpZM4LLnJ-> .

[fritsch]

Btw. concerning "in kernel" fixes I nominate those two: https://github.com/LibreELEC/LibreELEC.tv/blob/master/projects/WeTek_Play/patches/kodi/0001-aml-Fix-ALSA-sound-output-for-Amlogic-based-devices.patch (kernel driver should just do the maths)

or that one: https://github.com/LibreELEC/LibreELEC.tv/blob/master/projects/WeTek_Play/patches/kodi/0004-aml-Fill-audio-packets-completely-when-resampling-to.patch - why should user space care for improper number of data packets?

[stefansaraev]

sorry for jumping in, but at least https://github.com/LibreELEC/LibreELEC.tv/blob/master/projects/WeTek_Play/patches/kodi/0004-aml-Fill-audio-packets-completely-when-resampling-to.patch is not needed anymore for aml 3.14 (EDIT: LibreELEC, that's what I use) kernel

[codesnake]

@fritsch That's why I never PRed the above mentioned patches upstream, because they are just workarounds, not real fixes.

[peak3d]

@codesnake @fritsch I'll revert this PR soon and will allow additional modes be set in the advanced_settings.xml file. The settings in advanced..... are merged to the modes read from disp_cap.