On Fri Jun 2 17:22:54 2023 +0000, Huw Davies wrote:
> Could you split this MR into two or three smaller ones? - just force
> push the first few commits to this one, then, once this is merged, send
> the next one.
Done.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2934#note_34477
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!
--
v2: winewayland.drv: Implement a simple window_surface flush.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2944
Some of these fixes are subtle (like the first patch) and very annoying to debug. Although the first patch looks like a hack, surprisingly, it's how the spec itself says it is! It's not even an IE quirk, but a special case in the spec.
For example, the variable name (which holds the builtin eval func) **does** matter: if it's called something other than 'eval', it gets treated differently (as if indirect), and this is verified by the tests + the spec's wording (so Microsoft's implementation follows it).
Most of the patches other than the first 2 are pretty small so they're in same MR.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2942
To be merged after !2907.
--
v3: wineoss: Use mmdevapi's AudioClient's GetService.
winecoreaudio: Use mmdevapi's AudioClient's GetService.
winealsa: Use mmdevapi's AudioClient's GetService.
winepulse: Move AudioClient's GetService into mmdevapi.
wineoss: Use mmdevapi's session_wrapper_create.
winecoreaudio: Use mmdevapi's session_wrapper_create.
winealsa: Use mmdevapi's session_wrapper_create.
winepulse: Move session_wrapper_create into mmdevapi.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2908
This allows access to the in-process cached monitor list and reduces the number of registry calls issued for QueryDisplayConfig (in case of no change) from `4 x monitors` to `1`.
--
v2: win32u: Move QueryDisplayConfig from user32.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2957
This allows access to the in-process cached monitor list and reduces the number of registry calls issued for QueryDisplayConfig (in case of no change) from `4 x monitors` to `1`.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2957
--
v3: ntdll: Add return address information in __wine_debug_context.
ntdll: Add file and line information in __wine_debug_context.
ntdll: Introduce struct __wine_debug_context for extensible debug info.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2274
The aim of this serie is to (re)implement dbghelp.EnumerateLoadedModules
in order to return correct 32bit & 64bit modules information for a 32bit
debuggee from a 64bit debugger.
- In this case, Wine ntdll (incorrectly) stores the paths in LdrData
(for system modules) within the syswow64 directory while native stores
them within the system32 directory
(except for 32bit ntdll which Wine correctly stores within system32).
- So now dbghelp implements the system32 => syswow64 path rewrite (for
the relevant cases), which is currently used only for ntdll.
- This allows:
- to be transparent in dbghelp if ntdll is fixed to store the same
path as native
- the paths returned by dbghelp are consistent with native (in the
64bit debugger / 32bit debuggee case mentionned above)
It must be noted that the remaining todo:s in tests are only for
the case of a 32bit debugger / 32bit debuggee in (old|new) wow setup,
where the returned paths are the (untouched from ntdll) paths, hence
in syswow64 when native reports them from system32.
- this patch doesn't modify the returned path, and we haven't noticed
any issue so far
- with redirection in place, access to the image files should be
tranparent
- so we can keep it as is (not fixing ntdll).
--
v2: dbghelp: Reimplement EnumerateLoadedModules().
dbghelp/tests: Add more test wrt. modules's imagename handling.
dbghelp/test: Review old-wow64 expected values.
dbghelp/tests: Fix process kind detection on old Windows machines.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2830
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.
--
v11: ws2_32/tests: Add test for AF_UNIX sockets.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2786
--
v2: xaudio2: Use the preprocessor to modify definitions in xaudio2.idl and xaudio2fx.idl.
xaudio2: Create XAPO objects directly from CreateAudioVolumeMeter() and CreateAudioReverb().
xaudio2: Move CreateAudioVolumeMeter() and CreateAudioReverb() to xapo.c.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2918
This is to prevent NULL pointers when creating a standalone text service
that doesn't have any text set and then using functions like EM_SETSEL.
This NULL pointers doesn't happen when creating a richedit windows, because
it sets an empty text when the richedit window procedure handles the WM_CREATE event.
--
v2: riched20: Set empty text by default in CreateTextServices.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2941
On Thu Jun 1 17:15:46 2023 +0000, Zebediah Figura wrote:
> > Well I don't know that, it's been mostly a week without any activity
> and it's not the first time winegstreamer MR have been left unnoticed. I
> have been upstreaming winegstreamer patches for a big part of last year
> and the slow iteration have been making it very difficult. We have
> patches piling up in Proton once again, and diverging implementations
> already. I would very much like to avoid getting in the same situation
> as we've been.
> It had been six days, which is nominally a bit slow, but the slowness
> was largely due to (a) multiple winegstreamer patches from you in that
> time [and while I appreciate smaller patch series, that doesn't mean
> that I'm going to review three patch series all in the same day], (b)
> the weekend, (c) a US holiday during which I wasn't doing any work, and
> (d) patch 5/5 which does multiple things at once and was therefore hard
> to read.
> > I don't think these changes present any risk, they have been
> thoroughly tested, by Paul and I, but also with a lot of Wine tests, and
> the changes have been in Proton for a long while already. I also
> maintain wg_transform and their client, so, although I'm happy to take
> constructive comments, I'm ultimately going to be responsible for the changes.
> As I've stated when the issue of maintainership was brought up last, I
> still would very much like to be consulted on winegstreamer changes.
> Whether they have been tested or not, I find that winegstreamer code has
> been getting increasingly complex and difficult to maintain, in ways
> that are fixable and in ways that aren't, and I see things that can be
> improved in many incoming winegstreamer patches.
> If you want to call for no-confidence in my maintainership, fine, but
> please let's be clear about that and not abuse gitlab.
It is not a matter of no-confidence, although I could argue that being told that my statements are non-sensical in several occasions isn't a great way to build confidence. Perhaps a matter of diverging opinions, but moreover it is a matter of trying hard to keep downstream from diverging.
I took maintainership of the wg_transform code, not just because I wrote most of it, but also in order to help with the bandwidth, and avoid bothering two persons on every single change. I believe I have taken every comment into account very carefully, and haven't bypassed your review or Nikolay's for MF related things, on any meaningful change.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2901#note_34369
> Well I don't know that, it's been mostly a week without any activity and it's not the first time winegstreamer MR have been left unnoticed. I have been upstreaming winegstreamer patches for a big part of last year and the slow iteration have been making it very difficult. We have patches piling up in Proton once again, and diverging implementations already. I would very much like to avoid getting in the same situation as we've been.
It had been six days, which is nominally a bit slow, but the slowness was largely due to (a) multiple winegstreamer patches from you in that time [and while I appreciate smaller patch series, that doesn't mean that I'm going to review three patch series all in the same day], (b) the weekend, (c) a US holiday during which I wasn't doing any work, and (d) patch 5/5 which does multiple things at once and was therefore hard to read.
> I don't think these changes present any risk, they have been thoroughly tested, by Paul and I, but also with a lot of Wine tests, and the changes have been in Proton for a long while already. I also maintain wg_transform and their client, so, although I'm happy to take constructive comments, I'm ultimately going to be responsible for the changes.
As I've stated when the issue of maintainership was brought up last, I still would very much like to be consulted on winegstreamer changes. Whether they have been tested or not, I find that winegstreamer code has been getting increasingly complex and difficult to maintain, in ways that are fixable and in ways that aren't, and I see things that can be improved in many incoming winegstreamer patches.
If you want to call for no-confidence in my maintainership, fine, but please let's be clear about that and not abuse gitlab.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2901#note_34367
On Thu Jun 1 16:21:55 2023 +0000, Zebediah Figura wrote:
> > Rémi Bernon removed review request for @zfigura May 31, 2023, 10:57 AM
> Please don't do that.
> In this case it's fine since I've reviewed the patch and was going to
> sign off on it anyway.
Well I don't know that, it's been mostly a week without any activity and it's not the first time winegstreamer MR have been left unnoticed. I have been upstreaming winegstreamer patches for a big part of last year and the slow iteration have been making it very difficult. We have patches piling up in Proton once again, and diverging implementations already. I would very much like to avoid getting in the same situation as we've been.
I don't think these changes present any risk, they have been thoroughly tested, by Paul and I, but also with a lot of Wine tests, and the changes have been in Proton for a long while already. I also maintain wg_transform and their client, so, although I'm happy to take constructive comments, I'm ultimately going to be responsible for the changes.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2901#note_34365
The application again the bug, passed 1 as the elem parameter which
doubled the memory being allocated. When it overflowed (became negative),
the value was passed into GlobalAlloc16 which then failed.
GlobalAlloc16 takes a DWORD parameter, so the value isn't going to be truncated.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53092
Original patch by github user cracyc for winevdm.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2947
To be merged after !2907.
--
v2: wineoss: Use mmdevapi's AudioClient's GetService.
winecoreaudio: Use mmdevapi's AudioClient's GetService.
winealsa: Use mmdevapi's AudioClient's GetService.
winepulse: Move AudioClient's GetService into mmdevapi.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2908
--
v2: win32u: Use WM_WINE_CLIPCURSOR / TRUE for empty clipping rect.
win32u: Add a separate function to process WM_WINE_CLIPCURSOR.
win32u: Move cursor clipping functions to input.c.
win32u: Move some window functions to window.c.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2936
Clang requires the __getReg function to be declared in addition to
be declared as an intrinsic with the pragma.
This fixes the following error:
../wine/include/winnt.h:2412:27: error: call to undeclared library function '__getReg' with type 'unsigned long long (int)'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
return (struct _TEB *)__getReg(18);
^
../wine/include/winnt.h:2412:27: note: include the header <intrin.h> or explicitly provide a declaration for '__getReg'
1 error generated.
Signed-off-by: Martin Storsjö <martin(a)martin.st>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2935
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!
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2944
This region is currently only reserved for 32-bit processes, which puts Wow64 at a disadvantage. The larger address space means it's not often an issue, but it's better to be explicit. Adding the reservation also causes ntdll/unix/virtual.c to consider that region first when making Wow64 allocations, before continuing through to the lower reservations. (And that's important for, e.g., changes like MR !2879.)
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2943
This seems to be a holdover from when ntdll was a Mach-O winelib
binary, so the reservation needed to be removed before it was
dlopen'd. Now that it's PE, unmapping the reservation is unnecessary
and leaves time for the system to reclaim it, thus requiring the
potentially problematic relocation of ntdll.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2879
This is to prevent NULL pointers when creating a standalone text service
that doesn't have any text set and then using functions like EM_SETSEL.
This NULL pointers doesn't happen when creating a richedit windows, because
it sets an empty text when the richedit window procedure handles the WM_CREATE event.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2941
To be merged after !2906.
--
v3: wineoss: Use mmdevapi's AudioClient2.
winecoreaudio: Use mmdevapi's AudioClient2.
winealsa: Use mmdevapi's AudioClient2.
winepulse: Move AudioClient2 into mmdevapi.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2907
Indexing with non-constants offsets requires relative addressing in SM4. In assembly, this is written like in the following example:
```
x1[r1.x + 3]
```
The first part of this patch series only includes support for indexing vectors with non-constant indexes.
Following patches in https://gitlab.winehq.org/fcasas/vkd3d/-/commits/nonconst-offsets-3.
---
Non-constant indexing of vectors cannot be implemented with relative addressing in SM4 because this
indexation cannot be performed at the level of register-components, only whole registers.
Mathematical operations must be used instead.
For floats, the native compiler seems to index an identity matrix, to
get the i-th column, and then proceedes to compute the dot product
between that column and the vector. For ints, bit operations seem to be
performed.
While probably less efficient, this implementation complies with the
type-checking at the IR level and when writing bytecode.
--
v3: vkd3d-shader/hlsl: Support non-constant vector indexing.
vkd3d-shader/hlsl: Lower dot for non-float types.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/207
This fixes some crashes especially when dealing with very long C++ names
(like template classes).
Fortunately, dwarf internals don't require type lookup by name (eg.
on forward declaration), so the impact of thrashing some names is limited.
It's very likely native doesn't store directly these very long names
(it could either store the qualified mangled name - which can be way shorter
for template classes - or use the names in lexical hierarchy: both boil down
to storing less information, and recompute it (unmangle or class hierarchy
walk) upon request).
But this would need a proper C++ support in dbghelp. Not for today.
Signed-off-by: Eric Pouech <epouech(a)codeweavers.com>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2932
--
v3: wineoss: Use mmdevapi's AudioClient3.
winecoreaudio: Use mmdevapi's AudioClient3.
winealsa: Use mmdevapi's AudioClient3.
winepulse: Move AudioClient3 into mmdevapi.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2906
The first patch is unrelated and a fix to a dumb mistake; I had forgotten that toggle() is a method and methods can have NULL output pointers (when return value is not needed), unlike getters. Sorry for the noise.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2924
MSVC is too stupid to see that line 3058 will not run unless n_variants
has been set together with variants in the switch statement below.
--
v3: vkd3d-shader/hlsl: Make sure variants is initialized in declare_predefined_types().
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/171
--
v2: vkd3d: Append CopyTileMappings() commands to the command queue op array.
vkd3d: Append UpdateTileMappings() commands to the command queue op array.
vkd3d: Add missing const attributes to ID3D12CommandQueue::UpdateTileMappings() parameters.
vkd3d: Validate plane count for tiled textures.
vkd3d: Validate tiled resources tier for 3D textures.
vkd3d: Always pass null heap properties to vkd3d_create_image() for sparse images.
vkd3d: Check sparse image format is supported.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/216