Mohamad Al-Jaf (@maljaf) commented about dlls/windows.devices.geolocation.geolocator/Makefile.in:
> +MODULE = windows.devices.geolocation.geolocator.dll
Isn't this supposed to be in `geolocation.dll`?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3189#note_38255
When there are no caches, this variable would be uninitialized.
Reported by clang-scan.
Not sure if that can ever happen, but IMHO initializing doesn't do harm.
--
v2: kerberos: Avoid potentially uninitialized variable (clang-scan)
https://gitlab.winehq.org/wine/wine/-/merge_requests/3058
Recent nameless struct/union changes broke MSVC Clang builds. That's because `VARIANT` still doesn't skip names when `__STDC__` is defined, which is true for most configs.
--
v2: include: Don't force named VARIANT members when __STDC__ is defined.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3256
This MR optimizes and makes correctness improvements to the window_surface flush implementation:
1. Implement a buffer queue to avoid constantly allocating new buffers.
2. Take into account the bounds of the window_surface flush and track per-buffer damage to reduce copying from the window_surface.
3. Copy from the window_surface only pixel data that lies within the flushed bounds. Maintain the latest contents for pixels outside these bounds, by copying them from the latest valid buffer.
4. Communicate damaged surface regions to the compositor to allow it to perform more efficient pixel data transfers (e.g., texture uploads).
Thanks!
--
v3: winewayland.drv: Send surface damage region to the compositor.
winewayland.drv: Update only the flushed bounds from the window_surface.
winewayland.drv: Track damaged buffer regions.
winewayland.drv: Use a buffer queue for window_surface.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3234
Recent nameless struct/union changes broke MSVC Clang builds. That's because `VARIANT` still doesn't skip names when `__STDC__` is defined, which is true for most configs.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3256
This is similar to https://gitlab.winehq.org/wine/wine/-/merge_requests/2684, https://gitlab.winehq.org/wine/wine/-/merge_requests/3004 or https://gitlab.winehq.org/wine/wine/-/merge_requests/3139 but it validates the session transform node behavior with tests.
The tests are added after the changes because they otherwise don't pass and making them pass would be unnecessarily complicated.
I also have some local tests for MF_TOPONODE_WORKQUEUE_ID attributes and how it is supposed to behave. It basically creates new serialized work queues for every source node and assign them to every node downstream. Any sample request or processing operation is done in the associated queue.
When joining streams, queues are assigned downstream one after another and the last assigned queue is used when requesting samples upstream, but when samples are received and processed downstream it looks like the current queue of the source node is used for every downstream operations.
The request behavior seems to be the same when work queues are used, with round robin input requests, and single ProcessInput call followed by ProcessOutput loop until it fails.
This is yet not optimally efficient, and could be improved, for the following reasons:
1) All session operations are serialized together, even unrelated streams, and ProcessInput / ProcessOutput calls may be costly and stalling the pipeline. I believe that native probably allows parallel processing of unrelated stream requests, this needs to be confirmed.
2) MFT_MESSAGE_COMMAND_DRAIN message use isn't ideal, the message forces the transform to process all queued input synchronously, which can take a long time. I haven't checked exactly what native does but I believe it instead uses MFT_MESSAGE_NOTIFY_END_OF_STREAM messages, which would allow us to notify and drain the GStreamer decoder asynchronously.
3) MFT_MESSAGE_COMMAND_DRAIN also doesn't distinguish between input streams and needs to be sent globally. It's unclear how it should be used when multiple input streams are involved, and when one stream ends its segment then start a new segment while other streams don't have yet reached EOS. MFT_MESSAGE_NOTIFY_END_OF_STREAM messages have a stream ID parameter and would be more appropriate to handle separate input streams independently.
--
v2: mf/tests: Add more media session transform tests with multiple inputs.
mf/tests: Add more media session transform tests with multiple outputs.
mf/tests: Add some media session transform call pattern tests.
mf/session: Increase the stream request count when requests are already queued.
mf/session: Request more samples from upstream when necessary.
mf/session: Push transform input samples one by one to ProcessInput.
mf/session: Use helpers to push and pop samples for transform streams.
mf/session: Flush requests in transform_node_deliver_samples when drained.
mf/session: Use a helper to deliver transform node requested samples.
mf/session: Use local variables to access transform node streams.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3245
This also converts the opaque pointers passed across the PE->Unix interface to opaque types
represented as UINT64 which store the unix side pointer. This makes the thunking simpler and should
avoid anyone accidently dereferencing the unix pointer in the PE code.
This was tested with warcraft 3 (1.26, the last non-reforged release), and is consistent with the standard 32bit build. ~~But since movies on warcraft 3 are broken in standard 32bit builds I could only test that that the gstreamer graph gets built up similarly and not verify the video playback. Id appreciate if someone knew of a working exercise of the gstreamer code.~~ it works great, the issue with cinematics ended up being related to modesetting under xwayland, running with a virtual desktop in winecfg confirms playback working perfectly.
--
v8: Fixup: define sized bool and enums in params
Fixup: assert struct sizes with bool/enum
Fixup: designated initializers
winegstreamer: Implement Wow64 entrypoints in the Unix library.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3075
This also converts the opaque pointers passed across the PE->Unix interface to opaque types
represented as UINT64 which store the unix side pointer. This makes the thunking simpler and should
avoid anyone accidently dereferencing the unix pointer in the PE code.
This was tested with warcraft 3 (1.26, the last non-reforged release), and is consistent with the standard 32bit build. ~~But since movies on warcraft 3 are broken in standard 32bit builds I could only test that that the gstreamer graph gets built up similarly and not verify the video playback. Id appreciate if someone knew of a working exercise of the gstreamer code.~~ it works great, the issue with cinematics ended up being related to modesetting under xwayland, running with a virtual desktop in winecfg confirms playback working perfectly.
--
v7: Fixup: define sized bool and enums in params
Fixup: assert struct sizes with bool/enum
Fixup: designated initializers
winegstreamer: Implement Wow64 entrypoints in the Unix library.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3075
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54699
I added the complete `windows.networking.idl` file since it was small and in case it's needed for mingw build.
--
v2: windows.networking.hostname: Implement IHostName::get_RawName().
windows.networking.hostname: Implement IHostNameFactory::CreateHostName().
windows.networking.hostname/tests: Add IHostNameFactory::CreateHostName() tests.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3249
On Wed Jul 5 17:57:30 2023 +0000, Gabriel Ivăncescu wrote:
> Ok I'll send one with just the win32u change. I didn't even know there
> was a fullscreen clip option, guess I'll just use that. :-)
By default it is off but Wine still sometimes decides to clip cursor when windows are fullscreen. There's a limited use for that and I don't even know why it's there because it's only enabled if there's a single monitor. I suspect it is to handle the case where the host screen has a task bar that isn't part of Wine virtual screen or something like that.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1153#note_38070