131 replies to this topic

[plnick]

We are in Pli board here so it is right to leave them work on their code.

Ok, my mistake sorry, I thought this is a common thread for developing hdmi-cec functions at e2 stb's.

[hemertje]

We are in Pli board here so it is right to leave them work on their code.

Ok, my mistake sorry, I thought this is a common thread for developing hdmi-cec functions at e2 stb's.

it is plnick, as this is third-party development!
It is not Pli only here, we encurage other developers and hobbyteams to join forces and host your sources and adjustments publicly available...
This way the whole OpenSource Enigma community can benefit from each other and become stronger every day...

Greetings, Hemertje.

[pieterg]

Sure this is a good place to discuss various design decisions.
It's just that we are not working on a common single implementation.

Due to the nature of our various building environments and repositories, that simply won't work.
For example the openstb repos contains just a few files, not a full project.
So in order to work on them, the files need to be copied over into some checked out enigma2 workdir.
And others might not even have a public repository, making it even harder to cooperate.

We find it easier to develop in our openpli e2 repository, because that gives us the possibility to implement external requirements, add new SWIG exports, etc, as they come along.

This does not mean we do not want to work together, but for now this simply is the only way for us to develop new functionality, because we do not have a shared open repository.

[bacicciosat]

Ok, my mistake sorry, I thought this is a common thread for developing hdmi-cec functions at e2 stb's.

I was talking about my partecipation not about your post.

[plnick]

Sure this is a good place to discuss various design decisions.

That was my intention . I will not say this way is right or that way is wrong. I only want to show another way to do some stuff without any rating.

It's just that we are not working on a common single implementation.
Due to the nature of our various building environments and repositories, that simply won't work.
We find it easier to develop in our openpli e2 repository, because that gives us the possibility to implement external requirements, add new SWIG exports, etc, as they come along.
This does not mean we do not want to work together, but for now this simply is the only way for us to develop new functionality, because we do not have a shared open repository.

That's ok, because everbody can see development at your e2 repository and here we can talk/discuss about it. We should do it as community.

Back to topic

In my opinion the most difficult is to get working basic CEC functions for different vendors because every vendor implement CEC stuff their way (e.g. player buttons at TV remotecontrol Samsung/Philips TV's) and nobody of us can test many different TV's or A/V receivers. So we should collect our experiences and talk about it to improve CEC functions/possibilities of e2 stb's.

If you want it or not I attached source of VTI's way of implementing CEC. Above I wrote that we tried to do most stuff at python side of e2 (I don't know if this is the right way) to be more flexible, so the C++ part is very small. At the moment there is a lot of debug stuff at plugin => don't be irritated. Furthermore there are some parts which could be done much nicer (e.g. in my opinion Components/HdmiCec.py (of VTI implementation) have to be moved to plugin dir/.py to get a "clean" plugin). At Screens/Standby.py we add a notifier to send CEC messages (for example power off messages) if stb goes to deepstandby.

Attached Files

•  vti_hdmi-cec.zip   7.02KB   72 downloads

[Sjaaky]

Why forwarding keys from the tv-remote to e2? Does it work flawlessly with other devices (ie tv -> bluray player)?
Only forwarding the volume keys from e2 to the receiver or tv seems easier to me. The number of keys on the et9000 or vu remote is larger than on my tv remote.

[hemertje]

thx for sharing!

[plnick]

Why forwarding keys from the tv-remote to e2? Does it work flawlessly with other devices (ie tv -> bluray player)?

I do not know how it works with additional devices like bluray player, but with this forwarding you can use TV remote control to control your stb, so you only have to use one remote control for watching TV. With Samsung TV's nearly every needed key is working (like @bacicciosat wrote it above) (player keys do not work because the Samsung TV's do not passthrough this keycodes or I do not know how to manage it, at Philips TV player keys are working so there is no need for stb remote control when you watch TV)

[plnick]

sorry for a second post

Only forwarding the volume keys from e2 to the receiver or tv seems easier to me. The number of keys on the et9000 or vu remote is larger than on my tv remote.

Forwarding volume +/-/mute to A/V receiver is our next plan.

[Sjaaky]

It is not that hard. Only thing you'll need in python is a keyrelease event.

CONNECT(input->keyEvent, eHdmiCEC::forwardRemoteControlKeys);

void eHdmiCEC::forwardRemoteControlKeys(const eRCKey &key)
{
    struct RCKeyToCecMessageMapping
    {
	   int code;
	   int flags;
	   struct eHdmiCEC::cec_message message;
    };
    const struct cec_message KEYRELEASE = {5,1,{0x45}};
    static struct RCKeyToCecMessageMapping VPTlookup[] =
    {
	   {KEY_VOLUMEUP, eRCKey::flagMake, {5,2,{0x44,0x41}}},
	   {KEY_VOLUMEUP, eRCKey::flagRepeat, {5,2,{0x44,0x41}}},
	   {KEY_VOLUMEUP, eRCKey::flagBreak, KEYRELEASE},
	   {KEY_VOLUMEDOWN, eRCKey::flagMake, {5,2,{0x44,0x42}}},
	   {KEY_VOLUMEDOWN, eRCKey::flagRepeat, {5,2,{0x44,0x42}}},
	   {KEY_VOLUMEDOWN, eRCKey::flagBreak, KEYRELEASE},
	   {KEY_MUTE, eRCKey::flagMake, {5,2,{0x44,0x43}}},
	   {KEY_MUTE, eRCKey::flagBreak, KEYRELEASE},
	   {-1,-1}
    };
    if (!volumeForwardingEnabled) return;

    int i = 0;
    while(VPTlookup[i].code != -1)
    {
	   if (VPTlookup[i].code == key.code &&
		  VPTlookup[i].flags == key.flags)
	   {
		  VPTlookup[i].address = volumeForwardingDestination;
		  sendMessage(VPTlookup[i].message);
	   }
	   i++;
    }
}

