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!
--
v5: 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
I have found some scripts where comparisons that use floats and OLECOLOR directly fail. For example:
```
If Light005.State Then
' State is a float V_R4
End If
If Light005.Colorfull Then
' Colorfull is an OLECOLOR VT_UI4
End If
```
This is because `stack_pop_bool` does not handle `VT_R4` and `VT_UI4` and returns `E_NOTIMPL`.
This adds additional types to `stack_pop_bool` similar to `VARIANT_Coerce`.
Fixes https://bugs.winehq.org/show_bug.cgi?id=54731
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2507
On Wed Jun 21 09:30:59 2023 +0000, Zhiyi Zhang wrote:
> I think it will be better if you can report different driver versions
> for different vendors. For example, NVIDIA, AMD, and Intel drivers
> should have different versions. You can use gpu->vendor_id to
> differentiate them. For other vendors, either report a 1.0.0 version or
> simply don't add this property.
It might be good, but that variable doesn't contain any ID, only zero. I tried running games and applications.
Probably, it could work in ValveSoftware/Wine when they update their repository.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3104#note_36443
Both window station visibility and session id are related to services being
spawned in a non-interactive session, however the process window station
can be manually set by the application while the session id can not be.
The enumerated display config should not change even in the case of a
window station update, hence testing for SessionId == 0 is more reliable
here.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55074
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3130
--
v2: wineoss: Use mmdevapi's AudioClient's Initialize.
winecoreaudio: Use mmdevapi's AudioClient's Initialize.
winealsa: Use mmdevapi's AudioClient's Initialize.
winepulse: Move AudioClient's Initialize into mmdevapi.
winepulse: Refactor AudioClient's Initialize to match other drivers.
wineoss: Use create_stream's channel count in AudioClient's Initialize.
winecoreaudio: Use create_stream's channel count in AudioClient's Initialize.
winealsa: Use create_stream's channel count in AudioClient's Initialize.
winepulse: Use mmdevapi's set_stream_volumes.
wineoss: Use mmdevapi's set_stream_volumes.
winecoreaudio: Use mmdevapi's set_stream_volumes.
winealsa: Use mmdevapi's set_stream_volumes.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3112
On my Nvidia GeForce GTX 1050 Ti `ddxddy.shader_test` doesn't pass because of considerably different numeric results.
As Giovanni pointed out, this is because my GPU uses the fine derivate and not the coarse derivate to implement ddx() and ddy().
For this reason, the result for ddx|ddy() is quantized so that the test passes if the GPU uses either coarse or fine derivates.
Additionally, tests for both ddx_coarse|ddy_coarse() and ddx_fine|ddy_fine() are added, that expect a more precise result.
--
v3: vkd3d-shader/hlsl: Support fine derivates.
vkd3d-shader/hlsl: Support coarse derivates.
tests: Quantize regular and coarse derivate test results.
tests: Make ddx() and ddy() test behave correctly for shader models < 4.
tests: Test coarse and fine derivates.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/224