http://bugs.winehq.org/show_bug.cgi?id=58145
Bug ID: 58145
Summary: Out of Ctrl 1.2: game doesn't launch, gives error
Product: Wine
Version: 10.6
Hardware: x86-64
OS: MacOS
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: cemer99797(a)isorax.com
Created attachment 78425
--> http://bugs.winehq.org/attachment.cgi?id=78425
Wine-devel 10.6 terminal log
The game Out of Ctrl 1.2 doesn't launch and gives the following error in a
pop-up window on launch:
Error
Failed to initialize player
Details:
Failed to initialize graphics.
Make sure you have DirectX 11 installed, have up to date
drivers for your graphics card and have not disabled
3D acceleration in display settings.
InitializeEngineGraphics failed
tested using Gcenx's wine-devel 10.6 build
(https://github.com/Gcenx/macOS_Wine_builds/releases/tag/10.6) with GStreamer
1.26.0
download link (20 MB) (choose "OutOfCtrl_v1_2_EXE.zip"):
https://miknugget.itch.io/out-of-ctrl
shas256: 5d26c746c4e85b98af2f1f9fb4a4daeed837deb49427bf108935545f8958dba9
I'm using macOS 11
--
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.
http://bugs.winehq.org/show_bug.cgi?id=59066
Bug ID: 59066
Summary: Legacy Family Tree much slower under 10.20 compared
with previous version
Product: Wine
Version: 10.20
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)list.winehq.org
Reporter: mice(a)duck.com
Distribution: ---
Since updating to WINE 10.20, Legacy Family Tree v10 is taking much longer to
open than under previous versions. It uses an old MS database system (Jet?) so
that might be a clue.
After updating WINE I had to reboot the system before legacy would open at all.
Even now it crashes randomly.
Apologies I don't have the skills to do regression testing.
--
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.
http://bugs.winehq.org/show_bug.cgi?id=58827
Bug ID: 58827
Summary: Running Mahjong with Wine ends without displaying the
game screen
Product: Wine
Version: 10.17
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: win32u
Assignee: wine-bugs(a)winehq.org
Reporter: craigaschulstad(a)gmail.com
Distribution: ---
Created attachment 79498
--> http://bugs.winehq.org/attachment.cgi?id=79498
Wine debug of no Mahjong game window display
After updating to Wine 10.17, my Windows game programs (such as Mahjong, Purble
Place, and so forth) end without displaying the game in a window. This
behavior seems very similar to the issue I submitted with bug 58321 a few
months ago which had an issue identified and resolved in win32u. As such, I am
attaching a debug log using the WINEDEBUG options suggested at that time.
Please let me know if other information is needed. For now, I will reset my
Linux virtual machine back to its state prior to installing Wine 10.17.
--
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.
http://bugs.winehq.org/show_bug.cgi?id=59065
Bug ID: 59065
Summary: 32-bit foobar2000 crashes when you play files
Product: Wine-staging
Version: 10.19
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)list.winehq.org
Reporter: just4steam778(a)gmail.com
CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com
Distribution: ---
Created attachment 79838
--> http://bugs.winehq.org/attachment.cgi?id=79838
Log
32-bit foobar2000 crashes when you try to play files. 64-bit foobar2000 works
fine.
OS: Arch Linux
--
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.
http://bugs.winehq.org/show_bug.cgi?id=58491
Bug ID: 58491
Summary: Flickering on video-surveilance-app is back
Product: Wine
Version: 10.12
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: andreas.franz(a)arcor.de
Distribution: ---
Created attachment 78948
--> http://bugs.winehq.org/attachment.cgi?id=78948
started from terminal
Flickering on viewing a camera stream with activated hardware accelerated d3d11
setting is back. Desktop picture and camera picture is swapping.
It was gone with 10.0 stable - it's back with 10.12 (maybe some versions
earlier).
Software rendering works still fine.
regards, Andy
--
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.
http://bugs.winehq.org/show_bug.cgi?id=59037
Bug ID: 59037
Summary: CLIP Studio Paint 4.10: Application performance issue
when selecting a material-based tool from the tool
panel
Product: Wine
Version: 10.19
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: trivial
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)list.winehq.org
Reporter: fun(a)fefes.co.uk
Distribution: ---
Created attachment 79801
--> http://bugs.winehq.org/attachment.cgi?id=79801
Terminal log showing the err:sync
CSP hangs for about one minute when starting a new session and selecting a
material-based tool, for example, a downloaded G-pen material, from the tool
panel. Selecting another similar tool will also cause the hang, but as long as
you do not switch tool groups, selecting the first material is instant.
There is also a lag when first attempting to use the tool on the canvas, and I
believe it is likely related, but I am happy to raise a new bug for that
behaviour.
CSP also hangs for longer when switching tool groups, if that tool group
contains at least one tool that uses a material.
From what I can gather, this might be related to a thread being locked by
another thread, but is then waiting 60 seconds to try again, as seen in lines
such as:
0158:err:sync:RtlpWaitForCriticalSection section 0000713087FB7238 "?" wait
timed out in thread 0158, blocked by 02b8, retrying (60 sec).
In the attached log is just the basic example of selecting a new material.
Download link:
https://vd.clipstudio.net/clipcontent/paint/app/410/CSP_410w_setup.exe
OS & DE: Linux Mint Cinnamon 22.2 Zara
Architecture: AMD x86_64
Workarounds utilised: All listed for Clip Studio Paint 4.10 at
https://appdb.winehq.org/objectManager.php?sClass=version&iId=42586 except for
using wine-stable 10.4 where performance was worse.
--
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=56681
Bug ID: 56681
Summary: 3d games continue receiving mouse input while not
focused
Product: Wine
Version: 9.8
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: winewayland
Assignee: wine-bugs(a)winehq.org
Reporter: pmargeti34(a)gmail.com
Distribution: ---
Wine wayland windows seem to get the mouse input even if the application window
is not focused. 3D game world continues to respond to mouse input as if the
game still had focus.
To reproduce:
-launch a 3d game in wayland mode (warframe in my example)
-open another application and make sure it has focus
-observe that when the mouse cursor is over the game window, game still
receives input
--
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.
http://bugs.winehq.org/show_bug.cgi?id=30853
Bug #: 30853
Summary: Wine doesn’t always handle "right alt" properly
Product: Wine
Version: 1.5.5
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: winex11.drv
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: sloonz(a)gmail.com
Classification: Unclassified
Created attachment 40410
--> http://bugs.winehq.org/attachment.cgi?id=40410
workaround/quick and dirty fix
I’m trying to get World of Warcraft working under Wine. However, I have huge
trouble with key bindings (I use unusual key bindings : I use the right half of
my keyboard, whereas most players use the left half).
After investigation, I found 3 bugs (different behaviors between Wine and my
Windows installation). The first one is the management of the right "Alt" key
(labeled "Alt-Gr" on my keyboard). When I press AltGr+l under Windows with
Spy++, I get the followings events :
<03637> 0007045A P WM_KEYDOWN nVirtKey:VK_CONTROL cRepeat:1 ScanCode:1D
fExtended:0 fAltDown:0 fRepeat:0 fUp:0
<03638> 0007045A P WM_KEYDOWN nVirtKey:VK_MENU cRepeat:1 ScanCode:38
fExtended:1 fAltDown:1 fRepeat:0 fUp:0
<03639> 0007045A P WM_KEYDOWN nVirtKey:'L' cRepeat:1 ScanCode:18
fExtended:0 fAltDown:1 fRepeat:0 fUp:0
<03640> 0007045A P WM_DEADCHAR chCharCode:'002F' (47) cRepeat:1 ScanCode:18
fExtended:0 fAltDown:1 fRepeat:0 fUp:0
<03641> 0007045A P WM_KEYUP nVirtKey:'L' cRepeat:1 ScanCode:18 fExtended:0
fAltDown:1 fRepeat:1 fUp:1
<03642> 0007045A P WM_SYSKEYUP nVirtKey:VK_CONTROL cRepeat:1 ScanCode:1D
fExtended:0 fAltDown:1 fRepeat:1 fUp:1
<03643> 0007045A P WM_KEYUP nVirtKey:VK_MENU cRepeat:1 ScanCode:38
fExtended:1 fAltDown:0 fRepeat:1 fUp:1
Under Wine 1.5.5 however (WINEDEBUG=+msg), I get those :
trace:msg:peek_message got type 7 msg 100 (WM_KEYDOWN) hwnd 0x6007e wp eb
lp 760001 [note: wp = VK_OEM_PA2]
trace:msg:peek_message got type 7 msg 101 (WM_KEYUP) hwnd 0x6007e wp 4c lp
c0260001 [note: wp = 'L']
trace:msg:peek_message got type 7 msg 101 (WM_KEYUP) hwnd 0x6007e wp eb lp
c0760001 [note: wp = VK_OEM_PA2]
With xev, I get :
KeyPress event, serial 93, synthetic NO, window 0x4000001,
root 0xbc, subw 0x0, time 5086996, (1585,410), root:(2578,425),
state 0x0, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen
YES,
XKeysymToKeycode returns keycode: 92
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 93, synthetic NO, window 0x4000001,
root 0xbc, subw 0x0, time 5087052, (1585,410), root:(2578,425),
state 0x80, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen
YES,
XKeysymToKeycode returns keycode: 92
XLookupString gives 0 bytes:
XFilterEvent returns: False
After "setxkbmap us", AltGr is bound to Alt_R under X (checked with xev), and I
get this under Wine :
trace:msg:peek_message got type 7 msg 104 (WM_SYSKEYDOWN) hwnd 0x10046 wp
a5 lp 21380001 [wp = VK_RMENU]
trace:msg:peek_message got type 7 msg 104 (WM_SYSKEYDOWN) hwnd 0x10046 wp
4c lp 20260001 [wp = 'L']
trace:msg:peek_message got type 6 msg 106 (WM_SYSCHAR) hwnd 0x10046 wp 6c
lp 20260001 [wp = 'l']
trace:msg:peek_message got type 7 msg 105 (WM_SYSKEYUP) hwnd 0x10046 wp 4c
lp e0260001 [wp = 'L']
trace:msg:peek_message got type 7 msg 101 (WM_KEYUP) hwnd 0x10046 wp a5 lp
c1380001 [wp = VK_RMENU]
(yes, I have a KEYUP without KEYDOWN)
Wich is still not the same as Windows. So I think there is two problems here :
- ISO_Level3_Shift is not properly recognized by Wine
- "AltGr" doesn't have the same behavior under Wine and Windows
FYI, attached patch is a workaround to have the same behavior than Windows.
With it, I get this under Wine :
trace:msg:peek_message got type 7 msg 100 (WM_KEYDOWN) hwnd 0x10062 wp a2
lp 1d0001 [note: wp = VK_LCONTROL]
trace:msg:peek_message got type 7 msg 100 (WM_KEYDOWN) hwnd 0x10062 wp a4
lp 20380001 [note: wp = VK_LMENU]
trace:msg:peek_message got type 7 msg 100 (WM_KEYDOWN) hwnd 0x10062 wp 4c
lp 20260001 [note: wp = 'L']
trace:msg:peek_message got type 7 msg 101 (WM_KEYUP) hwnd 0x10062 wp 4c lp
e0260001
trace:msg:peek_message got type 7 msg 105 (WM_SYSKEYUP) hwnd 0x10062 wp a2
lp e01d0001
trace:msg:peek_message got type 7 msg 101 (WM_KEYUP) hwnd 0x10062 wp a4 lp
c0380001
Which is still not the same as Windows :
- Windows uses (right) control + menu (with fExtended flag for menu) whereas
Wine uses left control + left menu. Not investigated if this is related to
TranslateMessage.
- AltGr+L is a dead symbol on my keymap. Windows send a DEADCHAR message,
wheras Wine send nothing. Note that I had to disable the XFilterEvent test in
event.c to have those messages, otherwise nothing is sent to the program (but
that’s another story for another bug report)
But it suffice for my use case (WoW key bindings with right alt)
--
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.
http://bugs.winehq.org/show_bug.cgi?id=59006
Bug ID: 59006
Summary: FL Studio fails to minimize on Wine 10.19
Product: Wine
Version: 10.19
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: major
Priority: P2
Component: winex11.drv
Assignee: wine-bugs(a)list.winehq.org
Reporter: agarplayerarlon(a)gmail.com
Distribution: ---
Created attachment 79738
--> http://bugs.winehq.org/attachment.cgi?id=79738
video of the issue
so as the title says, since Wine 10.19 FL Studio and probably other wine apps
with CSDs fail to minimize, I've attached a video that shows the issue, also
I'm using wine in xWayland mode so I'm guessing it's a winex11 issue, I haven't
tested if this issue happens with winewayland too for now
--
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=57925
Bug ID: 57925
Summary: winewayland.drv: Games are not filled to my monitor's
resolution
Product: Wine
Version: 10.2
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: winewayland
Assignee: wine-bugs(a)winehq.org
Reporter: daniel.penalized(a)proton.me
Distribution: ArchLinux
Created attachment 78178
--> https://bugs.winehq.org/attachment.cgi?id=78178
SWAT 4 output log (in this log I opened the settings and tried to set the
maximum resolution that the game supports)
Old games (specifically Ghost Recon, Splinter Cell 1, Splinter Cell 2 and SWAT
4) won't fill to my monitor's resolution, even if I switch to a higher
resolution in the game settings.
This MR (https://gitlab.winehq.org/wine/wine/-/merge_requests/6804) was
supposed to work with winewayland.drv and fix this issue, but it doesn't work
or fix it. However, this MR
(https://gitlab.winehq.org/wine/wine/-/merge_requests/5057) does work and fixes
that issue.
There is a workaround (at least for SWAT 4): which is to take the game window
out of fullscreen, then toggle the maximization state of the game window and
put the game window back into fullscreen (In labwc/openbox terms:
ToggleFullscreen > ToggleMaximize > ToggleFullscreen). I think it also works
for Ghost Recon.
Splinter Cell 1 even supports 16:9 resolutions, but only in game (in the menus,
loadings and cut-scenes are still not filled in for my monitor's resolution)
and Splinter Cell 2 is worse, there's no support for 16:9 resolutions or even a
workaround.
- I use labwc/wlroots as WM.
- I'm using the new WoW64 mode. I did some tests with normal wine, but it's
been a few weeks or months, so I'm not sure if the new WoW64 mode has any
impact here, but I don't think so.
(Sorry if the paraphrases seem disconnected from each other, if I'm not very
clear or if I'm giving too little information. I've been doing a lot of testing
over the last few hours and my mind isn't in a good place to come up with a
good text 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.