2014-09-12, 06:41
@Milhouse
we just had discussion here internally past hour about that and I was checking history of that file to help myself remember what that particular problem was. But based on missing comment from my side (in the reported issues regarding fps issue) it was something like stupid me .... or typo (while responding to OnScreenSaverDeactivated).
I'm pretty sure that bug was there at the time I shared with popcornmix - so if that fresh patch should help pretty much depends on how (and what) you was applying. If that past version, then yes, it should help.
But colleague @Anaconda is telling me that your build system if fetching all the patches each run. Then the answer would be no as there is ~1 change relevant to process of waking up (stopping the limiter) - or I got stupid in-between and am missing again (on first look unrelated) dependency of code which I missed also with ver 1 of that patch.
If possible without much hassle re-apply again and turn off TV. Check in logs for "CecStandby 1", turn TV back on. You will see in logs record about TV being "ON" again - problem is that this message comes from libCEC and comes not back to XBMC (as it is no message on CEC bus, but internal state change of libCEC for device 0(TV)). there is no OPCODE defined for device becoming ON (in contrast to dev going standby is required to be sent by the specific device).
I have the feeling that the first attempt - while trying to change as little of code as possible - was too optimistically depending on CEC messages and activity only (TV going OFF, TV changing source (so XBMC loosing ActiveSource attribute) and then back again with TV switching back to XBMC source (becoming ActiveSource again) or TV going OFF->ON - where (beside ugly LG) we don't get TVisON but TV should ask/reactivate last ActiveSource device so actually delivering the needed message to XBMC again (becoming AS)).
In reality that was far from paper specs... (not only for LG. there is also libCEC part like libCEC not reporting being AS if that info was already sent before - but not considering TV off-on cycle flushing all internal info about actual libCEC devices - so leaving TVs request to get info who is AS unanswered - limiting itself to DEBUG comment "not sending AS as libCEC is AS already and AS sent before")
to make this short - due to this (and also considering VNC usage where libCEC status is not touched in any way) I added calls to CecStandby triggered from Screensaver changing status too. I can't think currently of anything else.
As we speak in the process - realised otherwise clear consequence of that - if screensaver functionality is turned OFF but CEC as ON(xbmc's default) and otherwise CEC config in XBMC left to defaults also - XBMC will definitely sooner or later end up at 2fps limit. if not while changing sources then later after TV going through cycle OFF - > ON (as ON not being communicated -> with just one source (RPI), libCEC won't resend ActSource message, that won't wake up XBMC - and screensaver off event as helper is not existing).
If it is that case, we can re-add OPCODE handler for message type that is being send by TV during it's CEC init. CEC defines this as SET LANG to 0xf followed by GET VENDOR ID to 0xf (so we will create analogue to "TV is ON"). With LG it will be probably VENDOR ID followed by OPABORT (to reset/cleanup) existing bonds (undocumented LG only extensions).
To be even much shorter - LOG will get definitely handy - to cover the right OPCODE while not taking such which is being repeated constantly (again LG) - this would be turning the limiter off for no reason).
(and to provide user's choice/control to disable this feature completely - we can confront XBMC's CEC setting on each CecStandby() call (for instance again the "standby with screensaver")) - currently is checked only when handling the screensaver events.
I hope I didn't make the topic to sound/feel more complicated as it really is ...
btw: original idea was to turn off rendering completely. That is even more polite to XBMC code as Renderer() function is not messed at all and public function SetRenderGUI(or SetGUIRender) is called with true/false. It was/is working as expected on RPI but on IMX6 it was throwing VSync() apart - not working anymore upon reactivating GUIRenderer (probably by a leak in IMX6 implementation FBs MULTI_BUFFER gets destroyed). with new kernels this looks ok so once everybody is confident with the problem you have been experiencing I would propose switching from limiter to stop renderer - what can theoretically lead to later context offloads (releasing mem). RPI would profit from each 10M we can save.
btw2: rendereroff is causing xbmc going under 2%. that marginal load is caused by peripheral busses being polled and rescanned. I have seen you adapt that for CECbus already. But whole "input" subsystem is looping literally with no gaps (but most likely <2% is not worth anymore troubles).
mk
we just had discussion here internally past hour about that and I was checking history of that file to help myself remember what that particular problem was. But based on missing comment from my side (in the reported issues regarding fps issue) it was something like stupid me .... or typo (while responding to OnScreenSaverDeactivated).
I'm pretty sure that bug was there at the time I shared with popcornmix - so if that fresh patch should help pretty much depends on how (and what) you was applying. If that past version, then yes, it should help.
But colleague @Anaconda is telling me that your build system if fetching all the patches each run. Then the answer would be no as there is ~1 change relevant to process of waking up (stopping the limiter) - or I got stupid in-between and am missing again (on first look unrelated) dependency of code which I missed also with ver 1 of that patch.
If possible without much hassle re-apply again and turn off TV. Check in logs for "CecStandby 1", turn TV back on. You will see in logs record about TV being "ON" again - problem is that this message comes from libCEC and comes not back to XBMC (as it is no message on CEC bus, but internal state change of libCEC for device 0(TV)). there is no OPCODE defined for device becoming ON (in contrast to dev going standby is required to be sent by the specific device).
I have the feeling that the first attempt - while trying to change as little of code as possible - was too optimistically depending on CEC messages and activity only (TV going OFF, TV changing source (so XBMC loosing ActiveSource attribute) and then back again with TV switching back to XBMC source (becoming ActiveSource again) or TV going OFF->ON - where (beside ugly LG) we don't get TVisON but TV should ask/reactivate last ActiveSource device so actually delivering the needed message to XBMC again (becoming AS)).
In reality that was far from paper specs... (not only for LG. there is also libCEC part like libCEC not reporting being AS if that info was already sent before - but not considering TV off-on cycle flushing all internal info about actual libCEC devices - so leaving TVs request to get info who is AS unanswered - limiting itself to DEBUG comment "not sending AS as libCEC is AS already and AS sent before")
to make this short - due to this (and also considering VNC usage where libCEC status is not touched in any way) I added calls to CecStandby triggered from Screensaver changing status too. I can't think currently of anything else.
As we speak in the process - realised otherwise clear consequence of that - if screensaver functionality is turned OFF but CEC as ON(xbmc's default) and otherwise CEC config in XBMC left to defaults also - XBMC will definitely sooner or later end up at 2fps limit. if not while changing sources then later after TV going through cycle OFF - > ON (as ON not being communicated -> with just one source (RPI), libCEC won't resend ActSource message, that won't wake up XBMC - and screensaver off event as helper is not existing).
If it is that case, we can re-add OPCODE handler for message type that is being send by TV during it's CEC init. CEC defines this as SET LANG to 0xf followed by GET VENDOR ID to 0xf (so we will create analogue to "TV is ON"). With LG it will be probably VENDOR ID followed by OPABORT (to reset/cleanup) existing bonds (undocumented LG only extensions).
To be even much shorter - LOG will get definitely handy - to cover the right OPCODE while not taking such which is being repeated constantly (again LG) - this would be turning the limiter off for no reason).
(and to provide user's choice/control to disable this feature completely - we can confront XBMC's CEC setting on each CecStandby() call (for instance again the "standby with screensaver")) - currently is checked only when handling the screensaver events.
I hope I didn't make the topic to sound/feel more complicated as it really is ...
btw: original idea was to turn off rendering completely. That is even more polite to XBMC code as Renderer() function is not messed at all and public function SetRenderGUI(or SetGUIRender) is called with true/false. It was/is working as expected on RPI but on IMX6 it was throwing VSync() apart - not working anymore upon reactivating GUIRenderer (probably by a leak in IMX6 implementation FBs MULTI_BUFFER gets destroyed). with new kernels this looks ok so once everybody is confident with the problem you have been experiencing I would propose switching from limiter to stop renderer - what can theoretically lead to later context offloads (releasing mem). RPI would profit from each 10M we can save.
btw2: rendereroff is causing xbmc going under 2%. that marginal load is caused by peripheral busses being polled and rescanned. I have seen you adapt that for CECbus already. But whole "input" subsystem is looping literally with no gaps (but most likely <2% is not worth anymore troubles).
mk
