You can access it, probably, but then some members such as the composition string is behind a pseudo handle, which require callbacks to access. In general we want as little callbacks as possible, and here probably, do as much as possible in imm32.
Yes, KeUserModeCallback used. I think it can be implemented in win32u, probably using NtAllocateVirtualMemory.
There is also the fact that I'm trying to move XIM handling, and input in general, to a separate "rawinput" thread, which will fix several long standing bugs and design issues, as well as let us implement more HID features such as touch input, in user32.
If the thread sending the updates isn't the same as the one owning the input context, you cannot safely access the input context members anymore, because it isn't synchronized with the owning thread which may be reading, or destroying them at the same time.
Thanks for the answer.
I think imm32/ime.c should be designed as the common code for the Wine builtin ime infrastructure. Each sub-IME can be either an "in-thread" or "separate-thread" implementation.
In my opinion, you are applying a "separate-thread" implementation to "in-thread" code too early.
I would suggest separating the steps.
First, move the code to consider only the current implementation, "in-thread". If we implement the HIMCC related functions on the UNIX side and use client_ptr, the data copying issue will be eliminated.
Later, extend imm32/ime.c when implementing "separate thread" ime.
I know it's a presumptuous opinion. Just an opinion.