http://bugs.winehq.org/show_bug.cgi?id=23975
--- Comment #10 from Jörg Höhle hoehle@users.sourceforge.net 2010-08-13 09:11:53 ---
winmm shall transfer to mci driver the hiword
Ok. Isn't that passed through untouched already?
in string handling should cover the cdaudio1 for device name
I fully agree. But as I wrote, I never saw an app need this, because nobody seems to have several drivers of the same type (save for MPEGVIDEO2).
cdaudio1=mcicda.drv 1
What's the trailing 1? http://msdn.microsoft.com/en-us/library/dd797882%28v=VS.85%29.aspx
From what I understood, the trailing number after cdaudio is the extra index
already. Perhaps there's no 1. The first string is mpegvideo, the second mpegvideo2. Yet MSDN above has an example with cdaudio1.
The mci driver must be passed by winmm an id to know which device id has to be opened.
No, see below.
Therefore, the following scheme has to be implemented
I think you should first test that on a native system with several devices (which kind of devices? MCI? hardware drivers?). I can't remember anything in MSDN like what you describe. Seriously, I doubt it.
all mci drivers must support (if relevant, ie mciwave is not relevant) the hiword in mci_open requests, with mci_open_type_id flag set. This lets the mci driver know which device (if several installed on computer) to open.
I don't understand when it's relevant and when not and how winmm could decide.
My conceptual model explains a lot of observations: A provider writes a device for his HW, let's say a blue ray reader. For the sake of the example he finds DEVTYPE_CDAUDIO appropriate (not DGV). The *installer* creates CDAUDIO1 = mciblue.dll because CDAUDIO is already present.
This can be opened either with "open type cdaudio2", by file extension when it maps to CDAUDIO1 or with (MCI_DEVTYPE_CDAUDIO|1<<16). The driver receives the MCI_OPEN command but it's *not* going to look at the content of lpstrDeviceType. That was the job of WINMM-MCI. If there are several blue-ray devices from the same manufacturer attached to the system, it's still the one mciblue.dll hardware driver that manages them all, and likely selects one based on lpstrElementName (like mcicda) or an extra set command (like mciseq and mciwave).