- wine-gitlab - winehq.org

Re: [PATCH v2 0/1] MR3104: win32u: Add DriverVersion string for GPUs to registry
by Zhiyi Zhang (＠zhiyi) 21 Jun '23

21 Jun '23

I think it will be better if you can report different driver versions for different vendors. For example, NVIDIA, AMD, and Intel drivers should have different versions. You can use gpu->vendor_id to differentiate them. For other vendors, either report a 1.0.0 version or simply don't add this property. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3104#note_36398

1 0

[PATCH v4 0/6] MR2944: winewayland.drv: First window contents on screen
by Alexandros Frantzis (＠afrantzis) 21 Jun '23

21 Jun '23

The goal of this MR is to set up the minimum necessary infrastructure to display the contents of some simple, software rendered windows. This involves two major steps: 1. Associate a window with a Wayland surface and give it the `xdg_toplevel` role, so that the compositor can display it. We also have to implement the required initial `xdg_surface` configuration sequence to be able to safely (i.e., without the compositor disconnecting us with an error) attach buffers to the surface in step (2). 2. Implement the `window_surface` interface for the Wayland driver. For now we provide a simple (and suboptimal) `window_surface_flush` implementation: for each flush we create a new `wl_shm` buffer, copy the whole window contents (ignoring damaged bounds for now) into it and attach it to the target Wayland surface. In the next MR I will optimize this implementation in multiple ways: a. implement a buffer queue to avoid constantly allocating new buffers b. respect the damaged bounds of the `window_surface` to minimize copying of data from the `window_surface` to the SHM buffer (and also for correctness) c. communicate damaged surface regions to the compositor to (potentially) allow more efficient texture uploads. With this MR many (software-rendered) applications can now display dynamic content on screen. We can't interact with the apps yet, but we do get to enjoy `notepad` in all its blinking-cursor glory. Thanks! -- v4: winewayland.drv: Do not commit buffers to unconfigured surfaces. winewayland.drv: Implement a simple window_surface flush. winewayland.drv: Introduce window_surface for Wayland. winewayland.drv: Ensure Wayland surface handlers don't access invalid data. winewayland.drv: Basic Wayland toplevel surface support. https://gitlab.winehq.org/wine/wine/-/merge_requests/2944

4 17

[PATCH v6 0/2] MR3074: Move getpeername() implementation to wineserver
by Ally Sommers (＠dropbear) 21 Jun '23

21 Jun '23

`getpeername()` is currently handled in ntdll. This merge request changes ntdll to forward `getpeername()` to wineserver. The implementation utilises new `peer_addr` and `peer_addr_len` fields in wineserver's `struct sock`. This fixes multiple `todo_wine`s in `ws2_32/tests` and allows for more accurate peer names to be provided in case the address the socket is bound to on the Unix side does not match what `bind()` was called with on the Windows side. *This merge request was originally intended to be included in !2786 (Add support for AF_UNIX sockets) but was split into its own merge request because this is not an insignificant change.* -- v6: ws2_32/tests: Remove todo_wine from now-successful tests. server: Move getpeername() implementation from ntdll/unix. https://gitlab.winehq.org/wine/wine/-/merge_requests/3074

3 3

Re: [PATCH v5 0/2] MR3074: Move getpeername() implementation to wineserver
by Ally Sommers (＠dropbear) 20 Jun '23

20 Jun '23

Yes, once I add `SOCK_CONNECTING` to the allowed states for `getpeername()` to succeed. I then get the same output as on Windows 10. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3074#note_36391

1 0

[PATCH 0/1] MR3091: include: Avoid redefinitions of __fastcall on FreeBSD
by Gerald Pfeifer (＠gerald) 20 Jun '23

20 Jun '23

After commit b337c5b1a1757b2abbc90a7c6955d64242861ab9 builds on FreeBSD see 115 instances of include/windef.h:60: warning: "__fastcall" redefined which comes from <stdio.h> including <sys/cdefs.h> which in turns has #define __fastcall __attribute__((__fastcall__)) Simply #undef-ining __fastcall like we do for some other cases already addresses this. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3091

4 4

Re: [PATCH v2 0/1] MR3108: ws2_32: Don't export num_startup. - approved
by Alexandre Julliard (＠julliard) 20 Jun '23

20 Jun '23

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

1 0

Re: [PATCH v2 0/1] MR3110: crypt32: Don't export CRYPT_CopyReversed. - approved
by Alexandre Julliard (＠julliard) 20 Jun '23

20 Jun '23

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

1 0

Re: [PATCH v3 0/1] MR3097: sane: Fix use after free in create_item (scan-build). - approved
by Alexandre Julliard (＠julliard) 20 Jun '23

20 Jun '23

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

1 0

Re: [PATCH v2 0/4] MR3115: imm32: Fixes for comp string on character deletion and result commit. - approved
by Alexandre Julliard (＠julliard) 20 Jun '23

20 Jun '23

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

1 0

Re: [PATCH v2 0/5] MR3118: Implement dbghelp.SymSrvGetFileIndexesInfo(). - approved
by Alexandre Julliard (＠julliard) 20 Jun '23

20 Jun '23

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

1 0

2025

2024

2023

2022

wine-gitlab