On Tue Apr 7 21:17:37 2026 +0000, Rémi Bernon wrote:
Well, I don't know about modifying the current code, or even about trying to shoehorn it into the new KBDTABLE mechanism. I would personally just leave it to die, and introduce the new proper layout detection, until a point where we can switch over to using it by default, possibly guarded with some registry configuration option if we're still still unsure about it. This way we can decide to keep it or ditch it depending on actual reported use cases, possibly ditch it after fixing the issues with the new mechanism. I know I mentioned something about VNC before, but after checking again the issue isn't so much about layout detection and I think things should work as well (or as badly) as they are now. The detection is broken with VNC already with the current code, this is because VNC doesn't pass through keyboard layout information and simply exposes a server-side configured XKB layout to the applications. By default this is a single US keyboard, but it can be changed with setxkbmap as well. When VNC receives a key even, it remaps the keycode to whichever keycode would have generate that keysym with its layout. This means that if you have a FR client layout, and an US server layout, Wine will detect the layout as US too. The keycodes sent from the client would be the FR keycode, but they would be remapped by the XVNC server to match the keysym, and Wine would use keycode / keysym matching an US layout. As they are remapped by the XVNC server keysym would still correctly match whatever the user is typing. The only issues would be about key positions, for any application that relies on the keyboard physical layout. Note that this issue already exists with the current code, it is a problem coming from the VNC layout remapping and not something Wine can do anything about. By the end of the branch, the only thing left of the old code is `X11DRV_KEYBOARD_DetectLayout()`, which eventually calls `create_layout_from_xkb()` thus creating a `struct layout` which contains the `KBDTABLE` filled exactly the same as via the xkbregistry code path. Effectively the only difference with xkb + registry should be where the layout and variant names come from. It doesn't seem to me like it's super ugly, but I'm sure we can disagree here :sweat_smile: I could certainly add a registry key to force the old vs new detection code temporarily, for testing regressions while we switch the default to the new one.
WRT vncserver, that's what I've seen as well. I'm only checking with that to make sure things don't get any worse. FWIW, for me tightvnc's vncserver crashes with current Wine because it doesn't support Xshape while Wine is using it unconditionally. I have one patch in the branch to fix that so that I can test vncserver. I haven't decided whether to upstream it or not: wondering if other people don't run into it for some reason or if it was a conscious decision to not handle the case where Xshape is supported at compile time but not at runtime. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10550#note_135645