131 replies to this topic

[pieterg]

I have compiled an image with your driver and tested on my vu uno with a Sony Bravia
The code work fine and the set name function too. We have in television menu the name we have set: linux stb.

ok, thanks for confirming.
So the conclusion is now I need to find out how to convince my tv to accept the device

Here is the debug of your driver with my Bravia.

eHdmiCEC: received message
eHdmiCEC: received message 83
eHdmiCEC: send message 84 57 6B
eHdmiCEC: received message 46
eHdmiCEC: send message 47 6C 69 6E 75 78 20 73 74 62 00

yes, your tv is actually requesting stuff.
Maybe I should just try to send the replies (such as name and menu status), even though the tv does not query them.
See whether that helps.

I have modifyed the code too to test the menuon function

Yes, I did not understand the reason for your menu status reply, untill you explained yesterday evening that this is the trigger for your tv to enable the rc passthrough mode.
I'm thinking we should perhaps make the menu status depend on the standby status: stb active = menu activated, so rc passthrough will be enabled, stb in standby = menu deactivated, so no more passthrough.

eHdmiCEC: received message 46
eHdmiCEC: send message 47 6C 69 6E 75 78 20 73 74 62 00

eHdmiCEC: send message 8E 00
ERROR reading PES (fd=40) - ERROR reading PES (fd=40) - Value too large for defined data type
eHdmiCEC: received message 00 8E 00

Maybe the abort message sent by tv: 00 8E 00 contains the reason of the reject of menu active command that cause that the passtrough remote control is not activated, but we have to change code to read the debug messages because we have the error: Value too large for defined data type. Maybe it contains an ascii string ?

the 'value too large for defined data type' is just an errno which the dvb-core is (mis-)using to signal 'buffer overflow'.
So your box is too busy, and it is dropping PES data.
Not related to CEC

btw, I notice that your physical address is incorrect: eHdmiCEC: send message 82 ED 8E
So probably the vu does not support the ioctl, you should probably keep using your physical address configuration setting instead.
However, your tv does not even seem to care that you're reporting the wrong address. Mine is a lot harder to please it seems

[bacicciosat]

ok, thanks for confirming.
So the conclusion is now I need to find out how to convince my tv to accept the device

Yes this is the main problem of Hdmi-Cec. I think that all tv accept the standard command but the problem seemt to be that there is not a standard protocol. Many times the message we want to send are not expected so are ignored or aborted. Only Anynet system seems to ask by default: active state set osd name and menu state. My bravia ask only osd name and You Panasonic seems to ask nothing. (Have you a function in tv menu to scan hdmi devices ?)
So the main problem seems to discover howto convince all tv to ask for active state osd name and
menu state.

Yes, I did not understand the reason for your menu status reply, untill you explained yesterday evening that this is the trigger for your tv to enable the rc passthrough mode.

Yes i discovered this in hdmi-cec specs.
If you look at CEC table 27 User control codes, in the Note 1 is explained that bold commands work only in menu state active. So i tested this command 0x8E with parameter 0 (menu active)

Ah i have a doubt About Cec table 26: Operand descriptions: i don't understand the reason because the parameters of the same lenght: 1 byte are stated sometimes with integer values (as for example menu state 0) and sometimes in hex (0x00)

I'm thinking we should perhaps make the menu status depend on the standby status: stb active = menu activated, so rc passthrough will be enabled, stb in standby = menu deactivated, so no more passthrough.

good idea !

the 'value too large for defined data type' is just an errno which the dvb-core is (mis-)using to signal 'buffer overflow'.
So your box is too busy, and it is dropping PES data.
Not related to CEC

Uhmm you are right i think this is because i sent multiple commands without wait for a reply.

btw, I notice that your physical address is incorrect: eHdmiCEC: send message 82 ED 8E
So probably the vu does not support the ioctl, you should probably keep using your physical address configuration setting instead.
However, your tv does not even seem to care that you're reporting the wrong address. Mine is a lot harder to please it seems

Yes i think there is a problem in Vu+ drivers the wekup command seems to no work and i have to switch between hdmi ports in tv menu to have communication with the box.

Here is the pdf with the cec tables i referred (but i am sure you already have )

Attached Files

•  cec_specs.pdf   400.88KB   41 downloads

[pieterg]

