- wine-gitlab - winehq.org

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

2025

2024

2023

2022

wine-gitlab