On Sat 28/05/11 13:31 , Nick Bane <
nickbane1@gmail.com> wrote:
> Well, we have hardware graphics acceleration available.
And yet, with so little documentation, it's just ballast. Maybe that'll change. It would be nice to think so...
>Without monitor
> output of some sort it is limited to being only an inconvenient
> embedded development system.
Look, I'm not trying to make it impossible to plug a monitor in.
You get composite / S-vid for free. You get networked X and VNC for free.
You get HDMI if you pay for the silicon, and _YOU CAN'T GET IT LICENSED_. (in fact, I'm not sure I'm even meant to buy it without NDAs in place. Data certainly isn't available).
DVI-over-HDMI-socket can be done, at the cost of the DSS pins and something like the TFP410 chip Beagle uses. Hardware-wise, no big deal.
HDMI is not plug-and-play like VGA. It doesn't fall back to defaults, it _requires_ a discussion over the DDC channel. That discussion is fraught, even before you consider the joy of running a 2-metre long i2c bus outside your box.
The Beagleboard manual has some excitingly bright red, ALLCAPS, bold, underlined text, saying (cut&pasted)
"DO NOT PLUG IN THE DVI-D CONNECTOR TO A DISPLAY WITH THE
BEAGLEBAORD POWERED ON. PLUG IN THE CABLE TO THE DISPLAY
AND THEN POWER ON THE BEAGLEBOARD. "
This stuff is _not_ robust. If you want something you can plug in and have it work, the, composite and S-video are the way forward. I've spent too long working for set-top box design companies, watching HDMI being a monumental pain in the arse.
I've surely made my antipathy towards HDMI, and only HDMI, pretty bloody clear by now.
>Why add a camera(s) and not be able to conveniently view
> the output in real time.
My suggestion is that a DVI / HDMI monitor isn't convenient. Nowhere near as convenient as X, VNC, USB magic, composite/SVID or direct LCD panel.
> Is Android predicated on 3D acceleration now?
Yes. Good luck with that...
>I doubt HTML5 codecs / flash plugins perform well over vnc.
They work nicely over X, and pretty reasonably over VNC.
THIS BOARD IS NOT A PC. If we make it a PC, it will be an unsatisfying PC. It will also be a crappy non-PC because of the compromises we'd make in trying.
> I am not making a case for lots of board real estate/power being
> devoted to HDMI, just to make sure we don't option out connectivity that some
> would regard as expected. The form it takes probably doesn't matter and
> off-board is fine if HDMI is needed by a product.
I won't make it impossible to add an HDMI output. The HDMI consortium already makes that the case, for low volume manufacturers (well, not impossible, just ferociously expensive). The signals will be there on a connector. If someone wants to make an HDMI conversion board, I'll be as helpful as possible. I'll even do it. However, that's very much the easy part. The software and compliance side, that's tricky.
> The power issues should be resolved at the Balloon4 derived product
> level (eg Challenger) and not be a design limitation surely.
I wasn't saying that there was a power issue. I was saying that, where you have a TV, you're not scraping round for the last milliwatt, like you are in a battery portable system. (unless you're trying to power yourself off the 50mA, 5V available from the HDMI cable, which, while it'd be cool, is ambitious for an OMAP3.)
> DisplayLink hardware, while remarkably useable, does not survive
> suspend/resume (at the moment in 2.6.38.2) due to taking down USB
> and not re-initialising the device correctly after it is powered up. It is
> not a full solution.
Is that curable, do you reckon?
(Of course, with TVs getting Ethernet sockets and interwebby stuff, we could just, you know, use some kind of networking protocol to display our stuff :)
Steve
(text/plain)