October 2023 - wine-gitlab

[PATCH v3 0/6] MR2298: winewinrt: Introduce new WinRT common module.
by Rémi Bernon (＠rbernon) 31 Jan '24

31 Jan '24

The idea I have is to use this module to declare class stubs until there is a good reason to split them to dedicated modules. WinRT modules aren't usually loaded directly, and instead the registry is queried to figure which module to load for which class. This would help avoiding unnecessary proliferation of stub WinRT modules, while at the same time allowing to factor WinRT foundation code (such as vector / async, etc...) between the modules that seem to deserve to be implemented separately. The relevant classes could then be split out to dedicated modules on a as-needed basis, when they get fleshed out. -- v3: winewinrt: Factor IAsyncOperation<boolean> implementations. winewinrt: Factor IAsyncInfo implementations. winewinrt: Move Vector<HSTRING> from windows.media.speech. widl: Write C type names for function parameters. winewinrt: Factor Vector<IInspectable> implementations. winewinrt: Introduce new static library. https://gitlab.winehq.org/wine/wine/-/merge_requests/2298

5 12

[PATCH v3 0/12] MR4102: Draft: winewayland.drv: Implement keyboard input support.
by Rémi Bernon (＠rbernon) 29 Jan '24

29 Jan '24

@afrantzis Can't seem to be possible to add you as a reviewer, probably you need to request "Access" to the wine/wine project (near the top of the project page). What do you think of something like that? It is very different from the current winex11 code, but I believe it will match keyboard layouts in a much more accurate way, and it's also IMO much simpler. If that works well with Wayland, I think it could be a good hint that it might work as well in X11 and make a case for my other MR to use that approach there. I was a bit annoyed that it doesn't seem possible to retrieve the Xkb "layout:variant" string here, but only the layout description, so I had to use xkbregistry to match it back to the known layouts. It is mostly only there to provide a more accurate HKL value (which should match the layout langid), and scan to vk mapping table, and custom layouts should still work. The lang would be neutral then, and the scan to vk table is QWERTY by default, which is the most common case, and doesn't enforce any vkey -> unicode mapping anyway. So, if the xkbregistry dependency is an issue we could probably make it optional and dynamically loaded, and skip the langid and scan to vk specialized mappings. -- v3: winewayland.drv: Implement Xkb composition using ImeProcessKey. winewayland.drv: Translate Xkb keyboard layouts to KBDTABLES. win32u: Allow KBDTABLES conversion from CTLR + ALT to WCHAR. win32u: Force US layout in ToUnicode when CTRL is pressed. win32u: Introduce KbdLayerDescriptor user driver entry. win32u: Avoid accessing NULL key name string pointer. winewayland.drv: Enumerate Xkb layouts and create matching HKL. winewayland.drv: Handle and parse Xkb keymap events. win32u: Implement opt-in auto-repeat for WM_(SYS)KEYDOWN messages. winewayland.drv: Configure win32u keyboard repeat delay and speed. winewayland.drv: Basic handling of Wayland keyboard events. gitlab: Install libxkbcommon and libxkbregistry dependencies. https://gitlab.winehq.org/wine/wine/-/merge_requests/4102

6 37

[PATCH v5 0/1] MR263: vkd3d-shader/spirv: Refactor the type system.
by Conor McCarthy (＠cmccarthy) 24 Jan '24

24 Jan '24

Shader Model 6 introduces a 16-bit float (half) type, and 16-bit and 64-bit integer types. Storing extra info in the type enum simplifies checking if a type is any integer, floating point or numeric type, and the declaration of SPIR-V types. The benefits depend on using enum vkd3d_data_type in the backend instead of vkd3d_shader_component_type. Patch 2 is difficult to split because types typically flow through to vkd3d_spirv_get_type_id(), so partial changes would require new calls to conversion functions which would be deleted again later. -- v5: vkd3d-shader/spirv: Use enum vkd3d_data_type instead of vkd3d_shader_component_type. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/263

3 3

[PATCH 0/8] MR3059: Don't redefine typedefs (needed for gcc 4.3)
by Fabian Maurer (＠DarkShadow44) 20 Jan '24

20 Jan '24

Signed-off-by: Fabian Maurer <dark.shadow4(a)web.de> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3059

6 23

[PATCH v4 0/2] MR3061: libs/jxr: Compile with ansi flag to avoid typedef redefinitions (gcc 4.3)
by Fabian Maurer (＠DarkShadow44) 20 Jan '24

20 Jan '24

Signed-off-by: Fabian Maurer <dark.shadow4(a)web.de> -- v4: libs/jxr: Compile with ansi flag to avoid typedef redefinitions (gcc 4.3) wmphoto: Define ansi flag for JXRGlue to avoid typedef redefinitions (gcc 4.3) https://gitlab.winehq.org/wine/wine/-/merge_requests/3061

