July 2023 - Wine-gitlab - list.winehq.org

[PATCH 0/3] MR3208: riched20: Wrap marked paragraphs at Text Services initialization. (follow-up to !2941)
by Jinoh Kang (＠iamahuman) 11 Jul '23

11 Jul '23

Today, CreateTextServices() returns an Rich Edit object without row start and end marks, which are expected to exist by many Rich Edit operations as well as EM_* message handlers. This leads to a crash when certain messages (e.g., EM_SCROLLCARET) are sent to the Rich Edit object via ITextServices::TxSendMessage(), unless ME_WrapMarkedParagraphs() has been called beforehand. Fix this by calling wrap_marked_paras_dc() early in the initialization process. This is not a problem for windowed Rich Edit controls, which already calls ME_WrapMarkedParagraphs() before the user or application starts interacting with it. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3208

3 4

[PATCH v11 0/2] MR3114: comctl32: Make sure the type is sLink to increase id.
by Zhao Yi (＠Zhaoyi) 11 Jul '23

11 Jul '23

Fix the issue of incorrect linkid calculation due to a lack of judgment on the current type. Signed-off-by: Zhaoyi <zhaoyi(a)uniontech.com> -- v11: comctl32/syslink: Check item type before increasing link ID in SYSLINK_LinkAtPt(). https://gitlab.winehq.org/wine/wine/-/merge_requests/3114

3 5

[PATCH v2 0/1] MR3280: widl: Stop possible null dereference (Coverity)
by Alistair Leslie-Hughes (＠alesliehughes) 11 Jul '23

11 Jul '23

-- v2: widl: Stop possible dereference (Coverity) https://gitlab.winehq.org/wine/wine/-/merge_requests/3280

2 1

[PATCH v2 0/3] MR271: Draft: Introduce a GitLab pipeline for vkd3d
by Giovanni Mascellani (＠giomasce) 11 Jul '23

11 Jul '23

With this pipeline vkd3d automatically gets built on Linux (in an image based on Debian unstable), both in 32 and 64 bit mode. Both builds are tested with radv and llvmpipe. A number of caveats apply, though: * A number of tests currently fail in llvmpipe, so the llvmpipe jobs are marked as allowed to fail. Ideally we'll eventually fix our bugs and mark the llvmpipe ones in the tests, so that the CI tests completely pass and possible problems in the Vulkan driver are recorded at a better granularity (this is the reason why GitLab says that the pipeline is passed with warnings: the warnings are that there are jobs that failed, even if they were allowed to fail). * The runners provided by the GitLab instance don't have a GPU available, so I configured my own computer (equipped with an AMD Radeon RX 5700 RX) to provide a runner with access to the GPU. This setup is not currently satisfying: for me, because I use that computer for other things and I don't like having random code submitted to it (it is theoretically sandboxed, but sandboxes are not always bullet-proof, especially if they have access to a GPU); for the users, because my computer might be unavailable at any time. I'll work on a better solution. For the time being I intend the runner to only accept jobs from the master branch; once a better solution is implemented I'd like to run the pipeline for MRs too. * While the `Dockerfile` and related assets do not necessarily need to be available in this repository, given that the CI accesses the binary image from the Docker hub anyway, I think it's still valuable to have them, so others can improve them (and for sure improvement opportunities are nowhere near missing). However, other ways to make them available can be found, if for some reason it is not liked to have them in this repository (they are not pretty!). * One of the reason they are not pretty is that I have a custom hack to compile `widl` from the Wine sources without compiling (or installing from the distribution) the whole of Wine, in the interest of keeping the Docker image small (well, small-ish: Vulkan drivers, compilers and X libraries are not small anyway). * Again on the subject of the Docker image, I am currently putting the binary image in my own namespace on the Docker hub. Using the GitLab container registry in the namespace of the Wine project would probably be better, so that I am not a bottleneck in the future. * Even if we discount all the points above, this MR cannot be merged yet, because my runner is currently configured for my namespace only. I guess I need the intervention of a GitLab admin to fix that. However, I think there's already material enough for valuable feedback. -- v2: ci: Introduce a CI pipeline for GitLab. configure: Require widl >= 3.21. vkd3d: Filter devices according to VKD3D_VULKAN_DEVICE_FILTER. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/271

3 5

