[BUG]: WebMidi report device manufacturer incorrectly as Microsoft Corporation

[tkpjmsm]

Windows Version

Windows 11 Home 25H2

Service Installation Method

Other (please indicate below)

SDK version, if appropriate

Windows update

Location

Other or Unsure (please indicate in additional notes section below)

Type of bug

Application not working as expected

Steps to reproduce

Microsoft Edge version 146.0.3856.78 JavaScript reports midi port manufacturer:

Expected behavior

The manufacturer should reflect the correct manufactures from the midi device.

Additional notes

Previously this was reported correctly.

[PeteBrown-MSFT]

A few questions for you

1. Why is this important in your scenario? What do you need to do with the information? In most cases, the manufacturer information is/was only available when using a third-party driver or our new MIDI2/MIDI1 driver which has a specific device call to return the Manufacturer name.
2. Which driver is in use with this device? I see it's an inMusic device, and so you are likely using our in-box driver with it.

I generally don't recommend making any app decisions based on string information. This has caused a ton of problems in the past and now. It also prevents using features like routing between endpoints, using Network to USB adapter devices, etc.

Pete
Microsoft

[tkpjmsm]

Hi Pete,

1. The system provides MIDI note maps to web clients based on the manufacturer, name, and version reported by the connected device. With an incorrect manufacturer, name, or version, the map cannot be provided. It also affects the management of MIDI maps in the backend.
2. The device is USB without any 3rd party drivers, using your in-box driver.

Before Windows update that applied recent changes to the MIDI interface, the device manufacturer was reported correctly.

I appreciate your recommendation not relying on string information, but in this case I am not aware of any alternatives to identify the connected MIDI device.

Regards,
Kobus

[PeteBrown-MSFT]

Please note that users have complete control over port naming now. They can use old-style WinMM port names, new-style port names, or completely rename the ports to whatever they want. Counting on port names is going to break.

For WinMM, you can get the VID/PID of the device using the WinMM Device Interface Info call. I don't recall if that's exposed through Web MIDI, but I suspect not. Also, there are new types of device remoting coming out using Network MIDI 2.0 to expose USB ports that could be on the other side of the room etc. which will potentially break all of these things. (We support both MIDI 1.0 and MIDI 2.0 devices on Network MIDI 2.0 through boxes like that).

How to DAWs get around this? For many devices, they send a SysEx device identity request.

Regardless, we'll see what we can do in Windows here, but even if we fix it today, the earliest it would get into Windows is end of May with a 30 day rollout period after that.

Pete
Microsoft

[PeteBrown-MSFT]

Out of curiosity where are you getting "version" from? That's not something USB devices report from their descriptors.

Pete
Microsoft

[tkpjmsm]

Thanks for the detail! I will look into SysEx to identify device in a reliable manner.

The "version" is reported by the WebMidi port object (image above). I am not doing anything special, just using vanilla APIs on the client side.

Kobus

[PeteBrown-MSFT]

Thanks for the detail! I will look into SysEx to identify device in a reliable manner.

The "version" is reported by the WebMidi port object (image above). I am not doing anything special, just using vanilla APIs on the client side.

Kobus

Thanks. I'll check the Chromium source to see where that value is coming from.

Pete
MIcrosoft

[PeteBrown-MSFT]

Taking some notes here.

Looking at the Chromium code, they do a lookup into a static table of USB VIDs and PIDs. They generate it at build time using this python script

https://github.com/chromium/chromium/blob/5f51c749f7954ed942f64d1609fabe3e23950909/services/device/public/cpp/usb/tools/usb_ids.py

It looks like they use the poorly-documented MIDIINCAPS2W for input devices and MIDIOUTCAPS2W for output devices.
https://github.com/chromium/chromium/blob/main/media/midi/midi_manager_win.cc

I just verified in our source that we don't populate the extended fields in that caps structure. Chromium source uses these values which we leave at default:

    GUID        ManufacturerGuid;       /* for extensible MID mapping */
    GUID        ProductGuid;            /* for extensible PID mapping */
    GUID        NameGuid;               /* for name lookup in registry */

It's possible WinMM base will populate that, but I suspect not. Will need to bring this one to Gary when he returns.

Internal bug 61561224

Pete
Microsoft