June 2024 - Wine-gitlab - list.winehq.org

[PATCH 0/3] MR5885: ntdll: Add few Avl related stub functions.
by Vijay Kiran Kamuju (＠infyquest) 19 Jun '24

19 Jun '24

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

2 3

[PATCH 0/2] MR5882: Fix WMA DMO media type regression
by Alfred Agrell (＠Alcaro) 19 Jun '24

19 Jun '24

microkiri and Wagamama High Spec recently broke, most likely due to @rbernon's d05cd460. Here's a fix. (I didn't file a bugzilla, should I?) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5882

5 5

[PATCH v7 0/6] MR5798: winemac: Push window surface updates to the main thread.
by Rémi Bernon 19 Jun '24

19 Jun '24

Instead of accessing the surface with macdrv_get_surface_display_image. -- v7: winemac: Remove unnecessary surface_clip_to_visible_rect. winemac: Remove now unnecessary cocoa window surface pointer. winemac: Push window surface image updates to the main thread. winemac: Create window surface CGImageRef on surface flush. winemac: Create a provider for the surface and a HBITMAP wrapping it. winemac: Remove unused macdrv_get_surface_display_image copy_data parameter. https://gitlab.winehq.org/wine/wine/-/merge_requests/5798

1 9

[PATCH v3 0/9] MR5876: winegstreamer: Implement more Media Foundation compressed format mappings.
by Elizabeth Figura (＠zfigura) 19 Jun '24

19 Jun '24

-- v3: winegstreamer: Implement MPEG-1 audio to IMFMediaType conversion. winegstreamer: Implement WMA to IMFMediaType conversion. winegstreamer: Implement WMV to IMFMediaType conversion. winegstreamer: Implement AAC to IMFMediaType conversion. winegstreamer: Implement H.264 to IMFMediaType conversion. winegstreamer: Implement H.264 to wg_format conversion. winegstreamer: Implement MPEG-4 audio to wg_format conversion. winegstreamer: Check the version before calling wg_format_from_caps_video_mpeg1(). mfplat/tests: Add more tests for compressed formats. https://gitlab.winehq.org/wine/wine/-/merge_requests/5876

3 11

[PATCH v6 0/7] MR5798: winemac: Push window surface updates to the main thread.
by Rémi Bernon 19 Jun '24

19 Jun '24

Instead of accessing the surface with macdrv_get_surface_display_image. -- v6: winemac: Clip the surface rectangles to the virtual screen rect. winemac: Remove unnecessary surface_clip_to_visible_rect. winemac: Remove now unnecessary cocoa window surface pointer. winemac: Push window surface image updates to the main thread. winemac: Create window surface CGImageRef on surface flush. winemac: Create a provider for the surface and a HBITMAP wrapping it. winemac: Remove unused macdrv_get_surface_display_image copy_data parameter. https://gitlab.winehq.org/wine/wine/-/merge_requests/5798

3 11

[PATCH v9 0/7] MR5744: winegstreamer: Fix various Cinepak issues
by Alfred Agrell (＠Alcaro) 19 Jun '24

19 Jun '24

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56698 -- v9: quartz/tests: Test that avi_decompressor_source_qc_Notify does not deadlock if called from a foreign thread during IMemInput_Receive. quartz: Allow concurrent calls to AVI decoder qc_Notify and Receive. msvfw32/tests: Test that Cinepak rejects unsupported output types. iccvid: Reject unsupported output types. quartz/tests: Add Cinepak test to avi splitter. winegstreamer: Make AVI splitter use end of previous frame if the current frame doesn't have a timestamp. winegstreamer: Implement AM_MEDIA_TYPE to wg_format converter for Cinepak video. https://gitlab.winehq.org/wine/wine/-/merge_requests/5744

4 10

[PATCH 0/1] MR5883: odbc32: Rebind parameters when the result length array is resized.
by Hans Leidekker (＠hans) 19 Jun '24

19 Jun '24

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

2 1

[PATCH v6 0/3] MR4826: Mach vm operations improvements
by Marc-Aurel Zent (＠mzent) 19 Jun '24

19 Jun '24

For all mach vm operations this removes the task suspend and resume, which are not needed. This uses `mach_vm_read_overwrite` to read into a caller-specified buffer, saving the `mach_vm_deallocate` call (bringing all read operations down to 1 syscall from 4). The only alignment restriction on `mach_vm_write` according to the original CMU documentation is that data is > [pointer to page aligned in array of bytes] An array of data to be written. (In practice it also works with arbitrary addresses on macOS, but it probably doesn't hurt to follow the original specifications here). The only other reference that these read/writes should be page-aligned is from the GNU Hurd documentation > The current implementation requires that address, data and data_count all be page-aligned. Otherwise, KERN_INVALID_ARGUMENT is returned. which I assume was the reason why this was originally done (plus it sounds to me like they will fix that in the future and 4fe19777 already broke GNU Hurd support anyways, if that was supposed to be working). Also this includes the missing mach part of 5b1f3b14, which was only applied to the ptrace backend, and together with the `write_process_memory` rework, this gets rid of all fixmes in mach.c -- v6: server: Simplify mach write_process_memory. https://gitlab.winehq.org/wine/wine/-/merge_requests/4826

2 4

Re: [PATCH v2 0/5] MR5879: winegstreamer: Implement stubs for h264 encoder.
by Elizabeth Figura (＠zfigura) 19 Jun '24

19 Jun '24

> Can we add an encoder element without changing all this code? It doesn't look like you need all the complicated converter sequence, maybe only a videoconvert (do you even need one?). Yeah, in general the idea that we'd want the same sequence for decoding and encoding is probably wrong. E.g. for decoding we may want deinterlace, but we certainly don't want that for encoding. It's probably better to handle them separately. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5879#note_73748

1 0

Re: [PATCH v8 0/11] MR5444: jscript: Do not allocate dispex_prop_t for indexed props.
by Gabriel Ivăncescu 19 Jun '24

19 Jun '24

On Tue Jun 18 21:28:01 2024 +0000, Jacek Caban wrote: > Current func info is more than (id,iid) carrier, it would only make > things more confusing to reuse it as an opaque with constrains like > that. We could introduce a new struct, if needed. Well yes but wouldn't it be an implementation detail on mshtml side? By new struct do you mean one in `func_info_t` and then passing its address out to jscript? (so a single pointer, rather than filling (id,iid) on jscript side) I'm asking because it's easier to just use a single pointer around in jscript (and even check it for NULL if, for instance, it's not a function but a custom prop). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5444#note_73737

1 0