There is a working in progress winegstreamer muxer backend: !3303
This patch set is the windows api side(frontend) of the muxer stuff.
It will make the patch set too large to submit the backend and frontend together, so I decide to submit the frontend first.
--
v4: winegstreamer: Add async command handling to media sink.
winegstreamer: Add IMFClockStateSink stubs to media sink.
winegstreamer: Implement IMFMediaEventGenerator for media sink.
winegstreamer: Add IMFMediaTypeHandler stubs to stream sink.
winegstreamer: Implement IMFMediaEventGenerator for stream sink.
winegstreamer: Add stubs for stream sink.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3528
There is a working in progress winegstreamer muxer backend: !3303
This patch set is the windows api side(frontend) of the muxer stuff.
It will make the patch set too large to submit the backend and frontend together, so I decide to submit the frontend first.
--
v3: winegstreamer: Add async command handling to media sink.
winegstreamer: Add IMFClockStateSink stubs to media sink.
winegstreamer: Implement IMFMediaEventGenerator for media sink.
winegstreamer: Add IMFMediaTypeHandler stubs to stream sink.
winegstreamer: Implement IMFMediaEventGenerator for stream sink.
winegstreamer: Add stubs for stream sink.
winegstreamer: Add stubs for media sink.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3528
There is a working in progress winegstreamer muxer backend: !3303
This patch set is the windows api side(frontend) of the muxer stuff.
It will make the patch set too large to submit the backend and frontend together, so I decide to submit the frontend first.
--
v2: winegstreamer: Add async command handling to media sink.
winegstreamer: Add IMFClockStateSink stubs to media sink.
winegstreamer: Implement IMFMediaEventGenerator for media sink.
winegstreamer: Add IMFMediaTypeHandler stubs to stream sink.
winegstreamer: Add stubs for stream sink.
winegstreamer: Add stubs for media sink.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3528
I'm not sure how could I test this behavior, right now the test I wrote works but there are times where it doesn't enter into the deadlock.
--
v6: evr: Remove process input handling from streaming thread.
evr: Don't lock presenter allocator when calling NotifyRelease
https://gitlab.winehq.org/wine/wine/-/merge_requests/3319
This comes from behavioral study of Windows, which doesn't seem to check if the
lock is actually exclusively held, and just simply decrement the value stored
in the lock.
This fixes a dead lock which prevents WeCom from starting up.
--
v9: ntdll: An implementation of SRWLOCK that closer matches Windows'.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3504
This comes from behavioral study of Windows, which doesn't seem to check if the
lock is actually exclusively held, and just simply decrement the value stored
in the lock.
This fixes a dead lock which prevents WeCom from starting up.
--
v8: ntdll: An implementation of SRWLOCK that closer matches Windows'.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3504
This comes from behavioral study of Windows, which doesn't seem to check if the
lock is actually exclusively held, and just simply decrement the value stored
in the lock.
This fixes a dead lock which prevents WeCom from starting up.
--
v6: ntdll: An implementation of SRWLOCK that closer matches Windows'.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3504
This comes from behavioral study of Windows, which doesn't seem to check if the
lock is actually exclusively held, and just simply decrement the value stored
in the lock.
This fixes a dead lock which prevents WeCom from starting up.
--
v7: ntdll: An implementation of SRWLOCK that closer matches Windows'.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3504
There was talk about having a shared library to allow reuse of common code between each DirectX version.
Here is a proof of concept, for a single shared function between Dx10 and 11.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3481
This comes from behavioral study of Windows, which doesn't seem to check if the
lock is actually exclusively held, and just simply decrement the value stored
in the lock.
This fixes a dead lock which prevents WeCom from starting up.
--
v5: ntdll: An implementation of SRWLOCK that closer matches Windows'.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3504
Particularly it implements '/logonid' and '/user' options,
as well as adds stubs for '/upn' and '/fqdn'.
--
v6: whoami: Refactor and add more commands.
secur32: Add stub message for unimplemented name types in GetUserNameExW.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3473
lParam being NULL is handled in win32u/defwnd.c so make sure to pass the NULL through rather than relying on the pointer always being valid since it may not be in this case.
--
v2: wow64win: Skip WM_CREATE/WM_NCCREATE lParam conversion if NULL
https://gitlab.winehq.org/wine/wine/-/merge_requests/3314
Nikolay Sivov (@nsivov) commented about dlls/evr/sample.c:
> }
>
> IMFSample_Release(sample);
> -
> - if (allocator->callback)
> - IMFVideoSampleAllocatorNotify_NotifyRelease(allocator->callback);
> + callback = allocator->callback;
>
> LeaveCriticalSection(&allocator->cs);
>
> + if (callback)
> + IMFVideoSampleAllocatorNotify_NotifyRelease(allocator->callback);
> +
> return S_OK;
This is public API, and NotifyRelease() is blocking on Windows. What I suggested was to create some customized version of this, just for internal use. For example conditionally, or with a different Invoke() method implementation, whatever looks better.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3319#note_41781
Nikolay Sivov (@nsivov) commented about dlls/evr/presenter.c:
> WARN("Failed to get a backbuffer, hr %#lx.\n", hr);
> }
>
> - EnterCriticalSection(&presenter->cs);
> + EnterCriticalSection(&presenter->thread.queue.cs);
> if (presenter->thread.queue.last_presented)
> IMFSample_Release(presenter->thread.queue.last_presented);
> presenter->thread.queue.last_presented = sample;
> IMFSample_AddRef(presenter->thread.queue.last_presented);
> - LeaveCriticalSection(&presenter->cs);
> + LeaveCriticalSection(&presenter->thread.queue.cs);
Let's add a local variable for a queue pointer to make this more readable.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3319#note_41780
Needed by Underworld Island (Steam ID: 2150830) to skip videos properly.
--
v2: mfmediaengine: Implement media_engine_GetSeekable().
mfmediaengine/tests: Test IMFMediaEngine::GetSeekable().
mfmediaengine/tests: Fix a test failure in test_GetDuration().
https://gitlab.winehq.org/wine/wine/-/merge_requests/3536
I tried build a real Windows application (mimikatz) and had troubles with some wine headers incompatibility. The patch set improves headers to allow build the foreign application with Wine.
--
v5: include: Add standalone LSA_OBJECT_ATTRIBUTES prototype if ntdef.h is not included.
include: Add initial activeds.h.
include: Add missed PCWCHAR to winnt.h.
include: Include ncrypt.h in wincrypt.h.
include: Add specstrings_strict.h with some defines.
include: Use compatible file guard name (_NTSECAPI_, _NTSECPKG_).
include: Add some missed defines.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3506
On Wed Aug 9 04:43:08 2023 +0000, Mohamad Al-Jaf wrote:
> I thought I did add `WindowsDeleteString`. I wasn't sure if adding
> `WindowsDuplicateString` to `device_statics2_CreateWatcher` should be in
> the same commit or not. I added it in a new commit.
> Thanks for the review.
If you want to put it in a separate commit, it should probably come first, with the field addition and the `WindowsDeleteString` call. Otherwise when `device_statics2_CreateWatcher` was used, `Release` will call `WindowsDeleteString` on destruction with an invalid filter (though perhaps zero-initialized HSTRING is valid, but imho it'd be better that way).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3519#note_41752
There is a working in progress winegstreamer muxer backend: !3303
This patch set is the windows api side(frontend) of the muxer stuff.
It will make the patch set too large to submit the backend and frontend together, so I decide to submit the frontend first.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3528
On Tue Aug 8 20:11:16 2023 +0000, Esme Povirk wrote:
> Wouldn't this be implied by the transitive property?
I based this off the checks in `test_tiff_properties`, which did all three checks.
I could certainly remove one to avoid redundancy.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3524#note_41713
Recap:
I implemented relative addressing in !229, but I was suggested to handle register indexes by moving all the registers to the heap, which I did in my [nonconst-offsets-6](https://gitlab.winehq.org/fcasas/vkd3d/-/commits/noncon… branch. A part of this implementation required !269, but I was asked to try to turn the sm4 register structs into the vkd3d-shader register structs instead, to get closer to a common low level IR.
This is the first part of that transformation. The whole thing is in my [use_vkd3d_reg_4](https://gitlab.winehq.org/fcasas/vkd3d/-/commits/use_vkd3d… branch.
~~This is built on top of !225 (the first two patches), so it may be good to get that upstream first.~~
---
This patch series aims to do the following replacements:
```
struct sm4_register -> struct vkd3d_shader_register
struct sm4_dst_register -> struct vkd3d_shader_dst_param
struct sm4_src_register -> struct vkd3d_shader_src_param
```
to get us closer to a common level IR and simplify the implementation of relative-addressing.
To achieve this, the fields in the sm4 register structs are replaced with fields in the vkd3d-shader structs or removed altogether, one at the time.
As can be seen when looking at the whole branch, it is possible to do this transformation without having to add additional fields to `struct vkd3d_shader_register`, by restricting each register type to a single `enum vkd3d_sm4_dimension` (and its src registers to a single `enum vkd3d_sm4_swizzle_type`) by default.
The only exception we need so far is for sampler registers: They always have dimension NONE, except when used as arguments of gather instructions, in which case they have dimension VEC4 and SCALAR swizzle. This, and similar exceptions we may find in the future, can be handled using the opcode_info, as in 7/8 [81e17506](https://gitlab.winehq.org/fcasas/vkd3d/-/commit/81e17506ba2cb1fbf….
--
v7: vkd3d-shader/tpf: Get rid of sm4_register.dim.
vkd3d-shader/tpf: Use 's' in src_info to expect sampler register with vec4 dimension.
vkd3d-shader/tpf: Separate dst register write function.
vkd3d-shader/tpf: Separate src register write function.
vkd3d-shader/tpf: Make register_type_table an array of structs with lookup tables.
vkd3d-shader/tpf: Introduce struct tpf_writer to group sm4 write arguments.
vkd3d-shader/tpf: Use struct vkd3d_shader_register_index in sm4_register.idx[].
vkd3d-shader/tpf: Allow passing NULL register type on hlsl_sm4_register_from_semantic().
vkd3d-shader/tpf: Use enum vkd3d_shader_register_type in sm4_register.type.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/281
There are two motivations for this:
* First, the structure *almost* corresponds to D3D12_SHADER_INPUT_BIND_DESC, and
if more elements were included, it could be used as-is for shader reflection.
There is the quirk that currently we return scan information based on the
shader instructions, whereas d3dcompiler shader reflection expects to get it
from the shader reflection data (i.e. the RDEF chunk), which is particularly
relevant in the case that the RDEF chunk is stripped.
That said, even if we have to introduce an extra scan API to account for this
difference, being able to reuse the same structure seems like a benefit.
In order to reuse this structure, we need to add the following elements:
- Register ID (added in part 1 of this series)
- Sample count (added in part 2 of this series)
- Flags or resource types to distinguish between typed, raw, and structured
buffers. I have not decided which representation makes the most sense;
opinions are welcome.
* Second, I think it makes sense to use this reflection information internally
in spirv.c (and potentially other compiler backends) to declare resources in
the target environment, instead of parsing DCL instructions. The idea here is
that this allows backends to be more agnostic as to how resources are declared
(or inferred) in the frontend, while avoiding the need to synthesize those DCL
instructions in the frontend either [especially since epenthesizing
instructions is more expensive than converting them to NOPs.]
In order to do that, we will need vkd3d_shader_scan_descriptor_info1 to cover
everything that is currently covered by DCL instructions. This needs the same
elements as above (register ID and sample count), but also:
- Structure stride (added in part 2 of this series)
- Constant buffer used width (added in part 2 of this series)
I don't currently have a proof-of-concept using these new elements. On the other
hand, since it's just an extension of an existing API, I figured that seemed
less critical.
This does conflict trivially with 280; I'm submitting it now since 280 is
accepted, but due to Alexandre's vacation may not be committed soon, and since
this is new API I'd rather get comments early anyway.
--
v2: vkd3d-shader: Get rid of the uav_ranges array.
vkd3d-shader: Add register ID to struct vkd3d_shader_descriptor_info1.
vkd3d-shader: Introduce struct vkd3d_shader_scan_descriptor_info1.
vkd3d-shader: Centralize cleanup on error in scan_with_parser().
vkd3d-shader: Factor more code into vkd3d_shader_scan_get_uav_descriptor_info().
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/295
--
v9: vkd3d-shader/tpf: Handle the swizzle type bitfield in dst param tokens.
vkd3d-shader/tpf: Handle the dimension bitfield in dst param tokens.
vkd3d-shader/tpf: Use the default vec4 swizzle if a src param contains a mask.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/225
Updates reported driver versions
Fixes complaints of old drivers in Diablo IV
Note: The Intel 31.0.101.4577 driver only actually supports UHD 7XX and above. Should I be trying to track down the last supported driver for each of the previous GPU generations or is it fine to just pretend that we have a 101.4577 driver that supports HD4000+?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3516
This is similar to https://gitlab.winehq.org/wine/wine/-/merge_requests/2684, https://gitlab.winehq.org/wine/wine/-/merge_requests/3004 or https://gitlab.winehq.org/wine/wine/-/merge_requests/3139 but it validates the session transform node behavior with tests.
The tests are added after the changes because they otherwise don't pass and making them pass would be unnecessarily complicated.
I also have some local tests for MF_TOPONODE_WORKQUEUE_ID attributes and how it is supposed to behave. It basically creates new serialized work queues for every source node and assign them to every node downstream. Any sample request or processing operation is done in the associated queue.
When joining streams, queues are assigned downstream one after another and the last assigned queue is used when requesting samples upstream, but when samples are received and processed downstream it looks like the current queue of the source node is used for every downstream operations.
The request behavior seems to be the same when work queues are used, with round robin input requests, and single ProcessInput call followed by ProcessOutput loop until it fails.
This is yet not optimally efficient, and could be improved, for the following reasons:
1) All session operations are serialized together, even unrelated streams, and ProcessInput / ProcessOutput calls may be costly and stalling the pipeline. I believe that native probably allows parallel processing of unrelated stream requests, this needs to be confirmed.
2) MFT_MESSAGE_COMMAND_DRAIN message use isn't ideal, the message forces the transform to process all queued input synchronously, which can take a long time. I haven't checked exactly what native does but I believe it instead uses MFT_MESSAGE_NOTIFY_END_OF_STREAM messages, which would allow us to notify and drain the GStreamer decoder asynchronously.
3) MFT_MESSAGE_COMMAND_DRAIN also doesn't distinguish between input streams and needs to be sent globally. It's unclear how it should be used when multiple input streams are involved, and when one stream ends its segment then start a new segment while other streams don't have yet reached EOS. MFT_MESSAGE_NOTIFY_END_OF_STREAM messages have a stream ID parameter and would be more appropriate to handle separate input streams independently.
--
v3: mf/tests: Add more media session transform tests with multiple inputs.
mf/tests: Add more media session transform tests with multiple outputs.
mf/tests: Add some media session transform call pattern tests.
mf/session: Increase the stream request count when requests are already queued.
mf/session: Request more samples from upstream when necessary.
mf/session: Push transform input samples one by one to ProcessInput.
mf/session: Use helpers to push and pop samples for transform streams.
mf/session: Flush requests in transform_node_deliver_samples when drained.
mf/session: Use a helper to deliver transform node requested samples.
mf/session: Use local variables to access transform node streams.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3245
This fixes an issue when the path includes non-ASCII characters.
Signed-off-by: Jactry Zeng <jzeng(a)codeweavers.com>
--
v10: mshtml: Call UrlUnescapeW() with URL_UNESCAPE_AS_UTF8 in is_gecko_path().
shlwapi/tests: Test UrlUnescapeW() with URL_UNESCAPE_AS_UTF8.
kernelbase: Implement URL_UNESCAPE_AS_UTF8 for UrlUnescapeW().
https://gitlab.winehq.org/wine/wine/-/merge_requests/585
I tried build a real Windows application (mimikatz) and had troubles with some wine headers incompatibility. The patch set improves headers to allow build the foreign application with Wine.
--
v4: include: Add standalone LSA_OBJECT_ATTRIBUTES prototype if ntdef.h is not included.
include: Add initial activeds.h.
include: Add missed PCWCHAR to winnt.h.
include: Include ncrypt.h in wincrypt.h.
include: Add specstrings_strict.h with some defines.
include: Use compatible file guard name (_NTSECAPI_, _NTSECPKG_).
include: Add some missed defines.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3506
This fixes an issue when the path includes non-ASCII characters.
Signed-off-by: Jactry Zeng <jzeng(a)codeweavers.com>
--
v9: mshtml: Call UrlUnescapeW() with URL_UNESCAPE_AS_UTF8 in is_gecko_path().
shlwapi/tests: Test UrlUnescapeW() with URL_UNESCAPE_AS_UTF8.
kernelbase: Implement URL_UNESCAPE_AS_UTF8 for UrlUnescapeW().
https://gitlab.winehq.org/wine/wine/-/merge_requests/585
--
v7: vkd3d-shader/tpf: Handle the swizzle type bitfield in dst param tokens.
vkd3d-shader/tpf: Handle the dimension bitfield in dst param tokens.
vkd3d-shader/tpf: Use the default vec4 swizzle if a src param contains a mask.
vkd3d-shader/tpf: Handle the dimension bitfield in src param tokens.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/225
This fixes an issue when the path includes non-ASCII characters.
Signed-off-by: Jactry Zeng <jzeng(a)codeweavers.com>
--
v8: mshtml: Call UrlUnescapeW() with URL_UNESCAPE_AS_UTF8 in is_gecko_path().
shlwapi/tests: Test UrlUnescapeW() with URL_UNESCAPE_AS_UTF8.
kernelbase: Implement URL_UNESCAPE_AS_UTF8 for UrlUnescapeW().
https://gitlab.winehq.org/wine/wine/-/merge_requests/585
--
v6: vkd3d-shader/tpf: Remove the scalar register workaround for dst param write masks.
vkd3d-shader/tpf: Handle the swizzle type bitfield in dst param tokens.
vkd3d-shader/tpf: Handle the dimension bitfield in dst param tokens.
vkd3d-shader/tpf: Use the default vec4 swizzle if a src param contains a mask.
vkd3d-shader/tpf: Handle the dimension bitfield in src param tokens.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/225
--
v2: msxml3: Add tests of ValidateOnParse property.
msxml3: Set ValidateOnParse to VARIANT_TRUE by default.
msxml3: Add ValidateOnParse support for IXMLDOMDocument3_{get,set}Property().
https://gitlab.winehq.org/wine/wine/-/merge_requests/3424
This adds the unit, date-time, and palette histogram metadata properties for PNG images to GDI+. With these changes, the properties returned match Windows for all files in the PNG samples suite found at http://www.schaik.com/pngsuite/ .
--
v2: gdiplus: Set PNG palette histogram property when present.
gdiplus: Set PNG date-time property when present.
gdiplus: Set PNG unit properties always.
gdiplus: Refactor png_metadata_reader.
gdiplus/tests: Factor out check_properties functions.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3524
Release for 1.8.1 containing targeted fixes for issues uncovered by Wine tests, in particular an assert which is currently preventing Wine tests from running with 1.8.
There were other "safe fix" patches I noticed after 1.8, but on the precedent of 1.7.1 I didn't pick any of them.
I've marked this as a draft since it's supposed to be a merge request into a vkd3d-1.8.x branch, but that doesn't currently exist, and it'll need Alexandre to create it as I understand. In the meantime I'm submitting the patches so they can be reviewed.
--
v2: Release 1.8.1.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/298
--
v3: vkd3d-shader/hlsl: Use hlsl_block_add_instr() in clone_block().
vkd3d-shader/hlsl: Clean up the static_initializers block when the context is destroyed (Valgrind).
vkd3d-shader/hlsl: Pass a hlsl_block pointer to dump_instr_list().
vkd3d-shader/hlsl: Store the "instrs" field of struct hlsl_attribute as a hlsl_block.
vkd3d-shader/hlsl: Pass an hlsl_block pointer to add_load_component().
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/290
Release for 1.8.1 containing targeted fixes for issues uncovered by Wine tests, in particular an assert which is currently preventing Wine tests from running with 1.8.
There were other "safe fix" patches I noticed after 1.8, but on the precedent of 1.7.1 I didn't pick any of them.
I've marked this as a draft since it's supposed to be a merge request into a vkd3d-1.8.x branch, but that doesn't currently exist, and it'll need Alexandre to create it as I understand. In the meantime I'm submitting the patches so they can be reviewed.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/298
There are two motivations for this:
* First, the structure *almost* corresponds to D3D12_SHADER_INPUT_BIND_DESC, and
if more elements were included, it could be used as-is for shader reflection.
There is the quirk that currently we return scan information based on the
shader instructions, whereas d3dcompiler shader reflection expects to get it
from the shader reflection data (i.e. the RDEF chunk), which is particularly
relevant in the case that the RDEF chunk is stripped.
That said, even if we have to introduce an extra scan API to account for this
difference, being able to reuse the same structure seems like a benefit.
In order to reuse this structure, we need to add the following elements:
- Register ID (added in part 1 of this series)
- Sample count (added in part 2 of this series)
- Flags or resource types to distinguish between typed, raw, and structured
buffers. I have not decided which representation makes the most sense;
opinions are welcome.
* Second, I think it makes sense to use this reflection information internally
in spirv.c (and potentially other compiler backends) to declare resources in
the target environment, instead of parsing DCL instructions. The idea here is
that this allows backends to be more agnostic as to how resources are declared
(or inferred) in the frontend, while avoiding the need to synthesize those DCL
instructions in the frontend either [especially since epenthesizing
instructions is more expensive than converting them to NOPs.]
In order to do that, we will need vkd3d_shader_scan_descriptor_info1 to cover
everything that is currently covered by DCL instructions. This needs the same
elements as above (register ID and sample count), but also:
- Structure stride (added in part 2 of this series)
- Constant buffer used width (added in part 2 of this series)
I don't currently have a proof-of-concept using these new elements. On the other
hand, since it's just an extension of an existing API, I figured that seemed
less critical.
This does conflict trivially with 280; I'm submitting it now since 280 is
accepted, but due to Alexandre's vacation may not be committed soon, and since
this is new API I'd rather get comments early anyway.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/295