DualSense controller's report descriptor comes with a 1 bit vendor specific
(Usage Page & Usage) element repeated through 'report count'.
Those were correctly interpreted as non-ranged buttons (exposed as button caps
with appropriate usage values) but their size was incorrectly assumed to be 1
ignoring the 'report count'.
Because of that the InputReportByteLength is miscalculated as 63 instead of
64. If the buffer passed to HidD_GetInputReport() is allocated using that
value the call will fail with ERROR_INSUFFICIENT_BUFFER.
This change fixes the above and cleans up the code a bit so the size for each
case is calculated directly from the count and size instead of using the
values that were derived from them.
Signed-off-by: Arkadiusz Hiler <ahiler@codeweavers.com>
Signed-off-by: Aric Stewart <aric@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Analogous to the GL backend. The alternative would be to potentially
invalidate STATE_FRAMEBUFFER when changing the depth/stencil state object,
which doesn't seem worth it.
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This property is supposed to be set starting from Windows Installer
4.0 targeting Windows Vista. This patch fixes the installer that
checks this property in addition to VersionNT and ALLUSERS.
Signed-off-by: Dmitry Timoshkov <dmitry@baikal.ru>
Signed-off-by: Hans Leidekker <hans@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This noticeably improves stream startup time. The process of typefinding and
negotiation takes about 70 ms for a simple test file on one machine, and this
is currently done twice. This patch replaces the second instance with a simple
seek, which takes less than 10 ms.
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This is a fatal error condition for GStreamer, but should not cause errors for
DirectShow.
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
It does not matter whether we use PAUSED or PLAYING, but we should at least be
consistent.
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Instead of propagating GStreamer flush events to corresponding DirectShow pins.
This is mainly to avoid more callbacks from GStreamer and further separate the
Win32 and Unix code.
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
It's not used right now, Syriac specific groups will be accomodated
as additional joining types.
Signed-off-by: Nikolay Sivov <nsivov@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This is a rather large and complex change. It comprises several parts:
(1) Instead of directly sending EOS, segment, and sample events to the
downstream DirectShow sink, first queue them in a local buffer (i.e.
"pin->event").
(2) Spawn a separate thread per source pin (i.e. "stream_thread") which consumes
said events and sends them downstream.
(3) When flushing or stopping, explicitly wait for this thread to pause or stop
(respectively).
There are a few reasons for this:
(1) It reduces the number of Unix -> PE callbacks we need to make, easing PE
conversion. This is not a great advantage *a priori*, and may not be worth a
similar dedicated "handler" thread for most modules, but winegstreamer is
different—we were already marshalling these calls onto another thread, and
now that marshalling can go away (almost).
(2) Because GStreamer can only do pad negotiation (and hence autoplugging) while
running (in contrast to DirectShow, which can do it while stopped), we
currently have to renegotiate every time the pipeline is started. Most
applications don't start the graph more than once, but even that requires
two negotiations, and startup time is demonstrably too high. It would be
nice to keep the graph in PAUSED state all of the time, but this is
difficult to do without more fine-grained control over the streaming thread.
[In particular, we cannot reliably wait for all samples to be delivered
except by stopping the GStreamer pipeline.]
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Nikolay Sivov