On Mar 1, 2018, at 20:40, Luke Kenneth Casson Leighton <l...@lkcl.net> wrote:
> On Thu, Mar 1, 2018 at 10:42 PM, Richard Wilbur
> <richard.wil...@gmail.com> wrote:
>> Luke, have you tested the D/A circuit on the micro-desktop board?
> yep it works great up to 1024x768.  i haven't yet been able to get it
> to sync at anything greater than that, because you have to manually
> convert the signals into A20 timings... and of course if you can't
> read the EDID data you don't know *exactly* what the settings are in
> the first place for any given monitor.
> 1024x768, being a common VESA standard, has worked consistently on
> every monitor i've tried.

So if we could read the EDID the driver would figure out the A20 timings?  Does 
the A20 already have a graphics driver capable of that?  (In which case the 
bit-banging VESA DDC driver becomes very important.)  How much of this 
infrastructure already exists?  I'm bringing my tools, where do we start 

I have a collection of VGA monitors with different aspect ratios and sizes (3 
CRT and 3 LCD).  I'd be happy to test resolutions above and below 1024x768.

>> Only thing I would worry about is the hold time on the data lines.  If
>> the A20 sets up the data quickly (relative to the pixel time) and
>> holds it until the next setup, we should be in good shape.
> sigh yeah i thought about that... using buffer ICs with a "hold", and
> linking up the clock line to it.... never got round to it.  i'd prefer
> to just skip the entire circuit and use a TFP410 (or maybe it's a
> TFP401a), or a Chrontel RGB/TTL to VGA converter IC.  CH7036 i think
> it is.

Are you thinking of octal D flip-flops?  I'll have to look up those datasheets. 
 What do those chips offer over the flip-flops?  How do the prices compare?

> yyup.  exactly.  remember, you can't do more than one interface on
> any given set of pins, so i had to pick one (RGB/TTL or LVDS or MIPI
> or eDP), that then means you have to have a conversion IC in-place on
> the Card if a particular SoC doesn't *have* that interface... and many
> of the lower-cost SoCs don't because they're not part of the MIPI or
> DisplayPort cartel(s)....

Yes, that's the awful thing about so many industry standards:  you can't get 
the text without signing documents and paying a handsome price, you can't use 
them without paying royalties to the patent owners.

> ... and even if you had LVDS, the cost on the other side (Housing
> side) of having an LVDS-to-RGB/TTL converter is so high relative to
> the cost of the LCD itself that companies would rebel and not bother
> with the standard at all.
> so, bizarrely, RGB/TTL, by being both "free" and also unencumbered by
> patents *and* by being lowest-common-denominator, wins out on all
> fronts.  except for the fact that you need a 125mhz clock-rate for
> 1920x1080@60fps, which is a bit... high.  but hey.

Will the A20 clock the RGBTTL interface that high?
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
Send large attachments to arm-netb...@files.phcomp.co.uk

Reply via email to