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

[Benson Mitchell]

On Tue, Dec 13, 2016 at 8:55 PM, Luke Kenneth Casson Leighton
<lkcl at lkcl.net> wrote:
>
> On 12/14/16, Benson Mitchell <benson.mitchell+arm-netbook at gmail.com> wrote:
> > On Tue, Dec 13, 2016 at 9:51 AM, dumblob <dumblob at gmail.com> wrote:
> >> Can we provide both interfaces (RGB/TTL + MIPI DSI) on the same pins while
> >> having a HW way to choose from these?
> >>
> >> Yes we can! EOMA already counts on several types of PC Cards (originally
> >> called PCMCIA). At minimum two - thinner (Type I - 3.3 mm) and thicker
> >> (Type
> >> II - 5 mm). Let's declare the thicker cards to be high-end and offer only
> >> MIPI DSI while thinner cards low-end with just RGB/TTL. Problem solved!
> > To be specific, EOMA68 includes Type I, Type II and Type III already. There
> > are differences in permitted power, and RGB resolution. These differences
> > run in opposite directions, in order to make sure that any combination that
> > fits will work.
> >
> > WRT resolution, Type I is the high-end, with card-minimum/housing-maximum
> > 1920x1080, because a Type I housing will accept _only_ Type I cards. Thus
> > anything with a 1920x1080 screen has a Type I slot, and any card that
> > physically fits will drive that display.
>
>  nooo, 5.0mm is the 1366x768 because the 5.0mm needs to be prevented
> and prohibited from being physically inserted into incompatible 3.3mm
> (1920x1080) slots.
I think we're failing to communicate here. Type I is 3.3mm, Type II is
5.0mm. As far as I can tell, we're saying the same thing so far.

> > (AIUI, a Type II housing can have a 1920x1080 display, as long as that
> > display will accept and upscale a 1366x768 signal.
>
>  NO.  absolutely not.  that is a completely unacceptable technical
> burden on the manufacturers of the housings, forcing them to have
> additional circuitry which may or may not be used.... and may or may
> not be actually available on the open market.... and may actually end
> up being far more costly than the processor utilised in the Card.
I'm _not_ saying to require it, I'm saying I thought a housing _can_ have
it. There's no "forcing" them to, and I get that it makes no economic sense
in almost all cases. But _if_ a particular manufacturer wants to make a
particular housing with a high-resolution display, built-in upscaler, and
Type II (5.0mm) slot, that's not a problem, is it?

>  any kind of resolution scaling at these framerates and buffer sizes
> it actually needs a full processor - with several hundred megabytes of
> DDR2 / DDR3 RAM - to perform the conversion.
Or ASICs, such as are in most ordinary LCD monitors and TVs.

The specific application I was thinking of is "Smart TV": a 1080p TV (or
projector) with an EOMA68 slot in the side of it. It should already be able
to handle 1080p, 720p, and other resolutions from the DVI/VGA/etc. inputs,
so for little additional cost, it could handle both 1366x768 and 1920x1080,
from either Type II or Type I cards respectively.

The options I see are:
A Support _only_ 1920x1080 from EOMA68, and have a Type I 3.3mm slot; anyone
  with a spare Type II card can't run a lower resolution, but has to buy a
  new card.
B Support _only_ 1366x768 from EOMA68, and have a Type II 5.0mm slot; anyone
  with a spare Type I card can use it, but has to live with the lower
  resolution and upscaling artifacts, even though their card can do better.
C Support 1366x768 and 1920x1080, and have a Type II 5.0mm slot; anyone with
  a spare Type II card can use it with upscaling, while anyone with a Type I
  card can use it at full resolution.

Are you saying the _only_ ways for such a "Smart TV" to be EOMA68 compliant
are options A and B, and there's no way to do option C?

If so, can you help me understand why?

I know EOMA68 actually uses device-tree files rather than DDC like a VGA or
DVI connection, but it just seems like it should be easy to do the
conceptual equivalent of DDC -- the monitor (EOMA68: housing) sends a list
of modes, the PC (EOMA68: CPU card) picks the largest one it can handle, and
you're done. For single-resolution housings, the list has one entry. If it
can't/doesn't work this way... why not?

Benson Mitchell