4 7

[PATCH v5 0/6] MR3454: user32: Implement UOI_TIMERPROC_EXCEPTION_SUPPRESSION.
by Jinoh Kang (＠iamahuman) 20 Jan '24

20 Jan '24

This is required to avoid silencing (potentially fatal) exceptions from timer procedures. -- v5: win32u: Ignore unhandled info index in NtUserSetObjectInformation. win32u/tests: Add tests for NtUserSetObjectInformation. user32: Implement UOI_TIMERPROC_EXCEPTION_SUPPRESSION. user32/tests: Add tests for UOI_TIMERPROC_EXCEPTION_SUPPRESSION. include: Add definition for UOI_TIMERPROC_EXCEPTION_SUPPRESSION user32/tests: Make test_unicode_wm_char robust against superfluous messages. https://gitlab.winehq.org/wine/wine/-/merge_requests/3454

2 7

[PATCH v2 0/4] MR2408: winex11: Detect Xkb layouts and create HKL registry keys.
by Rémi Bernon (＠rbernon) 18 Jan '24

18 Jan '24

-- v2: winex11: Create registry keys for known Xkb layouts. winex11: Keep a list of every known Xkb layout. winex11: Read the _XKB_RULES_NAMES root window property. win32u: Init vsc2vk in NtUserGetKeyNameText only if necessary. https://gitlab.winehq.org/wine/wine/-/merge_requests/2408

3 8

[PATCH v2 0/4] MR3024: win32u: Introduce a new rawinput dedicated thread.
by Rémi Bernon (＠rbernon) 18 Jan '24

18 Jan '24

Currently only used to keep rawinput devices updated without iterating the entire list on every change. This thread will then let us solve several problems: * Solve issues with input not being polled if/when applications aren't checking their messages. This removes the need for polling messages in DInput, which is known to confuse and break DOSBOX. * Solve some issues with ll-hook deadlocks between hooking threads and the thread that is currently polling for inputs. * Useful to process internal messages and implement some user driver mechanisms. It can for instance already process WM_WINE_CLIPCURSOR messages, instead of relying on the foreground thread. * Similarly, for cursor icon changes, wineserver can notify it on cursor window changes and request the cursor icon to be updated from the user driver, instead of having to check the window the cursor is located in to change its icon on every mouse move. * Ultimately make it possible to drop the __wine_send_input PE export, the thread can read HID reports from devices that a process has registered for, and send WM_INPUT messages accordingly. This has some drawbacks though, as reading NT devices currently involves much more wineserver roundtrips than `__wine_send_input`. There's evidence that Windows uses a similar thread to process hardware events (as described in https://devblogs.microsoft.com/oldnewthing/20140213-00/?p=1773), although it's probably a system-wide kernel thread. I considered reading X11 input from a per-prefix dedicated thread (for instance in explorer.exe) or dedicated process, but having one thread per-process has several advantages. The rawinput device registration state is done per-process and according to https://gitlab.winehq.org/wine/wine/-/merge_requests/2120 it also needs to post notifications that are process specific. It also keeps the guarantee that each process will read the inputs from the window it has created, and not from some other windows, although the message dispatch may decide to send the message to another process later, it avoids having to listen to input on other processes windows. It can then be seen as an intermediate step towards having a per-prefix thread, if that's something we end up needing. Moving from a per-process thread to a per-prefix thread should be easier. -- v2: win32u: Keep rawinput device list updated using WM_DEVICECHANGE. win32u: Register for device notifications in the rawinput thread. win32u: Introduce a dedicated thread for rawinput processing. ntdll/tests: Use combase instead of comctl32 as a test module. https://gitlab.winehq.org/wine/wine/-/merge_requests/3024

4 8

[PATCH 0/2] MR3264: dinput: Improve keyboard devices scancode support.
by Rémi Bernon (＠rbernon) 18 Jan '24

18 Jan '24

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55205 This is not really a bug upstream because of the limited X11 scancode support, but it becomes one with the staging fixed scancode patch which enumerates more keys in the upper scancode range. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3264

2 3

[PATCH v5 0/1] MR3288: gdiplus: Clip polygons before drawing them
by David Kahurani (＠kahurani) 15 Dec '23

15 Dec '23

Validate user data before passing it to PolyDraw. The program in the bug requests to draw figures outrageously outside the DC's region after presumably, some uninitialized values happen as a result of a missing font. Native gdiplus seems to handle this gracefully so we probably also should. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=41617 Signed-off-by: David Kahurani <k.kahurani(a)gmail.com> -- v5: gdiplus: Clip polygons before drawing them https://gitlab.winehq.org/wine/wine/-/merge_requests/3288

3 5

2025

2024

2023

2022

wine-gitlab October 2023