May 2025 - Wine-GitLab - list.winehq.org

[PATCH v6 0/3] MR8078: windows.ui: Fix a double free.
by Zhiyi Zhang (＠zhiyi) May 23, 2025

May 23, 2025

The object reference is actually held by ref_weak. -- v6: geolocation: Use helpers to implement IWeakReference. windows.ui: Use helpers to implement IWeakReference. https://gitlab.winehq.org/wine/wine/-/merge_requests/8078

3 6

[PATCH v3 0/1] MR8111: win32u: Implement NtGdiDdDDIOpenAdapterFromDeviceName().
by Paul Gofman (＠gofman) May 23, 2025

May 23, 2025

-- v3: win32u: Implement NtGdiDdDDIOpenAdapterFromDeviceName(). https://gitlab.winehq.org/wine/wine/-/merge_requests/8111

3 3

[PATCH 0/1] MR8127: include: Add DBBOOKMARK enum.
by Piotr Caban (＠piotr) May 23, 2025

May 23, 2025

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

2 1

[PATCH v3 0/4] MR8034: winegstreamer: Call wg_format_get_max_size() to get the video decoder output sample size.
by Conor McCarthy (＠cmccarthy) May 23, 2025

May 23, 2025

Windows uses a smaller alignment than gstreamer for some formats, for example NV12. This means we cannot use MFCalculateImageSize() to get the output sample size. Commit 7b79e3a87b1e switched to calling it instead of GetOutputStreamInfo() to fix some game bugs. -- v3: winegstreamer: Call wg_format_get_max_size() to get the video decoder output sample size. winegstreamer: Do not pass a sample size to wg_transform_read_mf(). mf/tests: Add a video processor NV12 test with a width alignment of 2. mfplat/tests: Add NV12 650 x 850 to image_size_tests. https://gitlab.winehq.org/wine/wine/-/merge_requests/8034

2 4

[PATCH v3 0/7] MR8115: win32u: Open EGL display and configs on behalf of the drivers.
by Rémi Bernon May 23, 2025

May 23, 2025

-- v3: winewayland: Use win32u for EGL display and pixel formats. wineandroid: Use win32u for EGL display and pixel formats. win32u: Implement OpenGL pixel formats over EGL configs. win32u: Introduce an EGL opengl_driver_function table. winewayland: Use the EGL display opened from win32u. wineandroid: Use the EGL display opened from win32u. win32u: Open and initialize an EGL platform display. https://gitlab.winehq.org/wine/wine/-/merge_requests/8115

1 8

Re: [PATCH v2 0/5] MR8123: winex11: Track _MOTIF_WM_HINTS property in the window state.
by Rémi Bernon May 23, 2025

May 23, 2025

On Fri May 23 00:45:26 2025 +0000, Zhiyi Zhang wrote: > The reason why something like this didn't exist before is that after the > monitor changes, the old Xinerama monitor index might be different than > the new ones. For example, changing the secondary monitor from right to > left and then making the secondary monitor primary using the host > system's utilities. We can probably invalidate the old monitor Xinerama > indices after a device change. Oh I see. The reason for this is to reduce the number of requests sent as much as possible, in case they would somehow trigger things like window reconfigure from the window manager side. I'll look into invalidating the data on device change. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8123#note_104297

1 0

Re: [PATCH v25 0/6] MR7650: Add support for AF_UNIX sockets (followup)
by Ralf Habacker (＠rhabacker) May 23, 2025

May 23, 2025

The changes for adapting the current directory are currently relevant for socket names with relative or unspecified paths, which can cause problems anyway, see https://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/391#note_2914230. In order to make progress with the current implementation, the use of relative paths is excluded for the time being. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7650#note_104294

1 0

Re: [PATCH v25 0/6] MR7650: Add support for AF_UNIX sockets (followup)
by Ralf Habacker (＠rhabacker) May 23, 2025

May 23, 2025

Ralf Habacker (@rhabacker) commented about dlls/ws2_32/socket.c: > return -1; > } > params->unknown = 0; > - memcpy( &params->addr, addr, len ); > + if (addr->sa_family == AF_UNIX) > + memset( &params->addr, 0, len ); > + memcpy( &params->addr, addr, bind_len ); > + if (unix_path) Here a comment should be added, that in case of AF_UNIX sockets the unix path is appended as second string to `params->addr`. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7650#note_104293

1 0

Re: [PATCH v2 0/1] MR7747: ntdll: Guess optical disc type based on data size.
by Alex Henrie (＠alexhenrie) May 23, 2025

May 23, 2025

On Fri May 23 04:23:45 2025 +0000, Alexandre Julliard wrote: > > There is probably some tiny DVD somewhere in the world that will still > be misdetected, but I'm not sure that issuing SCSI commands to the drive > to try to determine the disc type would be any more reliable. > To support an app that is most likely going to issue DVD ioctls, > checking by using a DVD ioctl seems preferable. Linux has only three [DVD ioctls](https://docs.kernel.org/userspace-api/ioctl/cdrom.html): DVD_READ_STRUCT, DVD_WRITE_STRUCT, and DVD_AUTH. It has no blu-ray ioctls. Of the three DVD ioctls, only DVD_READ_STRUCT would be suitable for disc type detection. DVD_READ_STRUCT can read five kinds of information: DVD_STRUCT_PHYSICAL, DVD_STRUCT_COPYRIGHT, DVD_STRUCT_DISCKEY, DVD_STRUCT_BCA, and DVD_STRUCT_MANUFACT. Of those five, only DVD_STRUCT_PHYSICAL would be suitable for disc type detection. At least on my LG WH16NS40 drive, DVD_STRUCT_PHYSICAL succeeds when there is a DVD in the drive, but it fails when there is a CD or a blu-ray in the drive. That means that we could use DVD_STRUCT_PHYSICAL to accurately detect whether there is a DVD in the drive, but we would still need another way to detect blu-rays. Is there another ioctl that you had in mind, or something else that I missed? Do you want to try DVD_STRUCT_PHYSICAL first and fall back to guessing based on the data size if it fails? Please let me know how to proceed. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7747#note_104292

1 0

Re: [PATCH v2 0/5] MR8123: winex11: Track _MOTIF_WM_HINTS property in the window state.
by Zhiyi Zhang (＠zhiyi) May 23, 2025

May 23, 2025

Zhiyi Zhang (@zhiyi) commented about dlls/winex11.drv/window.c: > return; > > xinerama_get_fullscreen_monitors( &data->rects.visible, monitors ); > + memcpy( data->desired_state.monitors, monitors, sizeof(monitors) ); > + if (!memcmp( old_monitors, monitors, sizeof(monitors) )) return; /* states are the same, nothing to update */ The reason why something like this didn't exist before is that after the monitor changes, the old Xinerama monitor index might be different than the new ones. For example, changing the secondary monitor from right to left and then making the secondary monitor primary using the host system's utilities. We can probably invalidate the old monitor Xinerama indices after a device change. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8123#note_104289

1 0