I think this dates from a time where every window had its own window surface, and unless I'm missing something this isn't needed anymore. My intention is to refactor the client surfaces, so that they can be manipulated directly from win32u, and unify GL/VK client surfaces. This would make the code simpler, in preparation for that.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8504
On Thu Jul 31 05:43:48 2025 +0000, Brendan McGrath wrote:
> I never did get to the bottom of why this was required for `avdec_h264`,
> after all, GStreamer plays the test file just fine without the need for
> a `capsfilter` between `h264parse` and `avdec_h264`. So I dug a bit
> deeper this morning.
> It seems it fails under wine as a result of the `GST_EVENT_SEGMENT_DONE`
> event sent within `complete_drain`. When `h264parse` receives this
> event, it fixates its caps to `AVC` and then forwards its data buffers
> to `avdec_h264` without ever providing `codec_data` (which is required
> for AVC).
> Simply removing all the events sent in `complete_drain` fixes this
> problem but unsurprisingly causes a couple of other test failures (along
> with one fix!). You can see an example of what I mean here:
> https://gitlab.winehq.org/redmcg/wine/-/merge_requests/7
> But I'm not sure yet if this is a bug in `h264parse` or in our draining logic.
Ah, interesting. Thanks for looking in to that. I can't speak to any of that, really - I'm not very familiar with winegstreamer at all. I was more wondering if we needed to explicitly set `byte-stream`, and maybe we don't?: tclem/wine!8. Not sure if the tests cover the initial issue you were addressing though. And I guess if it fixates to AVC but doesn't have the required `codec_data` then maybe `byte-stream` is the only option. But like I said, that has broken h.264 on macOS.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8532#note_111746
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>
--
v4: winebus: Do not touch autocenter on device init and device reset
https://gitlab.winehq.org/wine/wine/-/merge_requests/8605
On Thu Jul 31 16:27:31 2025 +0000, Piotr Caban wrote:
> I think it would be best to move these tests before other tests instead
> (and add comment mentioning that this should be the first test). The
> function returns error returned by last function that failed (or E_FAIL
> if there was none). The tests can be easily modified so ConnectionPoint
> tests return different error.
I can see in your patch that it's probably more complicated (the error is always the same if I move test_ADORecordsetConstruction before test_ConnectionPoint). Anyway, it's probably better to run ConnectionPoint tests first. Another option is to try to investigate what's happening there but I'm not sure if it's worth the effort.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8683#note_111715
I think it would be best to move these tests before other tests instead (and add comment mentioning that this should be the first test). The function returns error returned by last function that failed (or E_FAIL if there was none). The tests can be easily modified so ConnectionPoint tests return different error.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8683#note_111714
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>
--
v3: winebus: Do not touch autocenter on device init and device reset
https://gitlab.winehq.org/wine/wine/-/merge_requests/8605
The per-device/vendor option list is allocated on the PE side and shared with the unix, it should be alright to access linked list from both side as winebus should not need and doesn't implement WOW64.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8686
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
reveived to remove the unwanted autocenter behavior.
Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny(a)gmail.com>
--
v2: winebus: Set FFB autcenter to 0 instead of 100 on device reset.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8605