- wine-gitlab - winehq.org

[PATCH 0/2] MR6401: uxtheme: Optimize drawing by avoiding unneeded TransparentBlt().
by Paul Gofman (＠gofman) 03 Sep '24

03 Sep '24

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/6401

4 13

[PATCH 0/2] MR6433: dssenh: Add support for enumerating algorithms.
by Dmitry Timoshkov (＠dmitry) 03 Sep '24

03 Sep '24

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/6433

4 4

[PATCH 0/1] MR6425: Draft: include: Name parameters in LPPROGRESS_ROUTINE typedef
by Ostap Brehin (＠osbre) 03 Sep '24

03 Sep '24

Source: https://learn.microsoft.com/en-us/windows/win32/api/winbase/nc-winbase-lppr… -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6425

4 3

[PATCH 0/1] MR6434: msiexec: Don't quote property values if already quoted.
by Hans Leidekker (＠hans) 03 Sep '24

03 Sep '24

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57024 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6434

3 2

[PATCH 0/2] MR6429: msi: Allow package template summary info strings without semicolon separator.
by Andrew Nguyen (＠arethusa) 03 Sep '24

03 Sep '24

The OpenKiosk MSI installer specifies "x64" for PID_TEMPLATE in its summary information stream, which is rejected by Wine at package open time. While the examples of valid template strings in MSDN suggest that a semicolon is mandatory in a template string, tests of template string validation show that a platform may be specified in a template without the semicolon delimiter. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52687 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6429

4 4

Re: [PATCH v4 0/4] MR5830: dxgi: Fix some d3d12 swapchain issues.
by Conor McCarthy (＠cmccarthy) 03 Sep '24

03 Sep '24

Rebased. If the two commits which move wakes down a line are an issue, please let me know and I'll remove them. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5830#note_80826

1 0

[PATCH v3 0/10] MR6374: winewayland: Get rid of the wayland surface lock.
by Rémi Bernon (＠rbernon) 03 Sep '24

03 Sep '24

