Robert Reif : winecfg: Added support for auto detecting all
drivers by attempting to
eric.pouech at wanadoo.fr
Sat Dec 10 03:53:56 CST 2005
> 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
- most of the drivers are not prepared for that. As a simple example:
h1 = OpenDriver("a.drv", ...);
h2 = OpenDriver("a.drv", ...);
// h1 <> h2, but driver ids are the same
// start a play back on one of media stream of a.drv with h1
CloseDriver(h2, 0, 0);
// playback will stop, and all data of h1 have been cleared
// by closing h2 !
>> Secondly, I do think it's a bad idea to reconstruct in winecfg most
>> the driver management. It's not done correctly (the DRV_INIT,
>> DRV_ENABLE and DRV_LOAD messages are not correctly passed). If it
>> works today, it's by chance as the configure message is never handled
>> (we just put out a message box), but it doesn't access the internal
>> structures. To do it, we need the DRV_ messages sent.
> It is true that winecfg is not calling each sub system driver (WaveIn,
> WaveOut, ...) like windows but device probing is done at main driver
> load in most drivers (and I am fixing the ones that don't) because
> device configuration is dynamic rather than read from the registry so
> opening the sub drivers individually to query static data is not a
> problem. I have a version of the alsa driver that can change registry
> entries from the configure dialog.
yes, but it implies that all drivers configured by winecfg must be
single instance drivers.
>> Finally, I'm not sure that presenting all the drivers, and the ports
>> available is really meaningful for most users. Some drivers return
>> just potential entries (esound for example). Even with the caps, most
>> users won't tell the difference between alsa and oss entries.
> Jack and esound are fundamentally flawed because they create 10 virtual
> sound cards that all reference a single physical device. This doesn't
> take into account multiple devices. The proper way to implement this is
> to allow multiple opens of the same device (just like windows). That
> way two or more programs can open one card and other programs can open
> another card and none of the programs are aware or even care about the
> others. I have multiple sound cards and headsets in a single computer
> for music and VoIP and I need a way for individual programs to work with
> specific devices (just like in windows).
we do agree here that jack & esound (like any interface with integrated
audio mixer) should be multiple instance drivers and not single instance
> Hiding stuff in the registry without giving the user an easy
> way (GUI rather than reading the source and using regedit) of
> configuring the sound system is not good.
that's not what I'm asking for. I request having even for winecfg driver
loading/unloading to be handled through winmm, and not by winecfg
itself, which forces you in lots of unneeded kludges.
> The direction I am trying to take the winecfg it to allow specific
> driver configuration through the windows DRV_CONFIGURE mechanism which
> displays a driver specific dialog box for changing driver specific
> registry entries. This is the only time there is potential contention
> problems between programs but only if configuration is performed
> immediately while the other programs are accessing the driver.
that's not true see above
More information about the wine-devel