January 2023 - wine-gitlab

[PATCH 0/1] MR1945: Draft: winegstreamer: Return correct format in stream_props_GetMediaType.
by Ziqing Hui (＠zhui) 13 Mar '23

13 Mar '23

This patch doesn't work now. Zebediah, I think I need your help. My goal is to get the original stream format in `stream_props_GetMediaType()`. For example, if I use wmreader to open a WMV3 stream, then this function should return WMV3 format as its result. I expect preferred_format to hold the format I need. But test shows that preferred_format is always RGB24 even if I open a WMV stream. I found that preferred_format is written in `wg_parser.c: sink_event_cb(): case GST_EVENT_CAPS`. So it means that the caps here is "video/x-raw", not "video/x-wmv" as I expected. So how could I get the stream format I want when I open a compressed stream using wmreader? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1945

3 9

[PATCH v3 0/2] MR626: Zooming fixes
by David Kahurani (＠kahurani) 10 Mar '23

10 Mar '23

Manipulating the font size results in the script_cache going stale. From MSDN[1] `The application should never pass the same handle for different fonts or different sizes.` This is however exactly what happens when the font size changes as a result of zooming(both in and out). ScriptShape and relative functions will only inspect the hardware device context only if the required data is not cached[2] and hence the data from a previous call to these functions is retrieved even though the font size has changed hence the bug where text both doesn't wrap and doesn't paint as it should. In patch one, I have tried to keep track of the script_cache objects alongside the relevant font. Patch two fixes an issue where the cursor doesn't scale after zooming until after one interacts with the editor. Signed-off-by: David Kahurani <k.kahurani(a)gmail.com> 1. https://docs.microsoft.com/en-us/windows/win32/intl/caching 2. https://docs.microsoft.com/en-us/windows/win32/intl/script-cache -- v3: riched20: update caret on zooming riched20: Cache script_cache alongside font cache https://gitlab.winehq.org/wine/wine/-/merge_requests/626

3 4

[PATCH v2 0/3] MR1897: kernel32/tests: Call newer functions not on Windows XP or 2003 via function addresses (locale)
by Hugh McMaster (＠hmc) 09 Mar '23

09 Mar '23

There are times when it is useful to test changes on the Windows XP and 2003 VMs, but the direct use of functions not on those platforms makes this impossible. -- v2: kernel32/tests: Call CompareStringEx via function address (locale.c) kernel32/tests: Call LCIDToLocaleName via function address (locale.c) kernel32/tests: Call LCMapStringEx via function address (locale.c) https://gitlab.winehq.org/wine/wine/-/merge_requests/1897

2 4

[PATCH 0/1] MR988: dmloader/tests: Mark tests failing randomly on Windows as flaky.
by Francois Gouget (＠fgouget) 02 Mar '23

02 Mar '23

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

3 6

[PATCH 0/1] MR1138: gitlab: Add winetest checksums to the build artifacts.
by Francois Gouget (＠fgouget) 02 Mar '23

02 Mar '23

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

3 5

[PATCH 0/5] MR1543: mmdevapi: Handle process_attach, process_detach and test_connect UNIX driver functions
by Davide Beatrici (＠davidebeatrici) 28 Feb '23

28 Feb '23

The goal is to eventually move all interfaces from each driver's `mmdevdrv.c` into `mmdevapi`. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1543

5 12

[PATCH 0/1] MR1580: winex11.drv: Hide invisible owner windows that have visible owned windows in pager.
by Zhiyi Zhang (＠zhiyi) 28 Feb '23

28 Feb '23

Manual tests on XP, Win7 and Win10 show that such windows are not shown in pager. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1580

3 3

[PATCH 0/5] MR2038: server: Track cursor handle and window changes.
by Rémi Bernon (＠rbernon) 24 Feb '23

24 Feb '23

The idea here is to track the cursor changes on the server side, ultimately [1] using a private message to notify user drivers of changes to apply, instead of tracking the changes in user drivers with throttle mechanisms. This would greatly simplify winex11 mouse message handling as we would not need to try syncing the window cursor on every mouse move, and ultimately it would also make it possible to have a single thread listening to input in the background. Currently the input thread needs to own the windows that are under the cursor to be able to set it. Having a single input thread (per-process at least, but ideally and ultimately per-prefix), will solve several issues with input not being received when the foreground thread isn't actively checking their message, as well as issues with DInput incorrectly checking window messages when it should not. [1] See https://gitlab.winehq.org/rbernon/wine/-/merge_requests/8/commits -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2038

3 9

[PATCH 0/1] MR1240: gitlab: Run related tests on every commit.
by Rémi Bernon (＠rbernon) 24 Feb '23

24 Feb '23

This restores the feature we had with the testbot running related on intermediate commits, though it only does it on Linux and it would be nice to have it on Windows too. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1240

2 2

[PATCH 0/5] MR2062: winex11: Expose supported and configured keyboard layout in winecfg.
by Rémi Bernon (＠rbernon) 24 Feb '23

24 Feb '23

This adds a new Input tab to winecfg, moving the mouse grab settings there. Then this makes winex11 keyboard layout detection configurable as well, allowing the user to override the keyboard layout detection if for some reason it was incorrect. This isn't solving anything yet, but I then intend to make keyboard scancode detection configurable as well, and optional. As I described in https://www.winehq.org/pipermail/wine-devel/2020-October/175641.html, I believe that X11 keyboard keycode to scancode mapping is most of the time a fixed mapping, except in some rare cases. Trying to detect it from the keyboard layout will never work reliably, especially nowadays where keyboard layouts are completely made up from Linux IME (for instance a GNOME language settings with up to four keyboard layouts translates to a single Xkb mapping using groups for each layout). The X11 keycode are remapped only in some more rarely used implementations, such as XVNC and we should try to detect it only in such cases. Many Windows applications are depending on accurate scancodes, and making the mapping detection optional (and disabled by default) will solve all the issues we have in the most common case (https://bugs.winehq.org/show_bug.cgi?id=30984, https://bugs.winehq.org/show_bug.cgi?id=45605). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2062

2 7

2025

2024

2023

2022

wine-gitlab January 2023