Re: [PATCH 0/1] MR182: winex11: Use XKB key names to map key codes to scan codes.

[Timo Zuccarello (＠timozuccarello)]

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