Sorry 1audio, should have been more specific, I meant at the data link layer - that is completely standardised... it has to be because that defines the positioning inside the multiplexed channels so that the channel can be read (or ignored as the case maybe!) - at the higher layers I have no idea how things are going (the actual content of the channel), but it doesn't surprise me to hear you say that there isn't anything yet, or the reasons you give for that!
Either way, it doesn't change the original thrust of what I was getting at. As long as the HDMI driver allows you access to (meaning multiplexes and demultiplexes that channel - raw) the CEC, theoretically you could control anything you like by layering an implementation of the TV specific application/presentation layer over the top. Hardly ideal from a standardisation point of view, but in principle at least, no different than setting up other custom devices such as 232... all that is still dependent on my other comment about DCERouter allowing this driver to be used to send/receive messages like any other device ... I'm assuming that DCERouter implements the same for 232 with a soft Ethernet->Com port bridge? Is that how it works, or is it more agnostic on the device interface (not limited to Ether)?
