https://bugs.winehq.org/show_bug.cgi?id=54007
Bug ID: 54007
Summary: in kde plasma fullscreen videogames cause gap between
taskbar and bottom edge of the screen
Product: Wine-staging
Version: 7.22
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: HarlanStaggs(a)gmail.com
CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com
Distribution: ---
Created attachment 73586
--> https://bugs.winehq.org/attachment.cgi?id=73586
this is how it looks with and without launched game
characteristics:
Operating System: Nobara Linux 36
KDE Plasma Version: 5.26.3
KDE Frameworks Version: 5.100.0
Qt Version: 5.15.7
Kernel Version: 6.0.10-201.fc36.x86_64 (64-bit)
Graphics Platform: X11
how to reproduce:
1) launch some fullscreen videogame (personally i do it with lutris from
flathub, maybe its important)
2) alt+tab to another non-fullscreen window
3) put cursor in bottom edge of the screen
4) try to switch windows with mouse wheel
5) notice small (several pixels height) gap between bottom edge of the screen
and taskbar, and also between taskbar and current non-fullscreen window in
focus.
6) close fullscreen videogame
7) everything is normal, taskbar is adjacent to the bottom edge of the screen
without gaps
this started to happen after update to wine-7.22 (Staging), i've never seen
this before, so i assume this bug occurs in this particular version.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=54854
Bug ID: 54854
Summary: Locking the KDE screen causes user32:win to fail
systematically
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: user32
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
Locking the KDE screen causes user32:win to fail systematically.
Specifically it gets failures in test_nonclient_area():
win.c:1581: Test failed: Got unexpected color 0xc0c0c0.
win.c:1581: Test failed: Got unexpected color 0xc0c0c0.
win.c:1581: Test failed: Got unexpected color 0xc0c0c0.
win.c:1581: Test failed: Got unexpected color 0xc0c0c0.
win.c:1581: Test failed: Got unexpected color 0xc0c0c0.
win.c:1581: Test failed: Got unexpected color 0xc0c0c0.
win.c:1581: Test failed: Got unexpected color 0xc0c0c0.
win.c:1581: Test failed: Got unexpected color 0xc0c0c0.
win.c:1581: Test failed: Got unexpected color 0xc0c0c0.
win.c:1581: Test failed: Got unexpected color 0xc0c0c0.
win.c:1581: Test failed: Got unexpected color 0xc0c0c0.
win.c:1581: Test failed: Got unexpected color 0xc0c0c0.
in test_activateapp():
win.c:11013: Test failed: Expected foreground window 0, got 00FE0060
win.c:11019: Test failed: Expected foreground window 002D0142, got 00FE0060
win.c:11082: Test marked todo: Expected WM_ACTIVATEAPP(0), did not receive it.
and in test_topmost():
win.c:11683: Test failed: 01ED0126: expected prev 005D00BE, got 00000000
win.c:11697: Test failed: hwnd should NOT be topmost
win.c:11699: Test failed: 01ED0126: expected NOT topmost
win.c:11643: Test failed: 1: hwnd 01ED0126 is still topmost
win.c:11724: Test marked todo: owner should be topmost
win.c:11727: Test marked todo: hwnd2 should be topmost
win.c:11750: Test marked todo: hwnd should NOT be topmost
win.c:11764: Test marked todo: hwnd should NOT be topmost
win.c:11805: Test marked todo: hwnd should be topmost
win.c:11807: Test succeeded inside todo block: child should be topmost
win.c:11809: Test marked todo: child2 should be topmost
win.c:11810: Test failed: grandchild should be topmost
win.c:11818: Test failed: child should NOT be topmost
win.c:11821: Test succeeded inside todo block: grandchild should NOT be topmost
win.c:11824: Test failed: 0007012A: expected NOT topmost
win.c:11643: Test succeeded inside todo block: 5: hwnd 01070060 is still
topmost
[... more todos ...]
See https://test.winehq.org/data/patterns.html#user32:win
Only my development desktop runs the Wine tests in KDE and I normally avoid
locking the screen when doing so. But it is quite remarkable that only three
tests units have an issue with this configuration: this one, comctl32:tooltips
(bug 54582) and user32:input (bug 54583).
--
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.
https://bugs.winehq.org/show_bug.cgi?id=54853
Bug ID: 54853
Summary: Locking the KDE screen causes user32:input to fail
systematically
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: user32
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
Locking the KDE screen causes user32:input to fail systematically.
Specifically it gets failures in test_rawinput():
input.c:2918: Test marked flaky: 4: unexpected WM_MOUSEMOVE message
input.c:2929: Test failed: 4: Unexpected cursor movement
input.c:2929: Test failed: 5: Unexpected cursor movement
input.c:2929: Test failed: 6: Unexpected cursor movement
input.c:2502: Test marked todo: Expected wparam 1, got 0
input.c:2929: Test failed: 7: Unexpected cursor movement
input.c:2929: Test failed: 8: Unexpected cursor movement
input.c:2918: Test marked flaky: 9: unexpected WM_MOUSEMOVE message
input.c:2645: Test marked flaky: 9: foreground process expected WM_MOUSEMOVE
message
input.c:2929: Test failed: 9: Unexpected cursor movement
input.c:2502: Test marked todo: Expected wparam 1, got 0
input.c:2645: Test marked flaky: 10: foreground process expected WM_MOUSEMOVE
message
input.c:2929: Test failed: 10: Unexpected cursor movement
input.c:2502: Test marked todo: Expected wparam 1, got 0
input.c:2645: Test marked flaky: 11: foreground process expected WM_MOUSEMOVE
message
input.c:2929: Test failed: 11: Unexpected cursor movement
input.c:2645: Test marked flaky: 12: foreground process expected WM_MOUSEMOVE
message
input.c:2929: Test failed: 12: Unexpected cursor movement
input.c:2921: Test marked todo: 13: expected WM_INPUT message
input.c:2929: Test failed: 13: Unexpected cursor movement
input.c:2929: Test failed: 14: Unexpected cursor movement
input.c:2929: Test failed: 15: Unexpected cursor movement
input.c:2929: Test failed: 16: Unexpected cursor movement
and in test_GetMouseMovePointsEx_process():
input.c:1730: Test failed: expected to get 64 mouse move points but got -1
input.c:1741: Test failed: expected to get 64 mouse move points but got -1
input.c:1787: Test marked todo: expected to get -1 mouse move points but got 64
input.c:1788: Test marked todo: expected ERROR_ACCESS_DENIED got -559038737
See https://test.winehq.org/data/patterns.html#user32:input
Only my development desktop runs the Wine tests in KDE and I normally avoid
locking the screen when doing so. But it is quite remarkable that only three
tests units have an issue with this configuration: this one, comctl32:tooltips
and user32:win.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=54852
Bug ID: 54852
Summary: Locking the KDE screen causes comctl32:tooltips to
fail systematically
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: comctl32
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
Locking the KDE screen causes comctl32:tooltips to fail systematically:
tooltips.c:252: Test failed: 0: Failed to get current tool 0.
tooltips.c:259: Test failed: 0: Unexpected hwnd CCCCCCCC.
tooltips.c:260: Test failed: 0: Unexpected hinst CCCCCCCC.
tooltips.c:261: Test failed: 0: Unexpected uId cccccccc.
tooltips.c:262: Test failed: 0: Unexpected lParam cccccccc.
[... same errors for iterations 1 to 5...]
tooltips.c:504: Test marked todo: Adding the tool to the tooltip succeeded!
tooltips.c:1150: Test marked todo: 0: Unexpected ret value 1, size 45, max size
44.
tooltips.c:1218: Test failed: TTN_SHOW parent seq: the msg sequence is not
complete: expected 0000 - actual 004e
v6util.h:92: created cc6.manifest
[... same errors again ...]
See https://test.winehq.org/data/patterns.html#comctl32:tooltips
Only my development desktop runs the Wine tests in KDE and I normally avoid
locking the screen when doing so. But it is quite remarkable that none of the
other comctl32 tests has any issue in that scenario, and that out of all the
Wine tests only two others have extra failures (user32:input and user32:win).
Also the failures are not unique to this case:
* The test_customdraw() failures also happen on Windows, but only one at a time
(bug 54580).
* The test_TTN_SHOW() also happen randomly in Wine the rest of the time (bug
54581).
Given that these failures are usually quite hard to reproduce, locking the KDE
screen may make them easier to debug, assuming this case does not involve a
totally different code path.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=48046
Bug ID: 48046
Summary: Resident Evil 4 (Steam): Frame rate issues when
clicking the left mouse button
Product: Wine
Version: 4.18
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: skidrowa(a)gmail.com
Distribution: ---
The game's frame rate tanks when you click the left mouse button and can go as
low as 5 FPS if you hold click and move the mouse at the same time. The cursor
also flickers between it's current position and the middle of the screen,
making it virtually impossible to play using keyboard and mouse.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=51372
Bug ID: 51372
Summary: Resident Evil 4 (2007) Sometimes crashes at startup.
Product: Wine
Version: 6.0.1
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: BOBBLOG(a)protonmail.com
Distribution: ---
Created attachment 70229
--> https://bugs.winehq.org/attachment.cgi?id=70229
RE4Terminal.txt
Resident Evil 4 (2007) Sometimes crashes at startup. I see a few error messages
about xrandr. I have attach the terminal messages.
Tested in a wine prefix just d3dx9_30 installed by winetricks.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=51325
Bug ID: 51325
Summary: Resident Evil 4 (2007) Hangs usually within 15-30
minutes.
Product: Wine
Version: 6.0.1
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: BOBBLOG(a)protonmail.com
Distribution: ---
Resident Evil 4 (2007) Ver.1.1.0 DVD Hangs usually within 15-30 minutes. Most
times i see a message box of Microsoft Visual C++ Runtime Error
"This application has requested the Runtime to terminate in an unusual way.
Please contact the applications support team for more information."
I tested this in a wine prefix with d3dx9 installed via winetricks because the
game will not boot up with it.
I tried WINEDEBUG=+msgbox but, every time i did the game would just hang and
not show anything related to the message box. I did however get this message on
the
terminal.
01e4:fixme:d3d9:Direct3DShaderValidatorCreate9 Returning stub validator
67C9E028.
0454:err:quartz:BaseMemAllocator_Commit fnAlloc failed with error 0x8007000e
0454:err:quartz:BaseMemAllocator_Commit fnAlloc failed with error 0x8007000e
0454:err:gstreamer:gstdemux_init_stream Failed to commit allocator, hr
0x8007000e.
radeon: mmap failed, errno: 12
radeon: mmap failed, errno: 12
0174:err:d3d:wined3d_debug_callback 0x8f4a328: "GL_OUT_OF_MEMORY in
glTexSubImage".
This err message was only displayed once in the many times that the game
hanged.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=50550
Bug ID: 50550
Summary: Resident Evil 4 Ultimate HD crashes at gameplay near
beginning of game
Product: Wine
Version: 6.0
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: dron2065(a)rambler.ru
Distribution: ---
Created attachment 69220
--> https://bugs.winehq.org/attachment.cgi?id=69220
Backtrace of error
Steam version of Resident Evil 4 Ultimate HD crashes at gameplay near beginning
of game
--
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.
https://bugs.winehq.org/show_bug.cgi?id=41271
Bug ID: 41271
Summary: Fallout 4 - Audio issues (no sounds, hangs when
playing intro video)
Product: Wine
Version: 1.9.18
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: xaudio2
Assignee: wine-bugs(a)winehq.org
Reporter: kimmo.myllyvirta(a)gmail.com
Distribution: ---
Created attachment 55571
--> https://bugs.winehq.org/attachment.cgi?id=55571
1.9.18 logs
This could be dupe of bug #36977, but also hits bug #39402 possibly some others
too. But since I can't find a decent workaround which works for Fallout 4, it
might be ok to open a new bug. Not quite sure if the component is correct,
either xaudio2 or dsound anyway.
A bunch of logs attached, see below what they mean.
Steam version of the game, only Steam and Fallout 4 installed to a clean
prefix. Steam installs xact from _CommonRedist when first time launching the
game.
When the game is started it hangs when it should play the intro video;
+tid,+dsound log attached (Log: fo4_tid_dsound.txt, +tid,+dsound). This could
be bug #36977, since the game uses radgametools bink.
With builtin xaudio2_7 the intro video works sometimes (extremely rarely, sorry
I don't have decent log of this). But after the video is finished it will
always hang after;
warn:xaudio2:IXAudio2Impl_CreateSourceVoice OpenAL can't convert this format!
when it tries to play the music for the main menu. (see bug #39402)
With xaudio2_7 set to disabled the intro video works, but again extremely
rarely. And it results to no sounds in Fallout 4 since bink player uses dsound,
but Fallout 4 itself doesn't, it seems. There is "sAudioAPI=XAudio2" setting in
Fallout4.ini, but it is a legacy setting. I can't find any indication of it
supporting anything else than xaudio2 (on older Bethesda games there was other
options available).
Now the weird hack part;
Since this feels like a race condition, I added usleep(100000) to the beginning
of IDirectSound8Impl_Release, which seems to help a lot (this issue might not
have anything to do with dsound release, that's just the first place I tried);
- native xaudio2: the intro video works, and the music in main menu plays ok,
always - success :)
(Log: fo4_tid_dsound_sleep_hack.txt, +tid,+dsound )
- builtin xaudio2_7: the intro video works, but the music in main menu doesn't
and the game hangs (as expected) after;
warn:xaudio2:IXAudio2Impl_CreateSourceVoice OpenAL can't convert this format!
(Log: fo4_tid_dsound_xaudio2_sleep_hack_builtin_xaudio2_7.txt,
+tid,+dsound,+xaudio2 )
- disable xaudio2_7: the intro video works, no music in the main menu, but the
game doesn't hang
(Log: fo4_tid_dsound_sleep_hack_disable_xaudio2_7, +tid,+dsound )
Notes;
- The main menu is just a black screen (lots of d3d11 fixmes in those logs),
you just have to listen and imagine you are there :)
- I also tried xact and xact_jun2010 with winetricks - those make no
difference, works just like the xact shipped with the game
--
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.
https://bugs.winehq.org/show_bug.cgi?id=51536
Bug ID: 51536
Summary: Wrye Bash graphical issue in the modlist with
wine-staging
Product: Wine-staging
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: lorenzofer(a)live.it
CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com
Distribution: ---
Wrye Bash 309 show a glitchy panel where there should be the list of
masterfiles for a mod. The panel present itself all black. It refresh partially
and shows masters when clicking on a mod, but when clicking on a mod with less
masters then the previous ones, the masters in excess sren't removed from the
element.
BIsecting the staging patches result in this (used git-am as aplying backend
for the patches, then used git bisect)
094c35ee0083404c37dfa3f74309c73b23e10cef is the first bad commit
commit 094c35ee0083404c37dfa3f74309c73b23e10cef
Author: Dmitry Timoshkov <dmitry(a)baikal.ru>
Date: Tue Nov 12 18:13:20 2019 +0800
comctl32: Bump version to 6.0.
An application that I have here checks comctl32.dll version information
and refuses to run, changing DLL version to 6.0 makes it run.
Signed-off-by: Dmitry Timoshkov <dmitry(a)baikal.ru>
dlls/comctl32/comctl32.h | 2 +-
dlls/comctl32/comctl32.rc | 2 +-
include/commctrl.h | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
--
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.