> MoltenVK has its own scheme for assigning a PCI device ID to the AGX GPUs. I wonder if it wouldn't be worth attempting to emulate that in case apps try to match the ID from Vulkan to this one.
Or retrieve the devices from Vulkan (as winex11) if Vulkan is available?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3187#note_37353
This fixes an issue I ran into in UI Automation using an interface proxy marshaled with `MSHCTX_INPROC`. `CoUnmarshalInterface` always passes `MSHCTX_LOCAL` when the standard marshaler, regardless of what was passed to `CoMarshalInterface`.
When passing an interface that uses the free threaded marshaler as an argument to a method on the proxy retrieved from `CoUnmarshalInterface`, it passes `MSHCTX_LOCAL` when trying to marshal, which the results in the free threaded marshaler trying to create a proxy/stub which fails.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3198
> Do we need things built on 10.14 to run on M1 Macs (which don't support 32-bit)? If not, I can just ifdef it out in that case. Otherwise, I can try defining those symbols manually.
I think an ifdef (`#if defined(MAC_OS_X_VERSION_10_15) && MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_15`) should be fine, especially with Metal nobody should be expecting full functionality when building against old SDKs and then deploying to new ones.
(it would be nice if we could use `@available`, but that requires Xcode 9)
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3187#note_37348
> MoltenVK has its own scheme for assigning a PCI device ID to the AGX GPUs. I wonder if it wouldn't be worth attempting to emulate that in case apps try to match the ID from Vulkan to this one.
[They used to, but now they just use the device feature set plus the OS version](https://github.com/KhronosGroup/MoltenVK/commit/df043487e4711fe61e…. I'm a bit worried about sticking the OS version on top like they do, since PCI device IDs are normally 16-bit, but maybe that would work out fine?
> This is also producing a build failiure on macOS 10.14
Do we need things built on 10.14 to run on M1 Macs (which don't support 32-bit)? If not, I can just ifdef it out in that case. Otherwise, I can try defining those symbols manually.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3187#note_37342
Required for !1857 to not break when comctl32 version 6 isn't requested by application (in particular, found this in [qapitrace](https://github.com/apitrace/apitrace)).
Manifest resource id and assembly identity name match with Windows.
For isolation purposes, activation context is disabled while emitting events.
--
v10: comdlg32: Enable visual styles when showing IFileDialog.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2068
The goal of this MR is to set up the minimum necessary infrastructure to display the contents of some simple, software rendered windows. This involves two major steps:
1. Associate a window with a Wayland surface and give it the `xdg_toplevel` role, so that the compositor can display it. We also have to implement the required initial `xdg_surface` configuration sequence to be able to safely (i.e., without the compositor disconnecting us with an error) attach buffers to the surface in step (2).
2. Implement the `window_surface` interface for the Wayland driver. For now we provide a simple (and suboptimal) `window_surface_flush` implementation: for each flush we create a new `wl_shm` buffer, copy the whole window contents (ignoring damaged bounds for now) into it and attach it to the target Wayland surface. In the next MR I will optimize this implementation in multiple ways: a. implement a buffer queue to avoid constantly allocating new buffers b. respect the damaged bounds of the `window_surface` to minimize copying of data from the `window_surface` to the SHM buffer (and also for correctness) c. communicate damaged surface regions to the compositor to (potentially) allow more efficient texture uploads.
With this MR many (software-rendered) applications can now display dynamic content on screen. We can't interact with the apps yet, but we do get to enjoy `notepad` in all its blinking-cursor glory.
Thanks!
--
v7: winewayland.drv: Do not commit buffers to unconfigured surfaces.
winewayland.drv: Implement a simple window_surface flush.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2944
We update the cache in NtUserCreateDesktopEx, as it may change existing
thread desktop flags, but we need to do it as well when a new desktop is
created while still detached, then attached to a thread through
NtUserSetThreadDesktop.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55146
This is the case when forcing virtual desktop mode with new desktop creation by running `explorer /desktop=test,1024x768 winecfg` for instance.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3197
Initialize the calendars variable after checking if locale is NULL before using it to avoid NULL
pointer references. Fix a Excel 2016 crash when formatting dates with the custom format 'ddd'.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3190
--
v8: vkd3d-shader/tpf: Add support for writing 'resinfo' instruction.
vkd3d-shader/tpf: Add support for writing 'sampleinfo' instruction.
vkd3d-shader/hlsl: Parse GetDimensions() method.
tests: Add some tests for GetDimensions().
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/218
In a declaration with multiple variables, the variables must be created
before the initializer of the next variable is parsed. This is required
for initializers such as:
```
float a = 1, b = a, c = b + 1;
```
The solution is to parse the type information in the same rule as the first variable ('a' in this case) so that it can be declared before the parser reaches the initializer for the following variables.
To initialize the following variables, the type information is passed along from the first variable's struct parse_variable_def to the next and so on.
---
Solves https://bugs.winehq.org/show_bug.cgi?id=54484, pointed out by @nsivov.
--
v2: vkd3d-shader/hlsl: Declare vars individually when parsing struct declarations.
vkd3d-shader/hlsl: Declare vars individually when parsing regular declarations.
vkd3d-shader/hlsl: Split declare_vars().
tests: Test multiple variable initializers.
tests: Test semantics in uniform variables.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/250
--
v2: vkd3d: Release op data when destroying the queue.
vkd3d: Always emit an error when failing to reserve for the op array.
vkd3d: Release the op mutex on allocation failure.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/251
--
v2: wined3d: Remove no longer used arguments from wined3d_texture_update_desc().
wined3d: Recreate swapchain textures in wined3d_swapchain_resize_buffers().
wined3d: Factor out a swapchain_create_texture() helper.
dxgi: Do not create a d3d11 swapchain object for the implicit swapchain.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2822
This series of patches enable Adobe PDF Reader 11 protected mode, which is essentially a Chromium sandbox, to work properly.
--
v2: server: Allow creating a real explorer desktop window for invisible window stations.
user32/tests: Test that an actual desktop window should be created on invisible window stations.
win32u: Use the window station name to check if an application is running as a service.
user32/tests: Test monitor information with an invisible window station.
win32u: Create explorer with the thread effective access token.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3162
Ah, dammit, I wish I had caught this sooner.
MoltenVK has its own scheme for assigning a PCI device ID to the AGX GPUs. I wonder if it wouldn't be worth attempting to emulate that in case apps try to match the ID from Vulkan to this one.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3187#note_37247
On Windows, `sendto()` ignores its destination parameters when provided with a connection-based socket (currently only SOCK_STREAM), even if they contain invalid data. This patch implements this behavior.
--
v3: ws2_32/tests: Add test for sendto() and recvfrom() on TCP sockets.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3186
Windows 10 [received support](https://devblogs.microsoft.com/commandline/af_unix-comes-to-window… for AF_UNIX sockets in Insider Build 17063. This merge request adds basic support for AF_UNIX sockets to ws2_32 and wineserver.
Of particular note is the difficulty in handling `sun_path`. Most of the functions that allow for translating Windows paths to Unix paths are not accessible from ws2_32. I considered the following options:
* Pass the Windows path to wineserver and do the conversion there.
* This is, as far as I can tell, not possible without major rearchitecting. wineserver does not have functions to translate Windows paths to Unix paths, for obvious reasons.
* Obtain the current working directory of the requesting process and temporarily change directories to there.
* This only handles relative paths and fails for absolute paths, UNC paths, etc.
* Conditionally change directories based on whether the path is relative or not.
* This is error-prone and wineserver does not have the requisite functions to do this cleanly.
I ultimately decided to pass the translated Unix path to wineserver, which changes directories to `dirname(path)`. It then provides `bind` and `connect` with `basename(path)`. This is not threadsafe, but wineserver is not (currently) multithreaded.
Abstract sockets are supported by this patch.
--
v31: ws2_32/tests: Add test for AF_UNIX sockets.
server: Fix getsockname() and accept() on AF_UNIX sockets.
server: Introduce error when attempting to connect() to abstract AF_UNIX sockets.
server: Allow for deletion of socket files.
ws2_32: Add support for AF_UNIX sockets.
ntdll/unix: Add support for AF_UNIX sockets to multiple functions.
ws2_32: Add afunix.h header.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2786
Yeah, I don't particularly remember what I was trying to do with this... it may have been an attempt to formalize the list of HLSL maintainers and/or avoid the need for Henri to sign off on those patches.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/19#note_37232
It's probably as good a time as any to revisit this.
I don't think the project is quite large enough to really need this at this point; I think "git log" paints a fairly decent picture of who touches which code, and Wine essentially did fine without a maintainers file for the first two decades or so too. I could certainly be convinced the project would benefit from having this, but right now this feels a bit like a solution in search of a problem to me.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/19#note_37231
I think that's a libtool/automake thing. The vkd3d-compiler target will get the -lSPIRV-Tools-shared flag from libvkd3d-shader.la, but not the -L flag with the additional path, so ld won't know where to find libSPIRV-Tools-shared.so unless you e.g. set an appropriate LD_LIBRARY_PATH. Adding @SPIRV_TOOLS_LIBS@ to vkd3d_compiler_LDADD (and DEMOS_LDADD) avoids the issue at build time, but you'll still need to set LD_LIBRARY_PATH to run the resulting executable.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/52#note_37229
```
On Margate Sands.
I can connect
Nothing with nothing.
```
--
v2: vkd3d-shader/d3dbc: Scan for the maximum temporary register index.
vkd3d-shader: Record a global temporary count per sm4 shader.
vkd3d-shader/dxbc: Remove redundant zero-initialization of the vkd3d_shader_desc structure.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/255
> > Shared SPIRV-Tools is not shipped by Debian Bullseye, and is broken if built manually.
>
> Is that a regression? I'm using a build of shared SPIRV-Tools I made myself, and it seems to work fine, although it's an older (v2019.5) version.
Okay, I think I remember / have reproduced the problem I was encountering.
If I build spirv-tools with a prefix that doesn't put it in $PATH, and then try to build vkd3d, I get this:
elizabeth@ledyba:~/git/vkd3d64$ make
make all-am
make[1]: Entering directory '/home/elizabeth/git/vkd3d64'
CCLD vkd3d-compiler
/usr/bin/ld: warning: libSPIRV-Tools-shared.so, needed by ./.libs/libvkd3d-shader.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: ./.libs/libvkd3d-shader.so: undefined reference to `spvContextCreate'
/usr/bin/ld: ./.libs/libvkd3d-shader.so: undefined reference to `spvContextDestroy'
/usr/bin/ld: ./.libs/libvkd3d-shader.so: undefined reference to `spvTextDestroy'
/usr/bin/ld: ./.libs/libvkd3d-shader.so: undefined reference to `spvDiagnosticDestroy'
/usr/bin/ld: ./.libs/libvkd3d-shader.so: undefined reference to `spvBinaryToText'
/usr/bin/ld: ./.libs/libvkd3d-shader.so: undefined reference to `spvValidateBinary'
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:1510: vkd3d-compiler] Error 1
make[1]: Leaving directory '/home/elizabeth/git/vkd3d64'
make: *** [Makefile:1157: all] Error 2
I don't really understand linking enough to know whose fault this is, although I suspect it's the fault of spirv-tools, which is generally just a mess.
Either way I don't think this patch is the right thing to do, so I'm going to close this.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/52#note_37197
The Vulkan spec says:
Parameters to the command requesting a deferred operation may be accessed by the implementation at any time until the deferred operation enters the
complete state Pointer parameters must not be modified (e.g. reallocated/freed).
This fixes a regression in Doom Eternal with ray tracing enabled with drivers
that actually support deferred operations (e.g. nvidia, amdvlk).
--
v2: winevulkan: Keep deferred operation function params alive.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3188
The Vulkan spec says:
Parameters to the command requesting a deferred operation may be accessed by the implementation at any time until the deferred operation enters the
complete state Pointer parameters must not be modified (e.g. reallocated/freed).
This fixes a regression in Doom Eternal with ray tracing enabled with drivers
that actually support deferred operations (e.g. nvidia, amdvlk).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3188
Windows 10 [received support](https://devblogs.microsoft.com/commandline/af_unix-comes-to-window… for AF_UNIX sockets in Insider Build 17063. This merge request adds basic support for AF_UNIX sockets to ws2_32 and wineserver.
Of particular note is the difficulty in handling `sun_path`. Most of the functions that allow for translating Windows paths to Unix paths are not accessible from ws2_32. I considered the following options:
* Pass the Windows path to wineserver and do the conversion there.
* This is, as far as I can tell, not possible without major rearchitecting. wineserver does not have functions to translate Windows paths to Unix paths, for obvious reasons.
* Obtain the current working directory of the requesting process and temporarily change directories to there.
* This only handles relative paths and fails for absolute paths, UNC paths, etc.
* Conditionally change directories based on whether the path is relative or not.
* This is error-prone and wineserver does not have the requisite functions to do this cleanly.
I ultimately decided to pass the translated Unix path to wineserver, which changes directories to `dirname(path)`. It then provides `bind` and `connect` with `basename(path)`. This is not threadsafe, but wineserver is not (currently) multithreaded.
Abstract sockets are supported by this patch.
--
v30: ws2_32/tests: Add test for AF_UNIX sockets.
server: Fix getsockname() and accept() on AF_UNIX sockets.
server: Introduce error when attempting to connect() to abstract AF_UNIX sockets.
server: Allow for deletion of socket files.
ws2_32: Add support for AF_UNIX sockets.
ntdll/unix: Add support for AF_UNIX sockets to multiple functions.
ws2_32: Add afunix.h header.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2786
In a declaration with multiple variables, the variables must be created
before the initializer of the next variable is parsed. This is required
for initializers such as:
```
float a = 1, b = a, c = b + 1;
```
The solution is to parse the type information in the same rule as the first variable ('a' in this case) so that it can be declared before the parser reaches the initializer for the following variables.
To initialize the following variables, the type information is passed along from the first variable's struct parse_variable_def to the next and so on.
---
Solves https://bugs.winehq.org/show_bug.cgi?id=54484, pointed out by @nsivov.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/250
Reference
https://bugs.winehq.org/show_bug.cgi?id=54985
From the line we see the mingw version used causes an
In file included from /usr/share/mingw-w64/include/unknwnbase.h:47,
[ 935s] from /usr/share/mingw-w64/include/objidlbase.h:439,
[ 935s] from include/combaseapi.h:29,
[ 935s] from include/objbase.h:267,
[ 935s] from include/ole2.h:25,
[ 935s] from /usr/share/mingw-w64/include/wtypes.h:13,
[ 935s] from include/winscard.h:22,
[ 935s] from include/windows.h:68,
[ 935s] from libs/vkd3d/include/private/vkd3d_common.h:23,
[ 935s] from libs/vkd3d/libs/vkd3d-shader/vkd3d_shader_private.h:49,
[ 935s] from libs/vkd3d/libs/vkd3d-shader/preproc.y:24,
[ 935s] from libs/vkd3d/libs/vkd3d-shader/preproc.l:23:
[ 935s] /usr/share/mingw-w64/include/wtypesbase.h:148:16: error: redefinition of 'struct _SECURITY_ATTRIBUTES'
[ 935s] 148 | typedef struct _SECURITY_ATTRIBUTES {
The included file winscard.h seemed a little odd. The vkd3d isn't going to use this.
Adding the define WIN32_LEAN_AND_MEAN to the Makefile.in (in wine), produce the following warnings.
/home/alesliehughes/wine/libs/vkd3d/include/private/vkd3d_common.h:75:5: warning: implicit declaration of function ‘abort’ [-Wimplicit-function-declaration]
75 | abort();
| ^~~~~
/home/alesliehughes/wine/libs/vkd3d/include/private/vkd3d_common.h:258:14: warning: implicit declaration of function ‘atoi’ [-Wimplicit-function-declaration]
258 | *major = atoi(version);
Adding header <stdlib.h> removed all the warnings.
--
v2: include: Avoid including unnecessary Windows headers.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/217
This probably can be seen as pointless moving, but I at least appreciate the structure.
Besides structure, part of my motivation here is that I will soon want to introduce tests for d3d assembly.
I'd also like to stop once and for all the inconsistency between whether tests have "hlsl" prefixed or not.
--
v2: tests: Move HLSL tests to a subdirectory.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/248
This introduces temporary helpers block_to_list and list_to_block.
The job of block_to_list(), at least, could be done by simply writing
"&block->instrs" everywhere instead. Using the helper instead ensures that
all of these instances will eventually be converted.
--
v5: vkd3d-shader/hlsl: Store the fields of struct parse_if_body as hlsl_block pointers.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/230
Overwatch 2 calls `FlashWindowEx()` with `dwFlags = FLASHW_TRAY | FLASHW_TIMERNOFG` whenever you join an online game or respawn after getting killed. Without this MR the call causes us to send `WM_NCACTIVATE` with `wparam = FALSE`. This confuses the game and it stops reading controller input until you Alt+Tab out and back in to "reactivate" the nonclient area.
`WM_NCACTIVATE` should be only sent when there's `FLASHW_CAPTION` or `FLASHW_STOP` specified.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3184
Block records are not processed; only the bitcode is validated.
--
v16: vkd3d-shader/dxil: Read and validate global abbreviated operands.
vkd3d-shader/dxil: Read and validate local abbreviated operands.
vkd3d-compiler: Introduce a dxbc-dxil source type.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/44
Windows 10 [received support](https://devblogs.microsoft.com/commandline/af_unix-comes-to-window… for AF_UNIX sockets in Insider Build 17063. This merge request adds basic support for AF_UNIX sockets to ws2_32 and wineserver.
Of particular note is the difficulty in handling `sun_path`. Most of the functions that allow for translating Windows paths to Unix paths are not accessible from ws2_32. I considered the following options:
* Pass the Windows path to wineserver and do the conversion there.
* This is, as far as I can tell, not possible without major rearchitecting. wineserver does not have functions to translate Windows paths to Unix paths, for obvious reasons.
* Obtain the current working directory of the requesting process and temporarily change directories to there.
* This only handles relative paths and fails for absolute paths, UNC paths, etc.
* Conditionally change directories based on whether the path is relative or not.
* This is error-prone and wineserver does not have the requisite functions to do this cleanly.
I ultimately decided to pass the translated Unix path to wineserver, which changes directories to `dirname(path)`. It then provides `bind` and `connect` with `basename(path)`. This is not threadsafe, but wineserver is not (currently) multithreaded.
Abstract sockets are supported by this patch.
--
v29: ws2_32/tests: Add test for AF_UNIX sockets.
server: Fix getsockname() and accept() on AF_UNIX sockets.
server: Introduce error when attempting to connect() to abstract AF_UNIX sockets.
server: Allow for deletion of socket files.
ws2_32: Add support for AF_UNIX sockets.
ntdll/unix: Add support for AF_UNIX sockets to multiple functions.
ws2_32: Add afunix.h header.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2786
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55146
When virtual desktop mode is used, the current host display mode is still written to the registry, before the desktop is created and virtual desktop mode decided. When it matches the virtual screen size it also triggers the virtual desktop fullscreen detection and the window is resized to cover the entire screen.
Instead, when virtual desktop is used, update the current display mode to match the desktop window size.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3178