February 2024 - Wine-bugs - list.winehq.org

[Bug 56315] New: Package wine-mono for Debian
by WineHQ Bugzilla 11 Feb '24

11 Feb '24

https://bugs.winehq.org/show_bug.cgi?id=56315 Bug ID: 56315 Summary: Package wine-mono for Debian Product: Packaging Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: wine-packages Assignee: wine-bugs(a)winehq.org Reporter: shtetldik(a)gmail.com CC: dimesio(a)earthlink.net Distribution: --- It would be nice to have Wine-mono packaged for Debian and be available in Wine repos in order to avoid manually installing it in /opt/... every time there is a version bump that Wine expects. Those who don't want to use the packaged version for whatever reason (i.e. preferring per prefix installation for example) could simply not install the package. But everyone else could benefit from more automation. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 56314] New: MPEG-1 video playback does not properly resize screen
by WineHQ Bugzilla 11 Feb '24

11 Feb '24

https://bugs.winehq.org/show_bug.cgi?id=56314 Bug ID: 56314 Summary: MPEG-1 video playback does not properly resize screen Product: Wine Version: 9.1 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: cthielen(a)gmail.com Distribution: --- Created attachment 76042 --> https://bugs.winehq.org/attachment.cgi?id=76042 Screenshot showing the video in the corner. It should be fullscreen. Ultima IX has MPEG-1 based video playback that is now working thanks to https://bugs.winehq.org/show_bug.cgi?id=9127 being fixed. Thanks for everyone who helped out there! However, now the video playback only appears in the upper-left corner of the screen. It isn't clipped, but it looks like the system is failing to change screen resolution. These videos playback fullscreen on Windows. See attached for a visual. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 56210] New: Very slow event processing (seconds)
by WineHQ Bugzilla 11 Feb '24

11 Feb '24

https://bugs.winehq.org/show_bug.cgi?id=56210 Bug ID: 56210 Summary: Very slow event processing (seconds) Product: Wine Version: 9.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: nagle(a)animats.com Distribution: --- The Windows event queue, as emulated under Wine, appears to work differently than the real one under Windows 10. If you build my Rust test program, ui-mock, arc branch: [code] git clone https://github.com/John-Nagle/ui-mock.git cd ui-mock git checkout arc cargo build --release --target x86_64-pc-windows-gnu --examples cd target/x86_64-pc-windows-gnu/release/examples wine ui-mock.exe [/code] it will run fine under real Windows 10. But, built on Ubuntu 22.04 LTS with current Rust, it behaves strangely. Click on one of the big bars that says "placeholder", and you get get a login popup. It doesn't do anything; this is just a GUI dummy. Type something into the user name box. On real Windows, characters are echoed at full speed. [b]Under Wine 8 or 9, character echo is delayed about 3-4 seconds.[/b] What seems to be happening is that the endless refreshing of the screen (this is a game-type program) is starving out event processing. This uses the Rust crates Rend3, Winit, egui, and wgpu, all of which work cross-platform. A newer version of Rend3 (see the Cargo.toml file for the rev number) has a different approach to the event loop. There are two callback functions - "event", and "redraw" in Rend3's framework. The framework itself does a request-redraw at the end of each redraw. This seems to starve out non-redraw event processing. An earlier version of Rend3 did not have this problem. That older version can be built as above, by removing the line git checkout arc This uses a different version of the Rend3 framework, one which only redraws when the event queue is empty. "winit", a standard Rust crate, claims in its documentation that non-redraw events are always processed before redraws. But "winit", which has platform-dependent code for Windows, seems to assume, in the Windows platform code, that the underlying platform event queue does that. For real Windows, it does seem to do that. But Wine's event queue does not seem to work that way. If someone reports this problem in a commercial game, it's probably going to be reported as "keys are sluggish". Here, you have sources for everything and can reproduce the problem. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 56313] New: InstallShield is crashed when complete the setup
by WineHQ Bugzilla 10 Feb '24

10 Feb '24

https://bugs.winehq.org/show_bug.cgi?id=56313 Bug ID: 56313 Summary: InstallShield is crashed when complete the setup Product: Wine-staging Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: matnazarovsobirjon123(a)gmail.com CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Distribution: --- Created attachment 76041 --> https://bugs.winehq.org/attachment.cgi?id=76041 Wine dialog ask me to save this logs Hello Wine Team! I received an exception from Wine when I installed the NetSupport Manager program, its installer is InstallShield as I understand it. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 56312] New: Vulkan is broken for me after certain commits
by WineHQ Bugzilla 10 Feb '24

10 Feb '24

