qcap/avicap and driver models

Eric Pouech pouech-eric at wanadoo.fr
Sun May 22 02:33:34 CDT 2005


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 Pouech




More information about the wine-devel mailing list