[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:
> On Tue, Dec 13, 2016 at 8:55 PM, Luke Kenneth Casson Leighton
> <lkcl at lkcl.net> wrote:

>>  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.

 wheels turn a bit slowly in my head at the moment... :)  *click* yes
you're right.

> 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?

 ah.... ah.... oo!  as long as the housing was absolutely guaranteed
to work at 1366x768 *and* 1920x1080... you're absolutely right, it
would be fine!

>>  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.

 these days most of them are actually custom full processors (you
remember that vulnerability report recently about LCDs being hackable
over their HDMI interfacee?)  the framebuffer is so large -
1920x1080x8x4 = 64mb (!!)

> 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:

 ... remember there's two cases (at the moment) where up to 1920x1080
is supported by 3.3mm cards and housings, and up to 1366x768 is
supported by 5mm cards and housings.  what you're proposing below is
incomplete but i get the general idea

> 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.

 baaad.

> 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.

 blegh.

> 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.

 better.

> 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?

 no, you've come up with a really good suggestion (thanks to the OP
for the question and the discussion opportunity).

 it's a hell of an extra technical cost - to have a full custom
ASIC/processor and some DDR2/3 RAM to do the upscaling.... but if
that's what it takes - and it's not unreasonable - then that's what it
takes.

 ha.

 okay.

 so we have, in the resolution department:

 * type II 5.0 mm cards may expect up to 1366x768 as guaranteed and
given "native" resolution(s)

 * type I 3mm mm cards may expect up to 1920x1080 as guaranteed and
given "native" resolution(s)

 * 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....

 and in the power-provision department:

 * all housings MUST supply up to 5.0 watts

 * all housings MAY indicate in the I2C EEPROM that they have the
capability to extract sufficient heat away from the card in order to
support up to 10.0 watts.  that'll probably involve a fan in the
housing, pointing directly at the Card casework.

 oo this is actually quite exciting.

l.