Robert Reif : winecfg: Added support for auto detecting all drivers by attempting to

[Eric Pouech]

Robert Reif wrote:
> Eric Pouech wrote:
> 
>>> We never "load" a driver more than once.  Winecfg calls winmm 
>>> OpenDriver which will only ever load a single instance of the driver 
>>> into memory.  Subsequent OpenDriver calls will reference the existing 
>>> in memory driver. Wine models the single instance device driver that 
>>> supports multiple physical devices. 
>>
>>
>> what you end up with is a situation where:
>> - two calls to OpenDriver for the same driver will provide:
>>     + a separate HDRVR (one for each call)
>>     + the same driver ID at the driver level
>>     + an implementation at the driver level with a single data state
>>           shared across the two HDRVR instance 
> 
> 
> This is true and is also how windows works with the tests I have done 
> with a user installable driver. The reason this works is because I am 
> only accessing the static driver configuration (GetNumDevs and 
> GetDevCaps).  I have no intention of actually using the drivers for 
> anything else because they are not designed for that. 
Here again, I'm not saying you *will* badly use the drivers (and your 
current code doesn't). But, the way you changed things can let someone 
do it (or a windows app), and we have no protection for that.

 > I am opening the
> driver, not the individual devices (WaveIn, WaveOut, ...). I agree that 
> under normal circumstances, bypassing winmm and accessing the driver 
> directly is the wrong thing to do because winmm is responsible for 
> coordinating things, but in this case and only this case (accessing 
> static driver configuration) it is OK.  

> The real way to do this would be 
> to have each driver register itself with the PnP manager and then we 
> could interface with it.  I am using winmm (OpenDriver) for loading and 
> configuring the drivers which is perfectly legal to do.  Only using 
> LoadLibrary and xxxMessage to get the number of devices and their 
> capabilities is the thing that is really questionable. A PnP manager 
> would fix that in the long term.
My concern here is that your changes require a driver to be opened (thru 
OpenDriver) twice (one time by winecfg, a second time at winmm startup). 
IMO, the target should be to implement the audio configuration in 
winecfg without requiring to open twice a driver. It's likely to boil 
down to let winmm do the core job.

> I guess I have a terminology misunderstanding here and should probably 
> reread my driver documentation.  I would like to see this class of 
> driver implemented so that only a single device shows up for a physical 
> device (multi channel cards being the exception).  Each wave device 
> could be opened more than once.  Each open would dynamically open a 
> connection to the mixing server.  In this case with a single physical 
> sound card, waveOutGetNumDevs will always return 1 and a waveOutOpen 
> will always succeed (within mixer server limitations).  This is how 
> windows works on versions that have kmixer (98SE up).
yup. this is also the way to go for a unified wine audio driver by the way.

A+

-- 
Eric Pouech