[Arm-netbook] MIPI DSI instead of RGB/TTL - the only way out of the blind alley

[Luke Kenneth Casson Leighton]

On 12/14/16, Benson Mitchell <benson.mitchell+arm-netbook at gmail.com> wrote:
> Glad we're on the same page.

 :)

> On Wed, Dec 14, 2016 at 5:36 AM, Luke Kenneth Casson Leighton
> <lkcl at 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.