Hello I want to show an special message on the screen. (with image, buttons,...) My idear was to write an second Plugin which have a MainMenuAction which shows the message on the OSD. The param will be set by a service which was called before I call
cPlugin *Plugin = cPluginManager::GetPlugin("myShowMessage"); if (Plugin) Plugin->MainMenuAction();
The problem is that I need to call this code from an background thread, so the called plugin can't handle the osd.
Mar 28 10:27:49 localhost vdr[7282]: ERROR: attempt to open OSD while it is already open - using dummy OSD! Mar 28 10:27:49 localhost vdr[7282]: ERROR: OSD opened without closing previous OSD!
Is there any possibility to call the Plugin with full osd support?
Hi,
Am Dienstag, 28. März 2006 10:59 schrieb Patrick Fischer:
Hello I want to show an special message on the screen. (with image, buttons,...) My idear was to write an second Plugin which have a MainMenuAction which shows the message on the OSD. The param will be set by a service which was called before I call
cPlugin *Plugin = cPluginManager::GetPlugin("myShowMessage"); if (Plugin) Plugin->MainMenuAction();
The problem is that I need to call this code from an background thread, so the called plugin can't handle the osd.
Mar 28 10:27:49 localhost vdr[7282]: ERROR: attempt to open OSD while it is already open - using dummy OSD! Mar 28 10:27:49 localhost vdr[7282]: ERROR: OSD opened without closing previous OSD!
Is there any possibility to call the Plugin with full osd support?
for example, in your background-thread:
// AutoOsd if (ShowMessage && !Skins.IsOpen() && !cOsd::IsOpen()) { ShowMessage = false; cRemote::CallPlugin("myShowMessage"); }
BR, Uwe
Uwe Hanke schrieb:
for example, in your background-thread:
// AutoOsd if (ShowMessage && !Skins.IsOpen() && !cOsd::IsOpen()) { ShowMessage = false; cRemote::CallPlugin("myShowMessage"); }
BR, Uwe
Thanx it works fine:
int timeout = 1000; //10sec while ((Skins.IsOpen() || cOsd::IsOpen()) && timeout) { usleep(10000); timeout--; } if (!Skins.IsOpen() && !cOsd::IsOpen()) { cRemote::CallPlugin("myMessage"); result = true; }else{ result = false; }
Now I can use the full osd!
On Tuesday 28 March 2006 12:20, Uwe Hanke wrote:
for example, in your background-thread:
// AutoOsd if (ShowMessage && !Skins.IsOpen() && !cOsd::IsOpen()) { ShowMessage = false; cRemote::CallPlugin("myShowMessage"); }
this looks racy to me. What if two different threads do this? The OSD could open between the if () and ::CallPlugin
Wolfgang Rohdewald wrote:
On Tuesday 28 March 2006 12:20, Uwe Hanke wrote:
if (ShowMessage && !Skins.IsOpen() && !cOsd::IsOpen()) { ShowMessage = false; cRemote::CallPlugin("myShowMessage"); }
this looks racy to me. What if two different threads do this? The OSD could open between the if () and ::CallPlugin
CallPlugin is always racy, as only one plugin call will be remembered.
The only safe way is to set up a signal and wait for MainMenuAction being called. If it is not called within timeout, try again.
The IsOpen() calls should ideally be made from foreground thread, but usually there's no way to get there. Testing from within MainMenuAction is pointless, as OSD and menu get closed right before MainMenuAction.
Cheers,
Udo
Hi,
Udo Richter wrote:
if (ShowMessage && !Skins.IsOpen() && !cOsd::IsOpen()) { ShowMessage = false; cRemote::CallPlugin("myShowMessage"); }
this looks racy to me. What if two different threads do this? The OSD could open between the if () and ::CallPlugin
CallPlugin is always racy, as only one plugin call will be remembered.
The only safe way is to set up a signal and wait for MainMenuAction being called. If it is not called within timeout, try again.
The IsOpen() calls should ideally be made from foreground thread, but usually there's no way to get there. Testing from within MainMenuAction is pointless, as OSD and menu get closed right before MainMenuAction.
I did something similar in my vdr-xine plugin. Things could be improved using the attached patch.
It allows to remember up to 16 calls to different plugins and the caller can detect, whether putting the call in the remote key fifo was successful.
Bye.
Reinhard Nissl wrote:
Hi,
Udo Richter wrote:
if (ShowMessage && !Skins.IsOpen() && !cOsd::IsOpen()) { ShowMessage = false; cRemote::CallPlugin("myShowMessage"); }
this looks racy to me. What if two different threads do this? The OSD could open between the if () and ::CallPlugin
CallPlugin is always racy, as only one plugin call will be remembered.
The only safe way is to set up a signal and wait for MainMenuAction being called. If it is not called within timeout, try again.
The IsOpen() calls should ideally be made from foreground thread, but usually there's no way to get there. Testing from within MainMenuAction is pointless, as OSD and menu get closed right before MainMenuAction.
I did something similar in my vdr-xine plugin. Things could be improved using the attached patch.
It allows to remember up to 16 calls to different plugins and the caller can detect, whether putting the call in the remote key fifo was successful.
Just so I get this right: with your patch it will be possible to put several plugin calls into the key queue. Let's assume that there are 3 plugin calls currently in the queue. When VDR goes through the next main loop, it will encounter a k_Plugin in the queue and call the first plugin's MainMenuAction(). Since there is more input in the queue, that plugin's OSD won't be displayed, yet (that's only done in cInterface::GetKey() in case the queue is empty). So it takes the next k_Plugin out of the queue, deletes the menu it just created and call the second plugin's MainMenuAction(). Before displaying that one it will get the third k_Plugin out of the queue, call that plugin's MainMenuAction(), and that's what will be finally displayed.
Unless I'm missing something here, queueing (up to 16) k_Plugins doesn't have any different result (from the user's point of view) than just overwriting any previously stored plugin call. The only thing that appears to be important is the (currently missing) mutex lock in cRemote::CallPlugin().
Am I missing something here?
Klaus
Hi,
Klaus Schmidinger wrote:
if (ShowMessage && !Skins.IsOpen() && !cOsd::IsOpen()) { ShowMessage = false; cRemote::CallPlugin("myShowMessage"); }
this looks racy to me. What if two different threads do this? The OSD could open between the if () and ::CallPlugin
CallPlugin is always racy, as only one plugin call will be remembered.
The only safe way is to set up a signal and wait for MainMenuAction being called. If it is not called within timeout, try again.
The IsOpen() calls should ideally be made from foreground thread, but usually there's no way to get there. Testing from within MainMenuAction is pointless, as OSD and menu get closed right before MainMenuAction.
I did something similar in my vdr-xine plugin. Things could be improved using the attached patch.
It allows to remember up to 16 calls to different plugins and the caller can detect, whether putting the call in the remote key fifo was successful.
Just so I get this right: with your patch it will be possible to put several plugin calls into the key queue. Let's assume that there are 3 plugin calls currently in the queue. When VDR goes through the next main loop, it will encounter a k_Plugin in the queue and call the first plugin's MainMenuAction(). Since there is more input in the queue, that plugin's OSD won't be displayed, yet (that's only done in cInterface::GetKey() in case the queue is empty). So it takes the next k_Plugin out of the queue, deletes the menu it just created and call the second plugin's MainMenuAction(). Before displaying that one it will get the third k_Plugin out of the queue, call that plugin's MainMenuAction(), and that's what will be finally displayed.
Unless I'm missing something here, queueing (up to 16) k_Plugins doesn't have any different result (from the user's point of view) than just overwriting any previously stored plugin call. The only thing that appears to be important is the (currently missing) mutex lock in cRemote::CallPlugin().
Am I missing something here?
In my case, I don't show an OSD. I just use this functionality as a trampoline to have the VDR main thread execute my code for switching the primary device, as it doesn't work reliably when it is done in any other thread.
So you are right, when a plugin opens an OSD (which is the typical case), one will only see the OSD of the last plugin. On the other hand, it would be useful to know for the caller, that the MenuMenuAction of the specified plugin will be called when CallPlugin() returned true. Otherwise it would need more "intelligent" code at the caller to achieve the call under race conditions.
In the case where the above is of no interest, there is no need to have an additional mutex lock in CallPlugin(), as Put() has one in remote.c:79.
Bye.
Reinhard Nissl wrote:
Hi,
Klaus Schmidinger wrote:
if (ShowMessage && !Skins.IsOpen() && !cOsd::IsOpen()) { ShowMessage = false; cRemote::CallPlugin("myShowMessage"); }
this looks racy to me. What if two different threads do this? The OSD could open between the if () and ::CallPlugin
CallPlugin is always racy, as only one plugin call will be remembered.
The only safe way is to set up a signal and wait for MainMenuAction being called. If it is not called within timeout, try again.
The IsOpen() calls should ideally be made from foreground thread, but usually there's no way to get there. Testing from within MainMenuAction is pointless, as OSD and menu get closed right before MainMenuAction.
I did something similar in my vdr-xine plugin. Things could be improved using the attached patch.
It allows to remember up to 16 calls to different plugins and the caller can detect, whether putting the call in the remote key fifo was successful.
Just so I get this right: with your patch it will be possible to put several plugin calls into the key queue. Let's assume that there are 3 plugin calls currently in the queue. When VDR goes through the next main loop, it will encounter a k_Plugin in the queue and call the first plugin's MainMenuAction(). Since there is more input in the queue, that plugin's OSD won't be displayed, yet (that's only done in cInterface::GetKey() in case the queue is empty). So it takes the next k_Plugin out of the queue, deletes the menu it just created and call the second plugin's MainMenuAction(). Before displaying that one it will get the third k_Plugin out of the queue, call that plugin's MainMenuAction(), and that's what will be finally displayed.
Unless I'm missing something here, queueing (up to 16) k_Plugins doesn't have any different result (from the user's point of view) than just overwriting any previously stored plugin call. The only thing that appears to be important is the (currently missing) mutex lock in cRemote::CallPlugin().
Am I missing something here?
In my case, I don't show an OSD. I just use this functionality as a trampoline to have the VDR main thread execute my code for switching the primary device, as it doesn't work reliably when it is done in any other thread.
So you are right, when a plugin opens an OSD (which is the typical case), one will only see the OSD of the last plugin. On the other hand, it would be useful to know for the caller, that the MenuMenuAction of the specified plugin will be called when CallPlugin() returned true. Otherwise it would need more "intelligent" code at the caller to achieve the call under race conditions.
In the case where the above is of no interest, there is no need to have an additional mutex lock in CallPlugin(), as Put() has one in remote.c:79.
I'm not particularly fond of that FIFO of yours. However, I do realize that it is useful to tell the caller of cRemote::CallPlugin() whether the call was successful. The attached patch vdr-1.3.46-callplugin.diff makes cRemote::CallPlugin() return false if there is currently a plugin call pending.
The ability to "catch the main thread" will be implemented by the second attached patch (vdr-1.3.46-mainthreadhook.diff), so that no "dirty tricks" should be necessary. This patch may have its line numbers a little off, because I have already made other changes to these files, but I wanted to give you a chance to look at this and maybe comment on it before I release version 1.3.47 later today.
Klaus
Hi,
Klaus Schmidinger wrote:
In my case, I don't show an OSD. I just use this functionality as a trampoline to have the VDR main thread execute my code for switching the primary device, as it doesn't work reliably when it is done in any other thread.
So you are right, when a plugin opens an OSD (which is the typical case), one will only see the OSD of the last plugin. On the other hand, it would be useful to know for the caller, that the MenuMenuAction of the specified plugin will be called when CallPlugin() returned true. Otherwise it would need more "intelligent" code at the caller to achieve the call under race conditions.
In the case where the above is of no interest, there is no need to have an additional mutex lock in CallPlugin(), as Put() has one in remote.c:79.
I'm not particularly fond of that FIFO of yours. However, I do realize that it is useful to tell the caller of cRemote::CallPlugin() whether the call was successful. The attached patch vdr-1.3.46-callplugin.diff makes cRemote::CallPlugin() return false if there is currently a plugin call pending.
The code looks good to me. Am I right that CallPlugin() shall now only be used to open the plugins main menu, i. e. no longer any other processing in the context of the main thread?
The ability to "catch the main thread" will be implemented by the second attached patch (vdr-1.3.46-mainthreadhook.diff), so that no "dirty tricks" should be necessary. This patch may have its line numbers a little off, because I have already made other changes to these files, but I wanted to give you a chance to look at this and maybe comment on it before I release version 1.3.47 later today.
I assume that this new interface function should be used for the code which has nothing to do with the plugins main menu but was put in that MainMenuAction() to execute the code in the context of the main thread.
In my case, the following code is to be executed in the new function:
void cXineDevice::mainMenuTrampoline() { #if VDRVERSNUM >= 10332 cMutexLock switchPrimaryDeviceLock(&m_switchPrimaryDeviceMutex); if (m_switchPrimaryDeviceDeviceNo < 0) return;
cControl::Shutdown();
if (m_switchPrimaryDeviceDeviceNo == (1 + DeviceNumber())) { char *msg = 0; ::asprintf(&msg, tr("Switching primary DVB to %s..."), m_plugin->Name());
Skins.Message(mtInfo, msg); ::free(msg); }
SetPrimaryDevice(m_switchPrimaryDeviceDeviceNo);
if (m_switchPrimaryDeviceDeviceNo != (1 + DeviceNumber())) { char *msg = 0; ::asprintf(&msg, tr("Switched primary DVB back from %s"), m_plugin->Name());
Skins.Message(mtInfo, msg); ::free(msg); }
m_switchPrimaryDeviceCond.Broadcast(); #endif }
I see here a new problem, as I need to call cControl::Shutdown(), but when VDR's main thread returns to it's main loop, it still may use "Menu" which is most likely invalid at that time:
// Main thread hooks of plugins: PluginManager.MainThreadHook(); // User Input: cOsdObject *Interact = Menu ? Menu : cControl::Control();
Maybe PluginManager.MainThreadHook() should be called earlier.
Bye.
Reinhard Nissl wrote:
Hi,
Klaus Schmidinger wrote:
In my case, I don't show an OSD. I just use this functionality as a trampoline to have the VDR main thread execute my code for switching the primary device, as it doesn't work reliably when it is done in any other thread.
So you are right, when a plugin opens an OSD (which is the typical case), one will only see the OSD of the last plugin. On the other hand, it would be useful to know for the caller, that the MenuMenuAction of the specified plugin will be called when CallPlugin() returned true. Otherwise it would need more "intelligent" code at the caller to achieve the call under race conditions.
In the case where the above is of no interest, there is no need to have an additional mutex lock in CallPlugin(), as Put() has one in remote.c:79.
I'm not particularly fond of that FIFO of yours. However, I do realize that it is useful to tell the caller of cRemote::CallPlugin() whether the call was successful. The attached patch vdr-1.3.46-callplugin.diff makes cRemote::CallPlugin() return false if there is currently a plugin call pending.
The code looks good to me. Am I right that CallPlugin() shall now only be used to open the plugins main menu, i. e. no longer any other processing in the context of the main thread?
The ability to "catch the main thread" will be implemented by the second attached patch (vdr-1.3.46-mainthreadhook.diff), so that no "dirty tricks" should be necessary. This patch may have its line numbers a little off, because I have already made other changes to these files, but I wanted to give you a chance to look at this and maybe comment on it before I release version 1.3.47 later today.
I assume that this new interface function should be used for the code which has nothing to do with the plugins main menu but was put in that MainMenuAction() to execute the code in the context of the main thread.
Right. That was a dirty trick and I didn't want to manifest that ;-)
In my case, the following code is to be executed in the new function:
void cXineDevice::mainMenuTrampoline() { #if VDRVERSNUM >= 10332 cMutexLock switchPrimaryDeviceLock(&m_switchPrimaryDeviceMutex); if (m_switchPrimaryDeviceDeviceNo < 0) return;
cControl::Shutdown(); if (m_switchPrimaryDeviceDeviceNo == (1 + DeviceNumber())) { char *msg = 0; ::asprintf(&msg, tr("Switching primary DVB to %s..."),m_plugin->Name());
Skins.Message(mtInfo, msg); ::free(msg); } SetPrimaryDevice(m_switchPrimaryDeviceDeviceNo); if (m_switchPrimaryDeviceDeviceNo != (1 + DeviceNumber())) { char *msg = 0; ::asprintf(&msg, tr("Switched primary DVB back from %s"),m_plugin->Name());
Skins.Message(mtInfo, msg); ::free(msg); } m_switchPrimaryDeviceCond.Broadcast();#endif }
I see here a new problem, as I need to call cControl::Shutdown(), but when VDR's main thread returns to it's main loop, it still may use "Menu" which is most likely invalid at that time:
// Main thread hooks of plugins: PluginManager.MainThreadHook(); // User Input: cOsdObject *Interact = Menu ? Menu : cControl::Control();Maybe PluginManager.MainThreadHook() should be called earlier.
Originally I was thinking about actually putting it further down. How about we put it to the very end of the "while (!Interrupted) {" loop? That way it shouldn't interfere with anything.
I'll make it that way for version 1.3.47, which I will be releasing shortly.
Klaus
Hi,
Klaus Schmidinger wrote:
In my case, I don't show an OSD. I just use this functionality as a trampoline to have the VDR main thread execute my code for switching the primary device, as it doesn't work reliably when it is done in any other thread.
So you are right, when a plugin opens an OSD (which is the typical case), one will only see the OSD of the last plugin. On the other hand, it would be useful to know for the caller, that the MenuMenuAction of the specified plugin will be called when CallPlugin() returned true. Otherwise it would need more "intelligent" code at the caller to achieve the call under race conditions.
In the case where the above is of no interest, there is no need to have an additional mutex lock in CallPlugin(), as Put() has one in remote.c:79.
I'm not particularly fond of that FIFO of yours. However, I do realize that it is useful to tell the caller of cRemote::CallPlugin() whether the call was successful. The attached patch vdr-1.3.46-callplugin.diff makes cRemote::CallPlugin() return false if there is currently a plugin call pending.
The code looks good to me. Am I right that CallPlugin() shall now only be used to open the plugins main menu, i. e. no longer any other processing in the context of the main thread?
The ability to "catch the main thread" will be implemented by the second attached patch (vdr-1.3.46-mainthreadhook.diff), so that no "dirty tricks" should be necessary. This patch may have its line numbers a little off, because I have already made other changes to these files, but I wanted to give you a chance to look at this and maybe comment on it before I release version 1.3.47 later today.
I assume that this new interface function should be used for the code which has nothing to do with the plugins main menu but was put in that MainMenuAction() to execute the code in the context of the main thread.
Right. That was a dirty trick and I didn't want to manifest that ;-)
In my case, the following code is to be executed in the new function:
void cXineDevice::mainMenuTrampoline() { #if VDRVERSNUM >= 10332 cMutexLock switchPrimaryDeviceLock(&m_switchPrimaryDeviceMutex); if (m_switchPrimaryDeviceDeviceNo < 0) return;
cControl::Shutdown(); if (m_switchPrimaryDeviceDeviceNo == (1 + DeviceNumber())) {I see here a new problem, as I need to call cControl::Shutdown(), but when VDR's main thread returns to it's main loop, it still may use "Menu" which is most likely invalid at that time:
// Main thread hooks of plugins: PluginManager.MainThreadHook(); // User Input: cOsdObject *Interact = Menu ? Menu : cControl::Control();Maybe PluginManager.MainThreadHook() should be called earlier.
Originally I was thinking about actually putting it further down. How about we put it to the very end of the "while (!Interrupted) {" loop? That way it shouldn't interfere with anything.
Should be ok too. It's similar to call it earlier in the next loop run ;-)
Bye.
Klaus Schmidinger wrote:
The ability to "catch the main thread" will be implemented by the second attached patch (vdr-1.3.46-mainthreadhook.diff), so that no "dirty tricks" should be necessary.
--- plugin.h 2005/08/27 16:13:17 1.10 +++ plugin.h 2006/04/17 09:18:16 @@ -39,6 +39,7 @@ virtual bool Start(void); virtual void Stop(void); virtual void Housekeeping(void);
- virtual void MainThreadHook(void);
Nice thing to have, but while we're at it, what about a way to open the OSD from there? That way we could get rid of the CallPlugin / MainMenuAction hacks altogether. Just allow cOsdObject* as return type.
Of course this wont solve the races between plugins. Only one can be shown in one pass, the rest must be destroyed.
Cheers,
Udo
Udo Richter wrote:
Klaus Schmidinger wrote:
The ability to "catch the main thread" will be implemented by the second attached patch (vdr-1.3.46-mainthreadhook.diff), so that no "dirty tricks" should be necessary.
--- plugin.h 2005/08/27 16:13:17 1.10 +++ plugin.h 2006/04/17 09:18:16 @@ -39,6 +39,7 @@ virtual bool Start(void); virtual void Stop(void); virtual void Housekeeping(void);
- virtual void MainThreadHook(void);
Nice thing to have, but while we're at it, what about a way to open the OSD from there? That way we could get rid of the CallPlugin / MainMenuAction hacks altogether. Just allow cOsdObject* as return type.
Of course this wont solve the races between plugins. Only one can be shown in one pass, the rest must be destroyed.
Let's not get carried away ;-)
This was a quick way of allowing a plugin to do something in the main thread context that otherwise couldn't be done.
Now I want to wrap things up for the final approach to version 1.4.
Klaus
Hello Klaus,
Except for a few version numbers in the man pages etc., this is pretty much what will become the final version 1.4.
Sounds good ! Do you plan to add "enAIO patch" in final 1.4 ?
PS: At the end of vdr's description, could you please indicate what versions you're using : - Driver version (kernel 2.6.1x.y or CVS-xxxx). - Firmware version.
Many thanks ! Karim.
kafifi wrote:
Hello Klaus,
Except for a few version numbers in the man pages etc., this is pretty much what will become the final version 1.4.
Sounds good ! Do you plan to add "enAIO patch" in final 1.4 ?
No. There will be no more big changes for version 1.4.
PS: At the end of vdr's description, could you please indicate what versions you're using :
- Driver version (kernel 2.6.1x.y or CVS-xxxx).
- Firmware version.
I'll see what I can do.
Klaus
( don't use "reply" if you want to create a new mail thread )
Klaus Schmidinger wrote:
Am I missing something here?
This is mostly about plugins that expect their MainMenuAction to be called. A plugin may catch this call and display a message instead of the default menu. If the call is canceled, the message will unexpectedly appear the next time the user selects the main menu item. (As I said before, I would suggest signaling and timeouts anyway)
Things might get useful with another patch I wouldn't dare to suggest before 1.4 ;)
This is current code:
DELETE_MENU; if (cControl::Control()) cControl::Control()->Hide(); cPlugin *plugin = cPluginManager::GetPlugin(cRemote::GetPlugin()); if (plugin) { Menu = plugin->MainMenuAction(); if (Menu) Menu->Show(); }
This is my idea:
cPlugin *plugin = cPluginManager::GetPlugin(cRemote::GetPlugin()); if (plugin) { cMenu *NewMenu = plugin->MainMenuAction(); if (NewMenu) { DELETE_MENU; if (cControl::Control()) cControl::Control()->Hide(); Menu = NewMenu; Menu->Show(); } }
That way, the old OSD/menu will be destroyed only if MainMenuAction returned a new menu. If MainMenuAction returns NULL, nothing should happen. This would be a nice dirty trick to catch the main thread from a plugin. I don't know whether that change has bad side effects though.
Cheers,
Udo
-
kafifi -
Klaus Schmidinger -
Patrick Fischer -
Patrick Gleichmann -
Reinhard Nissl -
Udo Richter -
Uwe Hanke -
Wolfgang Rohdewald