On Thu Oct 6 11:01:52 2022 +0000, Timo Zuccarello wrote:
> After last day's discussion, I don't think anymore that it's necessary
> to use XKB names to map to scancodes. @rbernon says the keycodes are
> fixed across keyboard layouts and this seems to be the case for me as
> well even with exotic and custom layouts. Rather something about the
> keyboard layout detection may be broken and assigns incorrect scancodes.
> I'll take another look at this and try to figure something out.
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).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/182#note_10034
After last day's discussion, I don't think anymore that it's necessary to use XKB names to map to scancodes. @rbernon says the keycodes are fixed across keyboard layouts and this seems to be the case for me as well even with exotic and custom layouts. Rather something about the keyboard layout detection may be broken and assigns incorrect scancodes. I'll take another look at this and try to figure something out.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/182#note_10032
relative optional parameter will now be handled by setting the RelativeName of the relative struct to NT converted and collapsed relative path and the ContainingDirectory to an open handle of current working directory. CurDir is currently not implemented.
--
v5: ntdll/tests: Tests for RtlDosPathNameToRelativeNtPathName_U_WithStatus
ntdll: Implement handling of relative in RtlDosPathNameToRelativeNtPathName_U_WithStatus
https://gitlab.winehq.org/wine/wine/-/merge_requests/1004
relative optional parameter will now be handled by setting the RelativeName of the relative struct to NT converted and collapsed relative path and the ContainingDirectory to an open handle of current working directory. CurDir is currently not implemented.
--
v4: ntdll/tests: Corrected and refactored tests
https://gitlab.winehq.org/wine/wine/-/merge_requests/1004