The first parameter is defined as const BLUETOOTH_DEVICE_INFO in MSDN and bluetoothapis.h.

Signed-off-by: Connor McAdams <cmcadams@codeweavers.com>

Signed-off-by: Connor McAdams <cmcadams@codeweavers.com>

Signed-off-by: Connor McAdams <cmcadams@codeweavers.com>

Signed-off-by: Connor McAdams <cmcadams@codeweavers.com>

As background information from Windows testings:
- the debug port event is closed upon thread regular exit.
- results are however inconsistent across Windows versions for forced
  termination (through TerminateThread and equiv).
- this is moreover crippled by most of the 32bit implementation on Windows
  (except Win8) which don't enforce the close on exit flag for wow64 debuggee:s
  (they enforce it for 64bit though)
- but, in the cases where the debuggee terminates, the debug port is
  always closed *after* the debuggee process termination.

So I adapted the tests to conform to "debug port is closed" when handling
the thread termination. Some tests had to be moved *after* debuggee
termination to ensure success.

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53144Signed-off-by: Eric Pouech <eric.pouech@gmail.com>

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54534Signed-off-by: Eric Pouech <eric.pouech@gmail.com>

Signed-off-by: Eric Pouech <eric.pouech@gmail.com>

This implements the reduced fragmentation from the heap frontend, by
carving smaller blocks out of larger allocated blocks.

The super block and each sub-block are all flagged with BLOCK_FLAG_LFH.

The super-block (struct group) uses a standard struct block header, as
well as a list entry to be linked in free list, and a free bit map to
track free sub-blocks.

Sub-blocks reference their super block through the base_offset, instead
of the subheap, using the block size as radix.

We need this for larger LFH block bin steps. Use smaller block types to
get more space, they are somewhat redundant with the block flags.

We should probably ignore all incorrect ports. This is a minimal change
that restores 5dadeeb2 commit.

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54379

We're storing it now in DC attributes.

Normally, a new window_surface has no damage so its draw_start_ticks
value is reset at the time of the first lock_surface.

However, if contents from the old window_surface are copied to the new
one when the window_surface for a window is updated, the new
window_surface will be initially damaged. We want to reset the
draw_start_ticks value in this case too, to avoid flushes occuring soon
after such updates, during the initial redraw of the window_surface.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>

Track ticks since draw start per window_surface, instead of per DC as is
currently the case. This change helps reduce visual glitches caused by
badly timed flushes when drawing to the same window_surface from
multiple DCs (e.g., for child windows).

This approach is a better fit for the current heuristic for forcing
flushing, which consults the shared window_surface bounds to decide
whether this is the start of a draw in order to reset the (currently per
DC) draw start time.

The problem in the current implementation occurs when a drawing to a DC
begins with an already damaged window_surface, e.g., due to draws from
other DCs targeting that window_surface. In such a case, the DC draw
start time is not reset and refers to the start of some previous draw
sequence using this DC, thus increasing the chances that the 50ms time
flush limit will be eventually exceeded in the middle of the current
draw sequence. In other words, the state of the (shared) window_surface
damage is not a reliable indicator of the beginning (or not) of a draw
to a DC.

An example, assuming DC1 and DC2 target the same window_surface:

DC1.start_ticks = 0
DC2.start_ticks = 0
FLUSH_PERIOD = 50

0 flush
1 draw to DC1 -> DC1.start_ticks = 1
... [no flush] ...
2 draw to DC2 -> DC2.start_ticks remains 0 since surface is damaged
...
50 flush
51 draw to DC1 -> DC1.start_ticks = 51
... [no flush] ...
52 draw to DC2 -> DC2.start_ticks remains 0 since surface is damaged,
                  current - DC2.start_ticks > FLUSH_PERIOD so we are
                  forced to flush in the middle of the drawing
                  sequence => potential glitch

Tracking the draw start per window_surface ameliorates the problem
because the beginning of a draw on a DC targeting an undamaged
window_surface resets the start time for all DCs targeting that
window_surface:

...
50 flush
51 draw to DC1 -> surface.draw_ticks = 51
... [no flush] ...
52 draw to DC2 -> surface.draw_ticks remains 51 since surface is damaged,
                  but current - surface.draw_ticks < FLUSH_PERIOD, so we
                  do not flush
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54112