No subject

x=0D
already.=0D
Perhaps there's no 1. The first string is mpegvideo, the second mpegvideo2.=
 Yet=0D
MSDN above has an example with cdaudio1.=0D
=0D
>The mci driver must be passed by winmm an id to know which=0D
>device id has to be opened.=0D
No, see below.=0D
=0D
>Therefore, the following scheme has to be implemented=0D
I think you should first test that on a native system with several devices=
=0D
(which kind of devices? MCI? hardware drivers?).  I can't remember anything=
 in=0D
MSDN like what you describe.  Seriously, I doubt it.=0D
=0D
>all mci drivers must support (if relevant, ie mciwave is not=0D
>relevant) the hiword in mci_open requests, with mci_open_type_id flag set.=
 This=0D
>lets the mci driver know which device (if several installed on computer) t=
o=0D
>open.=0D
I don't understand when it's relevant and when not and how winmm could deci=
de.=0D
=0D
My conceptual model explains a lot of observations: A provider writes a dev=
ice=0D
for his HW, let's say a blue ray reader. For the sake of the example he fin=
ds=0D
DEVTYPE_CDAUDIO appropriate (not DGV).  The *installer* creates CDAUDIO1 =
=3D=0D
mciblue.dll because CDAUDIO is already present.=0D
=0D
This can be opened either with "open type cdaudio2", by file extension when=
 it=0D
maps to CDAUDIO1 or with (MCI_DEVTYPE_CDAUDIO|1<<16).  The driver receives =
the=0D
MCI_OPEN command but it's *not* going to look at the content of=0D
lpstrDeviceType.  That was the job of WINMM-MCI.  If there are several blue=
-ray=0D
devices from the same manufacturer attached to the system, it's still the o=
ne=0D
mciblue.dll hardware driver that manages them all, and likely selects one b=
ased=0D
on lpstrElementName (like mcicda) or an extra set command (like mciseq and=
=0D
mciwave).=0D
=0D
-- =0D
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=3Demail=0D
Do not reply to this email, post in Bugzilla using the=0D
above URL to reply.=0D
------- You are receiving this mail because: -------=0D
You are watching all bug changes.=