On Thu Oct 6 11:01:58 2022 +0000, Rémi Bernon wrote:
Well, I believe it is not necessary in general when
using standard X
server, as I described in
<https://www.winehq.org/pipermail/wine-devel/2020-October/175561.html>,
but that doesn't cover more exotic use cases where the X scancodes
aren't fixed.
Like @julliard replied in that thread, when using VNC X server for
instance the scancodes aren't fixed anymore and we need that logic to
figure them out. The problem, in my opinion, comes from VNC simulating
incorrect scancodes, as it recomputes them from the VKey it received
(the protocol only sends VKey and and it then assumes its client
keyboard layout is US), but I agree that nothing in the X specification
guarantees that the scancodes are fixed and that it makes some sense to
do that kind of detection.
Maybe an acceptable solution would be to make that layout detection
optional, and configurable through a `winecfg` option, so that by
default we'd assume a standard X server with fixed scancodes, and
optionally we'd keep support for layout detection (or the other way
around but I think improving the most common case as a default would be better).
I just went through the email thread (I'm still new to navigating
pipermail/mailing list archives) and I see the point, although I don't think I can
entirely grasp what VNC does. But the way I understand it is that even if we used XKB
names for the scan codes as in this MR, those would be messed up just as well when using a
VNC X server, as it maps backwards from vkeys to scan codes?
In the XKB specification/documentation, "The key name links keys with similar
functions or in similar positions on keyboards that report different scan codes",
which gets me wondering how Windows actually handles exotic keyboards or rather what is
common practice in the drivers for said exotic keyboards.
In any case, I agree, I suppose optional layout detection would be the most compatible
solution for now at least.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/182#note_10036