- 15 Feb, 2022 13 commits
-
-
Eric Pouech authored
Signed-off-by:
Eric Pouech <eric.pouech@gmail.com> Signed-off-by:
Alexandre Julliard <julliard@winehq.org>
-
Eric Pouech authored
Signed-off-by:
-
Eric Pouech authored
Signed-off-by:
-
Eric Pouech authored
Signed-off-by:
-
Eric Pouech authored
Signed-off-by:
-
Eric Pouech authored
Signed-off-by:
Zebediah Figura <zfigura@codeweavers.com> Signed-off-by:
-
Zebediah Figura authored
Signed-off-by:
-
Zebediah Figura authored
Signed-off-by:
-
Zebediah Figura authored
Signed-off-by:
-
Zebediah Figura authored
Signed-off-by:
-
Zebediah Figura authored
kernelbase: Also return E_FAIL when trying to parse username, password, or port for non-Internet URLs. Signed-off-by:
-
Matteo Bruni authored
Signed-off-by:
Matteo Bruni <mbruni@codeweavers.com> Signed-off-by:
-
Zebediah Figura authored
Signed-off-by:
-
- 14 Feb, 2022 27 commits
-
-
Zebediah Figura authored
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=44635Signed-off-by:
-
Zebediah Figura authored
Signed-off-by:
-
Zebediah Figura authored
Signed-off-by:
-
Zebediah Figura authored
Signed-off-by:
-
Eric Pouech authored
1a) fixes a too short memory allocation on 64bit (DRVCONFIGINFO is 20 byte large while only 16 bytes were allocated) 1b) incidentally, removes a bunch of GCC11 warnings (generated by 1a) 2) introduces DRVCONFIGINFOEX (note, in SDK, it's defined in mmiscapi.h; since it doesn't exist yet in Wine, I added the structure to mmsystem.h, where DRVCONFIGINFO already exists) 3) initializes the missing field Note: my testing don't show on Win10's msacm32 that DRV_CONFIGURE uses the DRVCONFIGINFOEX structure. So, maybe (wild guess here), the extended structure is only used when the driver is linked to some hardware. Signed-off-by:Andrew Eikum <aeikum@codeweavers.com> Signed-off-by:
-
Giovanni Mascellani authored
Signed-off-by:
Nikolay Sivov <nsivov@codeweavers.com> Signed-off-by:
-
Nikolay Sivov authored
Signed-off-by:
-
Zebediah Figura authored
Signed-off-by:
Henri Verbeet <hverbeet@codeweavers.com> Signed-off-by:
-
Zebediah Figura authored
Currently this has no effect. Depending on whether wined3d_map_persistent() returns true, either the client thread doesn't access the map pointer outside of d3d map requests, or the BO is never unmapped. However, we'd like to be able to let NOOVERWRITE maps be accelerated while still being able to unmap arbitrary BOs at arbitrary times from the CS thread. Signed-off-by:
-
Henri Verbeet authored
Signed-off-by:
-
Zebediah Figura authored
Signed-off-by:
-
Rémi Bernon authored
If a session is paused then started again, or if a start position is provided we wait forever for the source to send a MESourceStarted event, when it sends a MESourceSeeked instead. This causes a deadlock in Bright Memory: Infinite as the game then waits for the Start command to complete, while the session is stuck in the SESSION_STATE_STARTING_SOURCES state. Signed-off-by:
Rémi Bernon <rbernon@codeweavers.com> Signed-off-by:
-
Paul Gofman authored
Signed-off-by:
Paul Gofman <pgofman@codeweavers.com> Signed-off-by:
-
Francois Gouget authored
Signed-off-by:
Francois Gouget <fgouget@free.fr> Signed-off-by:
-
Francois Gouget authored
Signed-off-by:
-
Francois Gouget authored
Signed-off-by:
-
Francois Gouget authored
Signed-off-by:
-
Francois Gouget authored
Signed-off-by:
-
Francois Gouget authored
Signed-off-by:
-
Francois Gouget authored
Signed-off-by:
-
Rémi Bernon authored
Signed-off-by:
-
Rémi Bernon authored
There's some inconsistencies between the HID 1.22 specification and HID usage names in Windows SDK headers. The headers use STOP for the 0x1001 usage name, and NULL for 0x1002, where the HID spec uses None for the 0x1001 usage name and Stop for 0x1002. Both are implicit waveforms anyway, and the HID usages aren't really used anywhere, but their ordinal matters. The HID spec says that None has ordinal 1, and Stop ordinal 2, and that Stop waveform can be used to stop any previously started waveform. We are going to stick to that and ignore the HID usages, although the names won't match the usages. Signed-off-by:
-
Rémi Bernon authored
Depending on the API the device supports, in preferred order. Signed-off-by:
-
Rémi Bernon authored
Instead of stopping them, then re-starting them when a new effect is requested. Signed-off-by:
-
Rémi Bernon authored
The SDL_HAPTIC_LEFTRIGHT effect should be preferred when available. Signed-off-by:
-
Piotr Caban authored
Signed-off-by:
Piotr Caban <piotr@codeweavers.com> Signed-off-by:
-
Piotr Caban authored
Signed-off-by:
-
