- wine-gitlab - winehq.org

[PATCH v5 0/1] MR7806: winewayland: Implement relative motion accumulator
by Etaash Mathamsetty (＠etaash.mathamsetty) 17 Apr '25

17 Apr '25

Gets rid of the dead mouse issue when you move the mouse slowly -- v5: winewayland: Implement relative motion accumulator https://gitlab.winehq.org/wine/wine/-/merge_requests/7806

3 6

[PATCH v7 0/2] MR7032: Add embeddedbrowserwebview aka. WebView2 DLL stub.
by Bernhard Kölbl (＠besentv) 17 Apr '25

17 Apr '25

(For after the code freeze.) I think we want to have this DLL living in Wine for easier development, and probably dynamically load our custom Chromium fork from here. (just like MSHTML and wine-Gecko) The code for that fork could then be created in its own repo. -- v7: embeddedbrowserwebview: Create CreateWebViewEnvironmentWithOptionsInternal stub. embeddedbrowserwebview: Add stub dll. https://gitlab.winehq.org/wine/wine/-/merge_requests/7032

6 7

[PATCH 0/6] MR7844: PDB rewrite #9.
by eric pouech (＠epo) 17 Apr '25

17 Apr '25

This serie implements the migration of some type into the new PDB reader. During the migration phase (this serie and next one), the types (A) will: - always be loaded by old PDB reader, - be migrated accoring to the type's tag (UDT, pointer, enum...), one commit for each tag by: + storing in new PDB reader an offset to that type inside the PDB file, + requesting type details directly from the file. (A) typedef:s are handled differently than the other types, so they'll be taken care of later on. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7844

2 6

Re: [PATCH v4 0/1] MR7806: winewayland: Implement relative motion accumulator
by Alexandros Frantzis (＠afrantzis) 17 Apr '25

17 Apr '25

Alexandros Frantzis (@afrantzis) commented about dlls/winewayland.drv/wayland_pointer.c: > > if (!(hwnd = wayland_pointer_get_focused_hwnd())) return; > if (!(data = wayland_win_data_get(hwnd))) return; > + if (!private) return; > > - wayland_surface_coords_to_window(data->wayland_surface, > + wayland_motion_delta_to_window(data->wayland_surface, > wl_fixed_to_double(dx), > wl_fixed_to_double(dy), > - (int *)&screen.x, (int *)&screen.y); > - > + &screen.x, &screen.y); > wayland_win_data_release(data); > > + d_accum->x += screen.x; > + d_accum->y += screen.y; The accum x and y are accessed in two contexts: in `wayland_pointer_update_constraint` for the zeroing, and also updated here in relative motion handler. These may be running concurrently in different threads, and since access to doubles may not be atomic we ideally need to protect the variables. Especially with the suggestion below to place them in wayland_pointer instead, it's straightforward to guard these in the relative motion handler with the wayland_pointer mutex. Note that even with the lock, there are some Wayland event races left that are harder to resolve (e.g., Thread1: relative motion handler starts running, Thread2: zero accum and destroy relative motion, Thread1: handler updates accum), but at least we won't end up with some half-updated `double` value, and the worst case is then only a very small glitch. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7806#note_101267

1 0

Re: [PATCH v4 0/1] MR7806: winewayland: Implement relative motion accumulator
by Alexandros Frantzis (＠afrantzis) 17 Apr '25

17 Apr '25

