[mythtv] [mythtv-commits] mythtv/master commit: e090e9969 by Mark Kendall (mark-kendall)

[Martin Ellis]

I do mean interconnected physically, CEC is on a dedicated wire on the
HDMI cable, so it allows vendors to at least maintain routing
trivially

This design has been around since the time of SCART via AV.link, it
actually makes a lot of sense, in that it simply just works,
especially if you have a mixture of supported and non support devices
on the network

For instance


TV --- AMP --- Blu-Ray

Where the AMP is not CEC compatible, you can still get the TV to
control the Blu-Ray player without being reliant on having all steps
passing CEC data. Then you get onto things like HDMI Splitters etc and
the problem would just get worse and worse

I am personally comfortable with the way CEC was developed, regardless
of how it you might like it, that is the standard, its been widely
adopted by the A/V industry and we have to work within those bounds :)

On Sat, Nov 12, 2011 at 11:13 AM, James Courtier-Dutton
<james.dutton at gmail.com> wrote:
> On 12 November 2011 10:55, Martin Ellis <malard at gmail.com> wrote:
>> Sorry it's late, but the reason for GPU vendors not including this
>> because of the minefield of support issues with the CEC protocol and
>> standard,
>>
>> First thing, the CEC bus is a serial bus, all HDMI ports supporting
>> CEC must be interconnected, this is easy to achieve and comply with on
>> boards with embedded graphics and no expansion slot, but then how do
>> you connect an embeded graphics card CEC wire to an external graphics
>> CEC (i.e. via a USB - HDMI adapter) or via the PCI-Express slot.
>>
>> Intel have already launched a board that exposes the CEC pin directly
>> on their board, and we are building a daughter card for that slot,
>> they are soon to release another, it is hoped other vendors will pick
>> up this HTPC Header and more widespread support will become available.
>>
>> With Intel exposing the CEC wire, it proves they are aware of it and
>> had the opportunity to do something with it directly on the board, but
>> also shows their unwillingness to jump into that boat.
>>
>> My view on why this is the case is fairly simple. If you advertise a
>> motherboard that is 100 euros as supporting CEC, and then the customer
>> purchasing that board connects it to an old TV that claims CEC support
>> but in fact its support is non standard, or even on modern TVs which
>> do support the standard v1.3 spec, but then extend it with custom
>> commands and then that customer finds they don't get the interactivity
>> they wanted, they have reason to return the board as faulty.
>>
>> That's an expensive return for what in reality is no fault of the
>> Intel. It's far more sensible to expose the header, and then get a
>> company like us (Pulse-Eight) to take up that fight.
>>
>> P.S Thanks for adding support, if any mythtv developers need or want
>> an adapter, please email support at pulse-eight.com and we will set you
>> up with a discount code.
>>
>> Thanks
>>
>> Martin
>>
>
> It sounds to me that this is therefore a faulty design.
> "First thing, the CEC bus is a serial bus, all HDMI ports supporting
> CEC must be interconnected,"
>
> If you mean interconnected physically, then this leaves it wide open
> to compatibility problems.
> If the CEC was just over the HDMI cable point-tp-point, and then it
> left each device to do CEC message re-transmission in software to
> other HDMI ports, you could at least have software to fix
> incompatibility issues. I.e. When talking to TV X, use this quirk,
> when talking to TV Y, use a different quirk.
> This would also permit the software to filter out messages it did not
> want passed on.
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://www.mythtv.org/mailman/listinfo/mythtv-dev
>