131 replies to this topic

[bacicciosat]

Ah, ok i have understood.

[bacicciosat]

Ok i have a doubt about this implementation.
If you want only use the box rc to send to your sound system volume commands i think the easiest solution is not to duplicate volume control but to redirect it.

I other words: as for example in volume control.py

def volUp(self):
	   self.setVolume(+1)

    def volDown(self):
	   self.setVolume(-1)

Use something like:

def volUp(self):
    if config.hdmicec.redirect_volume.value:
	   cmd = struct.pack('BB', 0x44, 0x41)
	   eHdmiCEC.getInstance().sendMessage(5, len(cmd), str(cmd))
	   cmd = struct.pack('BB', 0x45, 0x41)
	   eHdmiCEC.getInstance().sendMessage(5, len(cmd), str(cmd))
    else:
	   self.setVolume(+1)

def volDown(self):
    if config.hdmicec.redirect_volume.value:
	   cmd = struct.pack('BB', 0x44, 0x42)
	   eHdmiCEC.getInstance().sendMessage(5, len(cmd), str(cmd))
	   cmd = struct.pack('BB', 0x45, 0x42)
	   eHdmiCEC.getInstance().sendMessage(5, len(cmd), str(cmd))
    else:
	   self.setVolume(-1)

Just an idea... i don't know if it can works

[pieterg]

but that does not allow to handle make/break key events. Those are only available in the c++ code.

[Sjaaky]

That's still another problem. The original volumecontrol has to be disabled. Redirection would be a sound solution. Although in true OO sense I would prefer a HdmiCECVolumeControl class

mytest.py:

    profile("Init:VolumeControl")
    if config.hdmicec.redirect_volume.value:
	  vol = HdmiCECVolumeControl(session)
    else:
	  vol = VolumeControl(session)

Your implementation does work, but the volume changes are too slow for me. My receiver does 0.5dB steps. Sending 2 commands for every keypress is considerably slower than my current implementation.

