September 2022 - wine-gitlab

[PATCH 0/1] MR841: ntoskrnl: processor change callback stubs
by Etaash Mathamsetty (＠etaash.mathamsetty) 13 Sep '22

13 Sep '22

required for mrac anti cheat -- https://gitlab.winehq.org/wine/wine/-/merge_requests/841

2 1

[PATCH 0/1] MR839: ntoskrnl: fix bug with MmGetSystemRoutineAddress
by Etaash Mathamsetty (＠etaash.mathamsetty) 13 Sep '22

13 Sep '22

MmGetSystemRoutineAddress wasn't finding some functions in ntoskrnl and hal.dll, this patch fixes it required by mrac anti cheat -- https://gitlab.winehq.org/wine/wine/-/merge_requests/839

3 2

[PATCH 0/1] MR840: ntoskrnl: KeSetTargetProcessorDpcEx stub
by Etaash Mathamsetty (＠etaash.mathamsetty) 13 Sep '22

13 Sep '22

required by mrac anti cheat -- https://gitlab.winehq.org/wine/wine/-/merge_requests/840

2 1

[PATCH v2 0/6] MR791: mf: Test AAC encoder / decoder presence, begin factoring some transform tests.
by Rémi Bernon (＠rbernon) 13 Sep '22

13 Sep '22

-- v2: mf/tests: Factor IMFTransform required attributes checks together. mf/tests: Test AAC decoder MFT presence and media types. mf/tests: Test AAC encoder MFT presence and media types. mf/tests: Split create_transform into check_(mft|dmo)_(enum|get_info). mf/tests: Add some winetest context to MFT tests. mf/tests: Split IMFTransform tests to transform.c. https://gitlab.winehq.org/wine/wine/-/merge_requests/791

3 8

Re: [PATCH v5 0/1] MR826: wined3d: Add support for Renoir GPUs
by Henri Verbeet (＠hverbeet) 13 Sep '22

13 Sep '22

> As far as I can tell it was changed (perhaps inadvertently) by Mesa commit 0cb42c57c569443b0af8296dfff4da1e6ab241ef. Previously "AMD" string would be present in the renderer string for cases where there was no marketing name (i.e. Etaash's gpu would have a GL_RENDERER value beginning with "AMD RENOIR"). Looks plausible enough; ideally we'd get that fixed. > As far as I can tell, radeonsi has only ever reported a GL_VENDOR of "X.org" or (more recently) "AMD", so we've been relying on "AMD" being present in the renderer string. It's slightly worse, actually. Cards with a "marketing" name will have a renderer string like "Radeon RX Vega (VEGA10, ...)", so for these we'd depend on the "Radeon"/"FirePro" strings. If the vendor string now includes "AMD" we'd certainly want to use that; in that regard the original commit is fine. > It may also be a good idea to try matching the card vendor based on the PCI vendor first; I imagine that will remain a bit more stable against changes like this. Yes, I think that would be helpful. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/826#note_8323

2 1

[PATCH v6 0/1] MR777: ntoskrnl: MmAllocateContiguousMemorySpecifyCache semi-stub
by Etaash Mathamsetty (＠etaash.mathamsetty) 13 Sep '22

13 Sep '22

This should help to get the nox android emulator to run fixes bug https://bugs.winehq.org/show_bug.cgi?id=46760 -- v6: ntoskrnl: MmAllocateContiguousMemorySpecifyCache semi-stub https://gitlab.winehq.org/wine/wine/-/merge_requests/777

4 5

Re: [PATCH v5 0/1] MR826: wined3d: Add support for Renoir GPUs
by Etaash Mathamsetty (＠etaash.mathamsetty) 13 Sep '22

13 Sep '22

On Tue Sep 13 15:10:00 2022 +0000, Henri Verbeet wrote: > > As far as I can tell it was changed (perhaps inadvertently) by Mesa > commit 0cb42c57c569443b0af8296dfff4da1e6ab241ef. Previously "AMD" string > would be present in the renderer string for cases where there was no > marketing name (i.e. Etaash's gpu would have a GL_RENDERER value > beginning with "AMD RENOIR"). > Looks plausible enough; ideally we'd get that fixed. > > As far as I can tell, radeonsi has only ever reported a GL_VENDOR of > "X.org" or (more recently) "AMD", so we've been relying on "AMD" being > present in the renderer string. > It's slightly worse, actually. Cards with a "marketing" name will have a > renderer string like "Radeon RX Vega (VEGA10, ...)", so for these we'd > depend on the "Radeon"/"FirePro" strings. If the vendor string now > includes "AMD" we'd certainly want to use that; in that regard the > original commit is fine. > > It may also be a good idea to try matching the card vendor based on > the PCI vendor first; I imagine that will remain a bit more stable > against changes like this. > Yes, I think that would be helpful. I modified the PR to use the PCI id yesterday, so there's no need to "guess" which card this is anymore, and it works as expected. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/826#note_8343

1 0

[PATCH v3 0/8] MR814: win32u: Avoid copies in display adapter settings logic.
by Rémi Bernon (＠rbernon) 13 Sep '22

13 Sep '22

As well as a few other fixes for https://gitlab.winehq.org/wine/wine/-/merge_requests/551. -- v3: win32u: Introduce a new internal WINE_DM_UNSUPPORTED display flag. win32u: Pass adapter parameter to (read|write)_registry_settings. win32u: Avoid unnecessary copy of adapter path and device name. win32u: Avoid copying the modes array in NtUserChangeDisplaySettings. win32u: Introduce reference counting to struct adapter. win32u: Fill the local full_mode variable instead of using the modes array. win32u: Rename get_full_mode variables and avoid using devmode directly. wineandroid.drv: Add missing DM_DISPLAYORIENTATION flag on display mode. https://gitlab.winehq.org/wine/wine/-/merge_requests/814

3 9

[PATCH 0/3] MR838: Improvement for inline context debug information.
by eric pouech (＠epo) 13 Sep '22

13 Sep '22

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

2 3

[PATCH v5 0/8] MR795: mshtml: Implement Storage Events.
by Gabriel Ivăncescu (＠insn) 13 Sep '22

13 Sep '22

This implements sending StorageEvents to the same window/doc from where the storage change happened, which seems to be a thing on native IE. For some reason I was unable to have them actually sent to other windows, so that's not implemented since I've no idea how that even gets triggered to test it, and if it does it will probably be in a follow up MR, even though that's *supposed* to be the use of these events�� localStorage sends for `onstoragecommit` on the doc that did the change, while sessionStorage sends for `onstorage` on the window and doc that did the change, depending on compat mode. Although the event sent to the document's `onstorage` seems to be a legacy/old-style event (as tests show). Tests are on the last patch since events have to be sent properly (else it hangs). -- v5: mshtml: Send StorageEvents to iframe windows properly. mshtml: Don't expose document.onstorage for IE9+ modes. mshtml/tests: Add tests for StorageEvents with parallel documents. mshtml: Send StorageEvents when removing an existing item. mshtml: Send StorageEvents when setting an item. mshtml: Implement StorageEvent and send it when clearing the storage. mshtml: Move the MessageEvent construction to a helper. include/mshtml: Add IDOMStorageEvent and DispDOMStorageEvent interfaces. https://gitlab.winehq.org/wine/wine/-/merge_requests/795

4 23

2025

2024

2023

2022

wine-gitlab September 2022