- wine-gitlab - winehq.org

[PATCH 0/2] MR7425: jscript: Obtain the jsdisp for host objects in other contexts.
by Gabriel Ivăncescu (＠insn) 27 Feb '25

27 Feb '25

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

3 9

[PATCH v4 0/2] MR7417: mfplat: Modify MFCreateWaveFormatExFromMFMediaType to allow all subtypes without MF_MT_USER_DATA.
by Brendan McGrath (＠redmcg) 27 Feb '25

27 Feb '25

This MR: - adds tests for additional subtypes when `MF_MT_USER_DATA` is missing; and - modifies MFCreateWaveFormatExFromMFMediaType to pass these tests -- v4: mfplat: Allow MF_MT_USER_DATA to be missing for all subtypes. mfplat/tests: Add additional MFCreateWaveFormatExFromMFMediaType tests. https://gitlab.winehq.org/wine/wine/-/merge_requests/7417

2 3

[PATCH v2 0/2] MR7437: rtworkq: Fix private queue id mask check.
by Nikolay Sivov (＠nsivov) 27 Feb '25

27 Feb '25

-- v2: mfplat/tests: Run tests modifying process state in separate processes. https://gitlab.winehq.org/wine/wine/-/merge_requests/7437

2 2

Re: [PATCH v3 0/0] MR7388: Draft: Master - closed
by Alexandre Julliard (＠julliard) 27 Feb '25

27 Feb '25

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

1 0

Re: [PATCH v18 0/1] MR7400: cmd: Allow any key to continue past DIR /P pauses.
by Joe Souza (＠JoeS209) 27 Feb '25

27 Feb '25

On Thu Feb 27 18:51:13 2025 +0000, eric pouech wrote: > the attached patch (on top of what you sent earlier on) should work as expected: > * the annoying parts: console handles don't support overlapped mode, and > input console handles are signaled when there's a pending event... but a > pending event could be mouse move, window resize, ctrl key down & up... > maybe that's the reason you always check it as signaled > * so the attached patch waits on both console input handle and control c > event, but has to discriminate when the console input handle is signaled > whether there's an actual character or some other things > * it's still racy at some places, but given the API I don't see a clean > way to do it > * [wait-con.patch](/uploads/a537c394d4b98165b791a7979ad3f8ca/wait-con.patch) Thanks for the patch. Will check it out here. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7400#note_96144

1 0

[PATCH 0/1] MR7437: rtworkq: Fix private queue id mask check.
by Nikolay Sivov (＠nsivov) 27 Feb '25

27 Feb '25

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

2 1

Re: [PATCH v18 0/1] MR7400: cmd: Allow any key to continue past DIR /P pauses.
by eric pouech (＠epo) 27 Feb '25

27 Feb '25

On Thu Feb 27 16:00:21 2025 +0000, Joe Souza wrote: > I'll answer #2 first: > Under Windows, Ctrl-C definitely does break out of a DIR /P pause. > Regarding the second part, I completely agree that the proper way to > handle this would be to wait on both input and the Ctrl-C event. I have > tried this. You may recall in an earlier iteration of my changes for a > prior merge request, I left some code commented out which I then removed > after you raised issue with it. This code was a call to > WaitForMultipleObjects, waiting on both the input handle and the Ctrl-C > event. The problem here which I believe I had stated at the time is > that with Wine, the input handle is always signaled, even if there is no > input waiting. The result was that the wait was always being satisfied > immediately and DIR /P was not pausing at all. So that approach was > abandoned in favor of what we have now. > #1: > This code here is based on the previous code for WCMD_Pause. That code > was setting console mode flags to 0. I'm guessing that PAUSE has > operated this way for many years. My changes use the new > WCMD_wait_for_input for both PAUSE and DIR /P, and I did not want to > break PAUSE behavior. Further, ENABLE_ECHO_INPUT is on by default, and > counter to Microsoft's docs for SetConsoleMode, on Wine the character is > echoed even if ENABLE_LINE_INPUT is disabled. The end result here is > that DIR /P was echoing the character that the user pressed, whereas > Windows does not exhibit that behavior. > All that said, based on shortcomings in Wine that I discuss above, I > believe that my changes here are currently the best approach. the attached patch (on top of what you sent earlier on) should work as expected: * the annoying parts: console handles don't support overlapped mode, and input console handles are signaled when there's a pending event... but a pending event could be mouse move, window resize, ctrl key down & up... maybe that's the reason you always check it as signaled * so the attached patch waits on both console input handle and control c event, but has to discriminate when the console input handle is signaled whether there's an actual character or some other things * it's still racy at some places, but given the API I don't see a clean way to do it * [wait-con.patch](/uploads/a537c394d4b98165b791a7979ad3f8ca/wait-con.patch) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7400#note_96140

1 0