(From https://gitlab.winehq.org/wine/wine/-/merge_requests/6323) -- v3: winewayland: Get rid of the window surface individual locks. winewayland: Introduce a new wayland_client_surface_create helper. winewayland: Get rid of window_surface reference from wayland_win_data. winewayland: Get rid of wayland_surface reference from window_surface. winewayland: Move window contents buffer to wayland_win_data struct. winewayland: Reset the buffer damage region immediately after copy. winewayland: Introduce a new get_window_surface_contents helper. winewayland: Introduce a new set_window_surface_contents helper. winewayland: Introduce a new ensure_window_surface_contents helper. winewayland: Post WM_WAYLAND_CONFIGURE outside of the surface lock. https://gitlab.winehq.org/wine/wine/-/merge_requests/6374

2 10

[PATCH 0/8] MR6430: Mr/dmo class reg
by Rémi Bernon (＠rbernon) 03 Sep '24

03 Sep '24

Similarly to !6362 this makes it possible to override these DLLs to use native implementation of the classes. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6430

2 8

[PATCH 0/1] MR6428: po: Update Lithuanian translation.
by Aurimas Fišeras (＠AurimasF) 03 Sep '24

03 Sep '24

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/6428

3 2

Re: [PATCH v2 0/3] MR5756: comdlg32: Fix a few issues with color dialog - approved
by Alexandre Julliard (＠julliard) 02 Sep '24

02 Sep '24

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5756

1 0

Re: [PATCH v2 0/1] MR6426: wpcap/tests: Skip tests when pcap_can_set_rfmon() returns PCAP_ERROR_PERM_DENIED. - approved
by Alexandre Julliard (＠julliard) 02 Sep '24

02 Sep '24

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6426

1 0

Re: [PATCH v4 0/8] MR6396: win32u: Stop setting DPI_PER_MONITOR_AWARE by default. - approved
by Alexandre Julliard (＠julliard) 02 Sep '24

02 Sep '24

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6396

1 0

Re: [PATCH v2 0/1] MR6422: include: Add ISelectionProvider2 definition in uiautomationcore.idl - approved
by Alexandre Julliard (＠julliard) 02 Sep '24

02 Sep '24

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6422

1 0

Re: [PATCH v10 0/3] MR5585: mmdevapi: Implement AudioClockAdjustment_SetSampleRate. - approved
by Alexandre Julliard (＠julliard) 02 Sep '24

02 Sep '24

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5585

1 0

Re: [PATCH v2 0/1] MR6419: ntdll: Ignore HW breakpoints on the Unix side. - approved
by Alexandre Julliard (＠julliard) 02 Sep '24

02 Sep '24

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6419

1 0

Re: [PATCH v2 0/1] MR6418: user32: Implement EVENT_OBJECT_FOCUS for listbox items. - approved
by Alexandre Julliard (＠julliard) 02 Sep '24

02 Sep '24

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6418

1 0

Re: [PATCH v3 0/1] MR6420: winevulkan: Update to VK spec version 1.3.295. - approved
by Alexandre Julliard (＠julliard) 02 Sep '24

02 Sep '24

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6420

1 0

Re: [PATCH v2 0/2] MR6421: d3d10/effect: Rename some variable array fields to better reflect their meaning. - approved
by Alexandre Julliard (＠julliard) 02 Sep '24

02 Sep '24

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6421

1 0

Re: [PATCH v3 0/1] MR6409: vkd3d: Import upstream release 1.13. - approved
by Alexandre Julliard (＠julliard) 02 Sep '24

02 Sep '24

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6409

1 0

Re: [PATCH v2 0/2] MR6424: explorer: Support the NoTrayItemsDisplay registry setting. - approved
by Alexandre Julliard (＠julliard) 02 Sep '24

02 Sep '24

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6424

1 0

[PATCH v2 0/6] MR6362: mfsrcsnk, mfmp4srcsnk: Register the sink and source classes in the DLLs they belong to.
by Rémi Bernon (＠rbernon) 02 Sep '24

02 Sep '24

This allows to use DLLOVERRIDES with native DLLs, making it more convenient for testing and debugging. This will also makes it possible to create an alternative media source implementation with a different backend without breaking the current one. -- v2: mfmp4srcsnk: Register the MP3 and MPEG4 sink factory classes. mfasfsrcsnk: Register the Asf Byte Stream Handler class. mfmp4srcsnk: Register the MPEG4 Byte Stream Handler class. mfsrcsnk: Register the WAV Byte Stream Handler class. mfsrcsnk: Register the AVI Byte Stream Handler class. mfsrcsnk: Refactor sink class factory helpers. https://gitlab.winehq.org/wine/wine/-/merge_requests/6362

3 7

Re: [PATCH v13 0/2] MR5761: comclt32: Allow ctrl-tab and tab hotkeys for propsheets - approved
by Alexandre Julliard (＠julliard) 02 Sep '24

02 Sep '24

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5761

1 0

[PATCH v9 0/3] MR5585: mmdevapi: Implement AudioClockAdjustment_SetSampleRate.
by Arek Hiler (＠ivyl) 02 Sep '24

02 Sep '24

This is based on work done by Andrew Eikum. It has been in some form in Proton for the last 4 years. If server's sampling rate is not 48kHz **DOOM Eternal** will try to set it 48kHz for the streams using the implemented interface. There's a whole class of audio devices that use 44.1kHz sampling rate and at least PulseAudio / PipeWire tends to inherit the value from the hardware to avoid resampling. The value can also be overridden by the user via the audio server's config files. In such cases, if the interface is not present or stubbed, this results in **audio underruns and noticeable crackling**. It's easy to test with pipewire-pulse: ``` $ cat /etc/pipewire/pipewire.conf.d/sample-rate.conf context.properties = { default.clock.rate = 41100 } ``` With PulseAudio this should be doable via setting `default-sample-rate = 41100` in `/etc/pulse/daemon.conf`. -- v9: winepulse.drv: Implement set_sample_rate. https://gitlab.winehq.org/wine/wine/-/merge_requests/5585

6 8

[PATCH v3 0/2] MR6423: kernel32: Implement GetFirmwareType, GetFirmwareEnvironmentVariable*
by Grigory Vasilyev (＠h0tc0d3) 02 Sep '24

02 Sep '24

Kernel32 Implement: - `GetFirmwareType` - `GetFirmwareEnvironmentVariableExA` - `GetFirmwareEnvironmentVariableExW` - `GetFirmwareEnvironmentVariableA` - `GetFirmwareEnvironmentVariableW`. The code is needed to check SecureBoot status, security systems and for example to check the licenses of software that can use efi variables. Example: ```C #include <stdint.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <windows.h> #include <winnt.h> /* x86_64-w64-mingw32-gcc wuefi.c -o wuefi.exe -Wl,--subsystem,console */ int main(int argc, char **argv) { BOOLEAN secureboot = 0; char asus_license[2048]; FIRMWARE_TYPE type; if(GetFirmwareType(&type)) printf("Firmware Type: %s\n", type == FirmwareTypeUefi ? "UEFI" : "BIOS"); if(GetFirmwareEnvironmentVariableA("SecureBoot", "{8be4df61-93ca-11d2-aa0d-00e098032b8c}", &secureboot, sizeof(BOOLEAN))) printf("SecureBoot: %s\n", secureboot ? "enabled" : "disabled"); if(GetFirmwareEnvironmentVariableW(L"SecureBoot", L"{8be4df61-93ca-11d2-aa0d-00e098032b8c}", &secureboot, sizeof(BOOLEAN))) printf("SecureBoot: %s\n", secureboot ? "enabled" : "disabled"); if(GetFirmwareEnvironmentVariableA("AsusOnboardToolLicense", "02076249-a52b-420e-bd53-aed044349379", asus_license, sizeof(asus_license))) printf("Asus License: \n%s\n\n", asus_license); return 0; } ``` ``` Firmware Type: UEFI SecureBoot: enabled SecureBoot: enabled Asus License: bigtext== [LicenseID]:FED7A1 [Model]:Dummy-BaseBoard-Id [Tools]:WAsusDmiS,LogoFlashS,ASUSFwConfigS,AsusEventLogS,AsusNvLockS [Customer]:DummyLic [Expire]:2022-11-24 ``` -- v3: kernel32: Implement GetFirmwareEnvironmentVariableExA, GetFirmwareEnvironmentVariableExW, GetFirmwareEnvironmentVariableA, GetFirmwareEnvironmentVariableW. kernel32: Implement GetFirmwareType. https://gitlab.winehq.org/wine/wine/-/merge_requests/6423

4 5

[PATCH 0/8] MR6427: winevulkan: Introduce a vulkan object structure.
by Rémi Bernon (＠rbernon) 02 Sep '24

02 Sep '24

I'm starting to consider wrapping more vulkan objects in win32u, I think it'll be useful to implement compositing (and incidentally shared resources with interop with the D3DKMT/NtGdi API), starting with nulldrv/offscreen swapchains. Alternatively we could export more functions from win32u and keep all the wrappers in winevulkan, but having access to win32u internals with a generic vulkan object wrapping mechanism seems to be more interesting. Right now this is not very convenient because the vulkan object hierarchy is only available in winevulkan. This introduces shared structures and API between win32u and winevulkan so they can manipulate the wrapped objects from both side. The interface would only expose what is necessary, ie: the object hierarchy and wrapped handles, the instance and device functions, and the objects rbtree for debugging, so win32u can insert its wrapper there as well. After moving the surface and swapchain wrappers to win32u, the interface would look like this: https://gitlab.winehq.org/rbernon/wine/-/blob/65ca1280d46a2dff792e298c22242… (I pushed a complete WIP branch to https://gitlab.winehq.org/rbernon/wine/-/commits/wip/vulkan-win32u-driver?r…). We can also consider moving all the winevulkan wrappers to win32u but it's not clear whether it's necessary or desirable, and we can also do that later using this interface. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6427

2 8

[PATCH 0/1] MR6426: wpcap/tests: Skip tests when pcap_can_set_rfmon() returns PCAP_ERROR_PERM_DENIED.
by Hans Leidekker (＠hans) 02 Sep '24

02 Sep '24

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/6426

2 1

[PATCH v3 0/8] MR6396: win32u: Stop setting DPI_PER_MONITOR_AWARE by default.
by Rémi Bernon (＠rbernon) 02 Sep '24

02 Sep '24

This activates the new DPI scaling, and stops pretending that every window is per-monitor DPI aware. It uses the GDI scaled surfaces for DPI-unaware windows, instead of the current higher resolution surfaces, which gives more blurry results but this is the same as Windows for DPI-unaware cases. -- v3: win32u: Stop setting DPI_PER_MONITOR_AWARE by default. explorer: Make the desktop thread per-monitor DPI aware. user32: Move dpiaware_init to SYSPARAMS_Init. server: Pass window's per-monitor DPI in set_window_pos. win32u: Pass window_from_point dpi to list_children_from_point. win32u: Map rect to window DPI in expose_window_surface. winex11: Map message pos to physical DPI in move_resize_window. winewayland: Remove unnecessary logical to physical DPI mapping. https://gitlab.winehq.org/wine/wine/-/merge_requests/6396

3 11

[PATCH v2 0/7] MR6396: win32u: Stop setting DPI_PER_MONITOR_AWARE by default.
by Rémi Bernon (＠rbernon) 02 Sep '24

02 Sep '24

This activates the new DPI scaling, and stops pretending that every window is per-monitor DPI aware. It uses the GDI scaled surfaces for DPI-unaware windows, instead of the current higher resolution surfaces, which gives more blurry results but this is the same as Windows for DPI-unaware cases. -- v2: win32u: Stop setting DPI_PER_MONITOR_AWARE by default. explorer: Make the desktop thread per-monitor DPI aware. server: Pass window's per-monitor DPI in set_window_pos. win32u: Pass window_from_point dpi to list_children_from_point. win32u: Map rect to window DPI in expose_window_surface. winex11: Map message pos to physical DPI in move_resize_window. winewayland: Remove unnecessary logical to physical DPI mapping. https://gitlab.winehq.org/wine/wine/-/merge_requests/6396

4 12

[PATCH v12 0/4] MR6304: comctl32/edit: Fix incorrect size for format rect.
by Jacob Czekalla (＠JacobCzekalla) 02 Sep '24

02 Sep '24

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56873 -- v12: comctl32/edit: Fix incorrect size for format rect when it is smaller than text. comctl32/tests: Add test for edit control format rect size. user32/edit: Fix incorrect size for format rect when it is smaller than text. user32/tests: Add test for edit control format rect size. https://gitlab.winehq.org/wine/wine/-/merge_requests/6304

4 6

[PATCH 0/3] MR5756: comdlg32: Fix a few issues with color dialog
by Fabian Maurer (＠DarkShadow44) 02 Sep '24

02 Sep '24

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/5756

3 14

Re: [PATCH v8 0/3] MR5585: mmdevapi: Implement AudioClockAdjustment_SetSampleRate.
by Huw Davies (＠huw) 02 Sep '24

02 Sep '24

Rebase. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5585#note_80684

1 0

[PATCH 0/2] MR6421: d3d10/effect: Rename some variable array fields to better reflect their meaning.
by Nikolay Sivov (＠nsivov) 02 Sep '24

02 Sep '24

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6421

3 3

[PATCH v2 0/1] MR6409: vkd3d: Import upstream release 1.13.
by Alexandre Julliard (＠julliard) 02 Sep '24

02 Sep '24

-- v2: vkd3d: Import upstream release 1.13. https://gitlab.winehq.org/wine/wine/-/merge_requests/6409

3 2

[PATCH 0/6] MR6396: win32u: Stop setting DPI_PER_MONITOR_AWARE by default.
by Rémi Bernon (＠rbernon) 02 Sep '24

02 Sep '24

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/6396

4 10

[PATCH 0/2] MR6424: explorer: Support the NoTrayItemsDisplay registry setting.
by Alex Henrie (＠alexhenrie) 02 Sep '24

02 Sep '24

This setting is a more extreme version of the ShowSystray setting: In addition to suppressing the floating systray, it suppresses systray icons in the host taskbar and in the virtual desktop taskbar. NoTrayItemsDisplay is the same registry setting that can be set on Windows to remove the system tray from the taskbar, so if any application sets it, Wine will now respect the setting. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6424

4 4

Re: [PATCH v3 0/1] MR6352: winegstreamer: Support IYUV alias for I420
by Aida Jonikienė (＠DodoGTA) 02 Sep '24

02 Sep '24

On Mon Sep 2 06:13:48 2024 +0000, Rémi Bernon wrote: > I don't know what @DodoGTA meant but it's actually **not** considered > good practice to push changes unnecessarily. > Rebasing MRs should only be done when they actually conflict (the Gitlab > indication on top is often misleading), as rebasing makes Gitlab > "Compare with previous version" feature much less useful. I meant only doing that when an MR update is actually needed (because merge commits aren't a good idea) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6352#note_80667

1 0

Re: [PATCH v3 0/1] MR6352: winegstreamer: Support IYUV alias for I420
by Rémi Bernon (＠rbernon) 02 Sep '24

02 Sep '24

However, you need to edit your commit to use your full name as committer. You don't need the "Signed-off-by" anymore but it's fine to keep it. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6352#note_80664

1 0

Re: [PATCH v3 0/1] MR6352: winegstreamer: Support IYUV alias for I420
by Rémi Bernon (＠rbernon) 02 Sep '24

02 Sep '24

I don't know what @DodoGTA meant but it's actually **not** considered good practice to push changes unnecessarily. Rebasing MRs should only be done when they actually conflict (the Gitlab indication on top is often misleading), as rebasing makes Gitlab "Compare with previous version" feature much less useful. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6352#note_80661

1 0

[PATCH v12 0/2] MR5761: comclt32: Allow ctrl-tab and tab hotkeys for propsheets
by Fabian Maurer (＠DarkShadow44) 02 Sep '24

02 Sep '24

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56103 -- v12: comclt32: Allow hotkeys for propsheet navigation. comctl32/tests: Add test for propsheet hotkey navigation. https://gitlab.winehq.org/wine/wine/-/merge_requests/5761

3 4

Re: [PATCH v2 0/1] MR6352: winegstreamer: Support IYUV alias for I420
by CreeperFace (＠dy-tea) 01 Sep '24

01 Sep '24

Will do -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6352#note_80636

1 0

[PATCH v2 0/2] MR6423: kernel32: Implement GetFirmwareType, GetFirmwareEnvironmentVariable*
by Grigory Vasilyev (＠h0tc0d3) 01 Sep '24

01 Sep '24

Kernel32 Implement: - `GetFirmwareType` - `GetFirmwareEnvironmentVariableExA` - `GetFirmwareEnvironmentVariableExW` - `GetFirmwareEnvironmentVariableA` - `GetFirmwareEnvironmentVariableW`. The code is needed to check SecureBoot status, security systems and for example to check the licenses of software that can use efi variables. Example: ```C #include <stdint.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <windows.h> #include <winnt.h> /* x86_64-w64-mingw32-gcc wuefi.c -o wuefi.exe -Wl,--subsystem,console */ int main(int argc, char **argv) { BOOLEAN secureboot = 0; char asus_license[2048]; FIRMWARE_TYPE type; if(GetFirmwareType(&type)) printf("Firmware Type: %s\n", type == FirmwareTypeUefi ? "UEFI" : "BIOS"); if(GetFirmwareEnvironmentVariableA("SecureBoot", "{8be4df61-93ca-11d2-aa0d-00e098032b8c}", &secureboot, sizeof(BOOLEAN))) printf("SecureBoot: %s\n", secureboot ? "enabled" : "disabled"); if(GetFirmwareEnvironmentVariableW(L"SecureBoot", L"{8be4df61-93ca-11d2-aa0d-00e098032b8c}", &secureboot, sizeof(BOOLEAN))) printf("SecureBoot: %s\n", secureboot ? "enabled" : "disabled"); if(GetFirmwareEnvironmentVariableA("AsusOnboardToolLicense", "02076249-a52b-420e-bd53-aed044349379", asus_license, sizeof(asus_license))) printf("Asus License: \n%s\n\n", asus_license); return 0; } ``` ``` Firmware Type: UEFI SecureBoot: enabled SecureBoot: enabled Asus License: bigtext== [LicenseID]:FED7A1 [Model]:Dummy-BaseBoard-Id [Tools]:WAsusDmiS,LogoFlashS,ASUSFwConfigS,AsusEventLogS,AsusNvLockS [Customer]:DummyLic [Expire]:2022-11-24 ``` -- v2: kernel32: Implement GetFirmwareEnvironmentVariableExA, GetFirmwareEnvironmentVariableExW, GetFirmwareEnvironmentVariableA, GetFirmwareEnvironmentVariableW. kernel32: Implement GetFirmwareType. https://gitlab.winehq.org/wine/wine/-/merge_requests/6423

3 4

[PATCH 0/1] MR6423: kernel32: Implement GetFirmwareType, GetFirmwareEnvironmentVariableExA,...
by Grigory Vasilyev (＠h0tc0d3) 01 Sep '24

01 Sep '24

kernel32: Implement GetFirmwareType, GetFirmwareEnvironmentVariableExA, GetFirmwareEnvironmentVariableExW, GetFirmwareEnvironmentVariableA, GetFirmwareEnvironmentVariableW. Example: ```C #include <stdint.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <windows.h> #include <winnt.h> /* x86_64-w64-mingw32-gcc wuefi.c -o wuefi.exe -Wl,--subsystem,console */ int main(int argc, char **argv) { BOOLEAN secureboot = 0; char asus_license[2048]; FIRMWARE_TYPE type; if(GetFirmwareType(&type)) printf("Firmware Type: %s\n", type == FirmwareTypeUefi ? "UEFI" : "BIOS"); if(GetFirmwareEnvironmentVariableA("SecureBoot", "{8be4df61-93ca-11d2-aa0d-00e098032b8c}", &secureboot, sizeof(BOOLEAN))) printf("SecureBoot: %s\n", secureboot ? "enabled" : "disabled"); if(GetFirmwareEnvironmentVariableW(L"SecureBoot", L"{8be4df61-93ca-11d2-aa0d-00e098032b8c}", &secureboot, sizeof(BOOLEAN))) printf("SecureBoot: %s\n", secureboot ? "enabled" : "disabled"); if(GetFirmwareEnvironmentVariableA("AsusOnboardToolLicense", "02076249-a52b-420e-bd53-aed044349379", asus_license, sizeof(asus_license))) printf("Asus License: \n%s\n\n", asus_license); return 0; } ``` ``` Firmware Type: UEFI SecureBoot: enabled SecureBoot: enabled Asus License: bigtext== [LicenseID]:FED7A1 [Model]:Dummy-BaseBoard-Id [Tools]:WAsusDmiS,LogoFlashS,ASUSFwConfigS,AsusEventLogS,AsusNvLockS [Customer]:DummyLic [Expire]:2022-11-24 ``` -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6423

6 8

Re: [PATCH v2 0/1] MR6352: winegstreamer: Support IYUV alias for I420
by Aida Jonikienė (＠DodoGTA) 01 Sep '24

01 Sep '24

You should rebase and force push to update a MR (this keeps things cleaner); Julliard will probably pick your commit manually (but it's good practice to do that) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6352#note_80626

1 0

Re: [PATCH v32 0/4] MR6315: plugplay: Rework how PnP notifications are sent over RPC to support DBT_DEVTYP_HANDLE events.
by Rémi Bernon (＠rbernon) 31 Aug '24

31 Aug '24

> If you're referring to the new RPC structs, I understand. That being said, my one concern is whether stuffing the file path into `dbch_data` could potentially break some code out there that uses `dbch_size` to guess which event is being sent (something like `if (n->dbch_size == (sizeof(DEV_BROADCAST_HANDLE) + sizeof(BTH_RADIO_IN_RANGE)`). It is an extremely stupid way to check for the event, but I'm not sure whether someone doing this can be safely discounted. I'll write some test code to see if this can be done on Windows to begin with. But as far as I understand, as `plugplay_send_event` is completely non-standard, these structs are only ever sent internally? So you don't really need to bother about abusing some fields or size for the internal notification, you even considered using custom structs which you would convert back and forth on both sides. Simply put whatever you need in the DEV_BROADCAST_HANDLE struct you send, using any unused field, or some other way, to put the device path in it if you need that, and just make sure you fix it up to a correct DEV_BROADCAST_HANDLE struct before calling the notification callback? Although I don't feel like it's even worth it you could even use a custom DEV_BROADCAST_HDR based struct, or extend DEV_BROADCAST_HANDLE with a custom derived struct which has an explicit device path, for the internal messages. I just don't think you need to change the DEV_BROADCAST_HDR base, or change the DEV_BROADCAST_DEVICEINTERFACE code in any significant way for this. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6315#note_80622

1 0

Re: [PATCH v32 0/4] MR6315: plugplay: Rework how PnP notifications are sent over RPC to support DBT_DEVTYP_HANDLE events.
by Vibhav Pant (＠vibhavp) 31 Aug '24

31 Aug '24

On Sat Aug 31 16:30:43 2024 +0000, Elizabeth Figura wrote: > Sorry it's taken me so long to get to this, but 3/4 seems suspicious. > I'd think BroadcastDeviceNotification() [or SendMessageNotify() or > whatever it calls internally] should be making a copy of the message > data itself. Are we not doing that? Should we be doing that instead? Yeah, I might be wrong here. A quick inspection of the code does suggest that we do make copies in `(un)pack_message`. MSDN's documentation for `SendNotifyMessageW`\[1\] warned that messages containing pointers could not be sent as they would result in access to a dangling reference, which is what prompted me to write 3/4. However, `DEV_BROADCAST_DEVICEINTERFACE` messages don't contain any pointers, so this doesn't apply here. \[1\] https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-send… -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6315#note_80621

1 0

Re: [PATCH v32 0/4] MR6315: plugplay: Rework how PnP notifications are sent over RPC to support DBT_DEVTYP_HANDLE events.
by Vibhav Pant (＠vibhavp) 31 Aug '24

31 Aug '24

> I don't think adding custom structs is justified at this point, especially as it requires rewriting large parts of the code in multiple modules at the same time. `wine/dbt.h` doesn't really _add_ a new struct. It merely makes `struct device_notification_details` a common public declaration. The struct is currently [a private def in `dlls/sechost/service.c`](https://gitlab.winehq.org/wine/wine/-/blob/055bddab4f14a1f73e887b88b86408d654382c2b/dlls/sechost/service.c?page=2#L1976), and needs to be defined again for any component that utilizes `I_ScRegisterDeviceNotification`. [`dlls/user32/input.c` seems to be the only place where it gets used ATM](https://gitlab.winehq.org/wine/wine/-/blob/055bddab4f14a1f73e887b88b86…, and the motivation behind shifting the definition to a common header was to preempt the possibility of the struct's definition accidentally diverging in the future. > However, passing process-private handles around ~~to other processes~~ and later getting them back looks wrong. What happens if you register for notification on a handle then close it right away? Does the notification keep firing with the old handle value? It seem surprising and it would be a nice thing to test for instance. Yeah, this is something I've been curious about as well. I suppose one way to test this would be to also add an implementation for`IoReportTargetDeviceChange` (thanks @zfigura!) to this MR, and test `RegisterDeviceNotification`'s behavior in `dlls/ntoskrnl.exe/tests/driver_pnp.c`. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6315#note_80620

1 0

[PATCH 0/1] MR6422: include: Add ISelectionProvider2 definition in uiautomationcore.idl
by Biswapriyo Nath (＠Biswa96) 31 Aug '24

31 Aug '24

Required for https://github.com/juce-framework/JUCE/blob/8.0.1/modules/juce_gui_basics/n… -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6422

3 2

[PATCH v12 0/6] MR6402: bluetoothapis: Implement basic SDP methods.
by Vibhav Pant (＠vibhavp) 31 Aug '24

31 Aug '24

The MR adds implementations (+ a few tests) for the following methods in `bluetoothapis.h`: * `BluetoothSdpEnumAttributes` * `BluetoothSdpGetContainerElementData` * `BluetoothSdpGetElementData` * `BluetoothSdpGetAttributeValue` -- v12: bluetoothapis/tests: Add tests for BluetoothSdpEnumAttributes and BluetoothSdpGetAttributeValue. bluetoothapis: Implement BluetoothSdpGetAttributeValue. bluetoothapis/tests: Add unit tests for BluetoothSdpGetContainerElementData and BluetoothSdpGetElementData. bluetoothapis: Implement BluetoothSdpEnumAttributes. bluetoothapis: Implement BluetoothSdpGetContainerElementData. bluetoothapis: Implement BluetoothSdpGetElementData. https://gitlab.winehq.org/wine/wine/-/merge_requests/6402

2 6

[PATCH 0/6] MR6360: d3dx9: Beginning of pixel format handling changes.
by Connor McAdams (＠cmcadams) 30 Aug '24

30 Aug '24

This is the initial set of patches for handling new pixel format types. I've pushed a branch [here](https://gitlab.winehq.org/cmcadams/wine/-/commits/WIP/d3dx-shared-sou… containing the rest of my current patches if additional context would be useful, the new format handling patches end with `ed7022a0838b346f4fa2b229ce7e8e6b8ebc2244`. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6360

3 24

Re: [PATCH v2 0/3] MR6407: include: Updated a few gdiplus types. - approved
by Alexandre Julliard (＠julliard) 30 Aug '24

30 Aug '24

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6407

1 0

Re: [PATCH v2 0/1] MR6412: winecoreaudio: Set the synth volume to the greater of the left and right channels. - approved
by Alexandre Julliard (＠julliard) 30 Aug '24

30 Aug '24

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6412

1 0

Re: [PATCH v2 0/1] MR6415: mscoree: Update Wine Mono to 9.3.0. - approved
by Alexandre Julliard (＠julliard) 30 Aug '24

30 Aug '24

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6415

1 0

Re: [PATCH v2 0/1] MR6416: secur32: Ensure unixlib function tables and enum stay in sync. - approved
by Alexandre Julliard (＠julliard) 30 Aug '24

30 Aug '24

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6416

1 0

Re: [PATCH v2 0/1] MR6414: secur32: Simplify the cred_enabled_protocols logic slightly. - approved
by Alexandre Julliard (＠julliard) 30 Aug '24

30 Aug '24

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6414

1 0

Re: [PATCH v2 0/5] MR6411: Cmd engine rewrite (part XXIII) - approved
by Alexandre Julliard (＠julliard) 30 Aug '24

30 Aug '24

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6411

1 0

Re: [PATCH v32 0/4] MR6315: plugplay: Rework how PnP notifications are sent over RPC to support DBT_DEVTYP_HANDLE events.
by Rémi Bernon (＠rbernon) 30 Aug '24

30 Aug '24

On Fri Aug 30 18:00:21 2024 +0000, Vibhav Pant wrote: > > Maybe we can avoid sending the paths every time by moving the > filtering to plugplay, adapting the interface a bit for this. There > could be additional methods to register paths / get plugplay handles in > return, and later use these handle as device handles. > Perhaps, but wouldn't this make both plugplay service, and the > notification code sechost/service.c a lot more stateful as a result? Re: > device handles, if you're referring to the `dbch_handle` field in > `DEV_BROADCAST_HANDLE`, we already get that from the user using > `RegisterDeviceNotification`, and the current code just uses them for > sending notifications. I don't think adding custom structs is justified at this point, especially as it requires rewriting large parts of the code in multiple modules at the same time. > Perhaps, but wouldn't this make both plugplay service, and the notification code sechost/service.c a lot more stateful as a result? Re: device handles, if you're referring to the `dbch_handle` field in `DEV_BROADCAST_HANDLE`, we already get that from the user using `RegisterDeviceNotification`, and the current code just uses them for sending notifications. Fwiw I'm fine keeping the paths, and using the `reserved` field to describe them. I was just considering additional improvements but this specifically doesn't need to be done now. However, passing process-private handles around to other processes and later getting them back looks wrong. What happens if you register for notification on a handle then close it right away? Does the notification keep firing with the old handle value? It seem surprising and it would be a nice thing to test for instance. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6315#note_80567

1 0

Re: [PATCH v2 0/1] MR6413: msi: Bump version to 5.0. - approved
by Alexandre Julliard (＠julliard) 30 Aug '24

30 Aug '24

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6413

1 0

Re: [PATCH v2 0/2] MR6410: msiexec: Don't remove quotes from properties passed on the command line. - approved
by Alexandre Julliard (＠julliard) 30 Aug '24

30 Aug '24

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6410

1 0

Re: [PATCH v2 0/1] MR6403: winemac.drv: Call CGWindowListCreateImageFromArray through a dlsym-obtained pointer. - approved
by Alexandre Julliard (＠julliard) 30 Aug '24

30 Aug '24

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6403

1 0

Re: [PATCH v2 0/1] MR6406: include: Add input assembler related constants in d3d11.idl - approved
by Alexandre Julliard (＠julliard) 30 Aug '24

30 Aug '24

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6406

1 0

Re: [PATCH v2 0/1] MR6405: winemapi: Don't write past the end of the argv array. - approved
by Alexandre Julliard (＠julliard) 30 Aug '24

30 Aug '24

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6405

1 0

Re: [PATCH v8 0/1] MR6299: ntdll: Determine the available address space dynamically for 64bit architectures. - approved
by Alexandre Julliard (＠julliard) 30 Aug '24

30 Aug '24

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6299

1 0

Re: [PATCH v2 0/1] MR6404: packager: Prefer native version. - approved
by Alexandre Julliard (＠julliard) 30 Aug '24

30 Aug '24

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6404

1 0

Re: [PATCH v6 0/5] MR6386: winewayland: Reduce window surface buffer queue recreations. - approved
by Alexandre Julliard (＠julliard) 30 Aug '24

30 Aug '24

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6386

1 0

[PATCH v2 0/1] MR6420: winevulkan: Update to VK spec version 1.3.295.
by Georg Lehmann (＠DadSchoorse) 30 Aug '24

30 Aug '24

I have been putting this off for too long because handling VK_KHR_maintenance7 is not trivial. But by now a lot of other extensions have been released, so we should at least support those. -- v2: winevulkan: Update to VK spec version 1.3.295. https://gitlab.winehq.org/wine/wine/-/merge_requests/6420

2 1

[PATCH 0/1] MR6419: ntdll: Ignore HW breakpoints on the Unix side.
by Paul Gofman (＠gofman) 30 Aug '24

30 Aug '24

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/6419

4 4

[PATCH 0/1] MR6418: user32: Implement EVENT_OBJECT_FOCUS for listbox items.
by Esme Povirk (＠madewokherd) 30 Aug '24

30 Aug '24

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/6418

2 1

[PATCH v14 0/2] MR6130: shell32: Added stubs for the EnumerableObjectCollection COM class.
by Kevin Martinez (＠kevinrmartinez) 30 Aug '24

30 Aug '24

Stub added for the IEnumObjects and IObjectCollection interfaces, so that programs won't crash when calling it. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53620 Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56891 -- v14: shell32: Added stub for IObjectCollection interface. shell32: Added stub for IEnumObjects interface. https://gitlab.winehq.org/wine/wine/-/merge_requests/6130

3 3

[PATCH 0/1] MR6416: secur32: Ensure unixlib function tables and enum stay in sync.
by Brendan Shanks (＠bshanks) 30 Aug '24

30 Aug '24

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/6416

3 2

[PATCH 0/1] MR6415: mscoree: Update Wine Mono to 9.3.0.
by Esme Povirk (＠madewokherd) 30 Aug '24

30 Aug '24

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/6415

3 2

[PATCH 0/1] MR6414: secur32: Simplify the cred_enabled_protocols logic slightly.
by Huw Davies (＠huw) 30 Aug '24

30 Aug '24

This avoids an (incorrect) compiler warning. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6414

2 1

Re: [PATCH v32 0/4] MR6315: plugplay: Rework how PnP notifications are sent over RPC to support DBT_DEVTYP_HANDLE events.
by Vibhav Pant (＠vibhavp) 30 Aug '24

30 Aug '24

> Maybe we can avoid sending the paths every time by moving the filtering to plugplay, adapting the interface a bit for this. There could be additional methods to register paths / get plugplay handles in return, and later use these handle as device handles. Perhaps, but wouldn't this make both plugplay service, and the notification code sechost/service.c a lot more stateful as a result? Re: device handles, if you're referring to the `dbch_handle` field in `DEV_BROADCAST_HANDLE`, we already get that from the user using `RegisterDeviceNotification`, and the current code just uses them for sending notifications. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6315#note_80535

1 0

[PATCH 0/1] MR6405: winemapi: Don't write past the end of the argv array.
by Huw Davies (＠huw) 30 Aug '24

30 Aug '24

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/6405

3 2

Re: [PATCH v32 0/4] MR6315: plugplay: Rework how PnP notifications are sent over RPC to support DBT_DEVTYP_HANDLE events.
by Elizabeth Figura (＠zfigura) 30 Aug '24

30 Aug '24

On Fri Aug 30 05:47:12 2024 +0000, Rémi Bernon wrote: > > @rbernon I'm okay with using reserved as an offset to pass the device > path, but we'd still have to pass it for every message for filtering. I > didn't want to utilize `reserved` mostly out of caution, if it ever > turned out to be that the field did have some undocumented semantics > after all. > Maybe we can avoid sending the paths every time by moving the filtering > to plugplay, adapting the interface a bit for this. There could be > additional methods to register paths / get plugplay handles in return, > and later use these handle as device handles. That seems like an awful lot of complication just to avoid defining a structure? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6315#note_80533

1 0

[PATCH 0/1] MR6412: winecoreaudio: Set the synth volume to the greater of the left and right channels.
by Huw Davies (＠huw) 30 Aug '24

30 Aug '24

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/6412

3 3

[PATCH 0/5] MR6399: Implement GetExtendedTcp/UdpTable on top of a new server call
by Tim Clem (＠tclem) 30 Aug '24

30 Aug '24

This series is motivated by performance requirements for GetExtendedTcpTable, especially the tables that require owner PIDs. In the worst case, the existing code scans all /proc/\<pid\>/fd directories for all Wine process for every socket, and may repeat the entire scan up to 5 times if the number of connections outgrew the buffer. With esync, processes can easily have hundreds of entries in /proc/\<pid\>/fd. And, in certain environments, reading the files under /proc can be very slow; I've seen GetExtendedTcpTable take almost 2 seconds to complete. Some applications (GOG Galaxy, Steam) use the TCP table to check that incoming connections to local services are from a set of whitelisted processes. It's possible for the GetExtendedTcpTable to take longer than the timeout on the socket, which results in failed communication between the client and service. wineserver knows about all sockets and what process they belong to. The only missing information needed for GetExtendedTcpTable is the state of TCP sockets, which is recoverable from getsockopt(TCP_INFO). I've added a function in server/handle.c that enumerates all handles of a given type in all processes. The new server calls use that to find all sockets and return the needed information. Apologies for commit 3 being large. I couldn't think of a way to split it without introducing dead code. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6399

4 14

[PATCH v11 0/6] MR6402: bluetoothapis: Implement basic SDP methods.
by Vibhav Pant (＠vibhavp) 30 Aug '24

30 Aug '24

The MR adds implementations (+ a few tests) for the following methods in `bluetoothapis.h`: * `BluetoothSdpEnumAttributes` * `BluetoothSdpGetContainerElementData` * `BluetoothSdpGetElementData` * `BluetoothSdpGetAttributeValue` -- v11: bluetoothapis/tests: Add test for BluetoothSdpEnumAttributes and BluetoothSdpGetAttributeValue. bluetoothapis: Implement BluetoothSdpGetAttributeValue. bluetoothapis/tests: Add unit tests for BluetoothSdpGetContainerElementData and BluetoothSdpGetElementData. https://gitlab.winehq.org/wine/wine/-/merge_requests/6402

2 6

[PATCH v8 0/6] MR6402: bluetoothapis: Implement basic SDP methods.
by Vibhav Pant (＠vibhavp) 30 Aug '24

30 Aug '24

The MR adds implementations (+ a few tests) for the following methods in `bluetoothapis.h`: * `BluetoothSdpEnumAttributes` * `BluetoothSdpGetContainerElementData` * `BluetoothSdpGetElementData` * `BluetoothSdpGetAttributeValue` -- v8: bluetoothapis/tests: Add test for BluetoothSdpGetAttributeValue. https://gitlab.winehq.org/wine/wine/-/merge_requests/6402

2 6

[PATCH v7 0/6] MR6402: bluetoothapis: Implement basic SDP methods.
by Vibhav Pant (＠vibhavp) 30 Aug '24

30 Aug '24

The MR adds implementations (+ a few tests) for the following methods in `bluetoothapis.h`: * `BluetoothSdpEnumAttributes` * `BluetoothSdpGetContainerElementData` * `BluetoothSdpGetElementData` * `BluetoothSdpGetAttributeValue` -- v7: bluetoothapis/tests: Add test for BluetoothSdpGetAttributeValue. bluetoothapis: Implement BluetoothSdpGetAttributeValue. bluetoothapis/tests: Add unit tests for BluetoothSdpEnumAttributes, BluetoothSdpGetContainerElementData, and BluetoothSdpGetElementData. https://gitlab.winehq.org/wine/wine/-/merge_requests/6402

3 7

[PATCH 0/1] MR6413: msi: Bump version to 5.0.
by Hans Leidekker (＠hans) 30 Aug '24

30 Aug '24

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54212 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6413

2 1

[PATCH 0/1] MR6409: vkd3d: Import upstream release 1.13.
by Alexandre Julliard (＠julliard) 30 Aug '24

30 Aug '24

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/6409

4 3

[PATCH 0/5] MR6411: Cmd engine rewrite (part XXIII)
by eric pouech (＠epo) 30 Aug '24

30 Aug '24

This is part XXIII of cmd engine rewrite. This MR covers: - some fixes from previous patches, - some preparation for revisiting external/builtin commands -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6411

3 6

[PATCH 0/2] MR6410: msiexec: Don't remove quotes from properties passed on the command line.
by Hans Leidekker (＠hans) 30 Aug '24

30 Aug '24

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57024 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6410

2 2

[PATCH 0/3] MR6408: odbc32: Handle odbcv2 for GetData
by Alistair Leslie-Hughes (＠alesliehughes) 30 Aug '24

30 Aug '24

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/6408

4 8

[PATCH v6 0/6] MR6402: bluetoothapis: Implement basic SDP methods.
by Vibhav Pant (＠vibhavp) 30 Aug '24

30 Aug '24

The MR adds implementations (+ a few tests) for the following methods in `bluetoothapis.h`: * `BluetoothSdpEnumAttributes` * `BluetoothSdpGetContainerElementData` * `BluetoothSdpGetElementData` * `BluetoothSdpGetAttributeValue` -- v6: bluetoothapis/tests: Add test for BluetoothSdpGetAttributeValue. bluetoothapis: Implement BluetoothSdpGetAttributeValue. bluetoothapis/tests: Add unit tests for BluetoothSdpEnumAttributes, BluetoothSdpGetContainerElementData, and BluetoothSdpGetElementData. https://gitlab.winehq.org/wine/wine/-/merge_requests/6402

3 7

[PATCH v2 0/1] MR6285: shell32: Allow FindExecutables to find unix files.
by Alistair Leslie-Hughes (＠alesliehughes) 30 Aug '24

30 Aug '24

This fixes one of the regression with ShellExecute when using a full patch and an executable without an extension. -- v2: shell32: Allow FindExecutables to find unix files. https://gitlab.winehq.org/wine/wine/-/merge_requests/6285

3 2

Re: [PATCH v5 0/5] MR6386: winewayland: Reduce window surface buffer queue recreations. - approved
by Alexandros Frantzis (＠afrantzis) 30 Aug '24

30 Aug '24

This merge request was approved by Alexandros Frantzis. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6386

1 0

Re: [PATCH v5 0/5] MR6386: winewayland: Reduce window surface buffer queue recreations.
by Alexandros Frantzis (＠afrantzis) 30 Aug '24

30 Aug '24

Thanks, LGTM! Note that with this MR we can sometimes get artifacts in GL applications such as: ![artifact](/uploads/1bb34fa9cefc1187e4edaebe65242497/artifact.png) However this is not a problem with the change itself, but rather this change is interacting with two existing deficiencies in the driver: 1. `wayland_window_surface_set_clip()` is not implemented, hence we get such artifacts in our committed window surface buffers. 2. OpenGL surfaces not presented opaquely hence we can actually see the artifacts in the window surface behind the GL subsurface. We might want to revisit using EGL_EXT_present_opaque now that https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28153 has been merged, although this would require a Mesa version check in the Wayland driver to use the feature safely. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6386#note_80510

1 0

[PATCH 0/3] MR6407: include: Updated a few gdiplus types.
by Alistair Leslie-Hughes (＠alesliehughes) 30 Aug '24

30 Aug '24

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/6407

3 4

[PATCH 0/1] MR6406: include: Add input assembler related constants in d3d11.idl
by Biswapriyo Nath (＠Biswa96) 30 Aug '24

30 Aug '24

Required for https://github.com/microsoft/DirectXTK/blob/jun2024/Src/ModelLoadSDKMESH.cp… -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6406

3 2

Re: [PATCH v32 0/4] MR6315: plugplay: Rework how PnP notifications are sent over RPC to support DBT_DEVTYP_HANDLE events.
by Rémi Bernon (＠rbernon) 30 Aug '24

30 Aug '24

> @rbernon I'm okay with using reserved as an offset to pass the device path, but we'd still have to pass it for every message for filtering. I didn't want to utilize `reserved` mostly out of caution, if it ever turned out to be that the field did have some undocumented semantics after all. Maybe we can avoid sending the paths every time by moving the filtering to plugplay, adapting the interface a bit for this. There could be additional methods to register paths / get plugplay handles in return, and later use these handle as device handles. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6315#note_80507

1 0

[PATCH 0/1] MR6404: packager: Prefer native version.
by Elizabeth Figura (＠zfigura) 30 Aug '24

30 Aug '24

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/6404

2 2

Re: [PATCH v32 0/4] MR6315: plugplay: Rework how PnP notifications are sent over RPC to support DBT_DEVTYP_HANDLE events.
by Elizabeth Figura (＠zfigura) 30 Aug '24

30 Aug '24

On Thu Aug 29 23:38:23 2024 +0000, Vibhav Pant wrote: > @zfigura Testing it is tricky. My plan was to utilize it in the > bluetooth driver by directly calling `plugplay_send_event` from the > driver code itself, and I'm not sure what the equivalent of that would > be in Windows. > @rbernon I'm okay with using reserved as an offset to pass the device > path, but we'd still have to pass it for every message for filtering. I > didn't want to utilize `reserved` mostly out of caution, if it ever > turned out to be that the field did have some undocumented semantics > after all. After doing a bit of research, I believe the Windows interface is IoReportTargetDeviceChange(). See [1], which mentions using that function to report the device notification, and that user mode should register for it with RegisterDeviceNotification(). That function is probably only used for DBT_DEVTYP_HANDLE. I suspect there is no public interface for DBT_DEVTYP_DEVICEINTERFACE. The corresponding kernel-mode identifier for that one is EventCategoryDeviceInterfaceChange, but I suspect that IoReportTargetDeviceChange() only deals with EventCategoryTargetDeviceChange. This would make sense since device interface notifications should only be generated by the kernel anyway. [I have no idea about the other DBT_DEVTYPE_* values. Are they even ever sent in NT?] [1] https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/using-pnp… -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6315#note_80501

1 0

Re: [PATCH v7 0/1] MR6299: ntdll: Determine the available address space dynamically for 64bit architectures.
by Garrett Mesmer (＠gmesmer) 30 Aug '24

30 Aug '24

On Fri Aug 30 02:21:05 2024 +0000, Alexandre Julliard wrote: > Much better, thanks. Could you please fix the authorship information in > the commit to use your full name? My apologies. I thought the authorship name was supposed to match the gitlab username instead of full name. It is corrected now. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6299#note_80500

1 0

Re: [PATCH v5 0/1] MR5509: Add tests to MF Media Engine
by Brendan McGrath (＠redmcg) 30 Aug '24

30 Aug '24

@nsivov Should I close this one? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5509#note_80498

1 0

[PATCH v2 0/1] MR5978: winegstreamer: Optimise copy to DXGI buffer.
by Brendan McGrath (＠redmcg) 30 Aug '24

30 Aug '24

Using IMF2DBuffer2_Lock2DSize with LockFlags_Write dramatically improves performance over IMFMediaBuffer_Lock when using a DXGI buffer. IMFMediaBuffer_Lock does not know that this buffer will not be read and therefore performs an unnecessary transfer of the texture from GPU to CPU before it is overwritten. -- v2: winegstreamer: Optimise copy to DXGI buffer. https://gitlab.winehq.org/wine/wine/-/merge_requests/5978

3 7

[PATCH v5 0/6] MR6402: bluetoothapis: Implement basic SDP methods.
by Vibhav Pant (＠vibhavp) 30 Aug '24

30 Aug '24

The MR adds implementations (+ a few tests) for the following methods in `bluetoothapis.h`: * `BluetoothSdpEnumAttributes` * `BluetoothSdpGetContainerElementData` * `BluetoothSdpGetElementData` * `BluetoothSdpGetAttributeValue` -- v5: bluetoothapis/tests: Add test for BluetoothSdpGetAttributeValue. bluetoothapis: Implement BluetoothSdpGetAttributeValue. bluetoothapis/tests: Add unit tests for BluetoothSdpEnumAttributes, BluetoothSdpGetContainerElementData, and BluetoothSdpGetElementData. https://gitlab.winehq.org/wine/wine/-/merge_requests/6402

3 7

[PATCH v4 0/6] MR6402: bluetoothapis: Implement basic SDP methods.
by Vibhav Pant (＠vibhavp) 30 Aug '24

30 Aug '24

The MR adds implementations (+ a few tests) for the following methods in `bluetoothapis.h`: * `BluetoothSdpEnumAttributes` * `BluetoothSdpGetContainerElementData` * `BluetoothSdpGetElementData` * `BluetoothSdpGetAttributeValue` -- v4: bluetoothapis/tests: Add test for BluetoothSdpGetAttributeValue. bluetoothapis: Implement BluetoothSdpGetAttributeValue. bluetoothapis/tests: Add unit tests for BluetoothSdpEnumAttributes, BluetoothSdpGetContainerElementData, and BluetoothSdpGetElementData. bluetoothapis: Implement BluetoothSdpEnumAttributes. bluetoothapis: Implement BluetoothSdpGetContainerElementData. bluetoothapis: Implement BluetoothSdpGetElementData. https://gitlab.winehq.org/wine/wine/-/merge_requests/6402

2 6

[PATCH v3 0/6] MR6402: bluetoothapis: Implement basic SDP methods.
by Vibhav Pant (＠vibhavp) 29 Aug '24

29 Aug '24

The MR adds implementations (+ a few tests) for the following methods in `bluetoothapis.h`: * `BluetoothSdpEnumAttributes` * `BluetoothSdpGetContainerElementData` * `BluetoothSdpGetElementData` * `BluetoothSdpGetAttributeValue` -- v3: bluetoothapis/tests: Add test for BluetoothSdpGetAttributeValue. bluetoothapis: Implement BluetoothSdpGetAttributeValue. bluetoothapis/tests: Add unit tests for BluetoothSdpEnumAttributes, BluetoothSdpGetContainerElementData, and BluetoothSdpGetElementData. https://gitlab.winehq.org/wine/wine/-/merge_requests/6402

2 6

Re: [PATCH v32 0/4] MR6315: plugplay: Rework how PnP notifications are sent over RPC to support DBT_DEVTYP_HANDLE events.
by Vibhav Pant (＠vibhavp) 29 Aug '24

29 Aug '24

On Thu Aug 29 16:19:09 2024 +0000, Elizabeth Figura wrote: > Actually, I'm a bit confused, because now I'm not sure where RPC does do > that? I was assuming it was a user-marshalled type which implicitly > calls DuplicateHandle(), but that's not the case. > The lack of tests in this patch set is a little disturbing. Is it > possible to test this behaviour? I don't know under what circumstances > handle events are sent [and I can't easily find anyone successfully > using DBT_DEVTYP_HANDLE online]. We do have support for testing PnP > drivers, though, if that's necessary; see dlls/ntoskrnl.exe/tests/driver_pnp.c. @zfigura Testing it is tricky. My plan was to utilize it in the bluetooth driver by directly calling `plugplay_send_event` from the driver code itself, and I'm not sure what the equivalent of that would be in Windows. @rbernon I'm okay with using reserved as an offset to pass the device path, but we'd still have to pass it for every message for filtering. I didn't want to utilize `reserved` mostly out of caution, if it ever turned out to be that the field did have some undocumented semantics after all. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6315#note_80493

1 0

2025

2024

2023

2022

wine-gitlab