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

[Eric Pouech]

> 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 
ones.

[snip]

> 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

A+
-- 
Eric Pouech