Basically applications have two obvious ways to use video capture services in Windows. One is avicap32.dll which is basically the Video for Windows way of doing this and the other one is ActiveMovie/DirectShow, soon to be obsoleted by Microsoft as well, as it seems.
Avicap32 implements two functions, one is for the enumeration of the VfW devices registered in the system. For this it does enumerate all entries in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\MediaResources\msvideo and for compatibilty reasons with 16bit Windows also in the Drivers32 section in system.ini. I have an untested version of this code already. The enumeration function does not try to detect any devices other than what it finds in above mentioned places. I assume that a webcam driver installation would have to do that. The second function in Avicap32.dll creates a (hidden) window which handles the actual interaction with the video device as well as being an optional user interface for the video data. The communication with the video device is always by so called installable drivers, like wineoss, etc. is used for audio devices. The interface to these installable video drivers is for the video device specific parts declared in a header file msviddrv.h which is really part of the DDK. (How would we add that to the Wine headers?) In modern Windows systems there is one MS provided installable driver vfwwdm32.dll, which is basically a translation layer between the installable interface and modern WDM stream based video drivers.
We are not windows, using HKLM/SYSTEM/.../msvideo would not be an option imho, because when should we write it? And what if you just connected your webcam and modprobe'd the drivers for it, it would make things too difficult. I think the best way is to use winmm like dsound/etc uses, and add a configure option in ~/.wine/config so you can select what video driver you want to use. Since I don't exactly know how winmm works, some insight in how (for example) the sound drivers in winmm are called/used would be more then welcome, since, unlike the rest of the stuff I worked upon until now was well documented, but I doubt winmm is...
Maarten Lankhorst
On 5/14/05, Maarten Lankhorst m.b.lankhorst@gmail.com wrote:
We are not windows, using HKLM/SYSTEM/.../msvideo would not be an option imho, because when should we write it? And what if you just connected your webcam and modprobe'd the drivers for it, it would make things too difficult. I think the best way is to use winmm like dsound/etc uses, and add a configure option in ~/.wine/config so you can select what video driver you want to use. Since I don't exactly know how winmm works, some insight in how (for example) the sound drivers in winmm are called/used would be more then welcome, since, unlike the rest of the stuff I worked upon until now was well documented, but I doubt winmm is...
We are currently phasing out .wine/config. The plan is to have winecfg ready by the end of June, and remove the config file at the same time. winmm uses a location in the registry to determine which driver to use. Writing to HKLM/SYSTEM/... etc is not out of the question; the win32 api does it, and wine is an implementation of this api. There are several possible times to right this registry data (I'm not here to say which one is best or correct). It can be put in wine.inf which the registry is loaded from, or can be written during a DllRegisterServer call.
James Hawkins wrote:
On 5/14/05, Maarten Lankhorst m.b.lankhorst@gmail.com wrote:
We are not windows, using HKLM/SYSTEM/.../msvideo would not be an option imho, because when should we write it? And what if you just connected your webcam and modprobe'd the drivers for it, it would make things too difficult. I think the best way is to use winmm like dsound/etc uses, and add a configure option in ~/.wine/config so you can select what video driver you want to use. Since I don't exactly know how winmm works, some insight in how (for example) the sound drivers in winmm are called/used would be more then welcome, since, unlike the rest of the stuff I worked upon until now was well documented, but I doubt winmm is...
We are currently phasing out .wine/config. The plan is to have winecfg ready by the end of June, and remove the config file at the same time. winmm uses a location in the registry to determine which driver to use. Writing to HKLM/SYSTEM/... etc is not out of the question; the win32 api does it, and wine is an implementation of this api. There are several possible times to right this registry data (I'm not here to say which one is best or correct). It can be put in wine.inf which the registry is loaded from, or can be written during a DllRegisterServer call.
Well, I think both methods wouldn't be the best way, in that case, you would have to restart whole wine as soon as a new webcam is modprobe'd, I know wine is a reimplementation of the windows api, but the drivers are very different from those in windows, because we don't have to call drivers directly now, but instead merely relay it to other driver models, I think using a wine-only dll would be best. Since there is only 1 capture system per platform, we could use configure scripts to determine what capture driver to use, if any, and possibly allow clues with --with(out)-videocapture(=...). Currently I already use something similar: - v4l.c (Compiled only if videodev.h (V4l) is found) - null.c (Compiled only if videodev is not found)
Vfw driver dlls (in windows) apparantly start with vfw, so I suggest the name of the dll should be vfwwine.dll, and that we link to it from avicap32 and qcap.
Maarten Lankhorst
-
James Hawkins -
Maarten Lankhorst