- wine-gitlab - winehq.org

[PATCH 0/1] MR6494: services: Add support for ChangeServiceConfig2(SERVICE_CONFIG_DELAYED_AUTO_START_INFO).
by Dmitry Timoshkov (＠dmitry) 15 Sep '24

15 Sep '24

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

4 6

[PATCH 0/2] MR6495: tools: Improve get_bindir on Windows targets.
by Jacek Caban (＠jacek) 15 Sep '24

15 Sep '24

Currently, mingw-w64 has its own implementation of relocable widl support. With new Wine helpers, it may use Wine support instead and reduce the diff. This MR brings `get_bindir` in pair with mingw-w64's counterpart. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6495

2 2

Re: [PATCH v2 0/6] MR6491: mfsrcsnk: Initialize a stream map, sorted for specific mime types.
by Emil Velikov (＠xexaxo) 14 Sep '24

14 Sep '24

Emil Velikov (@xexaxo) commented about dlls/winedmo/winedmo.spec: > @ cdecl winedmo_demuxer_check(str) > @ cdecl winedmo_demuxer_create(wstr ptr ptr ptr ptr ptr ptr) > @ cdecl winedmo_demuxer_destroy(ptr) > +@ cdecl winedmo_demuxer_stream_type(int64 ptr ptr) Unless I'm missing something, the arguments don't seem to match the declaration/definition. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6491#note_82220

1 0

[PATCH v2 0/5] MR6490: winsock: Avoid short writes on nonblocking sockets.
by Paul Gofman (＠gofman) 13 Sep '24

13 Sep '24

-- v2: server: Correct STATUS_NOT_FOUND return from (cancel_async). ntdll: Don't cancel background socket sends. ntdll: Locally duplicated socket fd for background send. ntdll: Avoid short writes on nonblocking sockets. ws2_32/Tests: Add tests for send buffering. https://gitlab.winehq.org/wine/wine/-/merge_requests/6490

5 16

[PATCH v3 0/6] MR6446: ntdll: Support process instrumentation callback.
by Paul Gofman (＠gofman) 13 Sep '24

13 Sep '24

-- v3: ntdll: Support old parameter layout for NtSetInformationProcess( ProcessInstrumentationCallback ). ntdll: Call instrumentation callback for KiUserModeCallback on x64. ntdll: Call instrumentation callback for LdrInitializeThunk on x64. ntdll: Call instrumentation callback for KiUserExceptionDispatcher on x64. ntdll: Call instrumentation callback from wine_syscall_dispatcher on x64. ntdll/tests: Add more tests for process instrumentation callback. https://gitlab.winehq.org/wine/wine/-/merge_requests/6446

4 10

Re: [PATCH v7 0/5] MR6375: mshtml: Don't process tasks recursively. - approved
by Alexandre Julliard (＠julliard) 13 Sep '24

13 Sep '24

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

1 0

Re: [PATCH v2 0/1] MR6493: gdiplus: Fix assignment of result in GdipCloneBrush. - approved
by Alexandre Julliard (＠julliard) 13 Sep '24

13 Sep '24

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

1 0

Re: [PATCH v5 0/8] MR6467: winex11: Implement vulkan DPI scaling and child window rendering. - approved
by Alexandre Julliard (＠julliard) 13 Sep '24

13 Sep '24

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

1 0

Re: [PATCH v2 0/6] MR6491: mfsrcsnk: Initialize a stream map, sorted for specific mime types. - approved
by Alexandre Julliard (＠julliard) 13 Sep '24

13 Sep '24

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

1 0

Re: [PATCH v2 0/2] MR6492: d2d1: Implement drawing of ID2D1GeometryGroup
by Philipp Knechtges (＠d1saster) 13 Sep '24

13 Sep '24

I am bit puzzled, why the rebased commits start failing the tests. Seems unrelated to the d2d1 fixes. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6492#note_82178

1 0

Re: [PATCH v2 0/2] MR6492: d2d1: Implement drawing of ID2D1GeometryGroup
by Philipp Knechtges (＠d1saster) 13 Sep '24

13 Sep '24

On Fri Sep 13 18:40:16 2024 +0000, Nikolay Sivov wrote: > It looks to me that there won't be any way to retroactively apply fill > mode later, once you have copied all the vertices. But I'm not sure > what's the correct way would be here. In my opinion the correct way would probably be populating a joint CDT from all the geometries and then erasing triangles depending on the fill_mode. However, this is a bigger undertaking and for the [bug](https://bugs.winehq.org/show_bug.cgi?id=51139) at hand it suffices to just concatenate all lists, since it seems the application uses the geometry groups for assembling glyphs to words and render them all at once. Due to the latter, there is no intersection between the different geometric entities. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6492#note_82177

