From d08073815d6d9132f7fb5cd9f82877967dc6b0e4 Mon Sep 17 00:00:00 2001 From: Klaus Schmidinger Date: Sun, 29 Sep 2002 18:00:00 +0200 Subject: Version 1.1.11 - Fixed an incomplete initialization of the filter parameters in eit.c (thanks to Jeremy Hall). - Fixed the 'newplugin' script for use with the NEWSTRUCT driver (thanks to Andreas Schultz for reporting this one). If you have already created a plugin directory and Makefile with 'newplugin', please apply the following patch to it: ------------------------------------------------------- --- Makefile 2002/06/10 16:24:06 1.4 +++ Makefile 2002/09/17 15:36:36 1.5 @@ -15,7 +15,12 @@ ### The directory environment: +ifdef NEWSTRUCT +DVBDIR = ../../../../DVB/include +DEFINES += -DNEWSTRUCT +else DVBDIR = ../../../../DVB/ost/include +endif VDRDIR = ../../.. VDRINC = $(VDRDIR)/include LIBDIR = ../../lib @@ -34,7 +39,7 @@ INCLUDES = -I$(VDRINC) -I$(DVBDIR) -DEFINES = -DPLUGIN_NAME_I18N='"$(PLUGIN)"' +DEFINES += -DPLUGIN_NAME_I18N='"$(PLUGIN)"' ### The object files (add further files here): ------------------------------------------------------- This is the diff for the 'setup' example that comes with VDR, so your line numbers may be different. - Added a missing 'public' keyword in device.h (thanks to Martin Hammerschmid). - Fixed a race condition when starting 'Transfer Mode'. - Rearranged the remote control key handling to allow plugins to implement additional types of remote controls (see PLUGINS.html, section "Remote Control"). The previously used files 'keys.conf' and 'keys-pc.conf' have been replaced by the file 'remote.conf', which holds the key definitions of all remote controls. - The LIRC remote control keys are now handled just like the keyboard and RCU keys. This means that you can use the lircd.conf file as is for your remote control, without the need of editing it to make the key names the same as used in VDR. When first starting VDR it will go into the "Learning keys" mode and ask you to press the various keys. The resulting key assignment will be stored in the file 'remote.conf'. Since I have no way of testing the LIRC support, I hope I didn't break it in the process... - While learning the remote control keys it is now possible to press the 'Menu' key to skip the definition of keys that are not available on your particular RC unit. - Fixed handling DVD subtitles in the SPU decoder (thanks to Andreas Schultz). - Avoiding restarts due to 'panic level' when switching channels on the primary device during EPG scan. --- PLUGINS.html | 140 ++++++++++++++++++++++++++++++++++++++++++++++++++++------- 1 file changed, 125 insertions(+), 15 deletions(-) (limited to 'PLUGINS.html') diff --git a/PLUGINS.html b/PLUGINS.html index 02fd59a..55e935b 100644 --- a/PLUGINS.html +++ b/PLUGINS.html @@ -21,18 +21,18 @@ VDR program and present itself to the user. The inside interface provides the plugin code access to VDR's internal data structures and allows it to hook itself into specific areas to perform special actions.

-
  -Important modifications introduced in version 1.1.6 are marked like this. -
-
  +
  Important modifications introduced in version 1.1.7 are marked like this.
-
  +
  Important modifications introduced in version 1.1.8 are marked like this.
-
  +
  Important modifications introduced in version 1.1.9 are marked like this.
+
  +Important modifications introduced in version 1.1.11 are marked like this. +

Part I - The Outside Interface

@@ -957,7 +957,7 @@ stream. There are no prerequisites regarding the length or alignment of an individual block of data. The sum of all blocks must simply result in the desired video data stream, and it must be delivered fast enough so that the DVB device doesn't run out of data. -
  +
  To avoid busy loops the player should call its member function 



@@ -1065,7 +1065,6 @@ enjoy additional players, since they will be able to control them with actions
 that they already know. If you absolutely want to do things differently, just go
 ahead - it's your show...
 
-
 
 
Receivers

 
 
Tapping into the stream...

@@ -1119,7 +1118,6 @@ cDevice::PrimaryDevice()->AttachReceiver(Receiver);
 
 If the cReceiver isn't needed any more, it may simply be deleted
 and will automatically detach itself from the cDevice.
-

 
 
The On Screen Display

 
@@ -1151,7 +1149,6 @@ to define an actual OSD drawing area (see VDR/osdbase.h for the declarations
 of these functions, and VDR/osd.c to see how VDR opens the OSD and sets up
 its windows and color depths).
 
-
 
 
Devices

 
 
Expanding the possibilities

@@ -1187,7 +1184,7 @@ the cDvbDevice, which is used to access the DVB PCI cards.
 If the new device can receive, it most likely needs to provide a way of
 selecting which channel it shall tune to:
 
-
 
