It seems that libcec doesn't allow to implement an ARC device.
It doesn't support opcode 0xC[012345] nor does it allow to set the audio status or short audio descriptor from the API.
Moreover, I cannot implement that manually because there is no way to tell libcec that the command callback handled the command that that it should not be handled internally.
For example, if I want to answer to "RequestARCInitiated" (0xC3) with "InitiateARC" (0xC1), libcec will still send "unrecognized opcode" after my reply and also to the initial "RequestARCInitiated" message.
Possible fix 1
A simple fix would be to update the API to allow the command callback to return true or false if the command has been handled or not.
Currently, the command will be sent to the callback and the CECCommandHandler will respond to the command anyway. Unfortunately this would break all existing apps that rely on this callback.
Possible fix 2
A new commandHandler callback can be created so that applications can handle themselves CEC commands and return true/false if the command has been handled and should be ignored by the CECCommandHandler.
Possible fix 3
Another option is to fully implement ARC support in libCEC.
I can work on any of those options. IMHO option 2 is the best one at this time as it will provide additional flexibility.
Problem :
It seems that libcec doesn't allow to implement an ARC device. It doesn't support opcode 0xC[012345] nor does it allow to set the audio status or short audio descriptor from the API.
Moreover, I cannot implement that manually because there is no way to tell libcec that the command callback handled the command that that it should not be handled internally.
For example, if I want to answer to "RequestARCInitiated" (0xC3) with "InitiateARC" (0xC1), libcec will still send "unrecognized opcode" after my reply and also to the initial "RequestARCInitiated" message.
Possible fix 1 A simple fix would be to update the API to allow the command callback to return true or false if the command has been handled or not. Currently, the command will be sent to the callback and the CECCommandHandler will respond to the command anyway. Unfortunately this would break all existing apps that rely on this callback.
Possible fix 2 A new commandHandler callback can be created so that applications can handle themselves CEC commands and return true/false if the command has been handled and should be ignored by the CECCommandHandler.
Possible fix 3 Another option is to fully implement ARC support in libCEC.
I can work on any of those options. IMHO option 2 is the best one at this time as it will provide additional flexibility.