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