Qt 6.9 Gui module on Windows with D3D 11 and 12 uses dedicated vblank watcher thread to update window (https://doc.qt.io/qt-6/whatsnew69.html). This thread calls IDXGIOutput::WaitForVBlank that must halt the thread until the next vblank occurs.
This implementation is based on incorrect calculation of vblank occurrence. But it helps to update window.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8707
This is not the right fix, and I need some help. Let me explain.
`session_submit_command` checks that:
1. `session->commands` is empty, and
2. `SESSION_FLAG_PENDING_COMMAND` is NOT set
before submitting the `session_op`. The assumption is, if there are queued commands, or if there is a command currently running, that pending command will submit subsequent commands when it completes.
However, in this call chain:
```
#0 0x00006fffe1d27ad7 in create_async_result (object=object@entry=0x0, callback=callback@entry=0x7e62489f1c08,
state=state@entry=0x7e61cb5322b0, out=out@entry=0x7e6242bac7a0) at ../dlls/rtworkq/queue.c:1229
#1 0x00006fffe1d222d5 in RtwqCreateAsyncResult (object=object@entry=0x0, callback=callback@entry=0x7e62489f1c08,
state=state@entry=0x7e61cb5322b0, out=out@entry=0x7e6242bac7a0) at ../dlls/rtworkq/queue.c:1245
#2 0x00006fffd45e2096 in MFPutWorkItem (queue=queue@entry=1, callback=callback@entry=0x7e62489f1c08,
state=state@entry=0x7e61cb5322b0) at ../dlls/mfplat/queue.c:46
#3 0x00006fffe41244ee in session_command_complete (session=0x7e62489f1be0) at ../dlls/mf/session.c:975
#4 0x00006fffe412d00f in session_reset (session=session@entry=0x7e62489f1be0) at ../dlls/mf/session.c:1051
#5 0x00006fffe41299fc in session_handle_source_shutdown (session=session@entry=0x7e62489f1be0)
at ../dlls/mf/session.c:2957
#6 0x00006fffe4126e90 in session_events_callback_Invoke (iface=0x7e62489f1c20, result=<optimized out>)
at ../dlls/mf/session.c:4445
```
nowhere was the `SESSION_FLAG_PENDING_COMMAND` flag set. In addition to that, `session_events_callback_Invoke` is not a command. So this could happend:
```
Thread 1 | Thread 2
call session_events_callback_Invoke |
| call session_submit_command
| <critical section>
| list_empty(&session->commands) is true, and PENDING_COMMAND not set
| MFPutWorkItem(op)
| list_add(&session->commands, op) <- (1)
| </critical_section>
call session_handle_source_shutdown |
<critical_section> |
call session_reset |
call session_command_complete |
list_head(&session->commands) |
op is returned because of (1) |
MFPutWorkItem(op) again |
</critical_section> |
```
The result is this op will be executed twice, and also double freed, because `session_commands_callback_Invoke` releases the `op`.
* * *
There is even another way an `op` can be submitted twice, `session_handle_start_error` calls `session_reset`, which already calls `session_command_complete`, and later it calls `session_command_complete_with_event` again. I think a missing return?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8270
For React Native
--
v6: d2d1: Add initial support for creating bitmaps from DXGI subresource surfaces.
d2d1/tests: Test creating bitmap from DXGI subresource surface.
d2d1/tests: Silence some test traces.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8243
FFB Autocenter introduced in https://gitlab.winehq.org/wine/wine/-/merge_requests/4911
had one major misunderstanding.
The USB PID standard doesn't actually define any explicit way to
autocenter a device. One could of course use the spring effect with a
deadzone of 0 and dead band of 0. This is what I'm actually working on
for the Linux PID driver (spring + friction/damper).
Some devices implement autocenter in firmware when they receive the
DC Disable Actuators command. Very few, if not just one, implement this
weird autocenter effect on slot 1. This is, from what I can gather, only
implemented on the MS SideWinder joystick(s) and the Windows' USB PID
driver is created around these devices.
Windows PID driver is a bit out of spec, is quite permissive when it
comes to fields missing in the descriptor (basically, only effect types
and their effect type blocks are optional). Another thing it does is
handling of this out-of-spec autocentering for their joysticks.
Funnliy enough, the creator of the Linux PID driver based the initial
code on testing with MS Sidewinder so it's autocentering is supported.
This is where the autocentering mentioned in the MR comes from. It's not
the directinput api that does it but the Windows PID driver. As such,
autocentering on reset should be left to the drivers, not handeled by
Wine.
SDL lacks full reset support and Linux is even more barebones, whre it's
not even possible to query the device state, effects etc (something I'm
working on slowly). As such, when games send out RESET to prepare the
device, the device starts autocentering for no good reason and the
effect is not removed once other effect are uploaded and played which
would be the case for MS sidewinder.
In any case, even Windows in inconsistent and I think the directinput
documentation has some errors. directinput ffb api is largely based on
USB PID but:


Testing with my Moza Racing R9 wheelbase, the DC Reset PID command is
sent, but there's no DC Disable Actuators in sight. The games still
call reset then enable actuators though.
tl;dr
Set autocentering to 0 instead of max value when DISFFC_RESET is
received to remove the unwanted autocenter behavior.
Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny(a)gmail.com>
--
v6: winebus: Do not touch autocenter on device init and device reset
https://gitlab.winehq.org/wine/wine/-/merge_requests/8605
FFB Autocenter introduced in https://gitlab.winehq.org/wine/wine/-/merge_requests/4911
had one major misunderstanding.
The USB PID standard doesn't actually define any explicit way to
autocenter a device. One could of course use the spring effect with a
deadzone of 0 and dead band of 0. This is what I'm actually working on
for the Linux PID driver (spring + friction/damper).
Some devices implement autocenter in firmware when they receive the
DC Disable Actuators command. Very few, if not just one, implement this
weird autocenter effect on slot 1. This is, from what I can gather, only
implemented on the MS SideWinder joystick(s) and the Windows' USB PID
driver is created around these devices.
Windows PID driver is a bit out of spec, is quite permissive when it
comes to fields missing in the descriptor (basically, only effect types
and their effect type blocks are optional). Another thing it does is
handling of this out-of-spec autocentering for their joysticks.
Funnliy enough, the creator of the Linux PID driver based the initial
code on testing with MS Sidewinder so it's autocentering is supported.
This is where the autocentering mentioned in the MR comes from. It's not
the directinput api that does it but the Windows PID driver. As such,
autocentering on reset should be left to the drivers, not handeled by
Wine.
SDL lacks full reset support and Linux is even more barebones, whre it's
not even possible to query the device state, effects etc (something I'm
working on slowly). As such, when games send out RESET to prepare the
device, the device starts autocentering for no good reason and the
effect is not removed once other effect are uploaded and played which
would be the case for MS sidewinder.
In any case, even Windows in inconsistent and I think the directinput
documentation has some errors. directinput ffb api is largely based on
USB PID but:


Testing with my Moza Racing R9 wheelbase, the DC Reset PID command is
sent, but there's no DC Disable Actuators in sight. The games still
call reset then enable actuators though.
tl;dr
Set autocentering to 0 instead of max value when DISFFC_RESET is
received to remove the unwanted autocenter behavior.
Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny(a)gmail.com>
--
v5: winebus: Do not touch autocenter on device init and device reset
https://gitlab.winehq.org/wine/wine/-/merge_requests/8605
avdec_h264 will fail when combined with h264parse and a drain request
is made during caps neg.
To fix this, a capsfilter was added to force a stream-format of
byte-stream for all h.264 decoders. However, this introduced a new
issue with the vtdec element, as it only supports the avc stream-format.
Therefore, this patch looks to address both problems by only introducing
the capsfilter when the avdec_h264 element is used.
It also removes the stream-format and alignment requirements from
the parsed caps, applying them only to the capsfilter.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8719