- wine-gitlab - winehq.org

[PATCH v10 0/7] MR7111: Draft: support building Wine with LTO
by Konstantin Demin (＠rockdrilla) 23 Mar '25

23 Mar '25

work is still in progress. todo: - ensure that all affected sources (i.e. C sources with any kind of assembly) are listed in either way for all architectures - test Wine built with LTO relevant bug reports: - https://bugs.winehq.org/show_bug.cgi?id=41712 - https://bugs.winehq.org/show_bug.cgi?id=51051 -- v10: LTO quirks configure: enable building Wine with LTO makedep: support skipping/disabling LTO makedep: support LTO builds winegcc: support LTO builds winebuild: support LTO builds tools: helper functions for LTO builds https://gitlab.winehq.org/wine/wine/-/merge_requests/7111

2 7

[PATCH v2 0/1] MR7640: server: Fall back to epoll_wait if epoll_pwait2 doesn't work
by Alfred Agrell (＠Alcaro) 23 Mar '25

23 Mar '25

Fixes hangs if Wine is built with newer headers than kernel -- v2: server: Fall back to epoll_wait if epoll_pwait2 doesn't work. https://gitlab.winehq.org/wine/wine/-/merge_requests/7640

5 6

[PATCH v13 0/1] MR6199: winewayland.drv: Fix alt-tabbing out opening the alt key menu
by Yuri Hérouard (＠yurih) 23 Mar '25

23 Mar '25

Fix the wayland side of https://bugs.winehq.org/show_bug.cgi?id=55336 ### ~~Exit menu key by default:~~ That's the actual behavior, any non-special key will exit the menu key, and be sent to the client. I was also wondering if we should add `menu_sys_key = f10_key = 0;` when receiving a `WM_ACTIVATE` in `win32u/defwnd.c`'s `default_window_proc` but I guess not ? ### ~~Fix repeated key for no reason:~~ For some reason when ALT is pressed, it is spammed and thus spams SYS_COMMAND. This fix that, but I don't know what I am doing here. I don't see any repeating key spamming with winex11 but I could be wrong. However alt/SYS_COMMAND should not be repeated. That wasn't happening with winex11.drv. ### Fix release_all_keys modifier filtering: That was the main reason why alt-tab leads to the menu key, NtUserGetAsyncKeyboardState also uses left and right system keys. -- v13: winewayland: Fix release_all_keys's modifier filtering. https://gitlab.winehq.org/wine/wine/-/merge_requests/6199

2 1

Re: [PATCH v2 0/8] MR7644: powrprof.dll: Implement PowerGetActiveProfile and PowerSetActiveProfile
by Nikolay Sivov (＠nsivov) 22 Mar '25

22 Mar '25

On Sat Mar 22 22:56:23 2025 +0000, Robert Lippmann wrote: > Sorry, I'm new to this :disappointed: > What would happen if it was just a stub? > I also figured, while I was there, I might as well implement it... What would happen depends on an application that you run. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7644#note_98772

1 0

Re: [PATCH v2 0/8] MR7644: powrprof.dll: Implement PowerGetActiveProfile and PowerSetActiveProfile
by Robert Lippmann (＠rlippmann) 22 Mar '25

22 Mar '25

On Sat Mar 22 23:08:45 2025 +0000, Robert Lippmann wrote: > Oops. Well, they all actually just return errors. > Which is what I think the problem is. > Should I close this and just submit a patch that implements them? > I'd probably do it simpler with just a hack with a static variable anyway. Or should I keep the registry related code? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7644#note_98771

1 0

Re: [PATCH v2 0/8] MR7644: powrprof.dll: Implement PowerGetActiveProfile and PowerSetActiveProfile
by Robert Lippmann (＠rlippmann) 22 Mar '25

22 Mar '25

On Sat Mar 22 22:59:02 2025 +0000, Nikolay Sivov wrote: > All 4 functions you mentioned are already present in current code, in a > form of stubs. So you don't need to update the spec file. Oops. Well, they all actually just return errors. Which is what I think the problem is. Should I close this and just submit a patch that implements them? I'd probably do it simpler with just a hack with a static variable anyway. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7644#note_98770

1 0

Re: [PATCH v2 0/8] MR7644: powrprof.dll: Implement PowerGetActiveProfile and PowerSetActiveProfile
by Nikolay Sivov (＠nsivov) 22 Mar '25

22 Mar '25

On Sat Mar 22 22:54:23 2025 +0000, Robert Lippmann wrote: > As for ordinal numbers, I just copied and pasted what winedump gave me. > Should I change them all to @'s? All 4 functions you mentioned are already present in current code, in a form of stubs. So you don't need to update the spec file. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7644#note_98769

1 0

Re: [PATCH v2 0/8] MR7644: powrprof.dll: Implement PowerGetActiveProfile and PowerSetActiveProfile
by Robert Lippmann (＠rlippmann) 22 Mar '25

22 Mar '25

On Sat Mar 22 22:43:07 2025 +0000, Nikolay Sivov wrote: > Header is another thing, but source files do not have to match how > functions are arranged in the SDK. Sorry, just seemed like a good idea because the existing file is pretty big and full of functions returning not implemented. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7644#note_98768

1 0

Re: [PATCH v2 0/8] MR7644: powrprof.dll: Implement PowerGetActiveProfile and PowerSetActiveProfile
by Robert Lippmann (＠rlippmann) 22 Mar '25

22 Mar '25

On Sat Mar 22 22:43:29 2025 +0000, Nikolay Sivov wrote: > So what does it need exactly, and why stubs are not enough? Sorry, I'm new to this :disappointed: What would happen if it was just a stub? I also figured, while I was there, I might as well implement it... -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7644#note_98767

1 0

Re: [PATCH v2 0/8] MR7644: powrprof.dll: Implement PowerGetActiveProfile and PowerSetActiveProfile
by Robert Lippmann (＠rlippmann) 22 Mar '25

22 Mar '25

On Sat Mar 22 22:53:43 2025 +0000, Robert Lippmann wrote: > From what I can tell, it uses: > PowerSetActiveScheme > PowerGetActiveScheme > PowerReadFriendlyName > PowerEnumerate > I'm hoping just implementing the first 2 will get it to work. As for ordinal numbers, I just copied and pasted what winedump gave me. Should I change them all to @'s? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7644#note_98766

1 0

2025

2024

2023

2022

wine-gitlab