The adapter ids used by the host and settings handlers are not guaranteed to be compatible, so ensure we are using the proper id with each
handler.
Note that although the possibly incompatible id was already used in `settings_handler.get_modes()` before, the settings handler was ignoring it anyway for `get_modes()` in the case it was really incompatible (e.g., using host handler xrandr 1.4, settings handler xrandr 1.0), . The problem manifests now since we are additionally calling `settings_handler.get_current_mode()` which does check the id value (e.g., in xrandr 1.0 to differentiate primary vs non-primary).
Signed-off-by: Alexandros Frantzis <alexandros.frantzis(a)collabora.com>
Fixes: 4232312dffe1cd115aa6bfd755f5b7c6a403e3fc
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54781
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2593
include: _InterlockedExchangePointer and _InterlockedCompareExchangePointer are intrinsics in x86 msvc.
I fixed this issue in ad05f33d67, but a40973f20 regressed this again. I was carrying a
patch for quite a while, feeling dejavu.
The msvc ver of 1900 is taken from Boost's interlocked.hpp, which matches MSVC 2015
(toolset version v140). Boost has a comment that claims that in msvc 2012 those
functions were defined in intrin.h, but those defines are broken with Microsoft's
winnt.h.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2591
On Wed Apr 5 09:07:47 2023 +0000, Byeongsik Jeon wrote:
> I tested a bit of code, it appears that fdwInit is also cached during
> IME switching.
Yeah I'm thinking that the entire `INPUTCONTEXT` is probably switched and kept cached, to avoid sharing its contents with a different IME.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2520#note_29002