November 2021 - Wine-Devel - list.winehq.org

Re: Add xinputuap.dll

by Marvin

Hi, While running your changed tests, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at: https://testbot.winehq.org/JobDetails.pl?Key=101124 Your paranoid android. === debiant2 (build log) === error: patch failed: configure:1 error: patch failed: configure.ac:3473 Task: Patch failed to apply === debiant2 (build log) === error: patch failed: configure:1 error: patch failed: configure.ac:3473 Task: Patch failed to apply

Nov. 1, 2021

Re: [PATCH v4 1/3] uiautomationcore: Implement UiaGetReservedNotSupportedValue.

by Nikolay Sivov

On 10/29/21 4:43 PM, Connor McAdams wrote: > +struct uia_rsrv_obj_marshal_wrapper > +{ > + IUnknown IUnknown_iface; > + LONG refcount; > + > + IUnknown *marshaler; > + IUnknown *marshal_object; > +}; > + > +static struct uia_rsrv_obj_marshal_wrapper *impl_uia_rsrv_obj_marshal_wrapper_from_IUnknown(IUnknown *iface) > +{ > + return CONTAINING_RECORD(iface, struct uia_rsrv_obj_marshal_wrapper, IUnknown_iface); > +} > +static HRESULT uia_rsrv_obj_create_marshal_wrapper(IUnknown *reserved, void **ppv) > +{ Other than naming, I think this looks good now. I'm not sure if this is waiting for someone to sign off.

Nov. 1, 2021

Re: [PATCH 2/4] mfreadwrite/tests: Add some video media type attributes tests.

by Nikolay Sivov

On 10/28/21 5:01 PM, Rémi Bernon wrote: > + UINT32 uint32_value, buffer_value_size, width = expect->width, height = expect->height; > + BOOL is_h264 = IsEqualGUID(&expect->subtype, &MFVideoFormat_H264); > + BYTE buffer_value[512]; > + UINT64 uint64_value; > + GUID guid_value; > + HRESULT hr; > + > + memset(&guid_value, 0xcd, sizeof(guid_value)); > + hr = IMFMediaType_GetGUID(media_type, &MF_MT_MAJOR_TYPE, &guid_value); > + ok(hr == S_OK, "missing MF_MT_MAJOR_TYPE, hr %#x\n", hr); > + ok(IsEqualGUID(&guid_value, &MFMediaType_Video), "got MF_MT_MAJOR_TYPE %s\n", debugstr_guid(&guid_value)); > + > + memset(&guid_value, 0xcd, sizeof(guid_value)); > + hr = IMFMediaType_GetGUID(media_type, &MF_MT_SUBTYPE, &guid_value); > + ok(hr == S_OK, "missing MF_MT_SUBTYPE, hr %#x\n", hr); > + todo_wine_if(is_h264) > + ok(IsEqualGUID(&guid_value, &expect->subtype), "got MF_MT_SUBTYPE %s\n", debugstr_guid(&guid_value)); > + > + uint32_value = 0xdeadbeef; > + hr = IMFMediaType_GetUINT32(media_type, &MF_MT_ALL_SAMPLES_INDEPENDENT, &uint32_value); > + if (is_h264) > + { > + todo_wine > + ok(hr == MF_E_ATTRIBUTENOTFOUND, "got MF_MT_ALL_SAMPLES_INDEPENDENT, hr %#x\n", hr); > + } > + else > + { > + ok(hr == S_OK, "missing MF_MT_ALL_SAMPLES_INDEPENDENT, hr %#x\n", hr); > + ok(uint32_value == 1, "got MF_MT_ALL_SAMPLES_INDEPENDENT %u\n", uint32_value); > + } It's certainly possible decoders differ in attributes they use, but here what matters is compressed/uncompressed distinction, and not whether it's H264 or not, I think. So turning this in two paths, with possibility to add more format-specific checks for compressed part, will make this more compact and easy to follow.

Nov. 1, 2021

Add xinputuap.dll

by Yusuf Khan

Nov. 1, 2021

Re: [PATCH 1/4] mfreadwrite/tests: Add some audio media type attributes tests.

by Nikolay Sivov

On 10/28/21 5:01 PM, Rémi Bernon wrote: > +struct audio_format > +{ > + GUID subtype; > + UINT32 bits; > + UINT32 rate; > +}; > + > +static void test_audio_media_type(const char *resource_name, IMFMediaType *media_type, struct audio_format *expect) > +{ > + UINT32 uint32_value, buffer_value_size; > + BYTE buffer_value[512]; > + double double_value; > + GUID guid_value; > + HRESULT hr; > + > + memset(&guid_value, 0xcd, sizeof(guid_value)); > + hr = IMFMediaType_GetGUID(media_type, &MF_MT_MAJOR_TYPE, &guid_value); > + ok(hr == S_OK, "missing MF_MT_MAJOR_TYPE, hr %#x\n", hr); > + ok(IsEqualGUID(&guid_value, &MFMediaType_Audio), "got MF_MT_MAJOR_TYPE %s\n", debugstr_guid(&guid_value)); > + > + memset(&guid_value, 0xcd, sizeof(guid_value)); > + hr = IMFMediaType_GetGUID(media_type, &MF_MT_SUBTYPE, &guid_value); > + ok(hr == S_OK, "missing MF_MT_SUBTYPE, hr %#x\n", hr); > + ok(IsEqualGUID(&guid_value, &expect->subtype), "got MF_MT_SUBTYPE %s\n", debugstr_guid(&guid_value)); > + > + uint32_value = 0xdeadbeef; > + hr = IMFMediaType_GetUINT32(media_type, &MF_MT_ALL_SAMPLES_INDEPENDENT, &uint32_value); > + ok(hr == S_OK, "missing MF_MT_ALL_SAMPLES_INDEPENDENT, hr %#x\n", hr); > + ok(uint32_value == 1, "got MF_MT_ALL_SAMPLES_INDEPENDENT %u\n", uint32_value); > + > + hr = IMFMediaType_GetGUID(media_type, &MF_MT_AM_FORMAT_TYPE, &guid_value); > + ok(hr == MF_E_ATTRIBUTENOTFOUND, "got MF_MT_AM_FORMAT_TYPE, hr %#x\n", hr); > + hr = IMFMediaType_GetUINT32(media_type, &MF_MT_COMPRESSED, &uint32_value); > + ok(hr == MF_E_ATTRIBUTENOTFOUND, "got MF_MT_COMPRESSED, hr %#x\n", hr); > + hr = IMFMediaType_GetUINT32(media_type, &MF_MT_FIXED_SIZE_SAMPLES, &uint32_value); > + ok(hr == MF_E_ATTRIBUTENOTFOUND, "got MF_MT_FIXED_SIZE_SAMPLES, hr %#x\n", hr); > + hr = IMFMediaType_GetUINT32(media_type, &MF_MT_SAMPLE_SIZE, &uint32_value); > + ok(hr == MF_E_ATTRIBUTENOTFOUND, "got MF_MT_SAMPLE_SIZE, hr %#x\n", hr); > + hr = IMFMediaType_GetBlob(media_type, &MF_MT_USER_DATA, buffer_value, sizeof(buffer_value), &buffer_value_size); > + ok(hr == MF_E_ATTRIBUTENOTFOUND, "got MF_MT_USER_DATA, hr %#x\n", hr); > + hr = IMFMediaType_GetBlob(media_type, &MF_MT_WRAPPED_TYPE, buffer_value, sizeof(buffer_value), &buffer_value_size); > + ok(hr == MF_E_ATTRIBUTENOTFOUND, "got MF_MT_WRAPPED_TYPE, hr %#x\n", hr); > + > Is it possible to test attribute count instead, and then all attributes up to this count? Instead of testing what type doesn't have set.

Nov. 1, 2021

Re: [PATCH v5 6/7] gdi32: allow passing BITMAPINFO with bmiHeader.biSizeImage == 0 for EMF DC.

by Jacek Caban

On 11/1/21 6:31 AM, Jinoh Kang wrote: > + UINT elm_size = coloruse == DIB_PAL_COLORS ? sizeof(WORD) : sizeof(DWORD); > + UINT colours = dst->biClrUsed; > + > + if (colours > UINT_MAX / elm_size) > + return FALSE; Should we use at most 1 << bpp entries here? Thanks, Jacek

Nov. 1, 2021

Re: [PATCH v5 3/7] win32u: fix return value of StretchDIBits for EMF DC.

by Jacek Caban

Hi Jinoh, On 11/1/21 6:30 AM, Jinoh Kang wrote: > Signed-off-by: Jinoh Kang <jinoh.kang.kr(a)gmail.com> > --- > dlls/win32u/emfdrv.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dlls/win32u/emfdrv.c b/dlls/win32u/emfdrv.c > index e05f11d7b9a..395d51048d8 100644 > --- a/dlls/win32u/emfdrv.c > +++ b/dlls/win32u/emfdrv.c > @@ -408,7 +408,7 @@ static INT CDECL EMFDRV_StretchDIBits( PHYSDEV dev, INT x_dst, INT y_dst, INT wi > UINT wUsage, DWORD dwRop ) > { > /* FIXME: Update bound rect */ > - return height_src; > + return abs( info->bmiHeader.biHeight ); > } > > static INT CDECL EMFDRV_SetDIBitsToDevice( PHYSDEV dev, INT x_dst, INT y_dst, DWORD width, For this and the next patch, you could simply remove EMFDRV_StretchDIBits and EMFDRV_SetDIBitsToDevice and let the null driver take care of it. I originally left it because of bound rect update (that's supposed to happen in win32u instead of of gdi32), but that doesn't seem worth keeping it now. Thanks, Jacek

Nov. 1, 2021

Re: [PATCH 3/3] wined3d: Factor out buffer bo_user invalidation.

by Zebediah Figura (she/her)

On 11/1/21 09:20, Henri Verbeet wrote: > On Wed, 20 Oct 2021 at 07:28, Zebediah Figura <zfigura(a)codeweavers.com> wrote: >> +static void adapter_gl_destroy_bo(struct wined3d_context *context, struct wined3d_bo *bo) >> +{ >> + struct wined3d_context_gl *context_gl = wined3d_context_gl(context); >> + struct wined3d_bo_gl *bo_gl = wined3d_bo_gl(bo); >> + >> + if (context_gl->c.transform_feedback_active && bo_gl->binding == GL_TRANSFORM_FEEDBACK_BUFFER >> + && wined3d_context_is_graphics_state_dirty(&context_gl->c, STATE_STREAM_OUTPUT)) >> + { >> + /* It's illegal to (un)bind GL_TRANSFORM_FEEDBACK_BUFFER while transform >> + * feedback is active. Deleting a buffer implicitly unbinds it, so we >> + * need to end transform feedback here if this buffer was bound. >> + * >> + * This should only be possible if STATE_STREAM_OUTPUT is dirty; if we >> + * do a draw call before destroying this buffer then the draw call will >> + * already rebind the GL target. */ >> + WARN("Deleting buffer object %p, disabling transform feedback.\n", bo_gl); >> + wined3d_context_gl_end_transform_feedback(context_gl); >> + } >> + > Is there any particular reason this belongs in adapter_gl_destroy_bo() > instead of wined3d_context_gl_destroy_bo()? > >> +static void adapter_vk_destroy_bo(struct wined3d_context *context, struct wined3d_bo *bo) >> +{ >> + struct wined3d_bo_vk *bo_vk = wined3d_bo_vk(bo); >> + >> + wined3d_context_vk_destroy_bo(wined3d_context_vk(context), bo_vk); >> + bo_vk->vk_buffer = VK_NULL_HANDLE; >> + bo_vk->memory = NULL; >> +} >> + > Similarly, it seems somewhat arbitrary to clear the "vk_buffer" and > "memory" fields in adapter_vk_destroy_bo() instead of > wined3d_context_vk_destroy_bo(). The answer to both of these is "well, wined3d_context_*_destroy_bo() didn't already do those things". That could be changed, though. > >> @@ -3370,6 +3380,7 @@ struct wined3d_adapter_ops >> const struct wined3d_bo_address *dst, const struct wined3d_bo_address *src, size_t size); >> void (*adapter_flush_bo_address)(struct wined3d_context *context, >> const struct wined3d_const_bo_address *data, size_t size); >> + void (*adapter_destroy_bo)(struct wined3d_context *context, struct wined3d_bo *bo); >> HRESULT (*adapter_create_swapchain)(struct wined3d_device *device, >> struct wined3d_swapchain_desc *desc, >> struct wined3d_swapchain_state_parent *state_parent, void *parent, >> @@ -4982,8 +4993,6 @@ struct wined3d_buffer_ops >> { >> BOOL (*buffer_prepare_location)(struct wined3d_buffer *buffer, >> struct wined3d_context *context, unsigned int location); >> - void (*buffer_unload_location)(struct wined3d_buffer *buffer, >> - struct wined3d_context *context, unsigned int location); >> void (*buffer_upload_ranges)(struct wined3d_buffer *buffer, struct wined3d_context *context, const void *data, >> unsigned int data_offset, unsigned int range_count, const struct wined3d_range *ranges); >> void (*buffer_download_ranges)(struct wined3d_buffer *buffer, struct wined3d_context *context, void *data, > > Is that the direction we want to go in? The original idea was to unify > wined3d_buffer_ops and wined3d_texture_ops, and then merge them into > wined3d_resource_ops. If there are additional reasons to introduce > adapter_destroy_bo(), perhaps that's fine though. > I guess not really. I don't think I had a particular reason for this commit except to effect some deduplication. Of course we could do a similar thing with textures, but there are quite a few more locations to deal with... I'll just drop the patch.

Nov. 1, 2021

Re: [PATCH 6/7] mshtml: Implement inline attributes parsing for createElement.

by Gabriel Ivăncescu

Ok so, I actually can't seem to solve this using either suggestion. First, Node.cloneNode seems to copy the entire element, unless I'm missing something. But what I need is to clone just the attributes of the DUMMYTAG element into the proper element, for example: Input: <div test="a"> What happens: SetInnerHTML('<body><dummytag test="a"/></body>') Create a "div" element, and copy all attrs (test) from dummytag to it Return the "div" element, which now has the "test" attribute How can I do this with cloneNode since it must copy to different element type? Now the second suggestion: if I use SetInnerHTML directly to the parsed tag element, it will fail to work for some of the html elements. I notice that the html element then contains <head> and <body> already, even if it just parses a div. I figured I could search for <body> and then get its child. But that's not gonna work for some of those pre-defined elements. How can I handle a <head>, <body> or <html> element parse in such situation? Do you have any ideas? Thanks, Gabriel

Nov. 1, 2021

Re: [PATCH v2] msvcrt: Don't use GetDaylightFlag function in _ftime64.

by Piotr Caban

On 11/1/21 6:15 PM, Zebediah Figura (she/her) wrote: > On 11/1/21 11:58, Piotr Caban wrote: >> On 11/1/21 5:37 PM, Zebediah Figura wrote: >>> On 11/1/21 9:07 AM, Piotr Caban wrote: >>>> >>>> The function is not available on current Windows releases. >>>> >>>> Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51959 >>>> Signed-off-by: Piotr Caban <piotr(a)codeweavers.com> >>>> --- >>>> dlls/msvcrt/time.c | 5 ++--- >>>> 1 file changed, 2 insertions(+), 3 deletions(-) >>>> >>>> >>> >>> This was added in the first place to avoid the overhead of loading >>> tzres.dll. Is that no longer a concern? >>> >> It's just copying body of GetDaylightFlag function to msvcrt. There's >> no change regarding tzres.dll being loaded. >> >> If GetTimeZoneInformation performance is a concern we should probably >> avoid calling it too often. > > Hrm, that's true. I distinctly remember 2efc73b96811 being an > alternative to caching the time zone information (cf [1]), but on > examination it was a no-op even then... > > [1] https://www.winehq.org/pipermail/wine-devel/2018-December/137085.html We're currently caching time zone name in GetDynamicTimeZone information, so it should no longer be a problem. GetDaylightFlag was using RtlQueryTimeZoneInformation to avoid localized time zone name lookup.

Nov. 1, 2021