Hi Alexandre,
I implemented a driver model in qcap now, but avicap32 still uses my old #ifdef LINUX_VIDEODEV_H, since some people might be interested in writing capcreatecapturewindow, I think we should move out the drivers from qcap to our own vfwwine dll/driver, windows uses a similar model for it, as rolf kalbermatter pointed out in http://www.winehq.com/?issue=274#Video%20Capture%20in%20Windows
For the qcap drivers, I used some kind of COM model
typedef struct capturefunctions { ... Video_SetMediaType SetFormat; ... void *pMine; } Capture;
First, it tries to initialise, and lets the constructor function fill this struct, then if something is needed, it just calls Capture->SetFormat(Capture->pMine, parameters..), this is the qcap implementation, but I'm sure that if I write some parts of it so it will be DirectShow indepent, it can be used by avicap and qcap, I'm not really interested in avicap, but in the very least capgetdriverdescription should use the same code as qcap, because writing the same twice would mean a huge overhead.
So basically, I'm just wondering what to do, should I go ahead with the seperate driver dll or should I do something else?
Maarten
Maarten Lankhorst a écrit :
Hi Alexandre,
I implemented a driver model in qcap now, but avicap32 still uses my old #ifdef LINUX_VIDEODEV_H, since some people might be interested in writing capcreatecapturewindow, I think we should move out the drivers from qcap to our own vfwwine dll/driver, windows uses a similar model 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) 2/ the driver shall be a driver for both avicap and qcap DLL 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) 4/ a single driver shall be provided for all possible unix interfaces (you can start with v4l of course) and shall
Item 2/ has the following benefits: - it centralizes access to a given kernel resource in a single DLL - some information between the two types of interfaces may have to be shared
Item 3/ has the following benefits: - you can test the qcap, avicap... DLLs under windows with *real* drivers and see if it works - we can share all the qcap, avicap... DLLs with the folks from ReactOS - some braindead programs may look at some (real driver) interfaces for their own use
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
BTW this is was has to be done for the audio/midi drivers (where 1, 2, 3 are already done, and 4 is missing)
A+
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
-
Eric Pouech -
Maarten Lankhorst -
Rolf Kalbermatter