Needed for mingw Firefox build.
The WIDL error points to the wrong function, specifically the one after it.
include/windows.ui.composition.interop.idl:35:63: error: parameter 'swapchain' of function 'CreateCompositionSurfaceForHandle' cannot derive from void *
HRESULT CreateCompositionSurfaceForSwapChain([in] IUnknown *swapchain, [out, retval] ICompositionSurface **result); ^ make[1]: *** [Makefile:163749: include/windows.ui.composition.interop.h] Error 1
-- v4: include: Add windows.ui.composition.interop.idl file. widl: Add support for WinRT HANDLE parameter type.
From: Mohamad Al-Jaf mohamadaljaf@gmail.com
Needed by windows.ui.composition.interop.idl. --- tools/widl/typegen.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/tools/widl/typegen.c b/tools/widl/typegen.c index b3373ded11d..270297c3ae7 100644 --- a/tools/widl/typegen.c +++ b/tools/widl/typegen.c @@ -342,6 +342,9 @@ enum typegen_type typegen_detect_type(const type_t *type, const attr_list_t *att return TGT_IFACE_POINTER; else if (is_aliaschain_attr(type_pointer_get_ref_type(type), ATTR_CONTEXTHANDLE)) return TGT_CTXT_HANDLE_POINTER; + else if (type_get_type(type_pointer_get_ref_type(type)) == TYPE_VOID && + (type->name && !strcmp(type->name, "HANDLE"))) + return TGT_CTXT_HANDLE; else return TGT_POINTER; case TYPE_STRUCT:
From: Mohamad Al-Jaf mohamadaljaf@gmail.com
Needed for mingw Firefox build. --- include/Makefile.in | 1 + include/windows.ui.composition.interop.idl | 40 ++++++++++++++++++++++ 2 files changed, 41 insertions(+) create mode 100644 include/windows.ui.composition.interop.idl
diff --git a/include/Makefile.in b/include/Makefile.in index f52314e745d..54d6dca234d 100644 --- a/include/Makefile.in +++ b/include/Makefile.in @@ -838,6 +838,7 @@ SOURCES = \ windows.system.threading.idl \ windows.system.userprofile.idl \ windows.ui.composition.idl \ + windows.ui.composition.interop.idl \ windows.ui.core.idl \ windows.ui.idl \ windows.ui.viewmanagement.idl \ diff --git a/include/windows.ui.composition.interop.idl b/include/windows.ui.composition.interop.idl new file mode 100644 index 00000000000..cde3e62f533 --- /dev/null +++ b/include/windows.ui.composition.interop.idl @@ -0,0 +1,40 @@ +/* + * Copyright (C) 2023 Mohamad Al-Jaf + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA + */ + +#ifdef __WIDL__ +#pragma winrt ns_prefix +#endif + +import "windows.ui.composition.idl"; +import "sdkddkver.h"; + +namespace Windows.UI.Composition { + interface ICompositorInterop; + + [ + object, + uuid(25297d5c-3ad4-4c9c-b5cf-e36a38512330), + pointer_default(unique) + ] + interface ICompositorInterop : IInspectable + { + HRESULT CreateCompositionSurfaceForHandle([in] HANDLE swapchain, [out, retval] ICompositionSurface **result); + HRESULT CreateCompositionSurfaceForSwapChain([in] IUnknown *swapchain, [out, retval] ICompositionSurface **result); + HRESULT CreateGraphicsDevice([in] IUnknown *device, [out, retval] ICompositionGraphicsDevice **result); + }; +}
Hi,
It looks like your patch introduced the new failures shown below. Please investigate and fix them before resubmitting your patch. If they are not new, fixing them anyway would help a lot. Otherwise please ask for the known failures list to be updated.
The tests also ran into some preexisting test failures. If you know how to fix them that would be helpful. See the TestBot job for the details:
The full results can be found at: https://testbot.winehq.org/JobDetails.pl?Key=131812
Your paranoid android.
=== debian11 (32 bit report) ===
imm32: imm32.c:844: Test failed: hwnd is not active imm32.c:852: Test failed: expected WM_IME_SETCONTEXT_DEACTIVATE imm32.c:853: Test failed: expected WM_IME_SETCONTEXT_ACTIVATE imm32.c:861: Test failed: expected WM_IME_SETCONTEXT_DEACTIVATE imm32.c:862: Test failed: expected WM_IME_SETCONTEXT_ACTIVATE imm32.c:874: Test failed: expected WM_IME_SETCONTEXT_DEACTIVATE imm32.c:875: Test failed: expected WM_IME_SETCONTEXT_ACTIVATE imm32.c:885: Test failed: expected WM_IME_SETCONTEXT_DEACTIVATE imm32.c:383: Test failed: unexpected call WM_IME_SETCONTEXT_DEACTIVATE imm32.c:382: Test failed: unexpected call WM_IME_SETCONTEXT_ACTIVATE imm32.c:383: Test failed: unexpected call WM_IME_SETCONTEXT_DEACTIVATE imm32.c:382: Test failed: unexpected call WM_IME_SETCONTEXT_ACTIVATE
On Tue Apr 11 23:04:23 2023 +0000, Mohamad Al-Jaf wrote:
Instead of returning `TGT_CTXT_HANDLE` when type is void, which will
then make void parameters incorrectly succeed some checks, I'd suggest adding some logic in the `TYPE_POINTER` case, checking whether the type is an alias to `void*` which name is `HANDLE`. Checking the name leads to a segmentation fault in dlls/actxprxy. Is the current way fine?
Probably the simplest thing to do, is to add it to the `TYPE_POINTER`
case in check_field_common, to avoid overloading the `TGT_CTXT_HANDLE` meaning, or having to add a specific `TGT_HANDLE` value. I couldn't find `TYPE_POINTER` case in check_field_common, unless you meant `TGT_POINTER`. Regardless, it doesn't seem like it would work because `typegen_detect_type` returns `TGT_INVALID` for TYPE_VOID.
Note that this is a problem only because we're trying to use an IDL
here. As far as I can see, the SDK doesn't have one and uses a .h directly instead (though it's probably fine and cleaner to use an IDL). Yeah, I thought it was preferred to add an IDL if possible. I don't mind doing it either way though.
Sorry, I wasn't thinking clearly earlier, I added a check for the name `HANDLE` and to see if it's NULL before checking it.
On Wed Apr 12 06:01:07 2023 +0000, Mohamad Al-Jaf wrote:
Sorry, I wasn't thinking clearly earlier, I added a check for the name `HANDLE` and to see if it's NULL before checking it.
I think typegen_detect_type returns TGT_POINTER the first time, and then it causes check_field_common to loop and call it again with the pointee.
On Wed Apr 12 06:05:11 2023 +0000, Rémi Bernon wrote:
I think typegen_detect_type returns TGT_POINTER the first time, and then it causes check_field_common to loop and call it again with the pointee.
I'm not really sure what to do in check_field_common. It seems to just be doing error checking. Adding in logic to check whether the type is an alias to `void*` in `TGT_POINTER` and either returning or setting more_to_do as FALSE breaks assertion:
widl: tools/widl/typetree.h:403: type_pointer_get_ref: Assertion `type_get_type(type) == TYPE_POINTER' failed.
In any case, adding in logic to typegen_detect_type seems the easiest way.
In any case, adding in logic to typegen_detect_type seems the easiest way.
Sure but it's incorrect to return `TGT_CTXT_HANDLE_POINTER`, which has more uses than just these checks.
I think something like that in check_field_common works:
```C case TGT_POINTER: if (type_get_type(type_pointer_get_ref_type(type)) != TYPE_VOID || !type->name || strcmp(type->name, "HANDLE")) { type = type_pointer_get_ref_type(type); more_to_do = TRUE; } break; ```
-
Marvin -
Mohamad Al-Jaf -
Mohamad Al-Jaf (＠maljaf)
-
Rémi Bernon (＠rbernon)