Skip to content

MIDI device hotplug: detect devices plugged in after Wine start (dynamic enumeration) #7

Description

@giang17

Problem

When a MIDI device (e.g. a USB master keyboard) is plugged in / switched on after Wine (and a DAW such as Reaper) is already running, it is not detected. The DAW's MIDI device list and its "retry/refresh" do not pick it up; a previously-selected input shows as <not found>. Only restarting Wine/DAW with the device already on makes it appear.

Root cause (confirmed via WINEDEBUG=+midi,+alsa,+winmm trace)

winealsa enumerates MIDI ports once at load time into the static srcs/dests arrays in dlls/winealsa.drv/alsamidi.c. After that:

  • winealsa does not subscribe to the ALSA system-announce port, so it never receives SND_SEQ_EVENT_PORT_START when a new sequencer port appears.
  • winmm caches the device count/caps from that one-time enumeration and does not re-query the driver on midiInGetNumDevs / midiInGetDevCaps.

Net effect: a device not present at Wine start is invisible forever, no matter how often the DAW retries. Confirmed in a trace: at start winealsa enumerated 5 inputs (System, PipeWire×2, Midi Through, M4, nanoKEY2); after switching on an absent KM88 keyboard there was zero activity in the winealsa record thread — no announce event, no PORT_START. Reaper's "retry" re-queried midiInGetDevCapsW for devices 0–4 (the cached set) and never saw a device 5.

Proposed fix — three layers

Layer What Reference
1 winealsa: subscribe to the system-announce port → receive PORT_START part of shibco/ableton-linux patch 0028
2 winealsa: on PORT_START, port_add a brand-new device into srcs/dests (not just re-attach an existing one) 0028 only re-attaches known devices; it does not add new ones
3 (the hard part) winmm: invalidate / refresh its device cache when the driver's device set changes Wine has no mechanism for this today — a winealsa→winmm device-change signal + re-enumerate would need to be built

Layer 3 is the crux. Even with srcs/dests updated in winealsa, a DAW's midiInGetDevCaps / midiInGetNumDevs hits the winmm cache, not the driver — so the new device stays invisible until winmm re-enumerates. Solving only layers 1–2 (winealsa) is not enough; the DAW still won't see the new device.

Related

  • shibco/ableton-linux patch 0028 ("re-subscribe MIDI devices when they reappear") solves only the re-attach case (device present at start, briefly removed/replugged). The brand-new-after-start case tracked here is not covered.
  • This is a general Wine gap, not specific to this fork.

Workaround (until fixed)

Switch the device on before starting Wine/DAW, so it is present in the one-time static enumeration.

Scope note

This issue concerns the winmm / winealsa (classic MIDI) path used by DAWs such as Reaper. Separately, some applications use the WinRT MIDI API (Windows.Devices.Midi.MidiInPort), which Wine does not implement at all (dlls/ has windows.devices.bluetooth, .enumeration, .usb, windows.media.devices — but no windows.devices.midi). That is a different, larger gap.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions