On Tue, Dec 13, 2016 at 8:55 PM, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
On 12/14/16, Benson Mitchell benson.mitchell+arm-netbook@gmail.com wrote:
On Tue, Dec 13, 2016 at 9:51 AM, dumblob dumblob@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