test_index_buffer_offset() occasionally fails (on some machines and/or Mesa versions) due to a bug in radeonsi. Although the bug has since been fixed upstream, I ended up writing these patches for it, and since they reduce GL calls I'm inclined to believe they're a good idea regardless.
The relevant Mesa bug is <https://gitlab.freedesktop.org/mesa/mesa/-/issues/6138>.
--
v2: wined3d: Do not pause transform feedback after every draw call.
wined3d: Pause transform feedback in wined3d_context_gl_draw_textured_quad().
wined3d: Pause transform feedback in wined3d_context_gl_draw_shaded_quad().
https://gitlab.winehq.org/wine/wine/-/merge_requests/450
Currently the wine function `get_dir_case_sensitivity_stat` calls `ioctl` syscall with command `EXT2_IOC_GETFLAGS` and tries to read a flag `EXT4_CASEFOLD_FL` from the result. It does this on all filesystems without checking if the filesystem supports that flag.
This patch adds a check: only do the call on filesystems that are known to support `EXT4_CASEFOLD_FL`. To my knowledge these are EXT4 and F2FS.
Advantages:
- The `EXT4_CASEFOLD_FL` flag is nonstandard and other filesystems may use the same binary value to represent another flag. This patch prevents flag compatibility issues with other filesystems.
- This fixes (or works around) an issue on FUSE filesystems using libfuse 3.10 or older and kernel 5.13 or newer, where unsupported `ioctl` calls always succeed and return random (uninitialized) data (see https://github.com/libfuse/libfuse/issues/640). On such setups Wine randomly fails to read files because it thinks that the `EXT4_CASEFOLD_FL` is set when really it is just random data. Ubuntu 22.04 LTS has settled on libfuse 3.10 and kernel 5.15 so this issue will be around for years to come.
Disadvantages:
- The flag will not be read on possible other current and future filesystems that support it.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/451
> GitLab
>
> gitlab-to-mail <https://gitlab.winehq.org/project_2_bot> started a new
> discussion
> <https://gitlab.winehq.org/wine/wine/-/merge_requests/384#note_4039>:
>
> Zebediah Figura replied on the mailing list:
>
> |On 7/5/22 14:53, Paul Gofman wrote: @@ -602,9 +623,68 @@ static
> NTSTATUS try_recv( int fd, struct async_recv_ioctl *async, ULONG_PTR
> *siz } status = (hdr.msg_flags & MSG_TRUNC) ? STATUS_BUFFER_OVERFLOW :
> STATUS_SUCCESS; + if (async->fixup_type ==
> SOCK_PROT_FIXUP_ICMP_OVER_DGRAM) + { + unsigned int tot_len =
> sizeof(struct ip_hdr) + ret; + size_t len = hdr.msg_iov[0].iov_len; +
> char *buf = hdr.msg_iov[0].iov_base; + struct cmsghdr *cmsg; + struct
> ip_hdr ip_h; + + if (ret + sizeof(ip_h) > len) + status =
> STATUS_BUFFER_OVERFLOW; + + if (len < sizeof(ip_h)) + { + ret = len; +
> } + else + { + ret = min( ret, len - sizeof(ip_h) ); + memmove( buf +
> sizeof(ip_h), buf, ret ); + ret += sizeof(ip_h); + } + memset( &ip_h,
> 0, sizeof(ip_h) ); + ip_h.v_hl = (4 << 4) | (sizeof(ip_h) >> 2); +
> ip_h.tot_len = htons( tot_len ); + ip_h.protocol = 1; + ip_h.saddr =
> unix_addr.in.sin_addr.s_addr; + + for (cmsg = CMSG_FIRSTHDR( &hdr );
> cmsg; cmsg = CMSG_NXTHDR( &hdr, cmsg )) + { + if (cmsg->cmsg_level !=
> IPPROTO_IP) continue; + switch (cmsg->cmsg_type) + { +#if
> defined(IP_TTL) + case IP_TTL: + ip_h.ttl = *(BYTE *)CMSG_DATA( cmsg
> ); + break; +#endif +#if defined(IP_TOS) + case IP_TOS: + ip_h.tos =
> *(BYTE *)CMSG_DATA( cmsg ); + break; +#endif +#if defined(IP_PKTINFO)
> + case IP_PKTINFO: + { + struct in_pktinfo *info; + + info = (struct
> in_pktinfo *)CMSG_DATA( cmsg ); + ip_h.daddr = info->ipi_addr.s_addr;
> + break; + } +#endif + } + } + memcpy( buf, &ip_h, min( sizeof(ip_h),
> len )); + } Would you mind making this a helper function? try_recv()
> is already large and this seems to be pretty self-contained logic.|
|Sure.|
> |> if (async->control) > { > + if (async->fixup_type ==
> SOCK_PROT_FIXUP_ICMP_OVER_DGRAM) > + FIXME( "May return extra control
> headers.\n" ); > + What is this for?|
When initializing the fixup on server I am setting IP_RECVTTL,
IP_RECVTOS and IP_PKTINFO socket options. If the app is calling
recvmsg() it may get the headers it didn't request. My reasoning that
such a situation doesn't deserve further code complication to avoid but
deserves a fixme.
> |> @@ -737,17 +818,26 @@ static NTSTATUS sock_recv( HANDLE handle,
> HANDLE event, PIO_APC_ROUTINE apc, voi > } > } > > - SERVER_START_REQ(
> recv_socket ) > + do > { > - req->force_async = force_async; > -
> req->async = server_async( handle, &async->io, event, apc, apc_user,
> iosb_client_ptr(io) ); > - req->oob = !!(unix_flags & MSG_OOB); > -
> status = wine_server_call( req ); > - wait_handle =
> wine_server_ptr_handle( reply->wait ); > - options = reply->options; >
> - nonblocking = reply->nonblocking; > - } > - SERVER_END_REQ; > +
> SERVER_START_REQ( recv_socket ) > + { > + req->force_async =
> force_async; > + req->async = server_async( handle, &async->io, event,
> apc, apc_user, iosb_client_ptr(io) ); > + req->oob = !!(unix_flags &
> MSG_OOB); > + req->fixup_type = async->fixup_type; > + status =
> wine_server_call( req ); > + if (status ==
> STATUS_MORE_PROCESSING_REQUIRED) > + { > + async->fixup_type =
> reply->fixup_type; > + continue; > + } > + wait_handle =
> wine_server_ptr_handle( reply->wait ); > + options = reply->options; >
> + nonblocking = reply->nonblocking; > + } > + SERVER_END_REQ; > + }
> while (status == STATUS_MORE_PROCESSING_REQUIRED); > > alerted =
> status == STATUS_ALERTED; > if (alerted) I'm missing something; why do
> we need to call this in a loop? Why does the client needs to
> communicate the fixup type to the server in the first place?|
The async may be initiated on the server and delivered to the process
(through SIGUSR1)�� before we set async->fixup_type. It might be not
likely in practice, but I double verified that it is possible by
injecting Sleep(...) before setting fixup type to async structure from
server. So I need to make sure that fixup_type in async structure is
correctly set before try_recv() can be reached. So idea is, fixup_type
is "no fixup" by default, no extra server call is involved in normal
case. But if fixup is required and client does not yet know about it
server doesn't�� do anything and just returns fixup type with
STATUS_MORE_PROCESSING_REQUIRED.
> |> diff --git a/server/protocol.def b/server/protocol.def > index
> a8beccaf468..e1e5f3d9faa 100644 > --- a/server/protocol.def > +++
> b/server/protocol.def > @@ -1446,17 +1446,23 @@ enum server_fd_type >
> file_pos_t count; /* count of bytes to unlock */ > @END > > - > /*
> Perform a recv on a socket */ > @REQ(recv_socket) > int oob; /* are we
> receiving OOB data? */ > async_data_t async; /* async I/O parameters
> */ > int force_async; /* Force asynchronous mode? */ > + int
> fixup_type; /* protocol fixup type returned previously */ > @REPLY >
> obj_handle_t wait; /* handle to wait on for blocking recv */ >
> unsigned int options; /* device open options */ > int nonblocking; /*
> is socket non-blocking? */ > + int fixup_type; /* protocol fixup type
> (see below) */ > @END > +enum sock_prot_fixup_type > +{ > +
> SOCK_PROT_FIXUP_NONE, > + SOCK_PROT_FIXUP_ICMP_OVER_DGRAM, > +};
> Making this an enum strikes me as odd in general. A bitmask might make
> more sense, but frankly I'd just leave it as a dedicated field until
> we have something else that needs fixups. Do you have any plans for
> introducing other types of fixups?|
Well, originally I did something between the lines of this (had
icmp_over_dgram field in request / reply). But then I looked at that and
it felt odd that general recv_socket() has some special icmp related
fields, it felt like naming that "fixup_type" tells what it is without
going into very specific ICMP fixup details looking weird at this level.
If you feel like it is better to name it, e. g., "icmp_over_dgram" I can
change it back. I don't currently have any other types of fixups in mind.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/384#note_4045
Assassin's Creed Origins clobbers rbx in its main module (second of three) TLS callbacks. That is apparent right in the beginning of the TLS callback disassembly when rbx is set to '4' unconditionally without any prior save. That leads to a fault in call_tls_callbacks() which is still in __TRY block and gets handled. However the third TLS callback is not executed and that leads to intermittent hangs later on.
It is rather involved to make a TLS callback test in Wine testsuite as there is no portable way to generate a custom TLS callback. I've made a test program (based on the example here: https://lallouslab.net/2017/05/30/using-cc-tls-callbacks-in-visual-studio-w…) and compiled it with MSVC. The source code is here: https://gist.github.com/gofman/3287a953bcab3a5c888a8d494461cb8a. The program calls all the callbacks on Windows 10 here.
There is also a similar wrapper already there for i386 on another occasion.
--
v2: ntdll: Preserve rbx register when calling DLL entry point on x64.
https://gitlab.winehq.org/wine/wine/-/merge_requests/427
Jinoh Kang (@iamahuman) commented about dlls/user32/tests/msg.c:
> DeleteObject( hrgn2 );
> }
>
> +static void visualize_region_differences( HWND hwnd, HWND hother, HRGN hrgn_expect, HRGN hrgn_actual )
I included this function since it was really helpful for me while testing debugging the implementation--it eliminates the need to interpret the rectangle list manually. I can remove this if it clutters the test, though.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/363#note_4317
Jinoh Kang (@iamahuman) commented about server/async.c:
> return woken;
> }
>
> +static int cancel_blocking( struct process *process, struct thread *thread, client_ptr_t iosb )
> +{
> + struct async *async;
> + int woken = 0;
> +
> +restart:
> + LIST_FOR_EACH_ENTRY( async, &process->asyncs, struct async, process_entry )
> + {
> + if (async->terminated || async->canceled) continue;
There is a pre-existing bug where cancellation requests are ignored for alerted asyncs (i.e. async instances that are not actually completed and can go back from the "terminated" state to the pending state). Perhaps it's worth addressing that bug first? https://www.winehq.org/pipermail/wine-devel/2022-March/210053.html
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/47#note_3836
On Thu Jul 14 06:48:37 2022 +0000, Daniel Lehman wrote:
> in the exchange, it sounded like you had or were working on a fix. were
> you asking me to fix it or wait for your fix?
Well, it was actually more of a question than a suggestion. I just wondered if it would be a good idea to get I/O cancellation right first, lest rolling in another cancellation function would result in some unknown regression due to falsely indicated success from that function.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/47#note_4299
"The King of Fighters '98 Ultimate Match Final Edition" depends on
this behavior. At least, the build I have is; it seems other builds
are not.
Signed-off-by: Giovanni Mascellani <gmascellani(a)codeweavers.com>
--
v5: xactengine3_7/tests: Test notifications when loading a wave bank.
https://gitlab.winehq.org/wine/wine/-/merge_requests/398
On Sun Jul 10 17:41:42 2022 +0000, Jinoh Kang wrote:
> There is a pre-existing bug where cancellation requests are ignored for
> alerted asyncs (i.e. async instances that are not actually completed and
> can go back from the "terminated" state to the pending state). Perhaps
> it's worth addressing that bug first? https://www.winehq.org/pipermail/wine-devel/2022-March/210053.html
in the exchange, it sounded like you had or were working on a fix. were you asking me to fix it or wait for your fix?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/47#note_4275
The test shows that during RedrawWindow( ... RDW_ERASENOW ...) WM_NCPAINT delivery is not waited on the RedrawWindow() thread if the window is on another thread. It is still delivered directly to window procedure without showing up in PeekMessage(), and is processed synchronously if window is on the same thread. That corresponds to SendNotifyMessage() behaviour.
Fixes Warhammer: Vermintide 2 hanging during the game start. The game redraws desktop window (RedrawWindow(NULL, NULL, NULL, RDW_INVALIDATE | RDW_ERASE | RDW_ALLCHILDREN | RDW_ERASENOW | RDW_FRAME)). During that all the windows are getting updated and might be hitting that SendMessage in question. This hangs when it comes to the game's launcher's (minimized) window which is another process and doesn't process message queue at this point.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/452
All these patches are required to fix Cladun X2 crash at start.
--
v2: winex11.drv: Don't compare error event serial if it's zero.
winex11.drv: Lock display when expecting error events.
winex11.drv: Handle X errors from glXCopyContext().
https://gitlab.winehq.org/wine/wine/-/merge_requests/416
--
v4: mshtml: Use the private interface to expose onload for XMLHttpRequest.
mshtml: Implement overrideMimeType for XMLHttpRequest.
mshtml: Check for valid XML Content-Type for responseXML in IE10+ modes.
mshtml: Respect LOAD_CALL_CONTENT_SNIFFERS when using detected mime type.
mshtml: Set the channel's content type when parsing the header.
https://gitlab.winehq.org/wine/wine/-/merge_requests/399
This is the hidclass/ntoskrnl/setupapi counterpart to !359. As with that merge request, implementing `BusQueryContainerID` in the bus driver is left out and will be addressed in a different MR.
I believe this is useful to expose the Container ID no matter how those end up being assigned by the bus driver.
--
v8: ntoskrnl: Set device ContainerID from driver
https://gitlab.winehq.org/wine/wine/-/merge_requests/432
This is the hidclass/ntoskrnl/setupapi counterpart to !359. As with that merge request, implementing `BusQueryContainerID` in the bus driver is left out and will be addressed in a different MR.
I believe this is useful to expose the Container ID no matter how those end up being assigned by the bus driver.
--
v7: ntoskrnl: Set device ContainerID from driver
https://gitlab.winehq.org/wine/wine/-/merge_requests/432
This is the hidclass/ntoskrnl/setupapi counterpart to !359. As with that merge request, implementing `BusQueryContainerID` in the bus driver is left out and will be addressed in a different MR.
I believe this is useful to expose the Container ID no matter how those end up being assigned by the bus driver.
--
v6: ntoskrnl: Set device ContainerID from driver
https://gitlab.winehq.org/wine/wine/-/merge_requests/432
This is the hidclass/ntoskrnl/setupapi counterpart to !359. As with that merge request, implementing `BusQueryContainerID` in the bus driver is left out and will be addressed in a different MR.
I believe this is useful to expose the Container ID no matter how those end up being assigned by the bus driver.
--
v5: ntoskrnl: Set Device ContainerID from driver when registering an interface
ntoskrnl: Set device ContainerID from driver
hidclass: Expose ContainerID
hidclass: Copy device ContainerID to child devices
hidclass: Copy ContainerID from underlying driver in driver_add_device
hidclass: Improve error handling in get_device_id
ntoskrnl/tests: Add test for getting SPDRP_BASE_CONTAINERID from PnP driver
setupapi: Add support for SPDRP_BASE_CONTAINERID
https://gitlab.winehq.org/wine/wine/-/merge_requests/432
Vulkan pipelines should be destroyed only after the last command buffer using
the pipeline is done executing. Since we do not track which pipelines are
encoded into which command buffers, defer destruction until the current command
buffer finishes.
It feels unfortunate to do this from the shader backend, and introducing something
like wined3d_shader_vk etc. seems more in line with what we do with other objects.
I'm not sure that the complication is worth it in this case.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/443
--
v3: mshtml: Use the private interface to expose onload for XMLHttpRequest.
mshtml: Implement overrideMimeType for XMLHttpRequest.
mshtml: Check for valid XML Content-Type for responseXML in IE10+ modes.
mshtml: Respect LOAD_CALL_CONTENT_SNIFFERS when using detected mime type.
mshtml: Set the channel's content type when parsing the header.
https://gitlab.winehq.org/wine/wine/-/merge_requests/399
--
v2: mshtml: Use the private interface to expose onload for XMLHttpRequest.
mshtml: Implement overrideMimeType for XMLHttpRequest.
mshtml: Check for valid XML Content-Type for responseXML in IE10+ modes.
mshtml: Respect LOAD_CALL_CONTENT_SNIFFERS when using detected mime type.
mshtml: Set the channel's content type when parsing the header.
https://gitlab.winehq.org/wine/wine/-/merge_requests/399
--
v2: mfplat/tests: Merge and reorganize image format tests.
mfplat/buffer: Support YV12, I420 and IYUV image formats.
mfplat/tests: Mark some tests as broken on Win 8 and 10 v1507.
https://gitlab.winehq.org/wine/wine/-/merge_requests/418
This is the hidclass/ntoskrnl/setupapi counterpart to !359. As with that merge request, implementing `BusQueryContainerID` in the bus driver is left out and will be addressed in a different MR.
I believe this is useful to expose the Container ID no matter how those end up being assigned by the bus driver.
--
v4: ntoskrnl/tests: Add test for getting SPDRP_BASE_CONTAINERID from PnP driver
https://gitlab.winehq.org/wine/wine/-/merge_requests/432
--
v3: wineusb.sys: Move the event queue and device list to the Unix library.
wineusb.sys: Move the event threads to IRP_MN_START_DEVICE.
wineusb.sys: Move the event handling loop to the Unix library.
wineusb.sys: Queue pending IRPs after submitting the URB.
https://gitlab.winehq.org/wine/wine/-/merge_requests/428
This is the hidclass/ntoskrnl/setupapi counterpart to !359. As with that merge request, implementing `BusQueryContainerID` in the bus driver is left out and will be addressed in a different MR.
I believe this is useful to expose the Container ID no matter how those end up being assigned by the bus driver.
--
v3: ntoskrnl: Set Device ContainerID from driver when registering an interface
ntoskrnl: Set device ContainerID from driver
ntoskrnl: Improve error handling in get_device_id
hidclass: Expose ContainerID
hidclass: Copy device ContainerID to child devices
hidclass: Copy ContainerID from underlying driver in driver_add_device
https://gitlab.winehq.org/wine/wine/-/merge_requests/432
libOVR brings a message window topmost claiming that this way it receives
WM_DEVICECHANGE faster. Currently, in Wine, this causes a WM_KILLFOCUS to
be sent to the actual topmost window, which in turn causes "Shantae: Risky's
Revenge" to minimize. The effect is that the game automatically minimizes
as soon as it is launched, which is incorrect.
Signed-off-by: Giovanni Mascellani <gmascellani(a)codeweavers.com>
--
v2: win32u/window: Ignore SetWindowPos() for message-only windows.
user32/tests: Check that a message window brought topmost does not defocus other windows.
https://gitlab.winehq.org/wine/wine/-/merge_requests/419
This is required to keep `riched20:richole test_clipboard()` from crashing once `ITextDocument::Undo` is implemented.
--
v2: riched20: Ensure MEPF_COMPLEX is unset when in password input mode.
https://gitlab.winehq.org/wine/wine/-/merge_requests/422
--
v3: win32u: Use KeUserModeCallback interface for DDE message callbacks.
win32u: Use KeUserModeCallback for ImmProcessKey and ImmTranslateMessage calls.
win32u: Move default IME window management from imm32.
imm32: Don't allow disabling other thread's IME by thread ID.
imm32/tests: Add more tests for disabling IME.
imm32/tests: Add NtUserAssociateInputContext tests.
win32u: Move window input context handling from imm32.
https://gitlab.winehq.org/wine/wine/-/merge_requests/434
This is the hidclass/ntoskrnl/setupapi counterpart to !359. As with that merge request, implementing `BusQueryContainerID` in the bus driver is left out and will be addressed in a different MR.
I believe this is useful to expose the Container ID no matter how those end up being assigned by the bus driver.
--
v2: ntoskrnl: Set Device ContainerID from driver when registering an interface
ntoskrnl: Set device ContainerID from driver
ntoskrnl: Improve error handling in get_device_id
hidclass: Expose ContainerID
hidclass: Copy device ContainerID to child devices
hidclass: Copy ContainerID from underlying driver in driver_add_device
hidclass: Improve error handling in get_device_id
https://gitlab.winehq.org/wine/wine/-/merge_requests/432
--
v2: win32u: Use KeUserModeCallback interface for DDE message callbacks.
win32u: Use KeUserModeCallback for ImmProcessKey and ImmTranslateMessage calls.
win32u: Move default IME window management from imm32.
imm32: Don't allow disabling other thread's IME by thread ID.
imm32/tests: Add more tests for disabling IME.
imm32/tests: Add NtUserAssociateInputContext tests.
win32u: Move window input context handling from imm32.
https://gitlab.winehq.org/wine/wine/-/merge_requests/434
This is the hidclass/ntoskrnl/setupapi counterpart to !359. As with that merge request, implementing `BusQueryContainerID` in the bus driver is left out and will be addressed in a different MR.
I believe this is useful to expose the Container ID no matter how those end up being assigned by the bus driver.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/432
This series:
- cleanups some code (using bitfield instead of hardcoded constants)
- silences some FIXMEs in SymGetTypeInfo
- fixes a couple of erroneous lexical relationship among dbghelp objects
(mainly attaching - as native does - some objects to SymTagExe object)
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/430
On Mon Jul 11 15:14:43 2022 +0000, Jinoh Kang wrote:
> How about the following race-free approach?
> ```suggestion:-0+0
> /* wait for I/O to start, which transitions the pipe handle from
> signaled to nonsignaled state. */
> while ((wait_status = WaitForSingleObject(pipe, 0)) ==
> WAIT_OBJECT_0) Sleep(1);
> ok(wait_status == WAIT_TIMEOUT, "WaitForSingleObject returned %lu
> (error %lu)\n", wait_status, GetLastError());
> ```
> Ditto for other places.
i had copied the `Sleep(100)` from one of the sync.c tests, i think. but if it makes the test less flaky, i'll take it. thanks!
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/47#note_3919