Robert Reif : winecfg: Added support for auto detecting all
drivers by attempting to
eric.pouech at wanadoo.fr
Sat Dec 10 13:53:36 CST 2005
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.
More information about the wine-devel