On Thu Sep 5 17:07:13 2024 +0000, Nikolay Sivov wrote:
> It should be the other way around. ExW calls Nt function that accepts
> UNICODE_STRING or WCHARs, and ExA converts acp->wchar and calls ExW
> function. Assuming returned buffer contents are the same for both
> functions of course.
Done.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6423#note_81242
On Thu Sep 5 17:06:57 2024 +0000, Rémi Bernon wrote:
> NtQuerySystemInformation is probably the correct function to call, with
> one of SystemFirmware constants, maybe
> `SystemFirmwarePartitionInformation`, or another. You will need to test
> them to figure which one is the right one.
Done.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6423#note_81240
On Thu Aug 29 20:16:32 2024 +0000, Rémi Bernon wrote:
> The problem with testing this kind of thing is that reading pixels from
> the screen is not very reliable. Writing tests for that will be
> difficult and will require a very robust framework. Some people have
> tried, many have failed to convince julliard.
If this is dwm-independent, let's just put it into a new blank desktop.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6400#note_81229
Credits to [mkrysm1](mailto:mkrsym1@gmail.com) for the patch.
This patch fixes a video regression when mfplat is being used in conjunction with Unity in a certain piece of closed-source commercial software.
See [fourcc](https://fourcc.org/pixel-format/yuv-i420/) for more information.
Signed-off-by: Dylan Donnell <dylan.donnell(a)student.griffith.ie>
--
v4: winegstreamer: Support IYUV alias for I420
https://gitlab.winehq.org/wine/wine/-/merge_requests/6352
--
v4: winewayland: Use subsurfaces for unmanaged windows.
winewayland: Introduce a new update_wayland_surface_state_toplevel helper.
winewayland: Introduce a new wayland_surface_reconfigure_xdg helper.
winewayland: Introduce a new wayland_surface role enumeration.
winewayland: Call wayland_surface_clear_role in wayland_surface_destroy.
winewayland: Move surface title change to wayland_surface_make_toplevel.
winewayland: Attach client client surfaces to …
[View More]their toplevel surface.
winewayland: Use WindowPosChanged swp_flags to decide if a window is visible.
winewayland: Use the wayland_win_data client rect for child GL windows.
winewayland: Split wayland_win_data_update_wayland_surface helper.
winewayland: Call ensure_window_surface_contents with the toplevel window.
win32u: Update children window state when the parent state changes.
winewayland: Get rid of window_surface reference from wayland_win_data.
winewayland: Move client surface to wayland_win_data struct.
winewayland: Get rid of the window surface individual locks.
winewayland: Introduce a new wayland_client_surface_create helper.
winewayland: Get rid of wayland_surface reference from window_surface.
winewayland: Move window contents buffer to wayland_win_data struct.
winewayland: Reset the buffer damage region immediately after copy.
winewayland: Introduce a new get_window_surface_contents helper.
winewayland: Introduce a new set_window_surface_contents helper.
winewayland: Introduce a new ensure_window_surface_contents helper.
winewayland: Post WM_WAYLAND_CONFIGURE outside of the surface lock.
winewayland: Store all window rects in wayland_win_data.
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/6323
[View Less]
This introduces a new alternative FFmpeg-based implementation for the
MF byte stream handlers, while keeping the current GStreamer-based as
default.
The new implementation can be enabled by setting the DWORD value:
DisableGstByteStreamHandler = 1
in the HKCU\Software\Wine\MediaFoundation registry key.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6442
On Wed Sep 4 17:57:07 2024 +0000, Jacek Caban wrote:
> > being able to register wrappers from win32u makes things simpler
> because we then don't need a manual function in winevulkan to register
> the objects, and the winevulkan thunks can call directly into win32u functions.
> So you plan to manage some of rbtree handling in winevulkan while others
> in win32u? That doesn't sound like a clean separation if the only
> benefit is avoiding a few manual thunks in winevulkan. …
[View More]It seems cleaner
> to have all of that on one side (probably winevulkan, but win32u is also
> a possibility).
> win32u doesn't need client handles for anything else, unless I'm missing
> something. It means that if we'd keep that in winevulkan, the only thing
> from `vulkan_object` struct that's needed by win32u would be a handle
> and a parent. The handle requires an unpleasant union and the parent
> needs casting to be useful. That makes me question if `vulkan_object` is
> really all that useful... Having a dedicated per-type structs would
> avoid both of those. You needs it for both the device and instance, why
> not have two or so more?
Actually, depending on other design details, win32u may sometimes need client handle, but then the same concerns apply as against the host handle.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6427#note_81106
[View Less]
> being able to register wrappers from win32u makes things simpler because we then don't need a manual function in winevulkan to register the objects, and the winevulkan thunks can call directly into win32u functions.
So you plan to manage some of rbtree handling in winevulkan while others in win32u? That doesn't sound like a clean separation if the only benefit is avoiding a few manual thunks in winevulkan. It seems cleaner to have all of that on one side (probably winevulkan, but win32u …
[View More]is also a possibility).
win32u doesn't need client handles for anything else, unless I'm missing something. It means that if we'd keep that in winevulkan, the only thing from `vulkan_object` struct that's needed by win32u would be a handle and a parent. The handle requires an unpleasant union and the parent needs casting to be useful. That makes me question if `vulkan_object` is really all that useful... Having a dedicated per-type structs would avoid both of those. You needs it for both the device and instance, why not have two or so more?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6427#note_81105
[View Less]