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.
