[Arm-netbook] MIPI DSI instead of RGB/TTL - the only way out of the blind alley
benson.mitchell+arm-netbook at gmail.com
Wed Dec 14 03:32:51 GMT 2016
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
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?
More information about the arm-netbook