+
 
 


 virtual bool ProvidesChannel(const cChannel *Channel, int Priority = -1, bool *NeedsDetachReceivers = NULL);
 virtual bool SetChannelDevice(const cChannel *Channel, bool LiveView);
@@ -1206,7 +1203,7 @@ A device that can be used for recording must implement the functions
 virtual bool SetPid(cPidHandle *Handle, int Type, bool On);
 virtual bool OpenDvr(void);
 virtual void CloseDvr(void);
-
 
+
 
 virtual bool GetTSPacket(uchar *&Data);
 

 

@@ -1230,7 +1227,7 @@ to indicate this to VDR.
 

 The functions to implement replaying capabilites are
 
-
 
+
 
 


 virtual bool HasDecoder(void) const;
 virtual bool SetPlayMode(ePlayMode PlayMode);
@@ -1254,7 +1251,7 @@ virtual void SetVideoFormat(bool VideoFormat16_9);
 virtual void SetVolumeDevice(int Volume);
 

 
-
 
+
 
 

 On Screen Display
 

@@ -1294,7 +1291,120 @@ Nothing needs to be done to shut down the devices. VDR will automatically
 shut down (delete) all devices when the program terminates. It is therefore
 important that the devices are created on the heap, using the new
 operator!
-

+
+
 
+
Remote Control

+
+
The joy of zapping!

+
+There are several ways to control the operation of VDR. The builtin methods
+are using the PC keyboard, a homebuilt RCU unit or the LIRC interface.
+Of course there may be many more ways you might think of to implement a
+remote control, so a plugin can use the cRemote class to do that.
+

+The simplest method for a plugin to issue commands to VDR is to call the
+static function cRemote::Put(eKeys Key), as in
+
+


+cRemote::Put(kUp);
+

+
+In this case the plugin must do the mapping of whatever incoming signal or code
+it processes to the eKeys values itself. This makes sense if the incoming
+codes are well known and won't ever change.
+

+In cases where the incoming codes are not known, or not all available keys may
+be supported by the actual remote control in use, you may want to derive your
+own remote control class from cRemote, as in
+
+


+#include <vdr/remote.h>
+#include <vdr/thread.h>
+
+class cMyRemote : public cRemote, private cThread {
+private:
+  virtual void Action(void);
+public:
+  cMyRemote(const char *Name);
+  virtual bool Initialize(void);
+  };
+

+
+Note that deriving from cThread is not required for a remote control
+class to work, but typically you may want to have a separate thread running that
+collects the input and delivers it to the cRemote base class.
+

+You should create your derived remote control object in the
+Start() function of your plugin.
+Note that the object has to be created on the heap (using new),
+and you shall not delete it at any point (it will be deleted automatically
+when the program ends).
+

+The constructor of your remote control class should look like this
+
+


+cMyRemote::cMyRemote(const char *Name)
+:cRemote(Name)
+{
+  Start();
+}
+

+
+The Name is important in order for the cRemote base class
+to be able to distinguish the codes for the various remote controls.
+When creating your cMyRemote object you should use the value returned
+by the Name() member function of the plugin class, which returns the
+plugin's name. Calling Start() will start the thread that collects
+the incoming data (by calling your Action() function).
+In case you need to do any other setup steps, like opening a file or initializing
+member variables, you should do so before calling Start().
+

+VDR will handle everything necessary to learn the key mappings of your remote
+control. In order to do so, it will first call the virtual function Initialize(),
+in which you should take all necessary steps to make sure your remote control
+can be accessed. This may, for instance, include trying various communications
+protocols. Initialize(), if implemented, shall only return after it has
+made sure data can be received from the remote control. Before calling this
+function, VDR will prompt the user on the OSD to press any key on the remote control.
+As soon as your derived cRemote class has detected useful incoming data,
+Initialize() should return true. If any fatal error occurs, false
+should be returned.
+

+If your remote control class needs some setup data that shall be
+readily available next time VDR starts (without having to go through the initialization
+procedure again) it can use the cRemote member functions
+
+


+void PutSetup(const char *Setup);
+const char *GetSetup(void);
+

+
+to store and retrieve a character string containing whatever data is needed.
+Note that the Initialize() function will only be called if there are
+no key mappings known for this remote control. Once the key mappings have been
+learned, Initialize() will never be called again.
+

+The cRemote class assumes that any incoming remote control code can be
+expressed as a character string. So whatever data your remote control provides
+needs to be given to the base class by calling
+
+


+Put(const char *Code, bool Repeat = false, bool Release = false);
+

+
+where Code is the string representation of the remote control's
+incoming data. Repeat and Release are boolean flags that
+indicate whether this is a repeated keypress, or the key has been released.
+Since a common case for remote control data is to be given as a numerical
+value, there is another Put() function available for your convenience,
+which takes a 64 bit unsigned integer value instead of a character string:
+
+


+Put(uint64 Code, bool Repeat = false, bool Release = false);
+

+
+The other parameters have the same meaning as in the first version of this function.
+

 
 
 
-- 
cgit v1.2.3