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

[Robert Reif]

Eric Pouech wrote:

> 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+
>
It is not typical for an application to bypass winmm and communicate 
directly with a driver.  Only a control panel or device manager type 
application would ever even try something like this.  Winecfg is one of 
those unusual programs.  Opening a driver more than once will not cause 
any problems.  The open functions in all the drivers are just stubs.  
Loading a driver is what causes a drivers state to be initialized and 
there is no way going through winmm to load the same driver more than 
once.  Trying to open a specific driver's device through for example 
waveOutOpen more than once either through winmm or directly to the 
driver will only allow the first open to succeed because all attempts 
after the first will see that the device is already opened and fail.