https://bugs.winehq.org/show_bug.cgi?id=56312 Bug ID: 56312 Summary: Vulkan is broken for me after certain commits Product: Wine Version: 9.1 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: winevulkan Assignee: wine-bugs(a)winehq.org Reporter: airidaslideikis(a)gmail.com Distribution: --- Created attachment 76035 --> https://bugs.winehq.org/attachment.cgi?id=76035 Contains Vulkan assert error. So after February 6 commits, I can't get Vulkan to work anymore. I'm suspecting it has to do with Vulkan headers update, because right before Vulkan headers were updated - Vulkan was working fine. My system - Samsung Galaxy S23U with Snapdragon 8 Gen 2, Termux-glibc prefix, latest dev build of box64, Mesa 24.1.0 latest dev build, latest dev build of Wine 9.1. Right before it got updated to Wine 9.2. Same error occurs when using DXVK. I enabled Vulkan renderer on WineD3D just to make a problem more in line with Wine and exclude any external factors. Funnily enough, if I switch WineD3D to use OpenGL, it works fine. Utilizes zink without an issue. Oh and by the way, same exact issue happens on vanilla and with staging patches. This means staging patches aren't at fault here. Couldn't bother reinstalling vanilla Wine for the same exact issue. Added a log which confirms Vulkan failure. I'll try reverting vulkan header update, because this is pretty much the only suspicious thing that's keeping Vulkan from working to my eyes. Or, it could also be Mesa bug. I'm completely lost here. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 14010] New: RivaTuner 2.09 not work ,no overclocking or sensor ability
by wine-bugs＠winehq.org 10 Feb '24

10 Feb '24

http://bugs.winehq.org/show_bug.cgi?id=14010 Summary: RivaTuner 2.09 not work ,no overclocking or sensor ability Product: Wine Version: 1.0.0 Platform: All OS/Version: Linux Status: UNCONFIRMED Severity: critical Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: dj--alex(a)ya.ru RivaTuner 2.09 not work ,no overclocking or sensor ability My videocard is very loud without this program!! I and not only i, want to overclocking without BIOS VRAM rewrite. Program can be downloaded free from http://www.radeon.ru/ (Main menu left - newest version) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

2 4

[Bug 56250] New: Elite Dangerous client gets stuck on black screen after launch
by WineHQ Bugzilla 09 Feb '24

09 Feb '24

https://bugs.winehq.org/show_bug.cgi?id=56250 Bug ID: 56250 Summary: Elite Dangerous client gets stuck on black screen after launch Product: Wine Version: 9.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: d3d Assignee: wine-bugs(a)winehq.org Reporter: brendan(a)redmandi.com Distribution: --- When using WINE_D3D_CONFIG='renderer=vulkan' to launch Elite, the game will launch but then get stuck on a black screen. The problem appears to be related to the following entry in the log: fixme:d3d11:d3d11_device_CheckFeatureSupport Unhandled feature 0xe. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 56259] New: Microsoft Webview 2 installer hangs forever
by WineHQ Bugzilla 09 Feb '24

09 Feb '24

https://bugs.winehq.org/show_bug.cgi?id=56259 Bug ID: 56259 Summary: Microsoft Webview 2 installer hangs forever Product: Wine Version: 9.1 Hardware: x86-64 URL: https://developer.microsoft.com/en-us/microsoft-edge/w ebview2/?form=MA13LH OS: Linux Status: NEW Keywords: download Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: xerox.xerox2000x(a)gmail.com Distribution: Debian Created attachment 75970 --> https://bugs.winehq.org/attachment.cgi?id=75970 stub that lets installer finish A user reported troubles with this at the forum. Apparently (didn't verify this) the installer works in win 7 because it downloads an older version of webview2. When version is set to win10 another version seems to be downloaded. See https://forum.winehq.org/viewtopic.php?t=38443 A +relay showed following trace, the kernelbase.SleepConditionVariableCS sequence keeps going on and on forever. Adding a stub for the function that the program tries to find (RtlGetDeviceFamilyInfoEnum) just before the "loop" of SleepConditionVariableCS, makes the installer succeed for me (it exits without a success message, but the files seem to be installed). I'll try to add a test and submit the patch later +relay log: 0204:Call KERNEL32.GetProcAddress(6fffffc50000,14038602f "RtlGetDeviceFamilyInfoEnum") ret=1401736ba 0204:Ret KERNEL32.GetProcAddress() retval=00000000 ret=1401736ba 0204:Call kernelbase.SleepConditionVariableCS(1403deb48,1403deb58,00000064) ret=14020442a 0204:Call ntdll.RtlSleepConditionVariableCS(1403deb48,1403deb58,7ffffe1ff2f8) ret=6fffff4cbd7d 0204:Ret ntdll.RtlSleepConditionVariableCS() retval=00000102 ret=6fffff4cbd7d 0204:Call ntdll.RtlNtStatusToDosError(00000102) ret=6fffff4cbd98 0204:Ret ntdll.RtlNtStatusToDosError() retval=000005b4 ret=6fffff4cbd98 0204:Ret kernelbase.SleepConditionVariableCS() retval=00000000 ret=14020442a 0204:Call kernelbase.SleepConditionVariableCS(1403deb48,1403deb58,00000064) ret=14020442a 0204:Call ntdll.RtlSleepConditionVariableCS(1403deb48,1403deb58,7ffffe1ff2f8) ret=6fffff4cbd7d 0204:Ret ntdll.RtlSleepConditionVariableCS() retval=00000102 ret=6fffff4cbd7d -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 47521] New: digikam 6.10 crashes on start
by wine-bugs＠winehq.org 09 Feb '24