Alexandros Frantzis (@afrantzis) commented about dlls/winewayland.drv/wayland_pointer.c: > process_wayland.zwp_relative_pointer_manager_v1, > pointer->wl_pointer); > zwp_relative_pointer_v1_add_listener(pointer->zwp_relative_pointer_v1, > - &relative_pointer_v1_listener, NULL); > + &relative_pointer_v1_listener, &accum); > TRACE("Enabling relative motion\n"); > } > else if (!needs_relative && pointer->zwp_relative_pointer_v1) > { > + memset(&accum, 0, sizeof(accum)); I would recommend setting the doubles explicitly with `= 0.0`, as memset(0) of double variables is undefined behavior (from a C standard perspective, although you'd be hard-pressed to find a system where this causes a problem). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7806#note_101266

1 0

Re: [PATCH v4 0/1] MR7806: winewayland: Implement relative motion accumulator
by Alexandros Frantzis (＠afrantzis) 17 Apr '25

17 Apr '25

Alexandros Frantzis (@afrantzis) commented about dlls/winewayland.drv/waylanddrv.h: > pthread_mutex_t mutex; > }; > > +struct wayland_point > +{ > + double x; > + double y; > +}; With the move of accumulated x and y to `wayland_pointer` I don't think there is much benefit in a `struct wayland_point` anymore. A plain `double accum_x, accum_y;` or similar is enough. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7806#note_101265

1 0

Re: [PATCH v4 0/1] MR7806: winewayland: Implement relative motion accumulator
by Alexandros Frantzis (＠afrantzis) 17 Apr '25

17 Apr '25

Alexandros Frantzis (@afrantzis) commented about dlls/winewayland.drv/wayland_pointer.c: > { > INPUT input = {0}; > HWND hwnd; > - POINT screen; > + struct wayland_point screen = {0.0}, *d_accum = private; > struct wayland_win_data *data; > > if (!(hwnd = wayland_pointer_get_focused_hwnd())) return; > if (!(data = wayland_win_data_get(hwnd))) return; > + if (!private) return; > > - wayland_surface_coords_to_window(data->wayland_surface, > + wayland_motion_delta_to_window(data->wayland_surface, > wl_fixed_to_double(dx), Nit: realign to arguments above -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7806#note_101264

1 0

Re: [PATCH v4 0/1] MR7806: winewayland: Implement relative motion accumulator
by Alexandros Frantzis (＠afrantzis) 17 Apr '25

17 Apr '25

Alexandros Frantzis (@afrantzis) commented about dlls/winewayland.drv/wayland_pointer.c: > process_wayland.zwp_relative_pointer_manager_v1, > pointer->wl_pointer); > zwp_relative_pointer_v1_add_listener(pointer->zwp_relative_pointer_v1, > - &relative_pointer_v1_listener, NULL); > + &relative_pointer_v1_listener, &accum); Let's place the accumulated x and y values in wayland_pointer, since it's really a per-pointer state (currently per-process since we have a single pointer). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7806#note_101263

1 0

Re: [PATCH v4 0/1] MR7806: winewayland: Implement relative motion accumulator
by Alexandros Frantzis (＠afrantzis) 17 Apr '25

17 Apr '25

Alexandros Frantzis (@afrantzis) commented about dlls/winewayland.drv/wayland_pointer.c: > pointer_handle_axis_discrete > }; > > +/********************************************************************** > + * wayland_motion_delta_to_window > + * > + * Converts the surface-local delta to window (logical) coordinate delta. > + */ > +static void wayland_motion_delta_to_window(struct wayland_surface *surface, > + double surface_x, double surface_y, > + double *window_x, double *window_y) Nit: Align with parameters above -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7806#note_101262

1 0

Re: [PATCH v2 0/1] MR7833: mf: Update state and start clock for both paused and stopped.
by Nikolay Sivov (＠nsivov) 17 Apr '25

17 Apr '25

I'm using this demo player based on mfplay https://github.com/microsoft/Windows-classic-samples/tree/main/Samples/Win7…, and start->pause->restart works fine there for the audio. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7833#note_101261

1 0

Re: [PATCH v2 0/1] MR7833: mf: Update state and start clock for both paused and stopped.
by Nikolay Sivov (＠nsivov) 17 Apr '25

17 Apr '25

This is already working using OnClockRestart(). How does it break in your testing? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7833#note_101260

1 0

[PATCH 0/4] MR7826: ntdll: Fix some more Valgrind warnings.
by Sven Baars (＠sbaars) 17 Apr '25

17 Apr '25

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

3 5

[PATCH v3 0/7] MR7836: bcrypt: Partial BCryptKeyDerivation implementation (PBKDF2).
by Piotr Caban (＠piotr) 17 Apr '25

17 Apr '25

-- v3: bcrypt: Add BCryptKeyDerivation partial implementation (PBKDF2 algorithm). https://gitlab.winehq.org/wine/wine/-/merge_requests/7836

2 8

[PATCH v2 0/7] MR7836: bcrypt: Partial BCryptKeyDerivation implementation (PBKDF2).
by Piotr Caban (＠piotr) 17 Apr '25

17 Apr '25

-- v2: bcrypt: Add BCryptKeyDerivation partial implementation (PBKDF2 algorithm). bcrypt: Reorganize hash_handle_from_desc helper so it can be reused. bcrypt: Handle PBKDF2 in BCryptGenerateSymmetricKey. bcrypt: Handle PBKDF2 in BCryptGetProperty. bcrypt: Add PBKDF2 algorithm provider. bcrypt: Fix BcryptDeriveKeyPBKDF2 with NULL salt. include: Add some PBKDF2 related definitions. https://gitlab.winehq.org/wine/wine/-/merge_requests/7836

3 9

[PATCH 0/7] MR7836: bcrypt: Partial BCryptKeyDerivation implementation (PBKDF2).
by Piotr Caban (＠piotr) 17 Apr '25

17 Apr '25

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

3 9

Re: [PATCH v5 0/2] MR7623: winegstreamer: Use provided PTS and duration in video_decoder.
by Brendan McGrath (＠redmcg) 17 Apr '25

17 Apr '25

On Thu Apr 17 07:54:50 2025 +0000, Rémi Bernon wrote: > Have you tried GstVideoTimeCodeMeta / do you know what it does? No, I didn't look at that. But taking a look now, it looks like it might be good for Video PTS/DTS, but wouldn't work for audio. I'm not sure for duration either. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7623#note_101244

1 0

Re: [PATCH v5 0/2] MR7623: winegstreamer: Use provided PTS and duration in video_decoder.
by Rémi Bernon (＠rbernon) 17 Apr '25

17 Apr '25

On Wed Apr 16 08:20:27 2025 +0000, Brendan McGrath wrote: > Oops (again). I just tried using the `preserve_timestamps` boolean and > it doesn't work. The `timestamp/x-wg-transform` is a flag that lets > `video_decoder.c` know that an input timestamp has been provided (and > that it should use it). It will otherwise fall back to the behavior > defined by `provide_timestamps`. > But if we want to get rid of the need for the GUID, I guess we could > move the existing logic in `video_decoder.c` (for generating our own > timestamp) in to `wg_transform.c`. Hmm, I'm not sure that moving timestamp generation to the unix side is better. Can't we simply fill the sample timestamps from the input provided timestamps instead of the GStreamer-generated timestamps we don't really care about? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7623#note_101242

1 0

Re: [PATCH v5 0/2] MR7623: winegstreamer: Use provided PTS and duration in video_decoder.
by Rémi Bernon (＠rbernon) 17 Apr '25

17 Apr '25

On Wed Apr 16 01:09:24 2025 +0000, Brendan McGrath wrote: > On well formed media, that `dts < 0` should only ever be true once (as > after adding ts_offset, we should never get a value below 0 again). It's > mainly there in case we get media with malformed timestamps (and dts > goes backwards). IMO the offset should only be updated once, and there should be a check and warning/fixme message if that assumption is broken. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7623#note_101241

1 0

Re: [PATCH v5 0/2] MR7623: winegstreamer: Use provided PTS and duration in video_decoder.
by Rémi Bernon (＠rbernon) 17 Apr '25

17 Apr '25

Rémi Bernon (@rbernon) commented about dlls/winegstreamer/wg_transform.c: > - GST_BUFFER_PTS(buffer) = sample->pts * 100; > + { > + pts = sample->pts += transform->ts_offset; > + if (pts < 0) > + { > + transform->ts_offset -= pts; > + pts = 0; > + } > + GST_BUFFER_PTS(buffer) = pts * 100; > + > + if (transform->attrs.preserve_timestamps) > + { > + transform_timestamp = gst_caps_new_empty_simple("timestamp/x-wg-transform"); > + gst_buffer_add_reference_timestamp_meta(buffer, transform_timestamp, pts * 100, > + sample->flags & WG_SAMPLE_FLAG_HAS_DURATION ? sample->duration * 100 : GST_CLOCK_TIME_NONE); > + gst_caps_unref(transform_timestamp); Have you tried GstVideoTimeCodeMeta / do you know what it does? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7623#note_101240

1 0

Re: [PATCH v5 0/2] MR7623: winegstreamer: Use provided PTS and duration in video_decoder.
by Brendan McGrath (＠redmcg) 17 Apr '25

17 Apr '25

On Wed Apr 16 01:06:36 2025 +0000, Brendan McGrath wrote: > Good question. Unfortunately I must admit to not being an expert on > that. Obviously it seems to decode fine without it, so it may be more > useful for muxing than decoding. Although, the only codec with B-Frames > that I've tested is H.264; maybe there's another codec that's more > dependent on it. But I'll experiment and see if I can discern any > difference between its inclusion vs. exclusion. Testing H.264 decoding, I've been unable to discern any difference. I only tested with a small sample of videos, but it seems to work both with and without and with no notable difference in performance. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7623#note_101239

1 0

[PATCH v5 0/5] MR7812: win32u: Add more CompAttr, CompClause implementation using cursor_begin, cursor_end concept.
by Byeongsik Jeon (＠bsjeon) 17 Apr '25

17 Apr '25

If CompAttr and CompClause are properly configured, Japanese input will be more comfortable. Inspired by cursor_begin and cursor_end from Wayland zwp_text_input_v3:: preedit_string, I extended the cursor_pos concept as follows: cursor_pos = MAKELONG( cursor_begin, cursor_end ); ime_to_tascii_ex() uses this to construct CompAttr, CompClause. MS Windows native CompAttr, CompClause is a bit more complicated than this, but the concept is useful enough. It requires additional implementation in the Wine ime_ui_window proc and richedit control. However, it is useful for applications that inline ime composition string. This can be tested with MS Office Word, Excel. LANG=ja_JP.UTF-8 wine EXCEL.EXE Test key sequences: - “n-i-h-o-n-g-o-n-o-m-o-j-i-d-e-s-u-.-SPACE”. - And, RIGHT, LEFT, Shift+LEFT, Shift+RIGHT, ESC, SPACE, etc. -- v5: winex11: Update only when caret pos changed in xic_preedit_caret. winex11: Extend cursor_pos using cursor_begin, cursor_end. winemac: Extend cursor_pos using cursor_begin, cursor_end. winewayland: Extend cursor_pos using cursor_begin, cursor_end. win32u: Add more CompAttr, CompClause implementation using cursor_begin, cursor_end concept. https://gitlab.winehq.org/wine/wine/-/merge_requests/7812

3 7

[PATCH v3 0/2] MR7827: imm32: Fix the WM_IME_COMPOSITION messages to be between the WM_IME_{START|END}COMPOSITION message.
by Byeongsik Jeon (＠bsjeon) 17 Apr '25

17 Apr '25

This patch fixes a Japanese input issue in MS Office Visual Basic and Mery text editor ime inline mode. The following was considered: 1. Japanese ime: the result string message is always placed between WM_IME_STARTCOMPOSITION and WM_IME_ENDCOMPOSITION. Currently in Wine, the result string message follows WM_IME_ENDCOMPOSITION. dlls/imm32/tests/imm32.c::test_nihongo_no(). 2. Chinese ime: same as Japanese ime. 3. Korean ime: mostly the same, but there are some cases where it is not (e.g. CPS_COMPLETE, 'r-k-RETURN'). However, I haven't found any problem even if it behave like Japanese ime message order. 3. zero-length preedit string: as in MR !3115 commit d1f9aae, the message followed by WM_IME_ENDCOMPOSITION. Currently in Wine, it is associated with WM_IME_STARTCOMPOSITION. 4. zero-length result string: ignore. -- v3: winewayland: Use an empty string to clear the composition string. imm32: Fix the WM_IME_COMPOSITION messages to be between the WM_IME_{START|END}COMPOSITION message. https://gitlab.winehq.org/wine/wine/-/merge_requests/7827

3 4

[PATCH v3 0/5] MR7817: winebth.sys part 10: Add support for removing and disconnecting devices.
by Vibhav Pant (＠vibhavp) 17 Apr '25

17 Apr '25

-- v3: bluetoothapis/tests: Add tests for BluetoothRemoveDevice. bluetoothapis: Implement BluetoothRemoveDevice. bluetoothapis: Add stub for BluetoothRemoveDevice. winebth.sys: Implement IOCTL_WINEBTH_RADIO_REMOVE_DEVICE. winebth.sys: Implement IOCTL_BTH_DISCONNECT_DEVICE. https://gitlab.winehq.org/wine/wine/-/merge_requests/7817

2 6

Re: [PATCH v8 0/1] MR7706: powrprof.dll: Partially implement PowerGetActiveScheme for SteamVR
by Robert Lippmann (＠rlippmann) 17 Apr '25

17 Apr '25

Fixed GUID and added a comment -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7706#note_101230

1 0

Re: [PATCH v8 0/1] MR7706: powrprof.dll: Partially implement PowerGetActiveScheme for SteamVR
by Robert Lippmann (＠rlippmann) 17 Apr '25

17 Apr '25

On Thu Apr 17 03:21:46 2025 +0000, Robert Lippmann wrote: > Ugh. I don't know how that happened. > It does make SteamVR happy, though. Ok, fixed. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7706#note_101228

1 0

2025

2024

2023

2022

wine-gitlab