Eric Pouch wrote:
I've been on vacation for a few days but want to comment on this.
for it, as rolf kalbermatter pointed out in http://www.winehq.com/?issue=274#Video%20Capture%20in%20Windows
as already stated, drivers should be written as follows: 1/ since it's wine specific, its name should start with wine (so winevfw or whatever)
We agree here all I think. The postfix may be an issue but the rest is very clear. The idea to try to create one driver for all possible APIs looks like a good one, at least if Alexandre doesn't feel bad about to many conditional compilation macros to support the different possible APIs (if any, I'm only a little bit familiar with v4l)
2/ the driver shall be a driver for both avicap and qcap DLL
As far as I can see it, this is also exactly as Windows does it. The VfWCaptureFilter really is just a DirectShow wrapper around the same installable driver interface as is used in avicap.
3/ interfaces to the driver should be the regular windows' ones (fetch information on avicap driver interface, as well as DShow driver interface - DDK info on the Web are your friend)
Apparently there is indeed also a direct interface to WDM stream drivers somewhere, if you mean this with the DirectShow driver interface. However this has no importance for Wine as WDM drivers really are kernel mode drivers and therefore won't be possible to implement nor run in Wine at all.
From what I got from MSDN it appears that the DirectShow drivers implement
in kernel space a similar model as is available in user space through the DirectShow filters. The advantage of this is that data can be streamed between DirectShow drivers directly in kernel space through shared memory or similar resources to avoid context switches when transporting data between a capture device, a hardware mixer and a recording device.
VFWCaptureFilter is only a legacy interface to allow access to old style vfw drivers from DirectShow applications and only allows access to modern DirectShow drivers through the earlier mentioned vfwwdm32.dll installable driver and translation layer. As such it seems like a big detour to access WDM stream drivers through it but it seems to be what many applications including MSN Messenger are doing anyhow.
How Windows avoids double entries of WDM drivers in resource enumeration (one for the translation of the WDM driver through wfwwdm32.dll into a vfw device and one for the direct WDM driver) I haven't looked at nor when exactly the applicable entry in the system registry for a new vfw device based on the WDM driver model is created. Possibly this might be explicitedly part of the installation of a video capture device, an implicit part of some setupapi function when installing a video capture class device, or even implicitedly created by PnP whenever a PnP video device is detected.
Item 4/ has the following benefits:
- it's up to the driver, at runtime, to find out and setup
the existing physical devices
- you don't need to have fancy settings (configuration...),
which most users won't understand
Installable drivers support registering and unregistering (here called install and uninstall) as well as an optional configuration message dialog if necessary. While it seem not used in most examples I have seen nor in the wine audio drivers, it might actually be used here in wine to have the driver detect and add the necessary entries to the registry at some time during setup of wine. Maybe through winecfg or directly in the installation script?
Rolf Kalbermatter