- wine-gitlab - winehq.org

[PATCH v8 0/6] MR2275: winewayland.drv: part 1: Introduce the Wayland driver
by Alexandros Frantzis (＠afrantzis) 13 Mar '23

13 Mar '23

Introduction ------------ This is the first of (many) parts in the upstreaming of the Wayland driver for Wine. Since the amount of code and commits is large, my approach is to upstream the driver in multiple parts in a serial fashion, with each part being a cohesive (to the degree possible) set of not too many commits. When each part is reviewed and merged, I will move on to proposing the next part. My main goal with this approach is to make reviewing easier and more focused. If you have other ideas about how to improve this process for the reviewers, please let me know. A lot of pieces need to fall into place before the driver becomes even remotely functional, so, some MRs (especially the initial ones) will be a bit more preparatory in nature. To aid in the understanding of and justification for some of the code introduced in such MRs, all the remaining driver commits are always going to be available at https://gitlab.winehq.org/afrantzis/wine/-/tree/wayland. Part 1 ------- ~~This MR introduces the Wayland driver PE and unixlib components with some basic code, and prepares the makedep tool to be able to handle Wayland protocol files.~~ This MR introduces the Wayland driver PE and unixlib components with some basic code, and reports some basic monitor information to Wine. Please see the individual commit message for more details. Some questions I would appreciate some feedback on in the context of this MR: 1. Should the Wayland driver build be enabled by default at this point? (currently it's explicitly opt-in with --with-wayland) 2. How should the Wayland driver build be integrated with CI? (currently piggybacking on gitlab/build-linux by adding --with-wayland) Note that building the Wayland driver should not affect running/testing on X11/Xwayland etc, since it's placed lower in the driver priority list. ~~Part 2 preview: We will handle basic Wayland wl_output (i.e., display) events and populate the Wine monitor information.~~ Part 2 preview: We will report more monitor information and implement GetCurrentDisplaySettings. -- v8: winewayland.drv: Report all advertised monitor modes to Wine. winewayland.drv: Report basic monitor information. https://gitlab.winehq.org/wine/wine/-/merge_requests/2275

3 7

[PATCH 0/1] MR2384: vbscript/tests: Fix the testChrError() tests in the mixed locale case.
by Francois Gouget (＠fgouget) 13 Mar '23

13 Mar '23

VBscript actually uses the default code page of the user default locale which may not be the same as CP_THREAD_ACP. Also for locales that don't have an ANSI code page, such as Hindi, it falls back to UTF-8. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54003 --- Not sure how I missed the mixed locales case before. This time I made sure to run it in all of the TestBot's supported locales and it looks all good: https://testbot.winehq.org/JobDetails.pl?Key=130549 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2384

3 2

[PATCH 0/5] MR2388: imm32: Cleanup in preparation for ImmLoadIME / ImmFreeLayout implementation.
by Rémi Bernon (＠rbernon) 13 Mar '23

13 Mar '23

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

2 5

[PATCH 0/1] MR2381: wldap32: Add ldap_set_dbg_flags stub.
by Alex Henrie (＠alexhenrie) 13 Mar '23

13 Mar '23

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

3 2

[PATCH v2 0/4] MR2387: Draft: winegstreamer: Use codec format in stream_props_GetMediaType.
by Ziqing Hui (＠zhui) 13 Mar '23

13 Mar '23

According to the tests in 23b72ad, when we are reading a compressed stream, the type returned by `stream_props_GetMediaType()` should reflect compressed format even if we finnally output uncomressed data. For example, if we use wmvcore reader to read a WMV3 stream and output RGB24, the format information returned by `stream_props_GetMediaType()` should be WMV3, not RGB24. This patch set is marked as draft now, because PATCH 2 and PATCH 3 is affected by 3e8936a2 in MR !2258. So I'll submit a newer version of this after !2258 get merged. -- v2: winegstreamer: Use codec format in stream_props_GetMediaType. winegstreamer: Implement amt_from_wg_format_video_wmv. winegstreamer: Implement wg_format_from_caps_video_wmv. winegstreamer: Implement wg_parser_stream_get_codec_format. https://gitlab.winehq.org/wine/wine/-/merge_requests/2387

2 4

[PATCH 0/4] MR2387: Draft: winegstreamer: Use codec format in stream_props_GetMediaType.
by Ziqing Hui (＠zhui) 13 Mar '23

13 Mar '23

According to the tests in 23b72ad, when we are reading a compressed stream, the type returned by `stream_props_GetMediaType()` should reflect compressed format even if we finnally output uncomressed data. For example, if we use wmvcore reader to read a WMV3 stream and output RGB24, the format information returned by `stream_props_GetMediaType()` should be WMV3, not RGB24. This patch set is marked as draft now, because PATCH 2 and PATCH 3 is affected by 3e8936a2 in MR !2258. So I'll submit a newer version of this after !2258 get merged. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2387

2 4

[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 0/16] MR2386: windows.perception.stub: Implement IHolographicSpaceStatics2/3 interfaces.
by Mohamad Al-Jaf (＠maljaf) 13 Mar '23

13 Mar '23

Needed by the VR game Desperate: Vladivostok. `IHolographicSpaceStatics2::get_IsSupported()` only returns `FALSE` on 32-bit Windows 10, but the VMs are 64-bit. -- This merge request has too many patches to be relayed via email. Please visit the URL below to see the contents of the merge request. https://gitlab.winehq.org/wine/wine/-/merge_requests/2386

1 0

[PATCH 0/1] MR2385: openssh installer by chocolatey fails to install because of missing regkey.
by Louis Lenders (＠xe) 12 Mar '23

12 Mar '23

See https://community.chocolatey.org/packages/openssh#files (tools\chocolateyinstall.ps1) $EditionId = (Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' -Name 'EditionID').EditionId -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2385

3 3

[PATCH v3 0/2] MR2240: Winedbg to load 64bit modules for a wow64 debuggee in multi-arch config.
by eric pouech (＠epo) 12 Mar '23

12 Mar '23

This series intent is to let winedbg (and dbghelp) load the 64bit PE modules of a wow64 debuggee. At this stage, all debug info of all modules (PE and ELF) are properly loaded (and displayed with 'info wow share' command). Breakpoint and backtrace in 64bit code of a wow64 debuggee are not available. The serie contains: - extension of tests to show that 64bit load dll events are generated for a wow64 debuggee (for a 64bit debugger, not for a 32bit one) - change for adapting filtering of events I opted for doing it in ntdll and passing the machine of the mapping in request's reply. Please advisde if you'd prefer another approach. -- v3: server,ntdll,wow64: Move filter of (un)load DLL debug events to client side. kernel32/tests: Extend the tests for load/unload debug events on Wow64. https://gitlab.winehq.org/wine/wine/-/merge_requests/2240

2 3

2025

2024

2023

2022

wine-gitlab