[PATCH 0/1] MR3287: wow64: Add code-invalidation related BTCpuNotify* callbacks
by Billy Laws (＠bylaws) 11 Jul '23

11 Jul '23

Inter-process invalidation is left unimplemented, but this covers the majority of cases that a JIT needs to be aware of in order to flush any caches on code changes. Unsure if this is fine to merge without any user-code upstream, please do let me know if that's the case. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3287

3 3

[PATCH 0/1] MR3280: widl: Stop possible null dereference (Coverity)
by Alistair Leslie-Hughes (＠alesliehughes) 11 Jul '23

11 Jul '23

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

4 4

[PATCH 0/2] MR271: Draft: Introduce a GitLab pipeline for vkd3d
by Giovanni Mascellani (＠giomasce) 11 Jul '23

11 Jul '23

With this pipeline vkd3d automatically gets built on Linux (in an image based on Debian unstable), both in 32 and 64 bit mode. Both builds are tested with radv and llvmpipe. A number of caveats apply, though: * A number of tests currently fail in llvmpipe, so the llvmpipe jobs are marked as allowed to fail. Ideally we'll eventually fix our bugs and mark the llvmpipe ones in the tests, so that the CI tests completely pass and possible problems in the Vulkan driver are recorded at a better granularity (this is the reason why GitLab says that the pipeline is passed with warnings: the warnings are that there are jobs that failed, even if they were allowed to fail). * The runners provided by the GitLab instance don't have a GPU available, so I configured my own computer (equipped with an AMD Radeon RX 5700 RX) to provide a runner with access to the GPU. This setup is not currently satisfying: for me, because I use that computer for other things and I don't like having random code submitted to it (it is theoretically sandboxed, but sandboxes are not always bullet-proof, especially if they have access to a GPU); for the users, because my computer might be unavailable at any time. I'll work on a better solution. For the time being I intend the runner to only accept jobs from the master branch; once a better solution is implemented I'd like to run the pipeline for MRs too. * While the `Dockerfile` and related assets do not necessarily need to be available in this repository, given that the CI accesses the binary image from the Docker hub anyway, I think it's still valuable to have them, so others can improve them (and for sure improvement opportunities are nowhere near missing). However, other ways to make them available can be found, if for some reason it is not liked to have them in this repository (they are not pretty!). * One of the reason they are not pretty is that I have a custom hack to compile `widl` from the Wine sources without compiling (or installing from the distribution) the whole of Wine, in the interest of keeping the Docker image small (well, small-ish: Vulkan drivers, compilers and X libraries are not small anyway). * Again on the subject of the Docker image, I am currently putting the binary image in my own namespace on the Docker hub. Using the GitLab container registry in the namespace of the Wine project would probably be better, so that I am not a bottleneck in the future. * Even if we discount all the points above, this MR cannot be merged yet, because my runner is currently configured for my namespace only. I guess I need the intervention of a GitLab admin to fix that. However, I think there's already material enough for valuable feedback. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/271

4 6

[PATCH v2 0/4] MR263: vkd3d-shader/spirv: Refactor the type system.
by Conor McCarthy (＠cmccarthy) 11 Jul '23

11 Jul '23

Shader Model 6 introduces a 16-bit float (half) type, and 16-bit and 64-bit integer types. Storing extra info in the type enum simplifies checking if a type is any integer, floating point or numeric type, and the declaration of SPIR-V types. The benefits depend on using enum vkd3d_data_type in the backend instead of vkd3d_shader_component_type. Patch 2 is difficult to split because types typically flow through to vkd3d_spirv_get_type_id(), so partial changes would require new calls to conversion functions which would be deleted again later. -- v2: vkd3d-shader/spirv: Use a helper function to check if a data type is floating point. vkd3d-shader/spirv: Use vkd3d_spirv_get_op_constant() for 64-bit types. vkd3d-shader/spirv: Use enum vkd3d_data_type instead of vkd3d_shader_component_type. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/263

3 7

Re: [PATCH v2 0/4] MR3289: wine{alsa,coreaudio,oss,pulse}: Set zero_bits correctly for large address aware applications on Wow64. - approved
by Alexandre Julliard (＠julliard) 10 Jul '23

10 Jul '23

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

1 0

Re: [PATCH v9 0/1] MR3275: po: Add Georgian translation. - approved
by Alexandre Julliard (＠julliard) 10 Jul '23

10 Jul '23

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

1 0