October 2022 - Wine-gitlab - list.winehq.org

[PATCH 0/7] MR1007: Add some tests for l3codecx.ax
by Anton Baskanov (＠baskanov) 10 Oct '22

10 Oct '22

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/1007

3 8

[PATCH 0/3] MR1019: shell32: Add Active Desktop stub.
by Nikolay Sivov (＠nsivov) 09 Oct '22

09 Oct '22

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1019

3 4

[PATCH 0/4] MR1013: Mostly cleanup
by eric pouech (＠epo) 09 Oct '22

09 Oct '22

clean up of code: - remove usage of wine_dbgstr_longlong() - remove some FIXME - remove stabs's only stuff clean up of mistake: - partially revert one of previous commits (messed up with the tests) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1013

3 6

[PATCH v2 0/2] MR1017: sapi: Implement ISpObjectToken GetId
by Alistair Leslie-Hughes (＠alesliehughes) 08 Oct '22

08 Oct '22

-- v2: sapi: Implement ISpObjectToken GetId sapi: Store the token id in ISpObjectToken SetId. https://gitlab.winehq.org/wine/wine/-/merge_requests/1017

2 2

[PATCH 0/2] MR1017: sapi: Implement ISpObjectToken GetId
by Alistair Leslie-Hughes (＠alesliehughes) 08 Oct '22

08 Oct '22

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/1017

3 3

[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