Thanks for the info. I had not seen these VirtualChannelInit things
before, but now I think I am more clear on the design.
Another question regarding the printing virtual channel (maybe
off-topic). The original rdesktop uses "lpr", which is bad I think. How
about replacing it with CUPS API for Linux? Windows API for Windows? If
so, looks like it's going to be something like printer_cups.so,
On Sat, 2009-12-05 at 18:51 -0500, Marc-André Moreau wrote:
> I still do not think that the UI should be provided with a
> "freerdp_list_available_plugins" function. In fact, all the UI should
> care about is the name used to refer to the virtual channel. If I'm
> not mistaken, for audio redirection the virtual channel name is
> "rdpsnd". The virtual channel name is given by the plugin in a
> CHANNEL_DEF structure:
> Reading quickly the documentation on the virtual channel plugin API,
> each plugin must export a VirtualChannelEntry function that will
> receive a pointer to a structure containing pointers to functions.
> Those function pointers are given in a CHANNEL_ENTRY_POINTS structure.
> The plugin must then use the pointer to VirtualChannelInit in order to
> register a virtual channel. This is where the CHANNEL_DEF structure
> contained the virtual channel name is given. Obviously, two plugins
> trying to register the same virtual channel name are going to
> conflict. Some virtual channel names are defined by the documentation,
> such as rdpsnd. Those names could be used by libfreerdp to know that
> sound support is available (not successfully loading a virtual channel
> plugin registering "rdpsnd" would result in providing no sound
> redirection, may it be because the user wanted it or because it failed
> to load).
> Looking at the documentation, the virtual channel name for clipboard
> redirection is "cliprdr". What the UI should care about is only
> that.For instance, if the UI wants sound support, it should tell
> libfreerdp to load an "rdpsnd" plugin. libfreerdp would then choose
> the most suitable plugin, and attempt to load it. Same would go for
> clipboard redirection. Now there is the problem that for a given
> virtual channel there will be more than one plugin available. I
> suggest that plugins be named first by their virtual channel name,
> followed by anything that can be used to distinguish them from the
> others. For instance, we currently have multiple "rdpsnd_*.c" files.
> Those could become plugins named:
> When the UI would request sound support, it would call a function
> taking two arguments. The first argument would be the virtual channel
> name. The second would be a specific name used to distinguish it from
> the others. Just to get the idea:
> load_virtual_channel_plugin("rdpsnd", "alsa"); would tell libfreerdp
> to load the sound redirection plugin using alsa. The second argument
> would also need to be optional, where the UI could pass a NULL instead
> and just provide the virtual channel name. In this case, freerdp would
> simply choose which rdpsnd_*.so plugin is more suitable, with compile
> time flags.
> Ok, yeah, I started saying we shouldn't have a
> freerdp_list_available_plugins() function. However, if there is no
> rdpsnd_*.so plugin available the UI must know in advance so that it
> doesn't propose it to the user. What could be done in this case is a
> function that returns a list of virtual channel names along with the
> specific names. As the virtual channel names are defined in the
> documentation, it's easy to check that sound is supported by checking
> for availability of "rdpsnd" in the list. Third party plugins would
> appear in that list also, not necessarily requiring a "specific name",
> but could be proposed to be enabled to the user in the UI.