- wine-gitlab - winehq.org

[PATCH 0/1] MR1016: ntoskrnl.exe: Implement IoCreateNotificationEvent
by Etaash Mathamsetty (＠etaash.mathamsetty) 08 Oct '22

08 Oct '22

xigncode3 seems to use it -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1016

2 1

[PATCH 0/1] MR1012: xmllite/writer: properly validate DocType name
by David Kahurani (＠kahurani) 07 Oct '22

07 Oct '22

Signed-off-by: David Kahurani <k.kahurani(a)gmail.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1012

3 2

[PATCH v3 0/3] MR414: fltmgr.sys: Implement FltBuildDefaultSecurityDescriptor
by Alistair Leslie-Hughes (＠alesliehughes) 07 Oct '22

07 Oct '22

Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> -- v3: ntoskrnl.exe: Add FltBuildDefaultSecurityDescriptor test fltmgr.sys: Create import library fltmgr.sys: Implement FltBuildDefaultSecurityDescriptor https://gitlab.winehq.org/wine/wine/-/merge_requests/414

3 4

[PATCH v2 0/1] MR1005: ntdll: fixed size passed to GetTempPathW
by Marcus Meissner (＠msmeissn) 06 Oct '22

06 Oct '22

Signed-off-by: Marcus Meissner <marcus(a)jet.franken.de> -- v2: ntdll: Fix GetTempPathW() call passing wrong unit for the buffer size https://gitlab.winehq.org/wine/wine/-/merge_requests/1005

4 4

Re: [PATCH 0/1] MR182: winex11: Use XKB key names to map key codes to scan codes.
by Timo Zuccarello (＠timozuccarello) 06 Oct '22

06 Oct '22

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

1 0

Re: [PATCH 0/1] MR182: winex11: Use XKB key names to map key codes to scan codes.
by Rémi Bernon (＠rbernon) 06 Oct '22

06 Oct '22

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

1 0

Re: [PATCH 0/1] MR182: winex11: Use XKB key names to map key codes to scan codes.
by Timo Zuccarello (＠timozuccarello) 06 Oct '22

06 Oct '22

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

1 0

Re: [PATCH 0/1] MR182: winex11: Use XKB key names to map key codes to scan codes. - closed
by Timo Zuccarello (＠timozuccarello) 06 Oct '22

06 Oct '22

This merge request was closed by Timo Zuccarello. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/182

1 0

[PATCH 0/1] MR1005: ntdll: fixed size passed to GetTempPathW
by Marcus Meissner (＠msmeissn) 06 Oct '22

06 Oct '22

Signed-off-by: Marcus Meissner <marcus(a)jet.franken.de> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1005

3 2

[PATCH 0/1] MR1009: winemenubuilder: Skip desktop integration for certain associations.
by Alex Henrie (＠alexhenrie) 06 Oct '22

06 Oct '22

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=41275 A version of this patch has been in Wine Staging since March 2020. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1009

2 1

2025

2024

2023

2022

wine-gitlab