- wine-gitlab - winehq.org

[PATCH v6 0/8] MR66: vkd3d-shader/hlsl: Broaden resources support v2 (PART 1).
by Francisco Casas (＠fcasas) 07 Feb '23

07 Feb '23

First part of v2 of !27, which aims to: * Allow allocation of variables of complex types that contain both numerics and objects across multiple register sets (regsets). * Support the tex2D and tex3D intrinsics, inferring generic samplers dimension from usage, writing sampler declarations, and writing sample instructions. * Support for arrays of resources for both SM1 and SM4 (not to be confused with the resource-arrays of SM 5.1, which can have non-constant indexes). * Support for resources declared within structs. * Support for synthetic combined samplers for SM1 and synthetic separated samplers for SM4, considering that they can be arrays or members of structs. * Imitate the way the native compiler assigns the register indexes of the resources on allocation, which proved to be the most difficult thing. * Support for object components within complex input parameters. * Small fixes to corner cases. This part consists on parsing the `tex2D()` and `tex3D()` intrinsics and beginning to support the allocation of variables across multiple regsets. The whole series, is on my [master6](https://gitlab.winehq.org/fcasas/vkd3d/-/commits/master6) branch. -- v6: vkd3d-shader/hlsl: Allocate register reservations in a separate pass. vkd3d-shader/hlsl: Respect object reservations even if the object is unused. vkd3d-shader/hlsl: Allocate objects according to register set. vkd3d-shader/hlsl: Keep an hlsl_reg for each register set in hlsl_ir_var. vkd3d-shader/hlsl: Store the type's register size for each register set. vkd3d-shader/hlsl: Parse the tex3D() intrinsic. vkd3d-shader/hlsl: Parse the tex2D() intrinsic. vkd3d-shader/hlsl: Avoid segfault on missing sampler. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/66

4 15

[PATCH v3 0/2] MR2120: user32: Post WM_INPUT_DEVICE_CHANGE when registering for notifications
by Evan Tang (＠etang-cw) 07 Feb '23

07 Feb '23

This seems to be relied on by some versions of [this Unreal Engine input plugin](https://www.unrealengine.com/marketplace/en-US/product/wm-input-man… Note: I'm not sure how to deal with `HID_USAGE_GENERIC_KEYPAD`, which (I think) would fall under `RIM_TYPEKEYBOARD`. Do we need to store extra info to differentiate these from `HID_USAGE_GENERIC_KEYBOARD` or is there something in the device info struct that can differentiate them? -- v3: user32: Post WM_INPUT_DEVICE_CHANGE when registering for notifications https://gitlab.winehq.org/wine/wine/-/merge_requests/2120

4 5

[PATCH 0/1] MR1963: d3dcompiler_43/tests: Allow more imprecision in test_trig() for NVIDIA.
by Francois Gouget (＠fgouget) 07 Feb '23

07 Feb '23

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

3 2

[PATCH 0/9] MR2122: Draft: winex11: Support fixed X11 keycode to scancode conversion.
by Rémi Bernon (＠rbernon) 07 Feb '23

07 Feb '23

X11 keycodes are just Linux keycodes + 8 nowadays according to evdev or libinput drivers, and we can avoid innacurate reconstruction in the most common case. Opening this as a draft for now, to show where I'd like to go with https://gitlab.winehq.org/wine/wine/-/merge_requests/2062. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2122

3 10

[PATCH v8 0/4] MR1088: ntdll: Avoid calling pthread_exit on thread exit.
by Rémi Bernon (＠rbernon) 07 Feb '23

07 Feb '23

Using a dedicated exit jmpbuf and removing the need for assembly routines. When Wine handles an exception in unix code, we return to user mode by jumping to the last syscall frame. This can leave some pthread cancel cleanups registered, in the pthread internal linked list, and at the same time later overwrite the stack frame they were registered for. In the same way, jumping to the exit frame on thread exit or abort, can also leave some cleanup handlers registered for invalid stack frames. Depending on the implementation, calling pthread_exit will cause all the registered pthread cleanup handlers to be called, possibly jumping back to now overwritten stack frames and causing segmentation faults. Exiting a pthread normally, by returning from its procedure, or calling exit(0) for the main thread doesn't run pthread_exit and doesn't call cleanup handlers, avoiding that situation. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52213 ### Additional note: For robustness, we should probably try to execute these cleanup handlers when unwinding the stack frames, as we would otherwise leave pthread objects in a potential problematic state (like a mutex locked, etc). It is however hard to do so when the handlers are registered from some C code: pthread C implementation is done by calling some internal pthread functions to register the handlers, and they aren't registered as standard unwind handlers. Only pthread_cancel and pthread_exit can unwind and call / unregister the C handlers, but interrupting that procedure, for instance calling setjmp / longjmp from withing our own handler isn't supported. From C++ code, pthread cleanup handlers are registered through C++ class constructors / destructors, and it would then be possible to partially unwind and call them at the same time. -- v8: ntdll: Remove now unnecessary arch-specific exit frame. ntdll: Avoid calling pthread_exit on thread exit. ntdll: Return entry and suspend from server_init_process_done. ntdll: Create a pthread for the main thread. https://gitlab.winehq.org/wine/wine/-/merge_requests/1088

3 7

[PATCH v7 0/4] MR1088: ntdll: Avoid calling pthread_exit on thread exit.
by Rémi Bernon (＠rbernon) 07 Feb '23

07 Feb '23

Using a dedicated exit jmpbuf and removing the need for assembly routines. When Wine handles an exception in unix code, we return to user mode by jumping to the last syscall frame. This can leave some pthread cancel cleanups registered, in the pthread internal linked list, and at the same time later overwrite the stack frame they were registered for. In the same way, jumping to the exit frame on thread exit or abort, can also leave some cleanup handlers registered for invalid stack frames. Depending on the implementation, calling pthread_exit will cause all the registered pthread cleanup handlers to be called, possibly jumping back to now overwritten stack frames and causing segmentation faults. Exiting a pthread normally, by returning from its procedure, or calling exit(0) for the main thread doesn't run pthread_exit and doesn't call cleanup handlers, avoiding that situation. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52213 ### Additional note: For robustness, we should probably try to execute these cleanup handlers when unwinding the stack frames, as we would otherwise leave pthread objects in a potential problematic state (like a mutex locked, etc). It is however hard to do so when the handlers are registered from some C code: pthread C implementation is done by calling some internal pthread functions to register the handlers, and they aren't registered as standard unwind handlers. Only pthread_cancel and pthread_exit can unwind and call / unregister the C handlers, but interrupting that procedure, for instance calling setjmp / longjmp from withing our own handler isn't supported. From C++ code, pthread cleanup handlers are registered through C++ class constructors / destructors, and it would then be possible to partially unwind and call them at the same time. -- v7: ntdll: Remove now unnecessary arch-specific exit frame. ntdll: Avoid calling pthread_exit on thread exit. ntdll: Return entry and suspend from server_init_process_done. ntdll: Create a pthread for the main thread. https://gitlab.winehq.org/wine/wine/-/merge_requests/1088

4 9

[PATCH v3 0/6] MR77: hlsl: Fixes for function definition vs declaration.
by Zebediah Figura (＠zfigura) 07 Feb '23

07 Feb '23

-- v3: vkd3d-shader/hlsl: Add functions to the global list inside the func_prototype rule. vkd3d-shader/hlsl: Use the original hlsl_ir_function_decl struct rather than allocating a new one for each definition. vkd3d-shader/hlsl: Put synthetic variables into a dummy scope. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/77

4 10

[PATCH v2 0/5] MR81: vkd3d-shader/hlsl: Fixes for SM1 writemasks and swizzles.
by Francisco Casas (＠fcasas) 07 Feb '23

07 Feb '23

Because of the change introduced in f21693b2, SM1 scalars and vectors were not longer getting the correct writemask when they are allocated, so this is fixed. Also, the mapping of sm1 src register swizzles is moved outside `write_sm1_instruction()` since there are some instructions that don't do this, remarkably dp2add. This is fixed. Before the last patch we are writing the operation as: ``` dp2add r0.x, r1.x, r0.x, r2.x ``` and now it is: ``` dp2add r0.x, r1.xyxx, r0.xyxx, r2.x ``` dp2add now has its own function, `write_sm1_dp2add()`, since it seems to be the only instruction with this structure. Ideally we would be using the default swizzles for the first two src arguments: ``` dp2add r0.x, r1, r0, r2.x ``` since, according to native's documentation, these are supported for all sm < 4. But using default swizzles whenever is possible -- along with following the conversion of repeating the last component of the swizzle when fewer than 4 components are to be specified -- has a higher scope. Probably would involve modifying `hlsl_swizzle_from_writemask()` and `hlsl_map_swizzle()`. -- v2: vkd3d-shader/hlsl: Fix SM1 dp2add swizzles. vkd3d-shader/hlsl: Map SM1 src swizzles outside write_sm1_instruction(). vkd3d-shader/hlsl: Set writemasks correctly for SM1 scalar and vector types. vkd3d-shader/hlsl: Expect component count in allocate_register(). vkd3d-shader/hlsl: Rename 'component_count' arguments to 'reg_size'. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/81

5 9

[PATCH 0/11] MR2123: Wow64 support for wpcap.
by Hans Leidekker (＠hans) 07 Feb '23

07 Feb '23

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

3 12

Re: [PATCH 0/1] MR182: winex11: Use XKB key names to map key codes to scan codes.
by Rémi Bernon (＠rbernon) 07 Feb '23

07 Feb '23

On Mon Feb 6 15:36:14 2023 +0000, Timo Zuccarello wrote: > Is there anything I can help with? I obviously have a bit of a personal > interest in having this "fixed" finally. Well if you feel like it, you can always have a look at the MR and review the changes. I also opened https://gitlab.winehq.org/wine/wine/-/merge_requests/2122 with the complete changes, if you want to give it a try, and confirm that it does the right thing for you as well. I've done a bit of testing but I don't often use any very fancy keyboard layout either. Then I suspect that what's expected here is actually a bit more wider testing, so probably I should try to get this into Wine Staging or Proton first. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/182#note_23264

1 0

2025

2024

2023

2022

wine-gitlab