On 4/24/21 8:43 PM, Dmitry Timoshkov wrote:
Rémi Bernon rbernon@codeweavers.com wrote:
- 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.
- 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.