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