And some receive code (audio system status 0x72) to determine the volumeForwardingDestination (tv or avr).[/i][/i][/i][/i][/i]

[plnick]

THX for your code. I will try it next week. Additionally I will try to handle it via an

additional python config variable to dis/enable it and do it with a patched VolumeControl.py

[pieterg]

ok, decided to move the cec command handling to python alltogether.
We had too many things being handled in two places, so it made sense to move everything to the python component.
Only the key events are still handled in the c++ 'driver', as this is the easiest way to inject key events.

[delagroov]

I just noticed that hdmi-cec is available on VUDUO.
On my samsung le40c650 amynet CEC is switching to hdmi2 input wenn conecting to LINUX STB instead of hdmi1.

My vuduo is on hdmi1 input. So something is mixed up.

For testing I putted it on hdmi2.
Amynet-CEC indetifies remote for linux stb, but the commands of the Samsung RC are not working.

[delagroov]

I just noticed that hdmi-cec is available on VUDUO.
On my samsung le40c650 amynet CEC is switching to hdmi2 input wenn conecting to LINUX STB instead of hdmi1.

My vuduo is on hdmi1 input. So something is mixed up.

For testing I putted it on hdmi2.
Amynet-CEC indetifies remote for linux stb, but the commands of the Samsung RC are not working.

Above was apearantly with an older CEC plugin from the feed.

I downloaded latest CEC plugin and now enigma crashed wenn my samsung connects to CeC device "vuduo " (before it was linux stb)

eHdmiCEC: received message 9F 
[ePopen] command: ('hdparm', 'hdparm', '-y', '/dev/sda')
sdt update done!
eHdmiCEC: received message 85 
eHdmiCEC: send message 82 10 00 
child has terminated
pipes closed
poll: unhandled POLLERR/HUP/NVAL for fd 58(16)
eHdmiCEC: received message 8D 02 
Traceback (most recent call last):
  File "/usr/lib/enigma2/python/Components/HdmiCec.py", line 169, in messageReceived
struct.error: unpack requires a string argument of length 1
(PyObject_CallObject(<bound method HdmiCec.messageReceived of <Components.HdmiCec.HdmiCec instance at 0x17e6800>>,(<enigma.iCECMessagePtr; proxy of <Swig Object of type 'ePtr< iCECMessage > *' at 0x1887da0> >,)) failed)

[bacicciosat]

This confirm my opinion to not agree with the plugin approach. /images/smiley/wink.gif
If you use only core code and not external files (plugins) there will be no risk that ppl will install unaligned version of code or plugins for different images (Hdmi-Cec plugins are already going in the net and posted on generic sat boards without image specification).

[bacicciosat]

elif message == "poweractive":
  73					cmd = 0x90
  74					data = str(struct.pack('B', 0x01))
  75			  elif message == "powerinactive":
  76					cmd = 0x90
  77					data = str(struct.pack('B', 0x00))

pieterg have you tested this ?
I remember that in cec specs the values are inverted: active is 0x00 and standby 0x01.
But for a strange reason in Anynet system this command doesn't work (power status is requested when tv scan hdmi devices)

[pieterg]

Most of the commands are untested, as my equipment only sends 2 or 3 commands.
There could be a lot of typos

[bacicciosat]

Maybe it is useful to add a default reply at the last else of reply parsing.
following Sjaaky suggestion:

0x00(abort) 0xXX(opcode received) 0x00 (unrecognized opcode)

[Sjaaky]

Just implementing a 'feature abort' after every unhandled message doesn't work. There would be too much replies. Some message are just sending status and don't request anything from the box. Such message don't need a feature abort reply.

I implemented the volume key forwarding. Too bad only my receiver supports it and my TV doesn't. Which is kinda expected reading between the lines in the specs. In "system audio mode" the audio is played by receiver and only the video is passed to the tv. In this mode you can forward volup, voldown, mute to the receiver. There is no such thing as "system audio mode" for the tv, so it doesn't accept the volume keys either.
I hope other televisions aren't so picky and just allow hdmicec volume control. My receiver is always on when watching tv, so it doesn't matter that much to me.

I am not entirely happy about the dependency of VolumeControl on HdmiCec, but it sure was the easiest implementation and allowed for easy runtime switching and fallback of the feature. I would rather have created a PSignal2<bool, int, int> pyKeyEvent which returned a boolean indicating the key has been handled. But because of the nature of PSignal2 it doesn't allow return values, I guess.

[pieterg]

I think PSignals could be made to return a value. Though it would probably mean another SWIG fight to get the proper python glue working.