[Arm-netbook] motherboard negotiation

[jonsmirl at gmail.com]

On Fri, Jan 13, 2012 at 3:53 PM, lkcl luke <luke.leighton at gmail.com> wrote:
> On Fri, Jan 13, 2012 at 8:42 PM, jonsmirl at gmail.com <jonsmirl at gmail.com> wrote:
>
>> There is no good solution to the LCD problem, they are simply way too
>> many variations. I suspect that you'll end up with at most two or
>> three different LCDs interfaced to the EOMA board.
>
>  nope - no can do: inflexibility is failure.  failure is not an
> option.  this project has to cope with 320x240 all the way up to
> 1900x1200.
>
>  we'll start _off_ small, just to make it manageable (2 or 3 different
> LCDs), but not dealing with this isn't an option.
>
>
>> You also have to deal with the fact that different CPU LCD controllers
>> have different capabilities. You may make a baseboard for an LCD that
>> a future CPU does not have the ability to control.
>
>  that would surprise me greatly.  *thinks*.... actually it wouldn't,
> no you're right (forgot about a couple of cases)  i know for example
> that the S5PV210 and S5PC110 can only cope with 1024x768 - if you try
> to push them to 1388x768 (like hardkernel.com did) then not only do
> you lose 2 pixels at either edge (because the internal memory buffer
> is only 1mb) but the quality is pretty dreadful, too.

There is much more to this than resolution. LCDs come with various
interfaces: 6800, 8080, SPI, RGB, different types of signaling levels,
etc. They have multiple ways of setting them up: SPI, I2C, in-band,
registers, etc. Each one sets up differently. Even more basic: where
is the framebuffer - in the LCD or in the host? Backlight
control/power? There is no such thing as a generic LCD interface. That
why there is a different driver for each one in the kernel. There is
little to no standardization in LCDs.

You can plug and play VGA, HDMI, component, SD. But you can't do that
with embedded LCDs.

>  under these circumstances we just have to say "Tough: Uncertified Combination".
>
>
>> Plus what about touch?  4-wire, 5-wire, capacitive, etc...
>
>  outside of scope of EOMA: i.e. not our problem [*1].  external I2C or
> USB chipsets on motherboard, or even running entirely in software on
> an STM32F or other embedded R/T CPU.
>
>  l.
>
> [*1] except in the case of expansion headers such as putting the
> 4-wire TS controller of the A10 onto expansion-1, and even then it's
> _still_ not our problem because it's outside of the scope of EOMA.
>
> _______________________________________________
> arm-netbook mailing list arm-netbook at lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netbook at files.phcomp.co.uk



-- 
Jon Smirl
jonsmirl at gmail.com