1 0

Re: [PATCH v2 0/2] MR6492: d2d1: Implement drawing of ID2D1GeometryGroup
by Nikolay Sivov (＠nsivov) 13 Sep '24

13 Sep '24

Nikolay Sivov (@nsivov) commented about dlls/d2d1/geometry.c: > HRESULT d2d_geometry_group_init(struct d2d_geometry *geometry, ID2D1Factory *factory, > D2D1_FILL_MODE fill_mode, ID2D1Geometry **geometries, unsigned int geometry_count) > { > - unsigned int i; > + unsigned int i, j; > + struct d2d_geometry *other_geom; > + D2D_MATRIX_3X2_F g, gplain; > + size_t f_vertex_count, f_face_count, f_bezier_vertex_count, f_arc_vertex_count; > + size_t o_vertex_count, o_face_count, o_bezier_count, o_bezier_face_count, o_arc_count, o_arc_face_count; > > + FIXME("Ignoring fill_mode=%#x!\n", fill_mode); It looks to me that there won't be any way to retroactively apply fill mode later, once you have copied all the vertices. But I'm not sure what's the correct way would be here. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6492#note_82167

1 0

Re: [PATCH v4 0/9] MR6480: mfsrcsnk: Implement I/O for the FFmpeg backend.
by Emil Velikov (＠xexaxo) 13 Sep '24

13 Sep '24

On Fri Sep 13 17:35:55 2024 +0000, Rémi Bernon wrote: > Not sure what to say other than it's pretty arbitrary. Larger than > common read sizes, to reduce the chances of having to call the callbacks > multiple times, but otherwise nothing very interesting about it. Maybe > it should even be a bit shorter to avoid wasting two 64k page instead of > one though. Right, guess it's something to test and optimise once all the code is in. Thanks -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6480#note_82153

1 0

Re: [PATCH v4 0/9] MR6480: mfsrcsnk: Implement I/O for the FFmpeg backend.
by Emil Velikov (＠xexaxo) 13 Sep '24

13 Sep '24

On Fri Sep 13 17:38:30 2024 +0000, Rémi Bernon wrote: > Actually looks like it's some leftover of an older version of the code, > it's not doing that anymore even in later changes. Woohoo, I helped :sweat_smile: -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6480#note_82152

1 0

Re: [PATCH v4 0/9] MR6480: mfsrcsnk: Implement I/O for the FFmpeg backend.
by Emil Velikov (＠xexaxo) 13 Sep '24

13 Sep '24

On Fri Sep 13 17:35:55 2024 +0000, Rémi Bernon wrote: > The stream context needs to be allocated on the PE side while the > demuxer is a unix-side pointer. We could create a PE side object > wrapping both, but that didn't feel very useful. I was thinking about allocating each on their respective side adding the ctx alongside the handle in `wine/winedmo.h`. Might work, but it doesn't seem too pretty. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6480#note_82151

1 0

Re: [PATCH v4 0/9] MR6480: mfsrcsnk: Implement I/O for the FFmpeg backend.
by Rémi Bernon (＠rbernon) 13 Sep '24

13 Sep '24

On Fri Sep 13 17:35:55 2024 +0000, Rémi Bernon wrote: > That was to return the actual detected media size from the demuxer, in > case it can figure it out better than the caller (which may also be > unable to provide it). Actually looks like it's some leftover of an older version of the code, it's not doing that anymore even in later changes. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6480#note_82148

1 0

Re: [PATCH v4 0/9] MR6480: mfsrcsnk: Implement I/O for the FFmpeg backend.
by Rémi Bernon (＠rbernon) 13 Sep '24

13 Sep '24

On Fri Sep 13 16:51:13 2024 +0000, Emil Velikov wrote: > Out of curiosity: why do we pass stream_size as pointer to an int, > instead of an int directly? > Sorry for the belated questions :bow: That was to return the actual detected media size from the demuxer, in case it can figure it out better than the caller (which may also be unable to provide it). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6480#note_82147

1 0

Re: [PATCH v4 0/9] MR6480: mfsrcsnk: Implement I/O for the FFmpeg backend.
by Rémi Bernon (＠rbernon) 13 Sep '24

13 Sep '24

On Fri Sep 13 16:43:58 2024 +0000, Emil Velikov wrote: > Any chance we get an inline comment saying how `0x10000` was chosen? Not sure what to say other than it's pretty arbitrary. Larger than common read sizes, to reduce the chances of having to call the callbacks multiple times, but otherwise nothing very interesting about it. Maybe it should even be a bit shorter to avoid wasting two 64k page instead of one though. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6480#note_82146

1 0

Re: [PATCH v4 0/9] MR6480: mfsrcsnk: Implement I/O for the FFmpeg backend.
by Rémi Bernon (＠rbernon) 13 Sep '24

13 Sep '24

On Fri Sep 13 16:42:03 2024 +0000, Emil Velikov wrote: > Out of curiosity: is the `stream_context` expected to have different > life-time than `winedmo_demuxer`? > Alternatively it seems cleaner to me to have the `stream_context` > pointer within the `winedmo_demuxer` itself removing the rather uncommon > read-back pointer from the destructor. The stream context needs to be allocated on the PE side while the demuxer is a unix-side pointer. We could create a PE side object wrapping both, but that didn't feel very useful. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6480#note_82145

1 0

[PATCH v6 0/5] MR6375: mshtml: Don't process tasks recursively.
by Gabriel Ivăncescu (＠insn) 13 Sep '24

13 Sep '24

I kept the first patch (`Remember if timer was blocked.`) to avoid SetTimer on timers that weren't killed, mostly because it would apply on every task (which is likely to execute way faster than the ms granularity), not sure if it would skew the timer in such case. The other patches are split, with tests now showing why they're needed. Some places where wine-gecko callbacks into us and in which we call into external code need to be treated the same as a recursive task since it can end up in a message loop. I haven't supplied all of them from the previous MR, mostly because I didn't find a way to test those (e.g. show context menu, and the gecko async navigation). -- v6: mshtml: Don't process tasks recursively from Gecko events. mshtml: Don't process tasks recursively from script runners. mshtml: Don't process tasks recursively. mshtml: Remember if timer was blocked. mshtml: Don't cast to int to bound the timer. https://gitlab.winehq.org/wine/wine/-/merge_requests/6375

3 6

[PATCH 0/6] MR6491: mfsrcsnk: Initialize a stream map, sorted for specific mime types.
by Rémi Bernon (＠rbernon) 13 Sep '24

13 Sep '24

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

4 10

Re: [PATCH v4 0/9] MR6480: mfsrcsnk: Implement I/O for the FFmpeg backend.
by Emil Velikov (＠xexaxo) 13 Sep '24

13 Sep '24

Emil Velikov (@xexaxo) commented about dlls/winedmo/main.c: > WINE_DEFAULT_DEBUG_CHANNEL(dmo); > > > -static struct stream_context *stream_context_create(void) > +static struct stream_context *stream_context_create( struct winedmo_stream *stream, UINT64 *stream_size ) > { > struct stream_context *context; > > if (!(context = malloc( 0x10000 ))) return NULL; > - context->length = 0; > + context->stream = (UINT_PTR)stream; > + context->length = *stream_size; Out of curiosity: why do we pass stream_size as pointer to an int, instead of an int directly? Sorry for the belated questions :bow: -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6480#note_82140

1 0

Re: [PATCH v4 0/9] MR6480: mfsrcsnk: Implement I/O for the FFmpeg backend.
by Emil Velikov (＠xexaxo) 13 Sep '24

13 Sep '24

Emil Velikov (@xexaxo) commented about dlls/winedmo/main.c: > { > struct stream_context *context; > > - if (!(context = malloc( sizeof(*context) ))) return NULL; > + if (!(context = malloc( 0x10000 ))) return NULL; Any chance we get an inline comment saying how `0x10000` was chosen? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6480#note_82137

1 0

Re: [PATCH v4 0/9] MR6480: mfsrcsnk: Implement I/O for the FFmpeg backend.
by Emil Velikov (＠xexaxo) 13 Sep '24

13 Sep '24

Emil Velikov (@xexaxo) commented about dlls/winedmo/unixlib.h: > > struct demuxer_create_params > { > + struct stream_context *context; > struct winedmo_demuxer demuxer; Out of curiosity: is the `stream_context` expected to have different life-time than `winedmo_demuxer`? Alternatively it seems cleaner to me to have the `stream_context` pointer within the `winedmo_demuxer` itself removing the rather uncommon read-back pointer from the destructor. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6480#note_82136

1 0

[PATCH 0/1] MR6493: gdiplus: Fix assignment of result in GdipCloneBrush.
by Esme Povirk (＠madewokherd) 13 Sep '24

13 Sep '24

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

2 1

2025

2024

2023

2022

wine-gitlab