This makes it consistent with the other drivers.
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This will make the Wow64 syscall rather simpler.
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Jacek Caban <jacek@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This matches the other drivers.
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Jacek Caban <jacek@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This ensures the subsequent allocation is free to pick a new location.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52202
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Andrew Eikum <aeikum@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Notifications of incoming data are now directly added to a notify
ring-buffer by macOS's midi read callback. The ring-buffer is
implemented with an unused sentinel directly before the read ptr to
distinguish between the full vs empty state. Notifications are
processed by the client's notify thread via the midi_notify_wait
syscall.
Note that the read callback thread is not a Win32 thread, so the
Win32 api cannot be used in anything that it calls.
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Andrew Eikum <aeikum@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Currently the thread just blocks until told to quit by midi_release.
Eventually, this thread will dispatch the MIM_DATA and MIM_LONGDATA
notifications and essentially replace the existing RunLoop-based
mechanism.
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Andrew Eikum <aeikum@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The motivation is that this will need to be called from a
non-Win32 thread and so shouldn't use the Win32 API. An
added benefit is that it will eliminate the 16ms jitter
associated with GetTickCount().
The instance of the helper on the user-side is temporary.
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Andrew Eikum <aeikum@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The headers are removed one at a time so that each notification
can be reported back to the client-side. If there are remaining
headers, the unixlib will return ERROR_RETRY to request that the
client calls again.
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Andrew Eikum <aeikum@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This matches the behaviour of the other instance of the invocation of
the MIM_LONGDATA callback.
It's rather difficult to reliably write a test for this, but it has
been observed to be the case on Windows.
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Andrew Eikum <aeikum@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
While these could be left on the user-side, it seems simplest to move
everything across.
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Andrew Eikum <aeikum@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Notifications are filled out by the unixlib and returned to
the user-side for dispatch.
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Andrew Eikum <aeikum@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
midi_init temporarily returns unix-side info, which will eventually
be removed.
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Andrew Eikum <aeikum@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
