On Mon Nov 14 12:05:16 2022 +0000, Zebediah Figura wrote:
> Side note that just occurs to me, we should probably add thread
> descriptions for any new threads, though I don't mind deferring that.
Good idea, done.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1311#note_15681
On Fri Nov 11 21:23:39 2022 +0000, Zebediah Figura wrote:
> > First because it's how it's supposed to be.
> I initially thought that we weren't actually running any visible
> callbacks on these read threads, but I guess the allocation callbacks
> are coming from here. Windows really spawns two threads for each stream? Sheesh.
Yes.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1311#note_15679
On Fri Nov 11 21:26:14 2022 +0000, Zebediah Figura wrote:
> I think we'd still need that GetStreamSelected() check, though, given
> we're looping over all the streams here?
I don't think we need to check it here anymore with the latest version. Deselected streams will never have pending read requests (or they will shortly complete it after deselection, with either error or a last sample).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1311#note_15680
On Fri Nov 11 21:17:44 2022 +0000, Zebediah Figura wrote:
> Hmm, I never tested selecting streams while running. If that's supposed
> to work it may be better just to leave it as is.
Yeah, starting / stopping threads dynamically didn't seem like a good idea and it's easier to check the correctness with all stream threads started on open / stopped on close.
So instead I keep the thread running but only emit read requests to selected streams. When a stream is deselected, eventually dynamically, it will either fail its read request with `NS_E_NO_MORE_SAMPLES`, or returns a last sample if that happened before, but will then stop receiving read requests.
When a stream is selected again, a read request will be emitted and it will resume reading.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1311#note_15678
On Fri Nov 11 21:18:28 2022 +0000, Zebediah Figura wrote:
> Yeah, if we need to do this to prevent a deadlock, that sounds to me
> like something we need to solve on the sync reader side.
I dropped it for now.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1311#note_15677
Overwatch 2 verifies that every kernel callback that is run, lives in user32. Introduce a callback in user32 that just forwards to the other modules' callbacks.
--
v14: user32: Remove NtUserDriverCallback* kernel callbacks.
winex11.drv: Route kernel callbacks through user32.
winex11.drv: Pass a struct to x11drv_ime_set_result.
winex11.drv: Pass a struct to x11drv_dnd_post_drop.
winemac.drv: Route kernel callbacks through user32.
wineandroid.drv: Route kernel callbacks through user32.
opengl32: Route kernel callbacks through user32.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1180
This is my first time implementing an interface so thorough feedback would be appreciated.
--
v2: windows.media: Implement IClosedCaptionPropertiesStatics interface.
include/windowscontracts: Bump contractversion to 14.
windows.media: Add stub DLL.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1343
Co-authored-by: Joel Holdsworth <joel(a)airwebreathe.org.uk>
Signed-off-by: Joel Holdsworth <joel(a)airwebreathe.org.uk>
--
v2: ntdll: Add support for FreeBSD style extended attributes.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1315
Based on a patch by Jinoh Kang:
https://gitlab.winehq.org/wine/wine/-/merge_requests/155
This patch simplifies the comment somewhat; I don't see it as necessary to fully
explain the concept of memory barriers and acquire/release everywhere that they
are used. In my opinion, it's necessary and also sufficient to explain why these
specific places need an acquire/release pair, what that pair is protecting, and
to cross-reference the parts of the pair with each other.
I've also removed the IOSB aliasing patches. Personally I think that there's no
harm in making our code more endianness-conscious, for things like Winelib, but
on the other hand Windows never supported big-endian, and we've resisted adding
support for architectures Windows doesn't support (and see also [1]). Since it's
not clear to me they're desirable, and they're orthogonal to the purpose of this
patch set, I've removed them; they can be submitted later if there is a
favourable consensus.
[1] https://www.winehq.org/pipermail/wine-devel/2021-July/191600.html
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1342
GCC 12.2 rightfully complains about an out-of-founds array access.
This can possibly happen for unsupported variable names.
This is a rudimentary fix (don't write outside of array), but current
code will require more cudling (eg: native runs the loop for every parsed
token even if the variable name isn't supported) while builtin stops
parsing.
Signed-off-by: Eric Pouech <eric.pouech(a)gmail.com>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1346
- v2: Specify the maximum allowed feature level when creating the device.
- v3: Rebased.
- v4: Use a flag to indicate that indirect draws won't be used.
--
v4: wined3d: Use the chunk allocator for GL element array buffers.
wined3d: Introduce a new flag to indicate that indirect draws won't be used.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1307
--
v6: uiautomationcore: Add support for returning multiple HUIANODEs from UiaFind.
uiautomationcore: Store traverse_uia_node_tree() results in a dynamic array.
uiautomationcore: Add support for ExcludeRoot parameter in UiaFind.
uiautomationcore: Partially implement UiaFind.
uiautomationcore: Add UiaFind stub.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1249
--
v5: uiautomationcore: Add support for returning multiple HUIANODEs from UiaFind.
uiautomationcore: Store traverse_uia_node_tree() results in a dynamic array.
uiautomationcore: Add support for ExcludeRoot parameter in UiaFind.
uiautomationcore: Partially implement UiaFind.
uiautomationcore: Add UiaFind stub.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1249
Overwatch 2 verifies that every kernel callback that is run, lives in user32. Introduce a callback in user32 that just forwards to the other modules' callbacks.
--
v13: user32: Remove NtUserDriverCallback* kernel callbacks.
winex11.drv: Route kernel callbacks through user32.
winex11.drv: Pass a struct to x11drv_ime_set_result.
winex11.drv: Pass a struct to x11drv_dnd_post_drop.
winemac.drv: Route kernel callbacks through user32.
wineandroid.drv: Route kernel callbacks through user32.
opengl32: Route kernel callbacks through user32.
winevulkan: Route kernel callbacks through user32.
user32: Add NtUserDispatchCallback kernel callback.
user.exe16: Move kernel callbacks to wow_callbacks.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1180
The function is implemented by setting cache file pointer to fill
read_buf. Consequently, when HTTPREQ_ReadFile is called, it will try
reading data from cache after read_buf is depleted, before continuing
reading from http stream.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=26570
--
v7: wininet: Partially implement InternetSetFilePointer
wininet/tests: Add InternetSetFilePointer tests.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1268
The partial free is not supported from VirtualFree (we have a test for that) but NtFreeVirtualMemory supports it.
The primary motivation behind these patches is the preparation for VM placeholders support. With those flags (MEM_RESERVE_PLACEHOLDER, MEM_PRESERVE_PLACEHOLDER, MEM_REPLACE_PLACEHOLDER and MEM_COALESCE_PLACEHOLDERS) views might be arbitrary split or joined with just page alignment.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1339
--
v4: uiautomationcore: Add support for returning multiple HUIANODEs from UiaFind.
uiautomationcore: Store traverse_uia_node_tree() results in a dynamic array.
uiautomationcore: Add support for ExcludeRoot parameter in UiaFind.
uiautomationcore: Partially implement UiaFind.
uiautomationcore: Add UiaFind stub.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1249
--
v3: uiautomationcore: Add support for returning multiple HUIANODEs from UiaFind.
uiautomationcore: Store traverse_uia_node_tree() results in a dynamic array.
uiautomationcore: Add support for ExcludeRoot parameter in UiaFind.
uiautomationcore: Partially implement UiaFind.
uiautomationcore: Add UiaFind stub.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1249
It is possible that a stream is destroyed while another thread is waiting on
event_empty_cond or event_cond. The waiting thread should have the opportunity
to be rescheduled and exit the critical section before the condition variables
and the mutex are destroyed.
--
v2: winegstreamer: Do not destroy condition variables when a thread is waiting on them.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1278
Allows the Adobe Photoshop Elements installer to get slightly further than before
The `E_FAIL` check for switching to int while there's a non-integer string isn't needed for the installer and is just something I hit accidentally when trying to write the test cases. Should I leave it in?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1338
--
v2: uiautomationcore: Add support for returning multiple HUIANODEs from UiaFind.
uiautomationcore: Store traverse_uia_node_tree() results in a dynamic array.
uiautomationcore: Add support for ExcludeRoot parameter in UiaFind.
uiautomationcore: Partially implement UiaFind.
uiautomationcore: Add UiaFind stub.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1249
Just a few miscellaneous fixes I think are simple enough to make it into the next version.
--
v2: vkd3d-shader/hlsl: Revert expr_compatible_data_types() args names to "t1" and "t2".
vkd3d-shader/hlsl: Don't produce a parse error on empty buffer_body.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/48
> Why was this merged, knowing that it caused a significant performance drop across a wide range of games? Why was it necessary to not even wait for merge request 1324 to be finalized?
Because it's going in the right direction, it would be good to have in 8.0, and we don't want to merge it at the last minute. The performance fixes can be merged up until code freeze (or even after, depending on how intrusive they are).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1322#note_14030
On Fri Nov 11 03:17:20 2022 +0000, Zebediah Figura wrote:
> Why was this merged, knowing that it caused a significant performance
> drop across a wide range of games? Why was it necessary to not even wait
> for merge request 1324 to be finalized?
I wonder did we real need this ?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1322#note_14022
On Thu Nov 10 16:40:43 2022 +0000, Rémi Bernon wrote:
> It's for a MR that hasn't been rebased on top of latest HEAD and doesn't
> contain this change.
I've reverted it for now, until we can figure out why it's causing failures.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1304#note_13991
The server's idea of the cursor position is never really initialized. Normally that's not a problem, since the first mouse movement and a number of other X events will update it. But in the case where the user never moves the mouse, it can remain out of sync. That manifests as `GetCursorPos` bouncing between the server's incorrect value and the real one from the user driver, depending on the age of the position on the server.
I've marked this as a draft for two reasons:
1. I don't quite know where this belongs. We want to do it early in the lifespan of a user driver but after there's a desktop, so I've put it behind a `pthread_once` called from `get_desktop_window`.
2. I'm calling `NtUserSetCursorPos` to update the server, rather than a direct `set_cursor` request, because it contains some DPI logic. That has the side effect of potentially warping the cursor. That's not desirable or necessary, but it shouldn't be a problem. It's easily factored around if we want to avoid it.
Any guidance would be greatly appreciated!
--
v2: win32u: Initialize the server's cursor position from the user driver's.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1250
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53741
--
v2: ntdll: Implement RtlSetUserFlagsHeap.
ntdll: Check block user flags in RtlGetUserInfoHeap.
ntdll: Check block user flags in RtlSetUserValueHeap.
ntdll: Store the user flags in the heap block flags.
ntdll: Introduce a new heap block_set_flags helper.
kernel32/tests: Test (Global|Local)Handle with heap allocated pointers.
kernel32/tests: Test more Global/Local functions with invalid pointers.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1312
Performance hit measured on a few games (with esync and wined3d), CPU% is the time spent in the syscall dispatcher as measured with `perf top -K` while the game is running, the measured scene is usually right after starting a new game:
* Brink (32-bit, GL, id Tech 4): 550 fps, 3% CPU -> 480 fps, 12% CPU
* Shadow Warrior 2 (64-bit, d3d11): 75 fps, 2% CPU -> 50 fps, 20% CPU
* Hat in Time (64-bit, d3d9, UE3): 220 fps, 5% CPU -> 215 fps, 10% CPU
* Control (64-bit, d3d11): 25 fps, 0% CPU -> 25 fps, 3% CPU
* Obduction (64-bit, d3d11, UE4): 85 fps, 30% CPU -> 80 fps, 30% CPU
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1322
On Thu Nov 10 14:15:17 2022 +0000, Zhiyi Zhang wrote:
> It's hard to tell if it's caused by this commit. I can not reproduce
> this with Ubuntu 22.10 GNOME 43. Then I switched to FVWM and
> successfully reproduced the failures. However, just as when I tried to
> bisect, all the failures are gone. I also tried to create a new prefix
> with f7e1bb9(right before this commit), then apply this patch and rerun
> the tests, but still no failures. After applying the patch, I manually
> copied the new light.msstyles to the old prefix, no failures. Then
> toggling the theming status or recreating the prefix with 9f3138b can
> not reproduce those failures either.
> Those failures also look unrelated to the theming changes.
Reverting that single commit fixes the Gitlab pipeline, see https://gitlab.winehq.org/rbernon/wine/-/pipelines/4066 vs https://gitlab.winehq.org/rbernon/wine/-/pipelines/4064. It's perhaps something with missing fonts?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1304#note_13944
On Thu Nov 10 14:15:18 2022 +0000, Rémi Bernon wrote:
> I believe this broke Gitlab CI, this is the only pipeline that failed
> from yesterday, in user32, and it now fails with all MRs.
It's hard to tell if it's caused by this commit. I can not reproduce this with Ubuntu 22.10 GNOME 43. Then I switched to FVWM and successfully reproduced the failures. However, just as when I tried to bisect, all the failures are gone. I also tried to create a new prefix with f7e1bb9(right before this commit), then apply this patch and rerun the tests, but still no failures. After applying the patch, I manually copied the new light.msstyles to the old prefix, no failures. Then toggling the theming status or recreating the prefix with 9f3138b can not reproduce those failures either.
Those failures also look unrelated to the theming changes.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1304#note_13939
v2: Specify the maximum allowed feature level when creating the device.
v3: Rebased.
--
v3: wined3d: Use the chunk allocator for GL element array buffers.
wined3d: Specify the maximum allowed feature level when creating the device.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1307
This MR also contains a few fixes and missing conversions support. We no longer need 32-bit types outside vulkan_thunks.c, so we can default to host struct layouts and use `WINE_VK_HOST` in unixlib. This essentially means that vulkan.c is ready for wow64 (vulkan_thunks.c still needs more patches, mostly applying conversions to more types). Instead of defining *_host types, use local *32 types in generated thunks.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1323
v2: Specify the maximum allowed feature level when creating the device.
--
v2: wined3d: Use the chunk allocator for GL element array buffers.
wined3d: Specify the maximum allowed feature level when creating the device.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1307
On Wed Nov 9 23:47:19 2022 +0000, Georg Lehmann wrote:
> Did you already report the various xml inconsistencies you found? We
> should get them fixed and remove the hard coded workarounds when we
> update the xml to a new enough version.
Not yet, but I definitely agree that we should fix it in upstream xml instead. I keep finding them while reviewing generated code, so my plan was to report it once my work is more complete. There is still more code that will need to be generated for wow64. I have one more fixup in my tree, but I'm not yet sure if that list is complete.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1303#note_13912