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

[Robert Reif]

Eric Pouech wrote:

> I do think all the recent changes to winecfg are going into the wrong 
> direction.
>
> First of all, allowing the devices to be opened more than once without 
> having the devices ready for that is a ready bad idea. Basically, 
> windows drivers come in two flavors:
> - single instance (they can be loaded only once in memory)
> - multiple instance (they can be loaded several times in memory)
> For the second type, a specific init string (gotten from the registry, 
> and usually dealing with the HZ resources involved) is passed to the 
> driver.
> In the wine implementation, we don't get anything from the registry, 
> we just let the device (from the unix interface it uses) return as 
> many audio/midi... ports it finds. This is typically the behavior 
> expected from single instance drivers. Among the issues we'll face 
> here are dual open of the same unix resource (contention) for several 
> instances, overwriting of internal data and structures (they are not 
> prepared for that).
> Therefore, the multiple open patch has to be reverted.

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.  I work with highend multichannel sound cards 
in windows that show up as a single 8 channel device (with one card or 
16 channels with two cards) and as 4  (8) stereo devices.

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

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

>
> Lately, the available drivers button is not really useful. We 
> shouldn't present non available drivers to the users, and just let 
> him/her choose among the available ones (or just to mark the ones 
> which are not available).
>
It would be trivial to only show the drivers that opened properly so 
missing drivers or non-functioning drivers would not be displayed.  You 
can infer that from the device tree now if no physical devices show up 
under a driver.  I could add icons to broken or disabled drivers (just 
like windows) to show driver/hardware state.  I also plan to add device 
and driver management to the device tree in future versions.  This is 
really just wine's version of the audio portion of windows device 
manager.  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.


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.  This can 
be avoided by doing the reconfiguration at wine reboot time (winmm.dll 
unload/load) or by checking for open drivers and using locking to 
prevent modifications by other programs.  You could also move the sound 
drivers into the server but that won't happen.