09 Feb '24

https://bugs.winehq.org/show_bug.cgi?id=47521 Bug ID: 47521 Summary: digikam 6.10 crashes on start Product: Wine Version: 4.11 Hardware: x86 OS: Linux Status: NEW Keywords: download, source Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: austinenglish(a)gmail.com Distribution: Gentoo Created attachment 64913 --> https://bugs.winehq.org/attachment.cgi?id=64913 crash output Backtrace: =>0 0x66401f0a EntryPoint+0xb6a() in qt5widgets (0x006ff4f8) 1 0x1084cf64 WXMPUtils_DuplicateSubtree_1+0x44c5d3() in libdigikamcore (0x737adae8) 2 0x10388bb9 EntryPoint+0x387818() in libdigikamcore (0x006ff5f8) 3 0x104c0cba WXMPUtils_DuplicateSubtree_1+0xc0329() in libdigikamcore (0x006ff688) 4 0x2278b630 EntryPoint+0xba28f() in libdigikamgui (0x006ffab8) 5 0x2276e7b3 EntryPoint+0x9d412() in libdigikamgui (0x006ffb98) 6 0x00404be5 _ZN7Digikam6DColor11premultiplyEv+0x15e4() in digikam (0x006ffe88) 7 0x00401382 EntryPoint+0xffffffff() in digikam (0x006fff28) 8 0x7b47e022 call_process_entry+0x11() in kernel32 (0x006fff48) 9 0x7b480acc start_process+0xeb(entry=<couldn't compute location>, peb=<couldn't compute location>) [Z:\home\austin\wine-git\dlls\kernel32\process.c:1297] in kernel32 (0x006fffd8) 10 0x7b47e02e start_process_wrapper+0x9() in kernel32 (0x006fffec) 0x66401f0a EntryPoint+0xb6a in qt5widgets: movl 0x4(%eax),%ecx austin(a)laptop:~/Downloads$ du -sh digiKam-6.1.0-Win32.exe 321M digiKam-6.1.0-Win32.exe austin(a)laptop:~/Downloads$ sha256sum digiKam-6.1.0-Win32.exe fb870263a8bb2bd178590dfacfe68110b68d8c5b0ca53606084162a1a5e42b44 digiKam-6.1.0-Win32.exe -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

2 7

[Bug 51360] New: vkGetDeviceProcAddr invalid behavior for functions from extensions unsupported by host Vulkan instance
by WineHQ Bugzilla 09 Feb '24

09 Feb '24

https://bugs.winehq.org/show_bug.cgi?id=51360 Bug ID: 51360 Summary: vkGetDeviceProcAddr invalid behavior for functions from extensions unsupported by host Vulkan instance Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winevulkan Assignee: wine-bugs(a)winehq.org Reporter: loothelion(a)nvidia.com Distribution: --- I believe the below may also be true for vkGetInstanceProcAddr, but I haven't confirmed this locally. The Vulkan 1.2.182 specification states the following about the behavior of vkGetDeviceProcAddr: > The table below defines the various use cases for vkGetDeviceProcAddr and > expected return value for each case. > > The returned function pointer is of type PFN_vkVoidFunction, and must be cast to > the type of the command being queried before use. The function pointer must only > be called with a dispatchable object (the first parameter) that is device or a > child of device. > > Table 2. vkGetDeviceProcAddr behavior > > device | pName | return value > --------------------------------------------------------------------------------------- > NULL | *[1] | undefined > --------------------------------------------------------------------------------------- > invalid device | *[1] | undefined > --------------------------------------------------------------------------------------- > device | NULL | undefined > --------------------------------------------------------------------------------------- > device | core device-level Vulkan command [2] | fp[3] > --------------------------------------------------------------------------------------- > device | enabled extension device-level commands [2] | fp[3] > --------------------------------------------------------------------------------------- > any other case, not covered above | NULL > > [1] - "*" means any representable value for the parameter (including valid > values, invalid values, and NULL). > > [2] - In this function, device-level excludes all physical-device-level > commands. > > [3] - The returned function pointer must only be called with a dispatchable > object (the first parameter) that is device or a child of device e.g. > VkDevice, VkQueue, or VkCommandBuffer. Winevulkan's behavior differs from this slightly. Note the fifth row of the table uses the language "enabled extension device-level commands", this means that if a command is queried via vkGetDeviceProcAddr and isn't part of core, the extension which introduces it must be enabled for the given VkDevice object in order for vkGetDeviceProcAddr to return a valid function pointer, and otherwise it should return NULL. In order to properly conform to the Vulkan specification Winevulkan should only expose device-level commands whose extensions have been enabled. Note that applications should not be querying for Vulkan commands via vkGetDeviceProcAddr if they know the extension is not supported by the underlying implementation. However in the case of an application which does rely on this bad behavior, Winevulkan will return a function pointer to one of its thunks and then proceed to deference a null function pointer when it tries to call into the underlying host Vulkan implementation. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 5