This fixes two things:
* HID report descriptor parser enum for local items. Close inspection of page 40 of [Device Class Definition for HID 1.11](https://www.usb.org/document-library/device-class-definition-hid-111) reveals a jump between Designator Maximum (0101) and String Index (0111). This caused a controller of mine to not get recognized.
* HidP_SetUsageValue for items that define multiple controls (with Report Count > 1). Attempting to set one value would result in HIDP_STATUS_BUFFER_TOO_SMALL.
--
v4: hid: Fix HidP_(Get|Set)(Scaled)UsageValue with usage ranges and arrays.
hid: Move (get|set)_usage_value around and use it for scaled values.
winexinput.sys: Fix incorrect HID STRING_INDEX tag value.
winebus.sys: Fix incorrect HID STRING_INDEX tag value.
ntoskrnl.exe/tests: Fix incorrect HID STRING_INDEX tag value.
hidparse.sys: Fix incorrect HID STRING_INDEX tag value.
dinput/tests: Fix incorrect HID STRING_INDEX tag value.
dinput/tests: Add more HidP_(Set|Get)UsageValue tests with array caps.
dinput/tests: Add more tests for HidP_SetUsageValue.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1448
We need to make sure all (important) cleanup is finished when we exit DllMain,
otherwise we might already unload krnl386 and deadlock
Since we can't have a synchronous DestroyWindow, use an extra message
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52511
Signed-off-by: Fabian Maurer <dark.shadow4(a)web.de>
Code flow is like follows:
- DOSVM_Exit -> RtlExitUserThread -> LdrShutdownThread
- acquire loader lock
- send DLL_THREAD_DETACH to imm32
- - calls DestroyWindow on its window
- - WM_DESTROY is handled asynchonously!
- send DLL_THREAD_DETACH to krnl386.exe
- - TASK_ExitTask
- - try get win16 lock, is blocked by ime32
meanwhile, at ime32
- handles WM_DESTROY
- already have win16 lock from user32
- __wine_ime_wnd_proc (WM_DESTROY) -> imm_couninit_thread -> CoRevokeInitializeSpy
- LdrGetProcedureAddress (want CoRevokeInitializeSpy)
- try get loader_lock, is blocked
Solution is to wait in ime32 DllMain until the cleanup as happened, aka CoRevokeInitializeSpy has finished.
--
v5: imm32: Prevent deadlock on unload
https://gitlab.winehq.org/wine/wine/-/merge_requests/1456
This serie allow to load alternate debug info from user's debuginfo cache.
This series (as is) will not bring lots of value as:
- no support for loading the missing debug info files (they should have been
been loaded beforehand)
- most of these files are in Dwarf5 format, that we don't support yet.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1477
--
v2: taskschd: Remove unused function heap_strdupW.
taskschd: Use standard C functions for memory allocation in task.c.
taskschd: Use standard C functions for memory allocation in regtask.c.
taskschd: Use standard C functions for memory allocation in folder_collection.c.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1466
--
v4: mfmediaengine: Add a fallback when the set engine format cannot be used to init samplegrabber.
mfmediaengine: Only accept engine formats which are render target compatible.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1046
I was watching some random YouTube stream and then heard a voice telling me to do this.
This can run wglgears on wow, though there's plenty of missing pieces which I don't have any idea how to fix (like buffer mapping, etc.). Opening it as a draft for now to show the whole thing, if it seems alright I'll send it in batches.
--
v7: HACK: wined3d: Disable persistent buffer mapping.
HACK: wined3d: Ignore D3DKMT open errors.
winex11.drv: Avoid crashing on invalid pixel format pointer.
opengl32: Use the +opengl debug channel everywhere.
opengl32: Implement wow64 thunks for glMapBuffer (et al.).
https://gitlab.winehq.org/wine/wine/-/merge_requests/1010
--
v2: mfmediaengine: Add a fallback when the set output format cannot be used to init samplegrabber.
mfmediaengine: Only accept output formats which are render target compatible.
mfmediaengine/tests: Test possible engine and output texture formats.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1046
This fixes two things:
* HID report descriptor parser enum for local items. Close inspection of page 40 of [Device Class Definition for HID 1.11](https://www.usb.org/document-library/device-class-definition-hid-111) reveals a jump between Designator Maximum (0101) and String Index (0111). This caused a controller of mine to not get recognized.
* HidP_SetUsageValue for items that define multiple controls (with Report Count > 1). Attempting to set one value would result in HIDP_STATUS_BUFFER_TOO_SMALL.
--
v3: hid: Add tests for fixed HidP_SetUsageValue
hid: Fix HidP_SetUsageValue for usage ranges
hidparse.sys: Fix incorrect enum
https://gitlab.winehq.org/wine/wine/-/merge_requests/1448
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53474
--
v2: kernelbase: Only discard HLOCAL with LMEM_MOVEABLE and if not locked.
kernel32: Return success from GlobalReAlloc with locked HGLOBAL pointer.
kernelbase: Avoid moving locked HLOCAL pointer without LMEM_MOVEABLE.
kernelbase: Handle LMEM_DISCARDABLE flag specifically in LocalReAlloc.
kernelbase: Handle LMEM_MODIFY flag first in LocalReAlloc.
kernelbase: Don't try in-place HeapReAlloc in LocalReAlloc.
user32: Call GlobalReAlloc with GMEM_MOVEABLE flag.
winemac.drv: Call GlobalReAlloc with GMEM_MOVEABLE flag.
riched20: Call GlobalReAlloc with GMEM_MOVEABLE flag.
ole32: Call GlobalReAlloc with GMEM_MOVEABLE flag.
comdlg32: Call GlobalReAlloc with GMEM_MOVEABLE flag.
kernel32/tests: Add more (Global|Local)ReAlloc tests.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1470
It occurred to me that you might not be aware that you can forward-declare static functions, so you don't really need to move them. Just put a declaration like this:
```
static void widen_open_figure(const GpPointF *points, int start, int end,
GpPen *pen, REAL pen_width, GpLineCap start_cap,
GpLineCap end_cap, path_list_node_t **last_point);
```
Further up in the file.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1297#note_16784
On Sat Nov 19 00:10:03 2022 +0000, Esme Povirk wrote:
> I suspect there are enough slow things we already have to do that it
> won't really matter, but if we need to we can optimize it later.
Resolving, this is fine for now and can be easily improved in the future.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1297#note_16782
On Fri Nov 18 20:11:22 2022 +0000, Esme Povirk wrote:
> I'm not sure. Maybe widen_open_figure needs to be aware of the inset and
> adjust the points it passes to width_joint. Or maybe the path needs to
> be adjusted after GdipFlattenPath.
> I think it depends on what happens when the path ends with a segment
> that's shorter than the inset.
Resolving this thread because this issue doesn't need to be taken care of for the MR to be accepted. It can be fixed later.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1297#note_16780
On Wed Nov 9 18:25:51 2022 +0000, Bartosz Kosiorek wrote:
> changed this line in [version 5 of the diff](/wine/wine/-/merge_requests/1297/diffs?diff_id=17873&start_sha=ec560a173011779aa36bdb3d54e0bd805a70a729#708701348c59d29ebde2b9d5cd4724966113ebf7_308_308)
I'm going to resolve this as it's only an explanation of the change and not a problem with it.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1297#note_16779
Esme Povirk (@madewokherd) commented about dlls/gdiplus/graphicspath.c:
> + widen_closed_figure(tmp_points, 0, custom->pathdata.Count - 1, pen, pen_width, last_point);
> + else
> + widen_open_figure(tmp_points, 0, custom->pathdata.Count - 1, pen, pen_width, LineCapFlat, LineCapFlat, last_point);
> + }
> + else
> + {
> + for (INT i = 0; i < custom->pathdata.Count; i++)
> + {
> + // rotation of CustomCap according to line
> + perp_dx = custom->pathdata.Points[i].X * cosa + (custom->pathdata.Points[i].Y - 1.0) * sina;
> + perp_dy = custom->pathdata.Points[i].X * sina - (custom->pathdata.Points[i].Y - 1.0) * cosa;
> + *last_point = add_path_list_node(*last_point, posx + perp_dx,
> + posy + perp_dy, custom->pathdata.Types[i]);
> + }
> + }
> + // FIXME: The line should be shorter, and it should ends up when Arrow/Cap is started draw
This comment makes things more confusing, I think. I'd suggest something like `FIXME: The line should be adjusted by the inset value of the custom cap.`.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1297#note_16777
There's a few missing thunks for some non-standard extension functions, but that probably doesn't matter.
--
v2: opengl32: Use the +opengl debug channel everywhere.
opengl32: Cast wow64 pointers in glGet(VertexAttrib)Pointerv.
opengl32: Implement wow64 thunks for glMapBuffer (et al.).
opengl32: Use manual win32 thunks for glMapBuffer (et al.).
opengl32: Implement wow64 thunk for glGetString (et al.).
https://gitlab.winehq.org/wine/wine/-/merge_requests/1472
Since we stop the thread in DllMain, we always haev the loaderlock.
Thread shutdown also requires the loader lock, so we will always time out
So just wait until all cleanup is done, the thread itself can exit later
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52314
Signed-off-by: Fabian Maurer <dark.shadow4(a)web.de>
--
v2: dinput: Wait on event instead of thread on stop
https://gitlab.winehq.org/wine/wine/-/merge_requests/1455
This avoids the following warning by GCC 13:
dlls/msado15/recordset.c:790:32: warning: 'i' may be used uninitialized
--
v3: msado15: Avoid uninitialized variable warning in fields_get_Item
https://gitlab.winehq.org/wine/wine/-/merge_requests/1449
In preparation for https://gitlab.winehq.org/wine/wine/-/merge_requests/1324.
This also begins preparation for a slightly different route than what the MR currently takes, with syscall flags eventually stored in the CounterTable rather than overusing syscall number unused bits.
To do that we're checking the syscall number and loading the syscall table (keeping it in %rbx/%ebx) earlier. This assumes that %rbx isn't modified in between, for instance by the eventual `SYS_arch_prctl` syscall, but I believe it is the case?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1437
We need to make sure all (important) cleanup is finished when we exit DllMain,
otherwise we might already unload krnl386 and deadlock
Since we can't have a synchronous DestroyWindow, use an extra message
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52511
Signed-off-by: Fabian Maurer <dark.shadow4(a)web.de>
Code flow is like follows:
- DOSVM_Exit -> RtlExitUserThread -> LdrShutdownThread
- acquire loader lock
- send DLL_THREAD_DETACH to imm32
- - calls DestroyWindow on its window
- - WM_DESTROY is handled asynchonously!
- send DLL_THREAD_DETACH to krnl386.exe
- - TASK_ExitTask
- - try get win16 lock, is blocked by ime32
meanwhile, at ime32
- handles WM_DESTROY
- already have win16 lock from user32
- __wine_ime_wnd_proc (WM_DESTROY) -> imm_couninit_thread -> CoRevokeInitializeSpy
- LdrGetProcedureAddress (want CoRevokeInitializeSpy)
- try get loader_lock, is blocked
Solution is to wait in ime32 DllMain until the cleanup as happened, aka CoRevokeInitializeSpy has finished.
--
v4: imm32: Prevent deadlock on unload
https://gitlab.winehq.org/wine/wine/-/merge_requests/1456
Atomic ops on images with Unknown type will cause SPIR-V validation failure,
and assertion failure in Mesa debug builds. D3D12 allows atomics on typed
buffers, and this requires a distinction to be made between UAV reads and
atomic ops.
--
v2: vkd3d-shader: Introduce DESCRIPTOR_INFO_FLAG_UAV_ATOMICS and always declare UAV images with known type for atomic ops.
tests: Test a typed UAV buffer in test_atomic_instructions().
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/49
This is my first time implementing an interface so thorough feedback would be appreciated.
--
v7: windows.media: Implement IClosedCaptionPropertiesStatics interface.
windows.media: Add stub DLL.
include/windowscontracts: Bump contractversion to 14.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1343
This avoids the following warning by GCC 13:
dlls/msado15/recordset.c:790:32: warning: 'i' may be used uninitialized
--
v2: msado15: Avoid uninitialized variable use in fields_get_Item
https://gitlab.winehq.org/wine/wine/-/merge_requests/1449
Changed MCHITTESTINFO.cbSize to fall back to V1:
From the rest of the tests, it looks like the extended size
of MCHITTESTINFO requires loading common controls V6, which is
only done afterwards in the tests.
Improved lookup of an unselected day.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=50097
Signed-off-by: Eric Pouech <eric.pouech(a)gmail.com>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1416
Sorry, forget about the last versions, I mistook where the WM_DESTROY is coming from. It's not coming from imm32 DllMain. That means it simply ignores the deinitialization... Sorry about that.
This is a new approach that should also fix the issue, this time preventing the loader lock that causes the issue in the first place.
Not 100% sure if that's the right way to go about it, though.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1456#note_16584
This is my first time implementing an interface so thorough feedback would be appreciated.
--
v6: windows.media: Implement IClosedCaptionPropertiesStatics interface.
include/windowscontracts: Bump contractversion to 14.
windows.media: Add stub DLL.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1343
We need to make sure all (important) cleanup is finished when we exit DllMain,
otherwise we might already unload krnl386 and deadlock
Since we can't have a synchronous DestroyWindow, use an extra message
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52511
Signed-off-by: Fabian Maurer <dark.shadow4(a)web.de>
Code flow is like follows:
- DOSVM_Exit -> RtlExitUserThread -> LdrShutdownThread
- acquire loader lock
- send DLL_THREAD_DETACH to imm32
- - calls DestroyWindow on its window
- - WM_DESTROY is handled asynchonously!
- send DLL_THREAD_DETACH to krnl386.exe
- - TASK_ExitTask
- - try get win16 lock, is blocked by ime32
meanwhile, at ime32
- handles WM_DESTROY
- already have win16 lock from user32
- __wine_ime_wnd_proc (WM_DESTROY) -> imm_couninit_thread -> CoRevokeInitializeSpy
- LdrGetProcedureAddress (want CoRevokeInitializeSpy)
- try get loader_lock, is blocked
Solution is to wait in ime32 DllMain until the cleanup as happened, aka CoRevokeInitializeSpy has finished.
--
v2: imm32: Prevent deadlock on unload
https://gitlab.winehq.org/wine/wine/-/merge_requests/1456
On Sat Nov 19 18:56:07 2022 +0000, Etaash Mathamsetty wrote:
> instead of saving the return value to a temp variable and returning the
> temp variable, I think you could moving the FIXME before the call and
> just return MoveFileWithProgressA, thus removing the need of the variable
I thought about it. But having the fixme after provides feedback in the event something goes wrong inside of MoveFile... Although maybe that is no with the memory allocation thats going to be held onto for the life the the call.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1444#note_16564
We need to make sure all (important) cleanup is finished when we exit DllMain,
otherwise we might already unload krnl386 and deadlock
Since we can't have a synchronous DestroyWindow, use an extra message
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52511
Signed-off-by: Fabian Maurer <dark.shadow4(a)web.de>
Code flow is like follows:
- DOSVM_Exit -> RtlExitUserThread -> LdrShutdownThread
- acquire loader lock
- send DLL_THREAD_DETACH to imm32
- - calls DestroyWindow on its window
- - WM_DESTROY is handled asynchonously!
- send DLL_THREAD_DETACH to krnl386.exe
- - TASK_ExitTask
- - try get win16 lock, is blocked by ime32
meanwhile, at ime32
- handles WM_DESTROY
- already have win16 lock from user32
- __wine_ime_wnd_proc (WM_DESTROY) -> imm_couninit_thread -> CoRevokeInitializeSpy
- LdrGetProcedureAddress (want CoRevokeInitializeSpy)
- try get loader_lock, is blocked
Solution is to wait in ime32 DllMain until the cleanup as happened, aka CoRevokeInitializeSpy has finished.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1456
This fixes two things:
* HID report descriptor parser enum for local items. Close inspection of page 40 of [Device Class Definition for HID 1.11](https://www.usb.org/document-library/device-class-definition-hid-111) reveals a jump between Designator Maximum (0101) and String Index (0111). This caused a controller of mine to not get recognized.
* HidP_SetUsageValue for items that define multiple controls (with Report Count > 1). Attempting to set one value would result in HIDP_STATUS_BUFFER_TOO_SMALL.
--
v2: hid: Fix HidP_SetUsageValue for usage ranges
https://gitlab.winehq.org/wine/wine/-/merge_requests/1448