April 2025 - wine-gitlab

[PATCH 0/1] MR7751: start: Add the /elevate option.
by Roman Pišl (＠rpisl) 05 Apr '25

05 Apr '25

Wine starts processes non-elevated since e92ba2de43d7afbe0704b11b29f7c30f44dfaeca but some installers exit prematurely when not elevated. The elevation mechanism is taken from 8cc22a60c304fc1398fab1ce8413b2b81fc2ccec. Would this be an acceptable extension? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7751

2 1

[PATCH v2 0/1] MR7440: dwrite: Use Noto Sans as fallback for General and Supplemental Punctuation.
by Daniel Lehman (＠dlehman25) 05 Apr '25

05 Apr '25

-- v2: dwrite: Use Noto Sans as fallback for General and Supplemental Punctuation. https://gitlab.winehq.org/wine/wine/-/merge_requests/7440

3 3

Re: [PATCH v3 0/1] MR7706: powrprof.dll: Partially implement PowerGetActiveScheme for SteamVR
by Robert Lippmann (＠rlippmann) 05 Apr '25

05 Apr '25

@julliard is there any reason why you're not merging this? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7706#note_100033

1 0

[PATCH 0/1] MR7747: ntdll: Guess optical disc type based on data size.
by Alex Henrie (＠alexhenrie) 05 Apr '25

05 Apr '25

A standard CD-ROM has up to 360,000 sectors that hold 2 KiB of data each, making the total capcity 703.125 MiB. Anything larger than that is almost certainly a DVD or a Blu-ray, and Windows does not distinguish between those two. There is probably some tiny DVD somewhere in the world that will still be misdetected, but I'm not sure that issuing SCSI commands to the drive to try to determine the disc type would be any more reliable. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57790 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7747

1 0

[PATCH 0/1] MR7746: shell32: Correctly display file sizes larger than 4 GiB.
by Alex Henrie (＠alexhenrie) 05 Apr '25

05 Apr '25

Only the lower 32 bits of the file size are stored in the IDLDATA struct, which means that a separate function call is necessary to get the complete 64-bit file size. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58058 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7746

2 1

[PATCH 0/1] MR7745: adsldp: Implement sysinfo_get_UserName
by Daniel Martin (＠danlm) 05 Apr '25

05 Apr '25

This patch implements the sysinfo_get_UserName function, an existing FIXME for adsldp. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7745

2 1

[PATCH v3 0/2] MR7318: gdiplus: Use correct format guid for .ico files.
by Fabian Maurer (＠DarkShadow44) 05 Apr '25

05 Apr '25

Adapted from https://github.com/reactos/reactos/pull/7714 -- v3: gdiplus: Use correct format guid for .ico files. gdiplus/tests: Add test for loading .ico. https://gitlab.winehq.org/wine/wine/-/merge_requests/7318

3 3

Re: [PATCH v7 0/5] MR7727: cfgmgr32, setupapi: Implement a few functions.
by Paul Gofman (＠gofman) 04 Apr '25

04 Apr '25

On Fri Apr 4 21:07:44 2025 +0000, Paul Gofman wrote: > Yes, it seems to be using it (while that worked for me without > CM_Get_Parent at least with some controllers). > CM_Get_Parent() per se is easy to implement, but to make any sense of it > the first thing is that the actual HID drivers (or ntoskrnl rather, > maybe) should be setting DEVPKEY_Device_Parent property. But also before > that, as I understand, currently Wine HID stack ends in xinput or SDL > backends and not in USD or Bluetooth Wine driver, that is probably the > major thing here. I think the linked hidapi library code only hits > CM_Get_Parent() in hid_internal_detect_bus_type() and failure there > results in HID_API_BUS_UNKNOWN, which doesn't fail the whole thing but > misses some properties. Maybe in theory those backends may expose device properties to partially mimic USB or BTH devices and make this library fully happy, but I am not sure, didn't really look into that part. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7727#note_100024

1 0

Re: [PATCH v7 0/5] MR7727: cfgmgr32, setupapi: Implement a few functions.
by Paul Gofman (＠gofman) 04 Apr '25

04 Apr '25

On Fri Apr 4 20:22:39 2025 +0000, Ivo Ivanov wrote: > They probably use "hidapi" to communicate with hid devices: > https://github.com/libusb/hidapi/blob/8c9cbf6c020974d23e4690497778f3df173d1… > The Simucube Tuner app, which is used to control Simucube 2 FFB wheel > bases, is also affected by this. Seems the usblib devs have switched > from setupapi to cfgmgr32 in the recent years, and now this is starting > to appear in games/apps. Looks like only CM_Get_Parent remains to be implemented. > BTW, Steam shows a similar usage pattern of these apis in the logs, so > it probably uses hidapi as well. Yes, it seems to be using it (while that worked for me without CM_Get_Parent at least with some controllers). CM_Get_Parent() per se is easy to implement, but to make any sense of it the first thing is that the actual HID drivers (or ntoskrnl rather, maybe) should be setting DEVPKEY_Device_Parent property. But also before that, as I understand, currently Wine HID stack ends in xinput or SDL backends and not in USD or Bluetooth Wine driver, that is probably the major thing here. I think the linked hidapi library code only hits CM_Get_Parent() in hid_internal_detect_bus_type() and failure there results in HID_API_BUS_UNKNOWN, which doesn't fail the whole thing but misses some properties. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7727#note_100023

1 0

Re: [PATCH v7 0/5] MR7727: cfgmgr32, setupapi: Implement a few functions.
by Ivo Ivanov (＠logos128) 04 Apr '25

04 Apr '25

On Fri Apr 4 20:22:39 2025 +0000, Paul Gofman wrote: > Fixes MySims Kingdom not working with controllers. > WRT the last patch, we don't set any properties for devicee interfaces > currently. I could not find device id in the properties subkeys for > device interfaces on Windows (as well as any properties, actually, > across a few interfaces I checked). So I guess even we will be adding > properties for device interfaces device instance id will be treated as a > special case anyway. DEVPKEY_Device_InstanceId is the only property > which this specific game queries with > CM_Get_Device_Interface_PropertyW(), so I don't have a real world > example of any other been used. They probably use "hidapi" to communicate with hid devices: https://github.com/libusb/hidapi/blob/8c9cbf6c020974d23e4690497778f3df173d1… The Simucube Tuner app, which is used to control Simucube 2 FFB wheel bases, is also affected by this. Seems the usblib devs have switched from setupapi to cfgmgr32 in the recent years, and now this is starting to appear in games/apps. Looks like only CM_Get_Parent remains to be implemented. BTW, Steam shows a similar usage pattern of these apis in the logs, so it probably uses hidapi as well. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7727#note_100022

1 0

2025

2024

2023

2022

wine-gitlab April 2025