This patch includes an implementation of the long-pending `transpose` intrinsic and the `smoothstep` intrinsic.
While implementing `smoothstep` I realized that some intrinsics have different rules for the allowed data types than expressions:
- Vectors and matrices at the same time are not allowed, regardless of their dimensions. Even if they have the same number of components.
- Any combination of matrices is always allowed, even those when no matrix fits inside another, e.g.:
`…
[View More]float2x3` is compatible with `float3x2`, resulting in `float2x2`.
The common data type is the min on each dimension.
This is the case for `max`, `pow`, `ldexp`, `clamp` and `smoothstep`; which suggest that it is the case for all intrinsics where the operation is applied element-wise. So this was corrected.
A minor fix in `pow`'s type conversion is also included.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/53
[View Less]
--
v2: mfplay/tests: Add MF_SD_LANGUAGE and MF_SD_STREAM_NAME value tests.
winegstreamer: Extract stream name from QT demuxer private data.
winegstreamer: Query stream tags and set MF_SD_LANGUAGE attribute.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1542
Fixes an out of bounds access in `show_popup`.
```c
if (menu->FocusedItem != NO_SELECTED_ITEM)
{
menu->items[menu->FocusedItem].fState &= ~(MF_HILITE|MF_MOUSESELECT); // <- can crash here
menu->FocusedItem = NO_SELECTED_ITEM;
}
```
Menu resets focused item on show, not on close.
If items were later deleted, next time user opens the menu, menu can crash on out of bounds access and won't show up again, as menu thinks it's still on screen.
In other words:
- open split …
[View More]button dropdown
- click on any item
- clear dropdown items
- open dropdown again
Menu borked and won't open again.
Source for the testing app for reproduction.
[test.c](/uploads/2f703f63891b33e1a0eb0fcd27c912b7/test.c)
I guess, the alternative is to reset focused item when menu is closed, but not sure where's the best place to do that, haven't dug deep enough.
--
v3: win32u: Update focused item when inserting a menu item
win32u: Reset focused item if it was removed when removing a menu item
https://gitlab.winehq.org/wine/wine/-/merge_requests/1554
[View Less]
I recently noticed problems with building with clang in msvc mode when using my distro clang. It seems specific to its configuration, I think that it doesn't affect default clang.
One problem is that --rtlib=libgcc is specified in /etc/clang, which causes clang to produce:
```
clang-15: error: unsupported runtime library 'libgcc' for platform 'MSVC'
```
I think it's a clang bug here:
https://github.com/llvm/llvm-project/blob/main/clang/lib/Driver/ToolChains/…
It should probably check for -…
[View More]nodefaultlibs in addition to -nostdlib. It's easy to handle on Wine side by using -nostdlib.
The other problem is that clang for some reason doesn't define `_MSV_VER` by default. I found that it's defined only if I pass `-fuse-ld=lld` to the command line. That's weird because it shouldn't affect compilation step, it should matter only for linking and that's when we pass it. I didn't track it down in clang code itself, but if we can't depend on clang providing it by default, we need to make sure to pass `-fms-compatibility-version` ourselves. The exact version doesn't really matter, we mostly need to make sure that it's defined at all so that our #ifdefs work correctly.
--
v2: configure: Use -fuse-ld=lld also for compilation targets.
winegcc: Use -nostdlib instead of -nostartfiles on Clang MSVC targets.
configure: Use -nostdlib instead of -nostartfiles in WINE_TRY_PE_CFLAGS.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1549
[View Less]
--
v5: mfmediaengine: Add a fallback when the set engine format cannot be used to init samplegrabber.
mfmediaengine: Only accept engine formats which are render target compatible.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1046
Overcooked! All You Can Eat only adds new controllers if existing controller has the same serial as it. SDL GUIDs mark the model of controller, but don't differentiate between multiple controllers of the same model. This is especially bad with Steam virtual controllers, which all have the same GUID.
Switch to using SDL_JoystickGetSerial if available, and otherwise combining the GUID with the controller index
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1551
For the `performance.navigation` props, I store them in the timing that's already linked from the window, to prevent adding more code around that just for 2 props, so it keeps it simple.
--
v3: include/mshtml: Add IHTMLXDomainRequest and factory interfaces and classes.
mshtml: Don't check for doc_node from the doc obj when it can't be NULL.
mshtml: Return proper error for invalid selectors in IE8 mode.
mshtml: Treat edit mode as a reload.
mshtml: Implement performance.…
[View More]navigation.type.
mshtml: Implement performance.navigation.redirectCount.
mshtml: Set `reload` load type to Gecko for document reloads.
mshtml: Implement `onload` prop for input elements.
mshtml: Implement location.reload().
mshtml: Implement print events.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1526
[View Less]
Called by IE11.
Signed-off-by: Mohamad Al-Jaf <mohamadaljaf(a)gmail.com>
v3: Fix failed test.
Don't know how to change the subject version number.
--
v4: shell32/tests: Add SHBindToFolderIDListParent tests.
shell32: Implement SHBindToFolderIDListParent.
shell32: Fix error handling in SHBindToParent.
shell32/tests: Test SHBindToParent last parameter behavior.
https://gitlab.winehq.org/wine/wine/-/merge_requests/566
Fixes an out of bounds access in `show_popup`.
```c
if (menu->FocusedItem != NO_SELECTED_ITEM)
{
menu->items[menu->FocusedItem].fState &= ~(MF_HILITE|MF_MOUSESELECT); // <- can crash here
menu->FocusedItem = NO_SELECTED_ITEM;
}
```
Menu resets focused item on show, not on close.
If items were later deleted, next time user opens the menu, menu can crash on out of bounds access and won't show up again, as menu thinks it's still on screen.
In other words:
- open split …
[View More]button dropdown
- click on any item
- clear dropdown items
- open dropdown again
Menu borked and won't open again.
Source for the testing app for reproduction.
[test.c](/uploads/2f703f63891b33e1a0eb0fcd27c912b7/test.c)
I guess, the alternative is to reset focused item when menu is closed, but not sure where's the best place to do that, haven't dug deep enough.
--
v2: win32u: Reset focused item when removing menu item
win32u: Allow (de)select_item to work with off-screen menus
win32u: Add deselect to HiliteMenuItem
win32u: Return FALSE in HiliteMenuItem when window handle is NULL
https://gitlab.winehq.org/wine/wine/-/merge_requests/1554
[View Less]
If a hlsl_ir_load loads a variable whose components are stored from different
instructions, copy propagation doesn't replace it.
But if all these instructions are constants (which currently is the case
for value constructors), the load can be replaced with a constant value, which
is what the first patch of this series does.
For instance, this shader:
```
sampler s;
Texture2D t;
float4 main() : sv_target
{
return t.Gather(s, float2(0.6, 0.6), int2(0, 0));
}
```
results in the following …
[View More]IR before applying the patch:
```
float | 6.00000024e-01
float | 6.00000024e-01
uint | 0
| = (<constructor-2>[@4].x @2)
uint | 1
| = (<constructor-2>[@6].x @3)
float2 | <constructor-2>
int | 0
int | 0
uint | 0
| = (<constructor-5>[@11].x @9)
uint | 1
| = (<constructor-5>[@13].x @10)
int2 | <constructor-5>
float4 | gather_red(resource = t, sampler = s, coords = @8, offset = @15)
| return
| = (<output-sv_target0> @16)
```
and this IR afterwards:
```
float2 | {6.00000024e-01 6.00000024e-01 }
int2 | {0 0 }
float4 | gather_red(resource = t, sampler = s, coords = @2, offset = @3)
| return
| = (<output-sv_target0> @4)
```
This is required to write texel_offsets as aoffimmi modifiers in the sm4 backend, since it expects the texel_offset arguments to be hlsl_ir_constant.
This series also:
* Allows Gather() methods to use aoffimmi modifiers instead of an additional source register (which is the only way allowed for shader model 4.1), when possible.
* Adds support to texel_offsets in the Load() method via aoffimmi modifiers (the only allowed method).
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/51
[View Less]
Fixes an out of bounds access in `show_popup`.
```c
if (menu->FocusedItem != NO_SELECTED_ITEM)
{
menu->items[menu->FocusedItem].fState &= ~(MF_HILITE|MF_MOUSESELECT); // <- can crash here
menu->FocusedItem = NO_SELECTED_ITEM;
}
```
Menu resets focused item on show, not on close.
If items were later deleted, next time user opens the menu, menu can crash on out of bounds access and won't show up again, as menu thinks it's still on screen.
In other words:
- open split …
[View More]button dropdown
- click on any item
- clear dropdown items
- open dropdown again
Menu borked and won't open again.
Source for the testing app for reproduction.
[test.c](/uploads/2f703f63891b33e1a0eb0fcd27c912b7/test.c)
I guess, the alternative is to reset focused item when menu is closed, but not sure where's the best place to do that, haven't dug deep enough.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1554
[View Less]
Migration a couple of bits to unsigned int.
Note to Zebediah (mainly on second commit of this serie):
- there is also a load of 'uint32_t flags' parameters that I didn't change
(mainly not to change too many things)
Is this something to consider?
- I didn't touch the local variables either.
Maybe it's something to consider also.
--
v2: wined3d: Set location's type to uint32_t.
wined3d: Set flags' type to uint32_t (internal definitions).
wined3d: Set flags's type to …
[View More]uint32_t (external definitions).
https://gitlab.winehq.org/wine/wine/-/merge_requests/1536
[View Less]
On 11/19/22 03:09, Eric Pouech wrote:
> Le 18/11/2022 à 22:45, Alexandre Julliard a écrit :
>> Module: wine
>> Branch: master
>> Commit: c7a97b5d5d56ef00a0061b75412c6e0e489fdc99
>> URL:
>> https://gitlab.winehq.org/wine/wine/-/commit/c7a97b5d5d56ef00a0061b75412c6e…
>>
>> Author: Zebediah Figura <zfigura(a)codeweavers.com>
>> Date: Thu Nov 17 19:32:39 2022 -0600
>>
>> configure: Override PKG_CONFIG_LIBDIR …
[View More]instead of PKG_CONFIG_PATH for
>> 32-bit builds on 64-bit hosts.
>>
>> This allows 32-bit packages to be found when the user has specified
>> PKG_CONFIG_PATH for some other reason.
>>
>> This also mirrors the way e.g. i686-linux-gnu-pkg-config is
>> implemented on
>> Debian, and possibly other distributions as well.
>>
>> This also prevents 64-bit .pc files from being found. This was originally
>> intended as a benefit [1], but can contribute to misdetection of
>> headers which
>> are not actually multiarch (e.g. GStreamer, although at the time that
>> [1] was
>> written that was a preëxisting problem). In general a distribution which
>> provides .pc files for one architecture should be expected to provide
>> them for
>> any architecture that it actually provides libraries for; even if that
>> was not
>> true of Debian in 2017, it is now. I moreover assert it is better to
>> fail to
>> find a present library than to incorrectly find the wrong one.
>>
>> Note that we can't easily use i686-linux-gnu-pkg-config, as would
>> otherwise be
>> preferable, for reasons also described in [1].
>>
>> [1] https://www.winehq.org/pipermail/wine-devel/2017-June/118002.html
>>
>> ---
>
> for the record, this patch can break compilation [[ and does <g> ]] when
> the 64bit .pc is installed while the 32bit isn't
>
> (on Fedora, be sure to have the -devel.i686 matching the installed
> -devel.x86_64 packages)
Right. For posterity, there's more discussion on bug 53953 [1]. This
strikes me as probably Fedora's bug, but I think we should probably work
around it in Wine regardless, if nothing else because that's what we've
been doing, and I undid it assuming that Fedora wouldn't be broken.
[1] https://bugs.winehq.org/show_bug.cgi?id=53953
[View Less]
I recently noticed problems with building with clang in msvc mode when using my distro clang. It seems specific to its configuration, I think that it doesn't affect default clang.
One problem is that --rtlib=libgcc is specified in /etc/clang, which causes clang to produce:
```
clang-15: error: unsupported runtime library 'libgcc' for platform 'MSVC'
```
I think it's a clang bug here:
https://github.com/llvm/llvm-project/blob/main/clang/lib/Driver/ToolChains/…
It should probably check for -…
[View More]nodefaultlibs in addition to -nostdlib. It's easy to handle on Wine side by using -nostdlib.
The other problem is that clang for some reason doesn't define `_MSV_VER` by default. I found that it's defined only if I pass `-fuse-ld=lld` to the command line. That's weird because it shouldn't affect compilation step, it should matter only for linking and that's when we pass it. I didn't track it down in clang code itself, but if we can't depend on clang providing it by default, we need to make sure to pass `-fms-compatibility-version` ourselves. The exact version doesn't really matter, we mostly need to make sure that it's defined at all so that our #ifdefs work correctly.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1549
[View Less]
As Wine currently does not have a way to set captions, returning the default value should suffice for most applications.
It looks like Windows does not do error checking for the *value parameter.
For the computed properties, they return E_INVALIDARG when all the captions are set as Default. But they return S_OK if any of the caption settings have been modified, regardless of whether a valid *value parameter is passed.
I expected it to at least return the computed values for the default …
[View More]properties but this does not appear to be the case. I guess there's no reason to keep the checks for each member of the computed color struct? Perhaps keep the checks for E_INVALIDARG and S_OK? I haven't come across an application that uses the functions so I didn't implement them.
For the rest of the properties, the if (0) test was added just to show that it crashes with a NULL value. Also, if the wrong type is passed, the function does not crash on Windows and the value remains unchanged, but it returns S_OK.
--
v5: windows.media: Partially implement IClosedCaptionPropertiesStatics_get_RegionOpacity.
windows.media: Partially implement IClosedCaptionPropertiesStatics_get_RegionColor.
windows.media: Partially implement IClosedCaptionPropertiesStatics_get_BackgroundOpacity.
windows.media: Partially implement IClosedCaptionPropertiesStatics_get_BackgroundColor.
windows.media: Partially implement IClosedCaptionPropertiesStatics_get_FontEffect.
windows.media: Partially implement IClosedCaptionPropertiesStatics_get_FontStyle.
windows.media: Partially implement IClosedCaptionPropertiesStatics_get_FontSize.
windows.media: Partially implement IClosedCaptionPropertiesStatics_get_FontOpacity.
windows.media: Partially implement IClosedCaptionPropertiesStatics_get_FontColor.
windows.media/tests: Add Closed Caption Properties tests.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1537
[View Less]
For the `performance.navigation` props, I store them in the timing that's already linked from the window, to prevent adding more code around that just for 2 props, so it keeps it simple.
--
v2: include/mshtml: Add IHTMLXDomainRequest and factory interfaces and classes.
mshtml: Don't check for doc_node from the doc obj when it can't be NULL.
mshtml: Return proper error for invalid selectors in IE8 mode.
mshtml: Treat edit mode as a reload.
mshtml: Implement performance.…
[View More]navigation.type.
mshtml: Implement performance.navigation.redirectCount.
mshtml: Set `reload` load type to Gecko for document reloads.
mshtml: Implement `onload` prop for input elements.
mshtml: Send load event synchronously for image elements if set to same src.
mshtml: Implement location.reload().
mshtml: Implement print events.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1526
[View Less]
We are currently locking the heap to iterate over the allocated regions, in order to check whether a pointer / block really belongs to one of them. This is not what native does it, as HeapFree / HeapReAlloc / HeapSize crashing on invalid pointers shows. This also makes it hard to improve the heap performance in multi-threaded scenarios.
This series reduces the locking requirement by keeping the region header offset in each block, relaxing the pointer checks, and assuming a heap region stays …
[View More]valid until all of its blocks have been freed. This also removes the locking requirement when accessing block level information, such as block type or flags or block user info. I'm assuming here that concurrent calls to heap functions on a given block are undefined.
Anything that involves modifying the block size, type or flags, walking the heap, or explicit validation still requires entering the heap lock.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1548
[View Less]
As Wine currently does not have a way to set captions, returning the default value should suffice for most applications.
It looks like Windows does not do error checking for the *value parameter.
For the computed properties, they return E_INVALIDARG when all the captions are set as Default. But they return S_OK if any of the caption settings have been modified, regardless of whether a valid *value parameter is passed.
I expected it to at least return the computed values for the default …
[View More]properties but this does not appear to be the case. I guess there's no reason to keep the checks for each member of the computed color struct? Perhaps keep the checks for E_INVALIDARG and S_OK? I haven't come across an application that uses the functions so I didn't implement them.
For the rest of the properties, the if (0) test was added just to show that it crashes with a NULL value. Also, if the wrong type is passed, the function does not crash on Windows and the value remains unchanged, but it returns S_OK.
--
v4: windows.media: Partially implement IClosedCaptionPropertiesStatics_get_RegionOpacity.
windows.media: Partially implement IClosedCaptionPropertiesStatics_get_RegionColor.
windows.media: Partially implement IClosedCaptionPropertiesStatics_get_BackgroundOpacity.
windows.media: Partially implement IClosedCaptionPropertiesStatics_get_BackgroundColor.
windows.media: Partially implement IClosedCaptionPropertiesStatics_get_FontEffect.
windows.media: Partially implement IClosedCaptionPropertiesStatics_get_FontStyle.
windows.media: Partially implement IClosedCaptionPropertiesStatics_get_FontSize.
windows.media: Partially implement IClosedCaptionPropertiesStatics_get_FontOpacity.
windows.media: Partially implement IClosedCaptionPropertiesStatics_get_FontColor.
windows.media/tests: Add Closed Caption Properties tests.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1537
[View Less]
Calling GetConsoleCP() when ReadConsoleW() fails (potentially indicating
that cmd.exe's instance isn't attached to a console) makes no sense.
In details, since GetConsoleCP() returns 0 when not attached to a console
to indicate error, we're in fact using CP_ACP.
So fallback explicitely to OEM CP (which is the default for CUI programs).
Signed-off-by: Eric Pouech <eric.pouech(a)gmail.com>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1546
This video codec is used by games such as Richman 4, and Zwei: The Arges Adventure.
The decoder logic is based on code from the FFmpeg project.
--
v5: loader/wine.inf: Enable ir50_32 video codec.
ir50_32: Implement decompression to 24-bit and 15-bit RGB.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1301
As Wine currently does not have a way to set captions, returning the default value should suffice for most applications.
It looks like Windows does not do error checking for the *value parameter.
For the computed properties, they return E_INVALIDARG when all the captions are set as Default. But they return S_OK if any of the caption settings have been modified, regardless of whether a valid *value parameter is passed.
I expected it to at least return the computed values for the default …
[View More]properties but this does not appear to be the case. I guess there's no reason to keep the checks for each member of the computed color struct? Perhaps keep the checks for E_INVALIDARG and S_OK? I haven't come across an application that uses the functions so I didn't implement them.
For the rest of the properties, the if (0) test was added just to show that it crashes with a NULL value. Also, if the wrong type is passed, the function does not crash on Windows and the value remains unchanged, but it returns S_OK.
--
v3: windows.media: Partially implement IClosedCaptionPropertiesStatics_get_RegionOpacity.
windows.media: Partially implement IClosedCaptionPropertiesStatics_get_RegionColor.
windows.media: Partially implement IClosedCaptionPropertiesStatics_get_BackgroundOpacity.
windows.media: Partially implement IClosedCaptionPropertiesStatics_get_BackgroundColor.
windows.media: Partially implement IClosedCaptionPropertiesStatics_get_FontEffect.
windows.media: Partially implement IClosedCaptionPropertiesStatics_get_FontStyle.
windows.media: Partially implement IClosedCaptionPropertiesStatics_get_FontSize.
windows.media: Partially implement IClosedCaptionPropertiesStatics_get_FontOpacity.
windows.media: Partially implement IClosedCaptionPropertiesStatics_get_FontColor.
windows.media/tests: Add Closed Caption Properties tests.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1537
[View Less]
As Wine currently does not have a way to set captions, returning the default value should suffice for most applications.
It looks like Windows does not do error checking for the *value parameter.
For the computed properties, they return E_INVALIDARG when all the captions are set as Default. But they return S_OK if any of the caption settings have been modified, regardless of whether a valid *value parameter is passed.
I expected it to at least return the computed values for the default …
[View More]properties but this does not appear to be the case. I guess there's no reason to keep the checks for each member of the computed color struct? Perhaps keep the checks for E_INVALIDARG and S_OK? I haven't come across an application that uses the functions so I didn't implement them.
For the rest of the properties, the if (0) test was added just to show that it crashes with a NULL value. Also, if the wrong type is passed, the function does not crash on Windows and the value remains unchanged, but it returns S_OK.
--
v2: windows.media: Partially implement IClosedCaptionPropertiesStatics_get_RegionOpacity.
windows.media: Partially implement IClosedCaptionPropertiesStatics_get_RegionColor.
windows.media: Partially implement IClosedCaptionPropertiesStatics_get_BackgroundOpacity.
windows.media: Partially implement IClosedCaptionPropertiesStatics_get_BackgroundColor.
windows.media: Partially implement IClosedCaptionPropertiesStatics_get_FontEffect.
windows.media: Partially implement IClosedCaptionPropertiesStatics_get_FontStyle.
windows.media: Partially implement IClosedCaptionPropertiesStatics_get_FontSize.
windows.media: Partially implement IClosedCaptionPropertiesStatics_get_FontOpacity.
windows.media: Partially implement IClosedCaptionPropertiesStatics_get_FontColor.
windows.media/tests: Add Closed Caption Properties tests.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1537
[View Less]
Also fixes a segmentation fault when exiting winedevice.exe.
I can file a separate bug report, but it seems related to Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52213
On my system the core dump can be provoked when using the bus_udev backend in winebus.sys ("Enable SDL" 0). It creates two hid devices - a mouse and a keyboard. Since it resides in the same winedevice.exe process as wineusb.sys, something similar to the above bug occurs when handling the SIGQUIT signal. The actual crash …
[View More]happens in the libusb event thread while waiting in pthread_cond_wait().
I'm using this for months without any issues (with a device driver which uses wineusb.sys for device access, etc.).
--
v4: wineusb.sys: Move event handling to a single thread.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1503
[View Less]
On Thu Nov 24 11:02:06 2022 +0000, Georg Lehmann wrote:
> Yeah this is a bit unfortunate. Maybe we should just not support 32bit
> ray tracing for now, if I recall correctly nvidia doesn't even support
> it with their driver.
Sure, 32bit ray tracing is probably not important on its own. But more generally, we can't reliably convert unions without selectors, so I'd suggest to express that in make_vulkan. I created !1541 that just skips them.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1508#note_17374
Migration a couple of bits to unsigned int.
Note to Zebediah (mainly on second commit of this serie):
- there is also a load of 'uint32_t flags' parameters that I didn't change
(mainly not to change too many things)
Is this something to consider?
- I didn't touch the local variables either.
Maybe it's something to consider also.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1536
This MR implements memory mapping for wow64 using VK_EXT_external_memory_host. This has some problems (more below), but overall, it looks promising as a stopgap. It passes D3D tests and works fine in general.
For proper solution, we'd need a new Vulkan extension. I experimented with a prototype extension https://github.com/KhronosGroup/Vulkan-Docs/pull/1906 and it looks like we can make it work, my WIP implementation is here https://gitlab.winehq.org/jacek/wine/-/tree/vulkan-map-placed. …
[View More]However, it would be nice to have a fallback working on existing drivers as well.
The main problem of this MR is that it breaks Vulkan spec. The main rule it breaks is that according to spec, we should explicitly specify that we plan to use external memory when creating VkBuffer or VkImage. The problem is that we don't know if we will until we bind memory to the buffer. I tried some workarounds for that (delaying actual buffer creation, recreating buffer when needed). I got it mostly working and passing tests without validation errors, but it was more invasive than I'd like and still had other problems. I'd rather avoid that if possible.
After looking at Mesa sources, I think that the way this MR breaks the spec should be harmless for its drivers. I don't have the hardware to test with Nvidia. If it works there, I'm tempted to ignore spec violation for now, given that the right path forward is VK_EXT_map_memory_placed anyway.
Performance-wise, this MR is sub-optimal because we're limited in what memory types we can use. However, I ran Unigine benchmarks on radv and the difference was marginal. In case of Heaven, it was even slightly faster on wow64, which could be explained by 64-bit Vulkan driver being generally slightly faster, but the difference is too small to draw any conclusion.
The last patch is not meant for (eventual) merge, but it's nice for testing the concept. It makes it possible to force using external memory in any kind of Wine build to experiment with its effects without need for wow64. To test that, just set `WINEVULKAN_EXTERNAL_MEMORY` environment variable.
--
v3: winevulkan: Introduce debugging environment variables.
winevulkan: Use VK_EXT_external_memory_host extension to map memory on wow64.
winevulkan: Wrap VkDeviceMemory.
winevulkan: Don't try to unwrap missing optional handle struct members.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1502
[View Less]
Fixes Marvel Snap being unable to connect to servers (part of it, another part is wmic patches), and maybe improves wait times in many other apps.
Typically "http://wpad/..." (which is commonly requested as lpszAutoConfigUrl for WinHttpGetProxyForUrl) is not available and WinHttpGetProxyForUrl() is hanging for a really long time resolving this name in download_script().
On Windows 10 here the name resolution timeout is about 9sec (and I could not find a way to configure it for a longer …
[View More]timeout). On Linux default DNS timeouts are typically longer. Yet, while WinHttpGetProxyForUrl() execution time is not consistent here, when I run it right after reboot or after network interface reconnection it typically takes ~4-7 seconds to complete on the first run. Then, testing it again shortly after yields no noticeable timeout. I suppose Windows caches and manages that globally in some service, so maximum possible 9 seconds name resolution timeout is rarely hit. Since proxy config URL, if available, is supposed to be in the local network, having the timeout of 5 seconds for name resolution looks more than enough to me.
--
v2: winhttp: Cache script in download_script().
winhttp: Set name resolution timeout in download_script().
https://gitlab.winehq.org/wine/wine/-/merge_requests/1528
[View Less]
The initial motivation is to make WinHttpCloseHandle(request) with request previously upgraded to websocket deliver WINHTTP_CALLBACK_STATUS_HANDLE_CLOSING right away and not after websocket is closed much later (this late notification causes crash in Microsoft Flight Simulator). That happens so as the notification is sent when the object is destroyed, not when the handle is closed. This logic seems correct to me: when testing some more things involving closing handles and observing which …
[View More]threads get the notifications I saw Windows delivering WINHTTP_CALLBACK_STATUS_HANDLE_CLOSING in the other threads, which suggests that the notification can be queued and delayed on Windows too in case there are pending operations involving the object.
So the right thing to do seems to be to have just the separate websocket and do not reference request from it.
It probably deserves a separate explanation why I am adding a refcounting to netconn and copying it to webscoket instead of just nullifying the netconn in request. Doing that way (just nullifying the netconn in request) immediately caused regression in Elden Ring which started failing in a convoluted way: it doesn't wait for WebSocketReceiveResponse() to complete and calls WebSocketCompleteUpgrade(). That currently succeeds in Wine due to some lack of validation. Then, after upgrade, async WebSocketReceiveResponse proceeds, but with NULL netconn it gets an error from prior WebSocketReceiveResponse in callback and fails the thing. The core problem here is that unless recursive request is involved WebSocketReceiveResponse is always sync on Windows and, as my testing goes, does not involve network communication at all. I. e., looks like the actual reply receiving should be done in WebSocketSendRequest, WebSocketReceiveResponse only sends notifications and possibly queues recursive reque
sts. I have a WIP patches for that and_with the help of those and existing winhttp test I realized that removing connection from request is wrong even without convoluted story. We have an existing test in winhttp.c which performs second request / upgrade on a request already upgraded socket. The test as is succeeds even with NULL connection in request by that is by chance only (as we don't try to receive response from our in process server yet which is failing in this case). With connection removed request opens a new one which doesn't get processed by our server, while in the same test on Windows I see that request is actually received by server, suggesting that it uses all the same existing connection on Windows, and so we should keep the same connection in request.
As a separate note, I suspect that we now can erroneously cache connection for request upgraded to websocket. But that happens not on request close but under different conditions and looks the same before and after present patches, so this should be probably checked and fixed separately.
Patch "winhttp: Move read buffer to websocket." might look weird as introducing the buffer for the only purpose of preserve initial data. While I don't immediately see how that can be done simplier, I have another small excuse for that. Currently the logic of closing websocket handles does the correct thing WRT notifications and aborting the operation. Yet it is still racy a bit due to we use app's buffer in socket read calls. If we happen to receive some data already after we sent notifications but before the read operation is aborted it may write to already freed or otherwise reused app's buffer. It seems to me that the only clean way to deal with that later is to use our own read buffer and copy the data only when we are going to send non-abort completion notification. So this read buffer might have more use in the future.
--
v2: winhttp: Do not reference request from socket.
winhttp: Move read buffer to websocket.
winhttp: Move flags to websocket header.
winhttp: Store connection in websocket.
winhttp: Send connection close notifications in finished_reading().
winhttp/tests: Avoid race condition on closing connection in server_thread().
winhttp: Add reference counting for connection.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1422
[View Less]
For the `performance.navigation` props, I store them in the timing that's already linked from the window, to prevent adding more code around that just for 2 props, so it keeps it simple.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1526
Based on [a patch](https://www.winehq.org/mailman3/hyperkitty/list/wine-devel@winehq.or… by Jinoh Kang (@iamahuman) from February 2022.
I removed the need for the event object and implemented fast paths for Linux.
On macOS 10.14+ `thread_get_register_pointer_values` is used on every thread of the process.
On Linux 4.14+ `membarrier(MEMBARRIER_CMD_GLOBAL_EXPEDITED, ...)` is used.
On x86 Linux <= 4.13 `madvise(..., MADV_DONTNEED)` is used, which sends IPIs to all cores causing them to …
[View More]do a memory barrier.
On non-x86 Linux <= 4.2 and on other platforms the fallback path using APCs is used.
--
v9: ntdll: Add thread_get_register_pointer_values-based implementation of NtFlushProcessWriteBuffers.
ntdll: Add sys_membarrier-based implementation of NtFlushProcessWriteBuffers.
ntdll: Add MADV_DONTNEED-based implementation of NtFlushProcessWriteBuffers.
https://gitlab.winehq.org/wine/wine/-/merge_requests/741
[View Less]
--
v2: windows.gaming.input: Assume that joysticks with single FFB axis are racing wheels.
windows.gaming.input: Implement the number of FFB axes according to the SupportedAxes property.
dinput/tests: Reduce the available FFB axes to X and Y in test_windows_gaming_input.
windows.gaming.input: Set initial effect parameters within the CS.
windows.gaming.input: Implement IForceFeedbackMotor_get_SupportedAxes.
dinput: Always send both "Type Specific" and "Set Effect" …
[View More]reports on initial Download.
dinput/tests: Test zero-ed force feedback effect parameters.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1535
[View Less]