[PATCH v3 0/6] MR7336: winewayland: Clipboard support through wlr-data-control-unstable-v1
by Alexandros Frantzis (＠afrantzis) 27 Feb '25

27 Feb '25

This MR adds clipboard support to the winewayland driver by using the wlr-data-control-unstable-v1 protocol. Note that this protocol was recently merged into wayland-protocols as ext-data-control-v1, but it's not yet widely supported, so I preferred to use the wlr version for now. This MR has many similarities to https://gitlab.winehq.org/wine/wine/-/merge_requests/7236, but due to the unconstrained nature of wlr-data-control-unstable-v1 the implementation is simpler and more robust. It can neatly fit into the existing Wine clipboard design (single proxy window in the desktop process) without requiring any event forwarding etc. Since wlr-data-control-unstable-v1/ext-data-control-v1 is considered privileged, it may not be available in all situations, e.g., in sandboxes, and there are also a couple of compositors that may not implement it at all. It is therefore useful to have a simple fallback using the core wl_data_device interface. This fallback is not part of this MR, but I have pushed a WIP implementation based on this MR at: https://gitlab.winehq.org/afrantzis/wine/-/commits/wayland-copy-paste-data-… (note: only the win32 -> wayland direction implemented at the moment). The new fallback approach is different from https://gitlab.winehq.org/wine/wine/-/merge_requests/7236 in that when using wl_data_device it creates per-process clipboard windows instead of forwarding messages from the desktop clipboard window. This allows it to work within the design of this MR with minimal changes and maximum code reuse. -- v3: winewayland: Normalize received MIME type strings. winewayland: Support copying data from native clipboard to win32 apps. winewayland: Support exporting various clipboard formats. winewayland: Generalize support for exporting clipboard formats. winewayland: Support copying text from win32 clipboard to native apps. winewayland: Implement zwlr_data_control_device_v1 initialization. https://gitlab.winehq.org/wine/wine/-/merge_requests/7336

3 10

[PATCH v2 0/1] MR7435: user32/tests: Fix monitor dpi awareness test.
by Bernhard Übelacker (＠bernhardu) 27 Feb '25

27 Feb '25

This adds brackets to make the comparison work and therefore the variable `scaled` gets set. Otherwise `scaled` and later `expect_width` and `expect_height` stays all zeros. https://test.winehq.org/data/patterns-tb-wine.html#user32:monitor This testbot run has this change applied: https://testbot.winehq.org/JobDetails.pl?Key=151521 -- v2: user32/tests: Fix monitor dpi awareness test. https://gitlab.winehq.org/wine/wine/-/merge_requests/7435

3 5

Re: [PATCH v18 0/1] MR7400: cmd: Allow any key to continue past DIR /P pauses.
by Joe Souza (＠JoeS209) 27 Feb '25

27 Feb '25

On Thu Feb 27 10:01:08 2025 +0000, eric pouech wrote: > 1) concerning the mode for waiting a key, > * ENABLE_PROCESS_INPUT is already set... default mode is 0x1f7 (so all > flags except ENABLE_WINDOW_INPUT and ENABLE_VIRTUAL_TERMINAL_PROCESSING) > * so IMO you just need to clear the ENABLE_LINE_INPUT flag to get key > press without wating for end of line > 2) for ctrl-c handling > * likely the ctrl-c is reported through the ctrl-c handler and it's not > clear to me if native does break the read operation in this case and > whether we should wait on both read operation & ctrl-c event I'll answer #2 first: Under Windows, Ctrl-C definitely does break out of a DIR /P pause. Regarding the second part, I completely agree that the proper way to handle this would be to wait on both input and the Ctrl-C event. I have tried this. You may recall in an earlier iteration of my changes for a prior merge request, I left some code commented out which I then removed after you raised issue with it. This code was a call to WaitForMultipleObjects, waiting on both the input handle and the Ctrl-C event. The problem here which I believe I had stated at the time is that with Wine, the input handle is always signaled, even if there is no input waiting. The result was that the wait was always being satisfied immediately and DIR /P was not pausing at all. So that approach was abandoned in favor of what we have now. #1: This code here is based on the previous code for WCMD_Pause. That code was setting console mode flags to 0. I'm guessing that PAUSE has operated this way for many years. My changes use the new WCMD_wait_for_input for both PAUSE and DIR /P, and I did not want to break PAUSE behavior. Further, ENABLE_ECHO_INPUT is on by default, and counter to Microsoft's docs for SetConsoleMode, on Wine the character is echoed even if ENABLE_LINE_INPUT is disabled. The end result here is that DIR /P was echoing the character that the user pressed, whereas Windows does not exhibit that behavior. All that said, based on shortcomings in Wine that I discuss above, I believe that my changes here are currently the best approach. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7400#note_96130

1 0

2025

2024

2023

2022

wine-gitlab