Sending the break is needed, otherwise my receiver repeats the keypress after somewhere between 0.5 and 1sec.
For example pressing 'up', 'up', 'up' results in 'up', 'up', 'up', 0.5s delay, 'up', 'up', 'up'. Which is very annoying and probably implementation specific per receiver (brand/chip/..).
In my previous python implementation I used a timeout to send the breakcode. (Sending only 0x45 is enough, it doesn't need the keycode (source: cec-o-matic).) But the timeout has to be adjusted to the delay-before-repeat time of the remote. Otherwise pressing and holding volume up will send this pattern "x44, x41", "x45", "x44, x41", "x44, x41", ...., "x45". Which gives an annoying slow start to increasing or decreasing volume.
The c++ implementation posted above gives me the best results, without timers and such.

Maybe we should send keyReleases to python? Or create a NOOPVolumeControl class. The globalActionMap.actions["volumeUp"] still needs to be set, otherwise the [\] icon appears for every volup, voldown, mute keypress.
Or just filter out the keypresses so they never make it any further. But that needs some changes as well. Setup priorities in the listeners, return a boolean which indicates the button has been handled. Or is such a mechanism already provided by enigma?

[bacicciosat]

The c++ implementation posted above gives me the best results, without timers and such.

If this solution assure the best results there is not choice. You can make tests and evalutate this.
Go ahed with your idea and bypass the enigma2 function "setVolume" when the option redirect_volume is enabled.

[Sjaaky]

The physical address reported by the driver ioctl is 9.A.7.0. The physical address should be 1.1.0.0 as the stb is on the first hdmi input of the receiver which is on the first hdmi input of the tv. I didn't notice a change in behaviour though, but it is too early to tell .

The current 'report address command' 0x84 doesn't include the type of the device and should probably be extended by one byte.

After a volup/voldown keyrelease I'm sending a 'request volume status' 0x71 to my receiver (denon avr1910), which reports back with a 'report audio status' 0x7A. But there seems to be a bug in my receiver, the volume is not updated unless I perform some other action like mute and unmute or enter the menu and exit. Too bad . Maybe I should rather output the current osd of the receiver (the receiver is in a closed closet) or find some innocent command which updates the volume.

The following doesn't work as the ePythonConfigQuery::m_queryFunc isn't set when the constructor is run, so getConfigValue always returns -1.

eHdmiCEC::eHdmiCEC() : eRCDriver(eRCInput::getInstance())
{
  ...
  if ( ePythonConfigQuery::getConfigValue("config.hdmicec.volumepunchthrough", config_str) >= 0 && config_str == "True" )
  {
    CONNECT(eRCInput::getInstance()->keyEvent, eHdmiCEC::keyEventVolumePunchThrough);
  }
}

A hacky solution would be to connect it anyway, and check the value on each keypress until a satisfactory result comes out and cache it. A better solution would be the hdmicec.py which further initializes the c++ part, wouldn't it?

Some logging when I put on my bluray player, of course these are all broadcast messages. I can't see the direct communication between the bluray player and the receiver or tv.

eHdmiCEC: received message 84 12 00 04 // I am a playback device on 1.2.0.0
eHdmiCEC: received message 84 12 00 04 
eHdmiCEC: received message 87 00 90 3E // Vendor id
eHdmiCEC: received message 82 12 00	 // Active source 1.2.0.0
eHdmiCEC: received message 84 12 00 04 
eHdmiCEC: received message 87 00 90 3E
eHdmiCEC: received message 82 12 00
eHdmiCEC: received message 82 12 00

Btw, this powerpoint presentation says hdmi-cec runs on a ~400hz clock resulting a wopping ~30bytes/sec transfer speed!

[pieterg]

The physical address reported by the driver ioctl is 9.A.7.0.

are you sure you are testing with a recent driver?
I also have a tv <-- avreceiver <-- et9k setup, and for me it reports 1.2.0.0 which is correct in my case. (and 1.0.0.0 when connected directly to the tv)

The current 'report address command' 0x84 doesn't include the type of the device and should probably be extended by one byte.

good one, we should add that.

The following doesn't work as the ePythonConfigQuery::m_queryFunc isn't set when the constructor is run, so getConfigValue always returns -1.

yeah, having to use config from python really sucks

[bacicciosat]

The current 'report address command' 0x84 doesn't include the type of the device and should probably be extended by one byte.

My code include it

			case 0x84:
117				 buf[1] = 4;
118				 buf[3] = phys;
119				 buf[4] = phys2;
120				 buf[5] = 3;

but it seems to have no effect.
The device type is already set to 3 (tuner) als if i try to set it to type 1.
This is wrong because the box is not only a tuner but a playback and record system too (type 1 )
Reading the Hdmi-Cec specs seems to me to understand that in these cases is possible to set multible types.
But my tries have not results. The device type is always set to 3 and seems to ignore different settings.
I suspect that if we can set the right type we can have available for rc passtrough the buttons to play and record too.

[pieterg]

I'm wondering how this should work.
The logical address is 3, and the devicetype is 3.
If a device supports multiple types, should it respond to multiple logical addresses? Or just the single address (3), with multiple types?

[Sjaaky]

Yes it may do so.

If a physical device contains the functions of more than one logical device then it should take the logical
addresses for each of those logical devices. For example, a if a DVD recorder has a tuner, it may take one of
the addresses 3, 6, 7 or 10 (Tuner) in addition to one of 1,2 or 9 (Recording Device).
It is allowed for a device to declare the functionality of another device by using a different logical address. For
example a recordable DVD device may take the address 4 or 8 to expose only the functionality of a standard
DVD Playback Device. In this case, the recording functionality will not be available or controllable via CEC.
A Recording Device with addresses 1,2 or 9 (Recording Device) shall not also take a Playback Device
address as the playback functionality is also included in the recorder functionality.
If a device has multiple instances of a particular functionality, it should advertise only one instance. For
instance, if a device has multiple tuners, it should only expose one for control via CEC. In this case, it is up to
the device itself to manage multiple tuners.
A device shall advertise a function with a Logical Address, such as a Tuner, only if it supports at least the
mandatory messages for that function.

But I haven't found in the specs how the device should report this.
Maybe multiple messages like this?

84 12 00 01
84 12 00 03

[bacicciosat]

Yes it may do so.
But I haven't found in the specs how the device should report this.
Maybe multiple messages like this?

84 12 00 01
84 12 00 03

I followed the same logic but my tests had no success.
I had always type 3 only.

[Sjaaky]

But in my case, i'd rather control my tv with the et9000 remote than the other way around. Just because my tv remote has less buttons. I would like to control my blu-ray player with the et9000 remote, though.
The specs tell us (table 27, page 95) only a limitted set of buttons is forwarded in menu active mode.

[bacicciosat]

I have seen debug reports of tv asking vendor id and hdmi cec version.
I think we can add these replies too
For cec version i think we can report 1.3.a: 0x04
For vendor id i think a solution should be to create a fake id vendor and store it in "config.hdmicec.vendor_id"
then to ask to tv the vendor id and store the correct value in the option so we will have stored the same vendor_id of the tv.
Or maybe you have a better idea howto manage vendorid request ?

[Sjaaky]

That isn't mandatory, only if we want to use vendor specific commands.

The 'feature abort' and 'abort' are mandatory. Maybe we should implements those. (So other device don't need to timeout waiting for a response).

[bacicciosat]

The 'feature abort' and 'abort' are mandatory. Maybe we should implements those. (So other device don't need to timeout waiting for a response).

Right.

[pieterg]

The following doesn't work as the ePythonConfigQuery::m_queryFunc isn't set when the constructor is run, so getConfigValue always returns -1.

even if we could get the config in the constructor, that would mean we could not change the config value, without having to restart e2.
So it might be better to always connect the key handler, and check the config option from there.
But because getting the config might be an expensive call, perhaps export an
enableStuff(bool onoff) function instead, and call that from python when the setting changes.

[Sjaaky]

And we are sending all replies back to the tv instead of to the device where the request came from.

[bacicciosat]

And we are sending all replies back to the tv instead of to the device where the request came from.

- message.address = 0; /* TV */

But i was wondering if the code structure have to be redesigned now that we have possible additional devices to manage.

BTW i have seen someone posting Hdmi-Cec plugin in one board.
For this reason too i don't agree with plugin idea.
Usually the plugin is considered a complete and separate application.
Here it seems that the plugin have only the reason to set options and is strictly dependent by the core version.

[plnick]

Hello @all

fine to see here a shared developing of CEC functions for e2 stb's.

I suspect that if we can set the right type we can have available for rc passtrough the buttons to play and record too.

Imho passthrough of "player" buttons is vendor specific. At Samsung TV's I do not get it working (I also wrote an email to samsung to get help for this issue => no answer yet). For example at Philips TV's passthrough of player buttons is working. So in my opinion you have to send a vendor specific cec message to enable it.

BTW i have seen someone posting Hdmi-Cec plugin in one board.

I think you mean VTI ?

Usually the plugin is considered a complete and separate application.
Here it seems that the plugin have only the reason to set options and is strictly dependent by the core version.

No, it is not only for setting options. the plugin handles all CEC messages (also translating key code messages). We tried to do much as possible at python side of e2 and not at c++ side.
In my opinion there are some advantages:
- easier to modify code / functions without compiling e2 (more flexible than hardcoded c++ stuff)
- enable/disable for CEC functions without restarting e2
- you do not have to pass python config variables to c++ side

If you add a few lines to get key codes of cec message 0x44 to this version
http://openpli.git.s...7fbb02dd80dd112 , you are able to handle remote control action of TV too.

switch(message.data[0])
					{
						   case 0x44: 
								 messageReceivedKey(message.address, message.data[1]);
								 break;
						  /* for further functions
						   case 0x99: 
								 messageReceivedKey(message.address, message.data[1]);
								 SecondmessageReceivedKey(message.address, message.data[2]);    
							    break;
						   */
					}

If you are interested in code of VTI version of cec plugin, please let me know => I will post it.

[bacicciosat]

I think it is difficoult to continue this kind of discussion in this thread for various reasons.
The first problem is that it seems there is not a logical objective in the direction we are following.
We have started thinking only to comunications between tv and box pointing at standby/wakeup functions.
Later we have introduced remote control tv passthrough
And now we have introduced the managment of comunications with other devices.
But it is not clear the objective. We want to use box rc to manage other devices or we want to use tv rc to manage both tv and box and other devices or we want to use Av rc and sound system rc to manage box and tv ? Or we think we can simply implement all communications possible between all devices without any objective ?
The second problem is that it is not clear what is the logical criteria we are following in distributing code between enigma2 c++ core, python component side and plugins side.
The third problem is that we are not more talking about a common source code but about different implementation of hdmi-cec in different firmwares.
My partecipation till now was only in theory and knowledge exchange because i am in vacation and i cannot make tests on working code and developing stuffs. But i see here that pieterg and Sjaaki are making a great work on coding so maybe is time to leave them works on their own implementation and don't create confusion.
We are in Pli board here so it is right to leave them work on their code.