- wine-gitlab - winehq.org

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

16 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. -- v4: 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 16

[PATCH 0/9] MR7835: win32u: Implement generic OpenGL context functions.
by Rémi Bernon (＠rbernon) 16 Apr '25

16 Apr '25

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

3 11

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

16 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. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7827

3 5

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

16 Apr '25

On Wed Apr 16 01:25:38 2025 +0000, Brendan McGrath wrote: > Oops - sorry. I got the GUID mixed up with `timestamp/x-wg-transform`. > The GUID might not be necessary actually. I might be able to use the > `preserve_timestamps` boolean instead. I think the only difference would > be that if GStreamer lost the `timestamp/x-wg-transform` state, we would > fall back to using the gstreamer values. Which is possibly better. 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`. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7623#note_101018

1 0

Re: [PATCH v9 0/2] MR7796: winegstreamer: Allow caller to allocate samples in MF_XVP_PLAYBACK_MODE.
by Rémi Bernon (＠rbernon) 16 Apr '25

16 Apr '25

The test is causing failures and crashes on Win8.1/early Win10 versions, see: https://test.winehq.org/data/patterns.html#mfplat:mfplat -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7796#note_101013

1 0

[PATCH v5 0/6] MR7715: Implement dynamic formats in directdraw media stream.
by Santino Mazza (＠tati) 16 Apr '25

16 Apr '25

-- v5: amstream: Implement dynamic formats in ddraw stream. amstream/tests: Test for dynamic formats in ddraw stream. amstream: Implement custom allocator for ddraw stream. amstream/tests: Test for custom allocator in ddraw stream. amstream: Release allocator when Disconnect is called in ddraw stream. amstream: Implement IMemAllocator stub for ddraw stream. https://gitlab.winehq.org/wine/wine/-/merge_requests/7715

4 9

[PATCH 0/2] MR7825: windowscodecs/metadata: Add a stub for bKGD writer.
by Nikolay Sivov (＠nsivov) 16 Apr '25

16 Apr '25

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7825

3 4

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

16 Apr '25

On Wed Apr 16 00:56:58 2025 +0000, Brendan McGrath wrote: > I'll just add, that the state I'm referring to is the sample PTS. On > Windows, the application can provide any arbitrary value and when the > decoder produces the output, it needs to preserve the provided value. Oops - sorry. I got the GUID mixed up with `timestamp/x-wg-transform`. The GUID might not be necessary actually. I might be able to use the `preserve_timestamps` boolean instead. I think the only difference would be that if GStreamer lost the `timestamp/x-wg-transform` state, we would fall back to using the gstreamer values. Which is possibly better. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7623#note_100994

1 0

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

16 Apr '25

On Tue Apr 15 22:44:37 2025 +0000, Rémi Bernon wrote: > Updating the offset continuously feels weird, though I've only skimmed > over the code for now. 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). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7623#note_100993

1 0

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

16 Apr '25

On Tue Apr 15 22:44:37 2025 +0000, Rémi Bernon wrote: > How useful are DTS? Do we really need to pass them through? 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. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7623#note_100992

1 0

2025

2024

2023

2022

wine-gitlab