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

Using EnumDisplaySettings() directly to query display depth has a high overhead when using the
XRandR 1.0 display device handler on some NVIDIA setups.

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

Cherry-picked from upstream commit 16f86bffec36b6e82e5c93d5f04ebc4ee4f980ab.

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

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

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

The pSignatureSettings field was not unitilized so it got a random value from
the stack causing a later crash when it was dereferenced in Wintrust
(SoftPubloadSignature).

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

An improvement of 5f0dcf79,
which, depending on theme, had an issue with
drawing the top border clipped inside the header.

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

I was unable to write tests for this; it seems it doesn't consistently work on
Windows. However, Rayman 3 seems to rely on it; it maps the same buffer twice
immediately after creation, with DISCARD flags on both maps, and expects the
same address to be returned.

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

The code originally intended to achieve this by simply waiting on flushing_cs,
and having the application thread hold flushing_cs while seeking. Unfortunately,
this can result in starvation of the application thread, since the streaming
thread always reacquires flushing_cs immediately after releasing it. Avoid this
by using a separate condition variable.

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53403Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>

The code previously relied on inherent atomicity of atomic types, but atomicity
doesn't imply the right memory ordering. Be explicit about the threading model
we want.
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>

Avoid using the pronouns "u", "uw", "je" and "jouw".
Signed-off-by: Floris Renaud <jkfloris@dds.nl>

Starting with Win10, height of multiline edit controls no longer seems
to be hardwired to a multiple of the font height (when larger than
font height).

- Adapt the tests accordingly (detecting how to compute the expected
  height of a control).
- Extend the ranges of the tested heights.

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

Already fixed in user32/tests/edit.c by
614b7d74

Apply same fix for equivalent test on comctl32/tests/edit.c

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

Return WHEEL_DELTA for the granularity of the mouse z-axis.

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

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

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

This fixes a regression introduced by ebbcc10b.
Prior to that commit, buffers which were not CPU-accessible would not have the
WINED3D_BUFFER_USE_BO flag set, and accordingly
buffer_resource_sub_resource_map() would simply return the SYSMEM location,
ignoring the DISCARD and NOOVERWRITE flags.

However, the "accelerated" path in wined3d_cs_map_upload_bo() only checks for
the DISCARD flag, assuming that it is only set for dynamic GPU-accessible
buffers, and would subsequently try to allocate non-mappable memory and then map
it.

This commit avoids the accelerated path for such buffers, once again matching
our old behaviour. According to [1], this also matches Windows: DISCARD on
SYSTEMMEM buffers is ignored on both AMD and NVidia, and NOOVERWRITE is ignored
on NVidia (but not AMD).

[1] https://www.winehq.org/mailman3/hyperkitty/list/wine-devel@winehq.org/message/XACSAVAGYTJUZDFLX4JWO665VTB6M7LX/

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

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53743Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>

Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>