February 2023 - wine-gitlab

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

06 Feb '23

On Mon Feb 6 15:28:54 2023 +0000, Timo Zuccarello wrote: > Looks great, I didn't know you were working on it already! I presume a > fixed offset is enough then in most cases, so no need for manual > mappings from XKB names? Yes I believe so. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/182#note_23087

1 0

Re: [PATCH 0/1] MR182: winex11: Use XKB key names to map key codes to scan codes.
by Timo Zuccarello (＠timozuccarello) 06 Feb '23

06 Feb '23

On Mon Feb 6 15:05:02 2023 +0000, Rémi Bernon wrote: > I mean, I don't know if we need to detect VNC, but at least having an > option to enable or disable the bogus scancode auto-detect is imho a > good solution. Looks great, I didn't know you were working on it already! I presume a fixed offset is enough then in most cases, so no need for manual mappings from XKB names? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/182#note_23086

1 0

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

06 Feb '23

On Mon Feb 6 15:03:35 2023 +0000, Rémi Bernon wrote: > I think it's a good way to fix this, and I started implementing the > `winecfg` option, with a first MR for some preparatory work here: https://gitlab.winehq.org/wine/wine/-/merge_requests/2062 I mean, I don't know if we need to detect VNC, but at least having an option to enable or disable the bogus scancode auto-detect is imho a good solution. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/182#note_23085

1 0

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

06 Feb '23

On Mon Feb 6 14:32:23 2023 +0000, Timo Zuccarello wrote: > @rbernon Prompted by someone who also had issues with exotic or > non-qwerty keyboard layouts in #winehq, I've taken another look at this. > Came across a StackOverflow post about detecting whether a display is > VNC > (https://stackoverflow.com/questions/29371717/linux-detecting-if-youre-runni…). > Would that be an option? I.e. add an override winecfg option and by > default try to detect a VNC session and if it's VNC, use previous > mapping/code, otherwise use XKB? I think it's a good way to fix this, and I started implementing the `winecfg` option, with a first MR for some preparatory work here: https://gitlab.winehq.org/wine/wine/-/merge_requests/2062 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/182#note_23083

1 0

[PATCH 0/1] MR80: vkd3d-shader/hlsl: Support reflect() intrinsic.
by Nikolay Sivov (＠nsivov) 06 Feb '23

06 Feb '23

-- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/80

3 4

Re: [PATCH 0/1] MR182: winex11: Use XKB key names to map key codes to scan codes.
by Timo Zuccarello (＠timozuccarello) 06 Feb '23

06 Feb '23

On Thu Oct 6 11:55:45 2022 +0000, Timo Zuccarello wrote: > I just went through the email thread (I'm still new to navigating > pipermail/mailing list archives) and I see the point, although I don't > think I can entirely grasp what VNC does. But the way I understand it is > that even if we used XKB names for the scan codes as in this MR, those > would be messed up just as well when using a VNC X server, as it maps > backwards from vkeys to scan codes? > In the XKB specification/documentation, "The key name links keys with > similar functions or in similar positions on keyboards that report > different scan codes", which gets me wondering how Windows actually > handles exotic keyboards or rather what is common practice in the > drivers for said exotic keyboards. > In any case, I agree, I suppose optional layout detection would be the > most compatible solution for now at least. @rbernon Prompted by someone who also had issues with exotic or non-qwerty keyboard layouts in #winehq, I've taken another look at this. Came across a StackOverflow post about detecting whether a display is VNC (https://stackoverflow.com/questions/29371717/linux-detecting-if-youre-runni…). Would that be an option? I.e. add an override winecfg option and by default try to detect a VNC session and if it's VNC, use previous mapping/code, otherwise use XKB? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/182#note_23078

1 0

[PATCH 0/1] MR82: vkd3d: Fix checking for failure from SleepConditionVariableCS().
by Zebediah Figura (＠zfigura) 06 Feb '23

06 Feb '23

Fixes: 552926cfca64db45e9731f675c65a7214bfa6441 -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/82

4 3

[PATCH 0/1] MR83: vkd3d-shader: Initialize the parameter allocator head.
by Zebediah Figura (＠zfigura) 06 Feb '23

06 Feb '23

This fixes a memory leak. Fixes: 007f894b9493eb80091899dab971e369f1673a4f -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/83

4 3

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

06 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. -- v6: 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

2 5

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

06 Feb '23

-- v2: 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. vkd3d-shader/hlsl: Add a hlsl_cleanup_semantic() helper. vkd3d-shader/hlsl: Store function parameters in an array. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/77

4 12

2025

2024

2023

2022

wine-gitlab February 2023