- wine-gitlab - winehq.org

[PATCH v4 0/1] MR180: vkd3d-shader/hlsl: Partially implement static expressions evaluation.
by Nikolay Sivov (＠nsivov) 01 May '23

01 May '23

-- v4: vkd3d-shader/hlsl: Partially implement static expressions evaluation. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/180

3 3

[PATCH 0/4] MR191: tests: Add more interesting HLSL tests for mipmap levels.
by Zebediah Figura (＠zfigura) 01 May '23

01 May '23

-- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/191

2 4

[PATCH 0/3] MR2727: hrtfapo: Add CreateHrtfApo() stub.
by Mohamad Al-Jaf (＠maljaf) 01 May '23

01 May '23

Needed by Britannia VR: Out of Your Mind. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2727

3 4

Re: [PATCH v2 0/3] MR2727: hrtfapo: Add CreateHrtfApo() stub.
by Zebediah Figura (＠zfigura) 01 May '23

01 May '23

Zebediah Figura (@zfigura) commented about include/hrtfapoapi.idl: > + float unityGainDistance; > + float cutoffDistance; > +} HrtfDistanceDecay; > + > +typedef struct HrtfApoInit > +{ > + HrtfDistanceDecay *distanceDecay; > + HrtfDirectivity *directivity; > +} HrtfApoInit; > + > +cpp_quote("STDAPI CreateHrtfApo(const HrtfApoInit *init, IXAPO **xapo);") > + > +[ > + object, > + uuid(15b3cd66-e9de-4464-b6e6-2bc3cf63d455), > + pointer_default(unique) You don't need the pointer_default(unique) attribute; it's the default. Yes, it's everywhere in Wine headers, but it's really unnecessary. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2727#note_31597

1 0

Re: [PATCH v2 0/3] MR2727: hrtfapo: Add CreateHrtfApo() stub.
by Zebediah Figura (＠zfigura) 01 May '23

01 May '23

Zebediah Figura (@zfigura) commented about include/hrtfapoapi.idl: > + HrtfDirectivity *directivity; > +} HrtfApoInit; > + > +cpp_quote("STDAPI CreateHrtfApo(const HrtfApoInit *init, IXAPO **xapo);") > + > +[ > + object, > + uuid(15b3cd66-e9de-4464-b6e6-2bc3cf63d455), > + pointer_default(unique) > +] > +interface IXAPOHrtfParameters : IUnknown > +{ > + HRESULT SetSourcePosition([in] const HrtfPosition *position); > + HRESULT SetSourceOrientation([in] const HrtfOrientation *orientation); > + HRESULT SetSourceGain([in] float gain); > + HRESULT SetEnvironment([in] HrtfEnvironment environment); You don't need these [in] attributes; they only matter for remoting. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2727#note_31598

1 0

Re: [PATCH v2 0/3] MR2727: hrtfapo: Add CreateHrtfApo() stub.
by Zebediah Figura (＠zfigura) 01 May '23

01 May '23

Zebediah Figura (@zfigura) commented about dlls/hrtfapo/main.c: > + * version 2.1 of the License, or (at your option) any later version. > + * > + * This library is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with this library; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA > + */ > + > +#include "hrtfapoapi.h" > +#include "wine/debug.h" > + > +WINE_DEFAULT_DEBUG_CHANNEL(hrtfapo); Let's use the existing xaudio2 channel here. And in general, matching the style used in xaudio2 would probably be good. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2727#note_31599

1 0

Re: [PATCH v2 0/3] MR2727: hrtfapo: Add CreateHrtfApo() stub.
by Zebediah Figura (＠zfigura) 01 May '23

01 May '23

Zebediah Figura (@zfigura) commented about include/hrtfapoapi.idl: > +typedef struct HrtfDistanceDecay > +{ > + HrtfDistanceDecayType type; > + float maxGain; > + float minGain; > + float unityGainDistance; > + float cutoffDistance; > +} HrtfDistanceDecay; > + > +typedef struct HrtfApoInit > +{ > + HrtfDistanceDecay *distanceDecay; > + HrtfDirectivity *directivity; > +} HrtfApoInit; > + > +cpp_quote("STDAPI CreateHrtfApo(const HrtfApoInit *init, IXAPO **xapo);") You can declare this directly in the IDL. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2727#note_31596

1 0

[PATCH 0/4] MR2726: wine{alsa,coreaudio,oss,pulse}: Move SimpleAudioVolume into mmdevapi.
by Davide Beatrici (＠davidebeatrici) 29 Apr '23

29 Apr '23

Please note that with this MR the following `TRACE()` calls are removed: - `"ALSA does not support volume control\n"` - `"OSS doesn't support setting volume\n"` - `"PulseAudio does not support session volume control\n"` Should I perhaps move them to the specific drivers' unixlib instead? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2726

3 6

[PATCH v2 0/1] MR189: tests: Add a test for arrays with an expression as the index.
by Ethan Lee (＠flibitijibibo) 29 Apr '23

29 Apr '23

See https://bugs.winehq.org/show_bug.cgi?id=54832 I'm starting to see this particular FIXME in quite a few games (Escape Goat 2, Murder Miners, and Little Racers STREET to name a few), and since I'm not sure how to fix this I figured I could at least provide a test for someone that knows more SM4 than me :P -- v2: tests: Add a test for arrays with an expression as the index. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/189

2 1

Re: [PATCH v3 0/1] MR499: server: Allow cancelling alerted asyncs.
by Jinoh Kang (＠iamahuman) 29 Apr '23

29 Apr '23

On Sat Apr 29 14:54:15 2023 +0000, Jinoh Kang wrote: > To reduce complexity, I've tried refactoring the state management. > Currently, the async has the following two state flags that deal with > the state of the client that originally requested the async: > - `signaled`: indicates whether the async object is signaled; the client > may wait on the async handle before returning from the corresponding > wine system call. > - Valid transition: 0 -> 1. > - This flag is set if only if any of the following conditions are true: > - Given that `!async->blocking`, > - `async_wake_obj(async)` has been called when > `async->unknown_status = 0`, or > - `async_handoff(async, ...)` has been called with `get_error() != > STATUS_ALERTED && (async->pending || !NT_ERROR(get_error()) && > (get_error() != STATUS_PENDING || async->iosb->status != STATUS_PENDING)`. > - (Regardless of `async->blocking`) `async_set_result(async, status, > ...)` has been called with `async->terminated && (!async->alerted || > status != STATUS_PENDING)`. > - Note that this flag exhibits slightly different behavior depending > on `async->blocking`. > - If `async->blocking`, it tries to block the requestor until the > async operation has completed. > - If `!async->blocking`, it tries to signal as soon as the initial > status is known, _unless_ the wait handle is being closed, in which case > it doesn't bother to touch the flag at all. > - If signaled and a wait on the async object is satisfied, the > requestor function should have performed the synchronous completion > sequence (either directly or via APC\_ASYNC\_IO) before the wait is > satisfied, unless `async->pending`. > - `direct_result`: from Wine codebase, `a flag if we're passing result > directly from request instead of APC`. > - Valid transition: 1 -> 0 (after set to 1 from `create_request_async`). > - Whenever async state is settled, the flag is set if all of the > following conditions are true: > - The async was created via create_request_async(), and > - async_set_unknown_status() has not been called, and > - The async handle has never been waited on (wait consumes the > flag), and > - Any of: > - async_handoff() has not been called, or > - From async_handoff(), the async is terminated or alerted synchronously. > - The flag has the following effect: > - For each async_terminate() call, it will send APC_ASYNC_IO if and > only if !direct_result. > - For each async handle wait satisfaction, it will call > async_set_result() if and only if direct_result. > We can observe the following from above: > - The flags are defined in terms of what the flags *do* rather than what > the value of the flags *mean*. It doesn't help that the transitions for > each flag are quite scattered and sparse. > - Their behaviors are dependent on the client-side async implementation, > so reasoning about them requires verifying how the requestor side behaves. > - Depending on other part of the async object state, one or more flags > may be left unobserved and thus ignored, effectivly becoming a "don't > care" bit. > This increases complexity and hinders maintenance in my opinion. In > particular, it's difficult to determine precisely *when* the flag is or > should be set or unset. > I'd propose that the constituent conditions of each flag be refactored > into separate state variables first. Paradoxically, it may even help > combine two or more binary flags into an enum as the semantics become > more simpler. Independent of above, I'm thinking about introducing a new `completed` flag and replacing `terminated` with `completed || alerted`. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/499#note_31580

1 0

2025

2024

2023

2022

wine-gitlab