On 12/14/16, Benson Mitchell benson.mitchell+arm-netbook@gmail.com wrote:
Glad we're on the same page.
:)
On Wed, Dec 14, 2016 at 5:36 AM, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
- type II 5.0mm cards may expect housings to provide "upscaling"
support for resolutions beyond 1366x768, a notification of the full list of available resolutions in the I2C EEPROM (in the form of DDC data) and, hmmm.... we'll need some form of auto-detection or standards-compliant means and method of communicating the desired resolution. hmmm....
I finally found the documentation for display-timings in devicetree. As I suspected, it already supports an arbitrary number of modes, and specifying one of them as native/preferred.
ah. rrright. okay. two things:
(1) the way it's going to have to work is: you read the EOMA68 I2C EEPROM @ addr 0x51, get the housing "id", and from there *decide which dtb fragments to load*. there's a patch related to beagleboards and so on which is being worked on that allows numbered pointer-references in devicetree to be replaced with arbitrary pre-compiled binary dtb fragments.
(2) getting the various settings isn't the problem (load DDC data over I2C like you would from any VESA-compliant monitor), picking the preferred one according to the devicetree specification isn't the problem, it's *TELLING* the hardware which one *HAS* been picked that's the problem.
now, if this was HDMI, it would not be a problem. HDMI: auto-detection is part of tthe protocol. VGA? not a problem (at least with modern monitors) - auto-detection can be designed in. but RGB/TTL? naah. there's absolutely no meta-data.
even in instances where LCDs contain DDC data, it's often completely and utterly wrong, so you have to use it as a "guide", experiment, then completely ignore it and hard-code the values that *WORKED* into the linux kernel source / dts.
now you have two possible (or potentially even more) resolutions to pick from... how the hell do you tell the IC (whatever it is) which one to use?
no idea - so that needs to be resolved, first, before the EOMA68 standard is to be augmented.
i'm not going to put something into the standard which hasn't at least been thoroughly researched.
l.