Module: wine
Branch: master
Commit: 194b47b4fd92dda8ebf24e88ca7a14fc926c84ab
URL: https://source.winehq.org/git/wine.git/?a=commit;h=194b47b4fd92dda8ebf24e88…
Author: Henri Verbeet <hverbeet(a)codeweavers.com>
Date: Thu Dec 9 17:45:15 2021 +0100
wined3d: Use the access flags used to create the bo for persistent maps in wined3d_bo_gl_map().
Signed-off-by: Henri Verbeet <hverbeet(a)codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard(a)winehq.org>
---
dlls/wined3d/context_gl.c | 26 ++++++++++++++++++--------
1 file changed, 18 insertions(+), 8 deletions(-)
diff --git a/dlls/wined3d/context_gl.c b/dlls/wined3d/context_gl.c
index 6391f6788e9..c08e44ce372 100644
--- a/dlls/wined3d/context_gl.c
+++ b/dlls/wined3d/context_gl.c
@@ -2711,14 +2711,24 @@ map:
gl_info = context_gl->gl_info;
wined3d_context_gl_bind_bo(context_gl, bo->binding, bo->id);
- if (gl_info->supported[ARB_BUFFER_STORAGE])
- {
- if ((map_ptr = GL_EXTCALL(glMapBufferRange(bo->binding, 0, bo->size,
- GL_MAP_PERSISTENT_BIT | GL_MAP_COHERENT_BIT | wined3d_resource_gl_map_flags(bo, flags)))))
- {
- if (wined3d_map_persistent())
- bo->b.map_ptr = map_ptr;
- }
+ if (gl_info->supported[ARB_BUFFER_STORAGE] && wined3d_map_persistent())
+ {
+ GLbitfield gl_flags;
+
+ /* When mapping the bo persistently, we need to use the access flags
+ * used to create the bo, instead of the access flags passed to the
+ * map call. Otherwise, if for example the initial map call that
+ * caused the bo to be persistently mapped was a read-only map,
+ * subsequent write access to the bo would be undefined. */
+ gl_flags = bo->flags & ~GL_CLIENT_STORAGE_BIT;
+ gl_flags |= GL_MAP_PERSISTENT_BIT | GL_MAP_COHERENT_BIT;
+ if (!(gl_flags & GL_MAP_READ_BIT))
+ gl_flags |= GL_MAP_UNSYNCHRONIZED_BIT;
+ if (gl_flags & GL_MAP_WRITE_BIT)
+ gl_flags |= GL_MAP_FLUSH_EXPLICIT_BIT;
+
+ if ((map_ptr = GL_EXTCALL(glMapBufferRange(bo->binding, 0, bo->size, gl_flags))))
+ bo->b.map_ptr = map_ptr;
}
else if (gl_info->supported[ARB_MAP_BUFFER_RANGE])
{
Module: wine
Branch: master
Commit: cbd324124ce2a5ddb241f0ff920660aa55b0b5c4
URL: https://source.winehq.org/git/wine.git/?a=commit;h=cbd324124ce2a5ddb241f0ff…
Author: Rémi Bernon <rbernon(a)codeweavers.com>
Date: Thu Dec 9 14:44:15 2021 +0100
winebus.sys: Revert direction rotation for UDEV lnxev devices.
This partially reverts b431dceeca9aa0d4229c3597b833bcaf04de7110, 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(a)codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard(a)winehq.org>
---
dlls/winebus.sys/bus_udev.c | 11 +++--------
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/dlls/winebus.sys/bus_udev.c b/dlls/winebus.sys/bus_udev.c
index dec8435555c..2269f5b904e 100644
--- a/dlls/winebus.sys/bus_udev.c
+++ b/dlls/winebus.sys/bus_udev.c
@@ -1046,14 +1046,9 @@ static NTSTATUS lnxev_device_physical_effect_update(struct unix_device *iface, B
effect.trigger.button = params->trigger_button;
effect.trigger.interval = params->trigger_repeat_interval;
- /* Linux FF only supports polar direction, and uses an inverted convention compared
- * to SDL or dinput (see SDL src/haptic/linux/SDL_syshaptic.c), where the force pulls
- * into the specified direction, instead of coming from it.
- *
- * The first direction we get from PID is in polar coordinate space, so we need to
- * add 180° to make it match Linux coordinates. */
- effect.direction = (params->direction[0] + 18000) % 36000;
- effect.direction = effect.direction * 0x800 / 1125;
+ /* Linux FF only supports polar direction, and the first direction we get from PID
+ * is in polar coordinate space already. */
+ effect.direction = params->direction[0] * 0x800 / 1125;
switch (params->effect_type)
{