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>
And rename the array from JOY_Sticks to joysticks.
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>
Samplers, blend states, rasterizer states and depth stencil states can
be retrieved from the cache in struct d3d_device even after the
reference count reaches zero, causing memory corruption.
Signed-off-by: Jan Sikorski <jsikorski@codeweavers.com>
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Today, Wine uses NtQueryInformationProcess/ProcessDebugPort to detect
whether the current process is being debugged. If it is, the process
issues a breakpoint to yield control to the debugger.
Some debuggers (e.g. latest CDB) appear to create debug handles with
restricted DACL, which causes querying debug port to fail with
STATUS_ACCESS_DENIED. This results in the debuggee erroneously
skipping the initial breakpoint.
Fix this by not requiring DEBUG_ALL_ACCESS when opening the debug port
object. Instead, use MAXIMUM_ALLOWED for the access mask.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52184
Signed-off-by: Jinoh Kang <jinoh.kang.kr@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Torge Matthies