just checked, when I send a 'menu activated' command to my tv, it enables rc passthrough mode
So I'll add menu active/inactive commands to the wakeup/standby options, so users can configure them in case their tv does not actively query the menu status (like in my case).

[bacicciosat]

just checked, when I send a 'menu activated' command to my tv, it enables rc passthrough mode

Great !!
So we have it working on Samsung and Panasonic too.
You have to map the remote control of your panasonic now.
My function "translateKey" is wrote looking at Samsung remote control, i don't know if it is ok for Panasonic remote control too.

P.s. i used a little debug line in action.cpp to look at keyboards events in e2:

void eActionMap::keyPressed(const std::string &device, int key, int flags)
{
    eDebug("[Actionmap] device %s key %02x flags %02x", device.c_str(), key, flags);

P.s.2 What buttons of your tv are able to send event pressed code ?

I suspect that if we can set device type 1 instead of 3 we will have the records and play buttons working too

[bacicciosat]

Ah, about set name code:

case 0x46: /* request name */
				message.data[0] = 0x47; /* set name */
				strcpy(&message.data[1], "linux stb");
				message.length = 11;
				break;

I think we can use the box model instead of "linux stb"
In Vu+ box this is easy because we have the box model in the file /proc/stb/info/vumodel
In Etx000 i don't know because i have not here one Et9000 box but i am sure you can easly find a solution.

[pieterg]

or we use the hostname, which might be better if a user has two of the same model.

[bacicciosat]

or we use the hostname, which might be better if a user has two of the same model.

Right. We have only to remember that we have 13 byte limit.
I discovered it after many tries with a long name grrrrrrrr

[Sjaaky]

Good work guys. Turning on my television with hdmi-cec works 100% reliable!

I'm currently moving the volume punchthrough code to hdmi_cec.cpp.

[Sjaaky]

I've added

eRCInput::getInstance()->keyEvent.connect(slot(keyEventVolumePunchThrough));

to the hdmicec constructor and handle keypresses from that function. It works better than the python version, because I didn't know how to obtain break codes in python. Only problem is that the original volumecontrol keeps functioning. So I'm looking for a way to indicate the key is already handled.

If eRCInput.keyEvent is the wrong class to connect to, please tell me. Still learning here.

[pieterg]

as all current remotes are 'input' devices (no more legacy rcdreambox/rcdb2), connecting to eRCInput should be fine I guess.

[HPPli]

Good work guys. Turning on my television with hdmi-cec works 100% reliable!

I'm currently moving the volume punchthrough code to hdmi_cec.cpp.

Can you inform howto ??? I saw a plugin today, but don't know how to manage.

[korsan]

How can I test? I have updated the image and then downloaded the hdmi cec extension, but how can I enable the options?

[Sjaaky]

Currently the hdmicec receive/respond logic is located in both hdmi_cec.cpp and hdmicec.py. The main discriminator seems to be configuration. I understand this may just be early implementation, but which direction do you want to go?
Volume punchthrough will need configuration, so the best place would be python. But the implementation is best suited in c++ (imho).

[Sjaaky]

@HPPli and korsan: This is a development topic. If you have any questions open a new topic in the enduser support or gebruikersondersteuning.

[taksi02]

dAF2000: Create a new topic please.

[pieterg]

normally I don't like accessing (python) config from c++ code.
But in this case, where you need access to key release events, I guess there is no other way.
Unless you'd export an 'enablePunchthrough' function perhaps, and call that from python.

But I suggest you add the code first, and we'll worry about config later

[bacicciosat]

Currently the hdmicec receive/respond logic is located in both hdmi_cec.cpp and hdmicec.py. The main discriminator seems to be configuration. I understand this may just be early implementation, but which direction do you want to go?
Volume punchthrough will need configuration, so the best place would be python. But the implementation is best suited in c++ (imho).

Here the preferences are different i think.
I prefer to move all the possible implementation in c++ and to not use a plugin, first because i think that this is a core implementation so it have been fully integrated. And second because i hate the plugins proliferation.
In current BH implementation of Hdmi-Cec i used the python component only to manage standby/wakeup funcions box side. But i want to try to move that code too in C++ side.
If this will be possible i will not have a python component and i will not have a plugin for configuration but i will include directly in image settings the Hdmi-cec preferences.
This is my idea. Maybe i will do a compromise and i will leave the component restricetd to standby only.
We will see at the end. It will depends too by code evolution because it seems that we will have a kind of initialization of CEC communications in box wakeup step.

[Sjaaky]

I will add the code. But I'll leave it disabled, until the configuration is done. Enabling it by default would probably upset a lot of users.

Which implementation for VPT do you prefer?

The straight forward way.

void keyEventVolumePunchThrough(const eRCKey &key)
{
    struct eHdmiCEC::cec_message message;

    message.length = 0;
    message.address = 5; //receiver
    if (key.flags & (eRCKey::flagMake | eRCKey::flagRepeat))
    {
	   message.length = 2;
	   message.data[0] = 0x44; //press rc key
	   if (key.code == KEY_VOLUMEUP)
	   {
		  message.data[1] = 0x41;
	   }
	   else if (key.code == KEY_VOLUMEDOWN)
	   {
		  message.data[1] = 0x42;
	   }
	   else if (key.code == KEY_MUTE && key.flags & eRCKey::flagMake)
	   {
		  message.data[1] = 0x43;
	   }
    }
    else if (key.flags & eRCKey::flagBreak)
    {
	   if (key.code == KEY_VOLUMEUP || key.code == KEY_VOLUMEDOWN || key.code == KEY_MUTE)
	   {
		  message.length = 1;
		  message.data[0] = 0x45; //release rc key
	   }
    }
    if (message.length)
    {
	   eHdmiCEC *hdmicec = eHdmiCEC::getInstance();
	   hdmicec->sendMessage(message.address, message.length, message.data);
    }
}

The imho nicer way with a lookup table. But I haven't tested it though.

struct RCKeyToCecMessageMapping
{
    int code;
    int flags;
    struct eHdmiCEC::cec_message message;
};
void keyEventVolumePunchThrough(const eRCKey &key)
{
    const struct eHdmiCEC::cec_message keyRelease = {5,1,{0x45}};
    const struct RCKeyToCecMessageMapping VPTlookup[] =
    {
	   {KEY_VOLUMEUP, eRCKey::flagMake|eRCKey::flagRepeat, {5,2,{0x44,0x41}}},
	   {KEY_VOLUMEUP, eRCKey::flagBreak, keyRelease},
	   {KEY_VOLUMEDOWN, eRCKey::flagMake|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}
    };
    int i = 0;

    while(VPTlookup[i].code != -1)
    {
	   if (VPTlookup[i].code == key.code &&
		  VPTlookup[i].flags & key.flags)
	   {
		  eHdmiCEC *hdmicec = eHdmiCEC::getInstance();
		  hdmicec->sendMessage(VPTlookup[i].message.address, VPTlookup[i].message.length, VPTlookup[i].message.data);
	   }
	   i++;
    }
}

btw, is there a reason why the cec_message struct is constructed in 1 place, separated to 3 parameters for sendMessage and reassembled again? Lookup at the code a hdmicec::sendMessage(cec_message message) would me more logical.[/i][/i][/i][/i][/i][/i]

[pieterg]

I will add the code. But I'll leave it disabled, until the configuration is done. Enabling it by default would probably upset a lot of users.

Yes, I guess for now you should just query a python config item. Though not very nice, we do that in a lot of other c++ classes already.

Which implementation for VPT do you prefer?

the first is easier to read, and probably faster
But I see what you mean, if we want to add additional key events in the future, the second is easier.
So it's up to you.

BTW, I guess you want to put this code in some class, instead of using global stuff?

btw, is there a reason why the cec_message struct is constructed in 1 place, separated to 3 parameters for sendMessage and reassembled again? Lookup at the code a hdmicec::sendMessage(cec_message message) would me more logical.

well, the reason is python. sendMessage is exported, and easier to use in the current form (especially for commands without data).
But we could simply add an overloaded version of course, SWIG should be able to handle that.

[bacicciosat]

I will add the code. But I'll leave it disabled, until the configuration is done. Enabling it by default would probably upset a lot of users.

Which implementation for VPT do you prefer?

The straight forward way.

void keyEventVolumePunchThrough(const eRCKey &key)
......[i][i][i][i][i][i]

[/i][/i][/i][/i][/i][/i]

Uh ? Sorry Sjaaky maybe my english is so bad that i have not understood.
Why you need all this implementation and to duplicate code?
You need only to manage cec event keys id 0x41, 0x42, 0x43 and send the command to the sound device ?