Re: [GnomeMeeting-devel-list] Towards a new video driver support in pwlib

[PUYDT Julien <julien puydt laposte net>]

Le lun 28/07/2003 à 16:21, Damien Sandras a écrit :

> > The way I think about it, the PVideoInputDevice class should be a
> > plugin-manager class, and could be used not only for linux, but also for
> > any reasonable system (POSIX?). The rest would be plugins.

Bah, not possible: PVideoInputDevice shouldn't add anything
platform-specific; that really should be a PVideoPluginInputDevice, or
something like this...

> > A plugin would have a prefix (V4L, IEEE1394AVC, IEEE1394DC, ...), and
> > add it to the list of devices it thinks can handle, so that the manager
> > would know which plugin to use when asked to open "[V4L]/dev/foo"; that
> > would allow the manager to do its magic, without breaking all apps.
> > 
> 
> I agree with this approach. I would use that approach if I had to code
> it myself.

I think there will be a list of pairs: (name, handle) for the devices.
The handle being itself a struct with some information (like: the
dl_handle, the callbacks for function calls...)

> > == Questions ==
> > 
> > The main question is: when do we load the plugins, and thus know what we
> > have at disposal? We don't really want to scan them twenty times, but we
> > don't want to change the way the programs that use pwlib work, and I
> > find it a little tricky; looking at the way a gm does device detection:
> > gw->video_devices = PVideoInputDevice::GetInputDeviceNames ();
> > gw->video_devices += PString (_("Picture"));
> > there is no created PVideoInputDevice at that moment, but since we want
> > to return the device names, we need the plugins!
> > 
> 
> That is indeed a tricky problem. What about loading/unloading the
> different plugins when detecting devices?
> 
> ie:
> - plugin1, plugin2 are available
> - /dev/video0 is a video device
> - /dev/video0 can not be opened with plugin1 but can be opened with
> plugin2, we remember it
> 

I had another idea: if the manager is called for whatever reason and its
list of plugins is empty, it loads them. That would be something like:
if (plugin_list == NULL) load_all_plugins();
at the beginning of each function... (or at least some of them)

> > PVideoInputDevice *grabber;
> > grabber = new PVideoInputDevice();
> > grabber->SetPreferredColourFormat (color_format);
> > ...
> > when PVideoInputDevice() is called, looks like a good moment to load
> > plugins, but I think it is already too late as gm already tried to get
> > the devices names...
> > 
> 
> That could be done inside PVideoInputDevice. When detecting the devices,
> you could try to remember what plugin was able to correctly open the
> device, so when the user calls the "Open" method, you automatically load
> the plugin.

Well, the idea above should take care of it.

> > And there's also the little technical detail that I don't know (yet) how
> > to code a plugin in C++. Already done so in C with dlopen...
> > 
> 
> That is exactly the same in C++ + some tricks required because of symbol
> mangling.

That were the tricks that bothered me; found this:
http://www.tldp.org/HOWTO/C++-dlopen/thesolution.html

Now, let's get into more details:
* the plugin should stuff pointers to the functions that it is supposed
to provide (ie: members of PVideoInputDevice) in a struct;
* in the same struct: put the plugin name "BAR";
* it will provide as extern C a function that gives a pointer to this
struct, so the manager can do plugin_struct->open(...); that will allow
to get everything needed with only a dlsym;

The PVideoPluginInputDevice inherits PVideoInputDevices, and adds:
* a selected plugin;
* private(or is it called protected?) functions to load/unload plugins;

Things I should worry about:
* the list of plugins should be common to all members of the
PVideoPluginInputDevice class; probably a static something outside of
the class declaration;
* the selected plugin should be member-specific, so a program that would
like to open several videodevices could do so!

This looks like perhaps I won't have that much to code to turn existing
drivers into plugins...

Is there some problem I overlooked?

Snark