Commit f37b953e07 (ntdll: Support both HP-UX-like libunwind and LLVM
libunwind error codes., 2021-12-10) made an unsuccessful attempt to fix
UNW_ENOINFO detection on LLVM libunwind. It turns out that UNW_ENOINFO
is actually negative in LLVM, so there's no need to flip the sign.
Fix this by flipping the return value sign only when UNW_ENOINFO < 0
(LLVM libunwind), and then comparing it against the negated error code.
Overall, all flavours of libunwind return a negative value on error.
Signed-off-by: Jinoh Kang <jinoh.kang.kr@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Commit 8c93549262 introduced a feature level
11.0 requirement for Direct2D, but that was unintentional. We want Direct2D to
be usable with feature level 10.0 hardware, and don't actually require any
feature level 11.0 features.
This issue was pointed out by Matteo Bruni.
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Matteo Bruni <mbruni@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
With help from Dmitry Timoshkov.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51790
Signed-off-by: Hans Leidekker <hans@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Fixes the failure of the test at dlls/nsi/tests/nsi.c:679 on certain
testbot machines.
Signed-off-by: Alex Henrie <alexhenrie24@gmail.com>
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Based on a patch from Zebediah Figura <zfigura@codeweavers.com>.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Andrew Eikum <aeikum@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
When thread shuts down, instead of holding and releasing a module ref.
This keeps the thread alive until the module is unloaded, instead of
keeping track of live IDirectInput instances.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This makes it easier to "unwind" through the CS thread when debugging.
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This reverts commit 908fb50728.
Moved to wined3d_cs_packet_{in/de}cref_objects().
Signed-off-by: Jan Sikorski <jsikorski@codeweavers.com>
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This reverts commit 0056ebf91e.
Sampler references in deferred contexts are now managed by inspecting CS
packets.
Signed-off-by: Jan Sikorski <jsikorski@codeweavers.com>
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
These are part of the public API, so there's not need for them to be at
the start of the file.
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
HP-UX libunwind uses the sign of error code to indicate whether the
operation was successful; however, LLVM always returns positive error
codes.
Normalise the sign of the error code so that it handles all flavours of
libunwind.
Signed-off-by: Jinoh Kang <jinoh.kang.kr@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This partially reverts b431dceeca, which
followed some misleading SDL comment, as well as the original dinput
evdev backend code, and resulted in inverted directions instead.
On the Linux drivers side, both in the PID driver or the I-Force driver,
the evdev direction is simply rescaled and passed to the device. It is
then very likely that we should pass through the PID reports direction.
In some other drivers, the sine of the angle is used to modulate the
force magnitude, although that doesn't really tell anything about the
orientation of the direction itself.
The SDL comment is incorrect, and its code isn't actually doing any kind
of conversion other than the rescaling. We now do the same here, and end
up with identical values being sent to evdev, whether we use it directly
or through the SDL library.
It's also been confirmed with hidraw PID capable devices, that with this
change, the direction values in the hardware PID reports are consistent
between the three backends (SDL, evdev, and hidraw).
If some devices are expecting inverted directions then it probably is
something that will need to be solved on the Linux driver level.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51922
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Jinoh Kang