[vdr] Passing events to plugins or external programs
marko.makela at hut.fi
Wed Sep 14 23:33:29 CEST 2005
On Wed, Sep 14, 2005 at 06:24:10PM +0200, Klaus Schmidinger wrote:
> Marko Mäkelä wrote:
> >I have equipped my vdr system with a solid-state relay that can power on
> >and off the monitor and speakers. The relay should be connected to the
> >value of Setup.Suspend (see my patch from yesterday).
> >I am not too familiar with the plugin interface of vdr, but I got the
> >impression that the only way to implement such a relay control in a
> >plugin would be by polling, which is inefficient.
> >Are there any plans to allow plugins to register for updates of cSetup
> >variables? (Or any plans for a svdrp interface to setting and querying
> >the variables, for that matter?)
> >Such an event interface could also be to a popen'ed child process.
> >Whenever something of interest happens, vdr would write a line to the
> >pipe. At the very least, changes to setup variables (both vdr and
> >plugins) would be logged. The child process would look for interesting
> >lines, such as "Setup.Suspend=0" or "Setup.Suspend=1" in the case of
> >relay control. Other events that could be logged would be changes in
> >aspect ratio and play mode.
> >Making the event interface to a child process would avoid licensing
> >problems. Before I decided to build a solid-state relay box myself,
> >I searched for existing solutions. I found a manufacturer of
> >USB-controlled power outlets that appeared to supply Linux drivers.
> >Unfortunately, the driver turned out to be a closed-source library,
> >which couldn't be used in a vdr plugin without breaking the GPL.
> Just run a separate thread that checks your Setup parameter from
> time to time and otherwise sleeps. I don't think there's any need
> for an overly complex mechanism here.
In other words, that would be polling. The flag would have to be checked
several times per second, because otherwise the user interface feedback
would be poor. The user would press the Power button to resume vdr, and
nothing will happen until the thread happens to check the parameter. The
user might assume that the system failed to receive the button press, and
presses the button again. As a result, playback would remain suspended.
I would not like to poll the flag at 10 Hz, as it changes very rarely.
I believe that the licensing issue is irrelevant in most cases, since
the GPL does not prohibit the use of GPLed code with proprietary
modifications. It only prohibits the distribution of such hybrids.
> If this suspend stuff should go into core VDR (not before version 1.4,
> though) I could imagine adding a new cStatus function for this.
Thanks for the hint, I was not aware of the cStatus class (read: I'm a
newbie when it comes to vdr code). I will consider adding a cStatus
method to my patch.
More information about the vdr