> There is probably some tiny DVD somewhere in the world that will still be misdetected, but I'm not sure that issuing SCSI commands to the drive to try to determine the disc type would be any more reliable.
To support an app that is most likely going to issue DVD ioctls, checking by using a DVD ioctl seems preferable.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7747#note_104243
--
v2: wineandroid: Use win32u for EGL display and pixel formats.
winewayland: Use win32u for EGL display and pixel formats.
win32u: Implement OpenGL pixel formats over EGL configs.
win32u: Introduce an EGL opengl_driver_function table.
winewayland: Use the EGL display opened from win32u.
wineandroid: Use the EGL display opened from win32u.
win32u: Open and initialize an EGL platform display.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8115
And a couple of other minor and (hopefully) harmless changes, in preparation for !8079 as it would otherwise grow large.
The main thing here is the introduction of _MOTIF_WM_HINTS into the state tracker, changing the property can trigger unexpected ConfigureNotify events and we will need to serialize its updates with other _NET_WM_STATE and window config requests in order to avoid getting surprised and confused.
It will also later be useful to be able to track further consequences of _MOTIF_WM_HINTS changes on Mutter-based window managers, such as a ReparentNotify > UnmapNotify > FocusOut > MapNotify > FocusIn > ConfigureNotify event sequence, to eventually ignore the transient focus loss and avoid changing Win32 foreground window during it.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8123
On Thu May 22 12:47:26 2025 +0000, Hans Leidekker wrote:
> That was my first guess too :) Perhaps I'm missing something but this
> appears to encrypt in-place. It seems to me that you would need to pass
> a separate SECBUFFER_STREAM buffer that is large enough to hold data + token.
Shouldn't also work {NULL,0} as a SECBUFFER_STREAM output?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8020#note_104216
Windows uses a smaller alignment than gstreamer for some formats, for
example NV12. This means we cannot use MFCalculateImageSize() to get the
output sample size. Commit 7b79e3a87b1e switched to calling it instead of
GetOutputStreamInfo() to fix some game bugs.
--
v2: mfplat/tests: Add NV12 650 x 850 to image_size_tests.
mf/tests: Add a video processor NV12 test with a width alignment of 2.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8034
On Thu May 22 12:41:19 2025 +0000, Dmitry Timoshkov wrote:
> I was mentioning the part about using SECBUFFER_STREAM in
> DecryptMessage(). It was my guess that EncryptMessage() is supposed to
> support the mirroring logic of using SECBUFFER_DATA as input and
> SECBUFFER_STREAM as output buffers.
That was my first guess too :) Perhaps I'm missing something but this appears to encrypt in-place. It seems to me that you would need to pass a separate SECBUFFER_STREAM buffer that is large enough to hold data + token.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8020#note_104208
On Thu May 22 12:32:42 2025 +0000, Hans Leidekker wrote:
> They don't pass a SECBUFFER_STREAM buffer in that sample.
I was mentioning the part about using SECBUFFER_STREAM in DecryptMessage(). It was my guess that EncryptMessage() is supposed to support the mirroring logic of using SECBUFFER_DATA as input and SECBUFFER_STREAM as output buffers.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8020#note_104207
On Thu May 22 11:10:27 2025 +0000, Dmitry Timoshkov wrote:
> Why not? EncryptMessage() would get SECBUFFER_DATA as input and
> SECBUFFER_STREAM as output buffers.
They don't pass a SECBUFFER_STREAM buffer in that sample.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8020#note_104206
On Thu May 22 11:10:27 2025 +0000, Hans Leidekker wrote:
> Yes, I had seen that. Note that it wouldn't make the issue of buffer
> layout
> differences between NTLM and Kerberos go away for EncryptMessage().
Why not? EncryptMessage() would get SECBUFFER_DATA as input and SECBUFFER_STREAM as output buffers.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8020#note_104199
This MR fixes seek in VRChat by copying the sequence of flushes/stop/starts that Windows does.
The order on Windows is:
1. Stop sources;
2. Flush MFTs;
3. Start sources;
4. Request output down the chain of sink inputs;
6. Flush sinks; and
7. Start the clock
This takes place whether we pause before we seek or seek without pause.
Changes in version 2:
1. Add test to see when SAR requests new samples;
2. Add test to examine when step 4 from above takes place;
3. Adjust the seek implementation in `mf/session.c` to match findings from the new tests
4. Adjust `mfmediaengine` to reflect findings from the new tests
--
v2: mfmediaengine: Request sample if we are seeking.
mfmediaengine: Don't perform implicit flush on state change.
mf: Don't send MFT_MESSAGE_NOTIFY_START_OF_STREAM when seeking.
mf: Restart transforms and sinks on seek.
mf/tests: Test sequence of calls during a Pause and Seek.
mf/tests: Test when SAR requests a new sample.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7932
In CopyFileEx, and DeleteFile functions, by default, the file name
and path are limited to MAX_PATH characters. To extend this limit
to 32,767 wide characters, need prepend "\\\\?\\" to the path.
--
v8: kernelbase: Limit the maximum path length for DeleteFile.
kernelbase: Fix DeleteFileA doesn't support long path.
kernelbase: Limit the maximum path length for filesystem.
ntdll: Check if long path aware is enabled.
kernel32/tests: Add tests for maximum path length limitation.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7540
On Thu May 22 09:05:46 2025 +0000, Rémi Bernon wrote:
> Looks like I broke focus again with this in some cases, some WMs use
> _NET_ACTIVE_WINDOW = None more often than others (and FVWM would fall in
> that category as spurious test failures seem to suggest) and it causes
> spurious focus loss.
> I don't have a good solution here, either revert this entirely and
> consider this as an XWayland problem, and that it should probably focus
> the root window instead when losing foreground to a Wayland window, or
> check ourselves for XWayland presence and enable this conditionally.
I'm saying XWayland but it's not clear where this effect is coming from, might be more complicated than that and perhaps it's not something that can be fixed in one place.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8108#note_104179
Looks like I broke focus again with this in some cases, some WMs use _NET_ACTIVE_WINDOW = None more often than others (and FVWM would fall in that category as spurious test failures seem to suggest) and it causes spurious focus loss.
I don't have a good solution here, either revert this entirely and consider this as an XWayland problem, and that it should probably focus the root window instead when losing foreground to a Wayland window, or check ourselves for XWayland presence and enable this conditionally.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8108#note_104178
--
v4: widl: Write the guid stream.
widl: Write the blob stream.
widl: Write the user string stream.
widl: Write the string stream.
widl: Initial support for generating Windows Runtime metadata.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8037
The object reference is actually held by ref_weak.
--
v3: geolocation: Use DEFINE_WEAKREF to implement IWeakReference.
windows.ui: Use DEFINE_WEAKREF to implement IWeakReference.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8078
The object reference is actually held by ref_weak.
--
v2: geolocation: Use DEFINE_WEAKREF to implement IWeakReference.
windows.ui: Use DEFINE_WEAKREF to implement IWeakReference.
windows.ui: Return a newer IUISettings5 interface.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8078
This fixes failure to play the prologue video in Planet of the Apes: Last Frontier, which unpauses by calling Start() with a location. The exact state leading to this issue does not occur in the Start() tests, and it's not clear how to reproduce it reliably.
--
v6: mf: Reset transform nodes when seeking.
mf: Initialise the grabber sample count when setting state after a seek.
mf: Set pending requests for transform outputs to zero on flush.
mf: Reset transform node outputs when seeking.
mf: Flush nodes before restarting a paused source at a specific position.
mf: Drop transform node input events when unpausing at a specific position.
mf: Reset transforms before restarting a paused source instead of after.
mf: Move transform node reset to a helper function.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7466
Only 64-bit targets for now. Enabling this on 32-bit x86 requires additional work, as we need to provide exception helpers for modules that don’t link against msvcrt/ucrt. LLVM currently does not support `__try`/`__except` on 32-bit ARM.
While `__try`/`__except` is generally available on the MinGW target with `-fms-extensions`, `-fasync-exceptions` is currently supported only on the MSVC target. For that reason, I did not enable it for the MinGW target.
--
v2: include: Enable compiler exceptions on Clang for 64-bit MSVC targets.
configure: Enable -fasync-exceptions when supported.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8112
Only 64-bit targets for now. Enabling this on 32-bit x86 requires additional work, as we need to provide exception helpers for modules that don’t link against msvcrt/ucrt. LLVM currently does not support `__try`/`__except` on 32-bit ARM.
While `__try`/`__except` is generally available on the MinGW target with `-fms-extensions`, `-fasync-exceptions` is currently supported only on the MSVC target. For that reason, I did not enable it for the MinGW target.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8112
--
v4: wineandroid: Use the EGL functions loaded from win32u.
winewayland: Use the EGL functions loaded from win32u.
win32u: Load EGL and expose functions in opengl_funcs.
include: Generate EGL prototypes and ALL_EGL_FUNCS macro.
win32u: Move the opengl_funcs tables out of the drivers.
win32u: Initialize opengl_funcs tables even on failure.
win32u: Pass opengl_funcs pointer to init_wgl_extensions.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8103
--
v3: wineandroid: Use the EGL functions loaded from win32u.
winewayland: Use the EGL functions loaded from win32u.
win32u: Load EGL and expose functions in opengl_funcs.
include: Generate EGL prototypes and ALL_EGL_FUNCS macro.
win32u: Move the opengl_funcs tables out of the drivers.
win32u: Initialize opengl_funcs tables even on failure.
win32u: Pass opengl_funcs pointer to init_wgl_extensions.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8103
--
v3: widl: Write the guid stream.
widl: Write the blob stream.
widl: Write the user string stream.
widl: Write the string stream.
widl: Initial support for generating Windows Runtime metadata.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8037
--
v2: wineandroid: Use the EGL functions loaded from win32u.
winewayland: Use the EGL functions loaded from win32u.
win32u: Load EGL and expose functions in opengl_funcs.
win32u: Move the opengl_funcs tables out of the drivers.
win32u: Initialize opengl_funcs tables even on failure.
win32u: Pass opengl_funcs pointer to init_wgl_extensions.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8103
--
v6: libs/ldap: Add support for missing ISC_RET_CONFIDENTIALITY in the server response.
libs/ldap: sasl_encode()/sasl_decode() should treat encrypted buffer as data + token for Kerberos.
libs/ldap: When initializing security context ask for mutual authentication.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8020
XWayland changes _NET_ACTIVE_WINDOW to None when focus switches to a
Wayland window. This makes sure app window is deactivated in that case
too and not just when focus changes to another X11 window.
_NET_ACTIVE_WINDOW also changes None when alt-tab is initiated, but
there's no easy way to tell the difference, so this will also trigger
a focus loss as soon as alt-tab is initiated, while we were previously
waiting for it to actually complete to make changes.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8108
1. For %fs/fsbase the patch follows the macOS logic with LDT descriptor registration and Linux with switching. One notable difference is that on 32->64 transition we set %fs to GSEL(GUFS32_SEL, SEL_UPL) before restoring fsbase, otherwise FreeBSD will just revert it by reloading the selector [at the first opportunity](https://github.com/freebsd/freebsd-src/blob/5673462af5330df207…. GSEL(GUFS32_SEL, SEL_UPL) is the default %fs value on FreeBSD and is special-cased to save/restore actual fsbase value to/from PCB.
2. I was told we could get rid of fsbase glitches in signal handlers by blocking signals with [sigfastblock(2)](https://man.freebsd.org/cgi/man.cgi?query=sigfastblock) between %fs reset to the default value and fsbase reset to pthread_teb. This is currently a part of internal API for libthr, which could be exposed as pthread_signal_block_np for Wine. I'm on the fence whether it's worth it.
3. I fully admit I have no idea what registers are worth preserving around fallback sysarch(AMD64_SET_FSBASE) syscalls and whether it's appropriate to push those registers to stack. ("Kernel" stack should be fine, I assume?) Syscalls definitely clobber r8-r11.
4. For %ss see https://lkml.org/lkml/2015/4/24/216. FreeBSD doesn't have a similar workaround in the kernel, so it goes into Wine.
--
v3: ntdll: Unbreak new wow64 mode on FreeBSD.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8073
I hope I read the code right: if `DLL_PROCESS_ATTACH` fails, `DllMain` will immediately be called again with `DLL_PROCESS_DETACH`, which will try to destroy the already destroyed `PSDRV_Heap`.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8019
--
v4: libs/ldap: sasl_decode() should treat intput buffer as data + token for Kerberos.
libs/ldap: sasl_encode() should construct output buffer as data + token for Kerberos.
libs/ldap: When initializing security context ask for mutual authentication.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8020
Wayland has 3 types of scrolling events:
- axis. Used for e.g., touchpad 2 finger smooth scrolling
- axis_discrete. Used for mouse scroll wheels (i.e., notches)
- axis_value120. Used for high resolution input devices
Wine currently only supports axis_discrete, meaning that
2 finger scroll events get ignored.
This commit tries to add basic support for axis scrolling events,
by translating the smooth motion in scroll increments using some
primitive assumptions about line height and number of lines to scroll.
--
v11: wip! winewayland.drv: Try to support smooth scroll events
https://gitlab.winehq.org/wine/wine/-/merge_requests/4809