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+