[PATCH v2 4/4] user32: Move (Un)LoadKeyboardLayoutW from winex11.drv to user32.

[Rémi Bernon]

On 4/24/21 8:43 PM, Dmitry Timoshkov wrote:
> Rémi Bernon <rbernon at codeweavers.com> wrote:
> 
>> 1) Assuming each thread can have a different input locale, which is a
>> legacy behavior according to MSDN, we could imagine the following scenario:
>>
>> An application with a child window running in a separate thread from its
>> parent. If the child window thread calls ActivateKeyboardLayout, the
>> vkey and char events it'll receive should use the new layout, while the
>> vkey and char events the parent receive should still use the default layout.
>>
>> The way winex11 is currently structured (and I don't see this changing
>> any time soon), the toplevel window would translate X11 events to vkeys
>> messages according its locale, which would be wrong if the child window
>> has input focus.
> 
> Every thread has its own x11 connection (aka Display), so all events
> including keyboard ones are bound to a thread. On the other hand input
> locale depends on a WM configuration, and might be window or system bound.
> 

Yes.

I don't know how XkbLockGroup acts, but if we want to support the legacy 
per-thread input locales and it acts system-wide then it will not be 
possible to have such granularity.

If it works per-window / per-client and we want to implement the new 
system-wide behavior, it'll be difficult too.

>> 2) MSDN now mentions that ActivateKeyboardLayout / LoadKeyboardLayout do
>> a system-wide change, as long as the calling application is foreground.
>>
>> This makes things simpler in some sense, and that would solve the issue
>> from 1), but then implementing it (somehow) and letting Wine change
>> system-wide input locale is in my opinion risky. I would rather see Wine
>> input locale management not leaking out.
>>
>> There's several (a lot of?) ways to change input locale on Linux, I
>> didn't even play with many of them but as far as I could see already
>> they don't work together very well.
>>
>> For instance, I can change input locale through setxkbmap (which Wine
>> sees when detecting keyboard or xkb groups btw), or using GNOME language
>> switcher (which Wine doesn't see). Both aren't synced at all, and I
>> don't think adding Wine to the party would help.
> 
> Everything under X11 goes via XKB these days, so if Wine doesn't see a
> layout switch from the GNOME switcher that's most likely a bug in Wine.
> 

Not only Wine, but GNOME language switcher itself doesn't see changes 
made by setxkbmap. I can call setxkbmap to set any kind of keyboard 
layout, and GNOME switcher still believes it's the default one (doesn't 
see new layouts, or layout changes).

If I use setxkbmap us instead, Wine correctly detects "United States 
keyboard layout", and translates both chars and vkey accordingly.

But if I switch keyboard layout using GNOME, for instance setting en 
instead of the default fr, Wine still detects my keyboard layout as 
"French keyboard layout". The char messages are correctly translated but 
not the vkey messages.

>> FWIW I also tried your patch and it wasn't able to change anything as
>> far as I could tell (I used setxkbmap fr,us to setup two groups and
>> tried switching between them, but the fr translation was always active).
> 
> How are you testing layout switching? With a custom Windows application
> or some other way?
> 

I did a quick try by calling "setxkbmap fr,us" first, then an 
application which calls ActivateKeyboardLayout(0x040c040c) / 
ActivateKeyboardLayout(0x04090409) from time to time. The char and vkey 
messages are always the one for the fr layout, regardless of the 
XkbLockGroup calls.

I had to tweak a bit the group names because my fr xkb group is actually 
named "French", but I checked that XkbLockGroup is actually called 
correctly when activating layouts back and forth.
-- 
Rémi Bernon <rbernon at codeweavers.com>