https://bugs.winehq.org/show_bug.cgi?id=56870
Bug ID: 56870
Summary: Final Fantasy XIV via XIV Launcher crashes upon
logging in
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: light.plan0535(a)fastmail.com
Distribution: ---
Created attachment 76669
--> https://bugs.winehq.org/attachment.cgi?id=76669
Backtrace of crash generated by XIV Launcher
Instance of repeated crash is when zoning into the Sharlayan zone. Wine
version selected by the XIV Launcher. Backtrace is attached.
--
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=52501
Bug ID: 52501
Summary: TASInput (Mupen64-RR-Lua): TASInput window doesn't
close and stops responding
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: jackyguo18(a)hotmail.com
Distribution: ---
source code:
https://github.com/mkdasher/mupen64-rr-lua-/tree/master/tasinput_plugin/src.
Checkboxes and radio buttons in the TASInput window are not cleared before
being redrawn, leading to weird overlapping graphics. See the attached
screenshot.
Wine version: 7.0 (winehq-stable)
Linux distro: Ubuntu 21.10 (impish)
Display server: Wayland, GNOME Mutter
To reproduce, download the package from https://repack.skazzy3.com, then simply
unzip to a folder and run mupen64.exe. From there:
- run an N64 ROM
- note that the TASInput window (the one with the fancy checkboxes) shows up
- File > Close ROM
- the TASInput window should close, but doesn't, and freezes up.
- Eventually, (at least for me) GNOME prompts me to force-quit Mupen.
--
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=56688
Bug ID: 56688
Summary: Audio input not working
Product: Wine
Version: 0.9.8.
Hardware: aarch64
OS: MacOS
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: erisi(a)comcast.net
Audio input is not working. This message was output:
0118:fixme:coreaudio:ca_channel_layout_to_channel_mask Unhandled channel
0xffffffff
0118:fixme:coreaudio:ca_channel_layout_to_channel_mask Unhandled channel
0xffffffff
0118:fixme:coreaudio:ca_channel_layout_to_channel_mask Unhandled channel
0xffffffff
Please let me know what info I can provide.
The program I ran was DSDPlus on MacOS.
--
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=56851
Bug ID: 56851
Summary: wineconsole runs at 20fps
Product: Wine
Version: 9.11
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: ikm(a)zbackup.org
Distribution: ---
Created attachment 76657
--> https://bugs.winehq.org/attachment.cgi?id=76657
Continuously outputs text so you can see that scrolling is sluggish
Simply by running `wineconsole` and pressing some letter on your keyboard so it
autorepeats you can already see that the console window is sluggish to refresh.
If that's not evident enough, run the attached `test.bat` in `wineconsole`,
which will output some lines of text repeatedly. You can notice the way the
text scrolls isn't smooth at all. It's at about 20fps.
Any application run by wineconsole is sluggish like that. This wasn't the case
some years ago, where the updates were instantaneous.
I've traced this to commit 8ccf24ccb0a4362c407aea61927e604e60d41f6e ("conhost:
Delay window refresh on output update"), which introduces a 50ms delay for the
window refresh. There's no rationale as for why this change was made. It does
make life miserable though. Please revert this unless there's some actual
reason the console should run at 20fps. It used to be nice and speedy, now it's
a slog.
--
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=53636
Bug ID: 53636
Summary: System tray not visible, Ubuntu 20.0.2, Wine 7.16
Staging
Product: Wine
Version: 7.16
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: jubilantjerry(a)gmail.com
Distribution: ---
Created attachment 73034
--> https://bugs.winehq.org/attachment.cgi?id=73034
Tooltip from WeChat that should be from the system tray
System is running Ubuntu 20.04 LTS.
Kernel version is 5.4.0-125-generic.
Desktop environment is Unity 7.5.0.
Hardware is Dell Inspiron 7577, which has an Intel(R) Core(TM) i5-7300HQ CPU
and a Nvidia GTX 1060 Max-Q GPU.
When running an application that minimizes to the system tray when closed, the
application is effectively gone. There is no small system tray panel on the
screen, unlike what I see about the issue online. Maybe the system tray is size
0x0 on the top left corner, since the tooltip pop-ups that should appear on the
system tray icon appear on the top left of my screen.
The lack of system tray was observed with WeChat, I don't know of other
applications that use the system tray and have an automatic tooltip at the
moment, though if you point me to an installer I can try it to see if the
problem is reproduced.
Let me know if other information is needed.
--
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=56624
Bug ID: 56624
Summary: Steam fails to install and seems to be stuck in an
endless loop - Login screen can't be reached
Product: Wine
Version: 9.7
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: maiktapwagner(a)aol.com
Distribution: ---
Created attachment 76393
--> https://bugs.winehq.org/attachment.cgi?id=76393
Console output 9.7 (non-staging)
Dear wine-team,
I am running a Slackware 15.0 box with
bash-5.1$ wine --version
wine-9.7
Here are the steps I went through:
bash-5.1$ mkdir WineApps/Steam
bash-5.1$ export WINEPREFIX=/home/mwagner/WineApps/Steam/
bash-5.1$ winetricks steam 2&>/home/mwagner/Desktop/SteamConsoleOutput.txt
I originally thought that this has been an issue with winetricks but they
confirmed the issue and said is wasn't related to their script.
https://github.com/Winetricks/winetricks/issues/2216
--
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=56208
Bug ID: 56208
Summary: Inconsistent mouse speed tied to frame rate and mouse
polling rate
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: korbel00(a)gmail.com
Distribution: ---
Created attachment 75922
--> https://bugs.winehq.org/attachment.cgi?id=75922
logs and patch
In Secret World Legends the actual mouse speed depends on the current frame
rate in Wine which does not seem to happen in Windows. (if it does, it's not
noticeable for me)
Looking around with the camera, the mouse speeds up and slows down randomly,
making the game really hard to control if possible at all. It's even worse when
a fight is going on in one direction, and there nothing in the other, making it
impossible to turn around. (I have ~30 FPS looking into a fight and ~300 FPS
looking away, the mouse movement slows down so much that I cannot do a 180
turn)
I attempted to do some investigation and I think I could pinpoint the problem
which I'll try to explain here.
The game loop does the following to control the camera (this is an assumption
based on my calculations and on the logged relay messages):
```
loop {
screen_movement := ZERO
last_position := GetCursorPos()
SetCursorPos(CENTER_OF_SCREEN) // reset cursor
while msg = PeekMessage() {
if (msg.type == WM_MOUSEMOVE) {
screen_movement += msg->position - last_position
last_position = msg->position
}
translate and dispatch msg
}
convert `screen_movement` to camera movement and do some stuff
}
```
My tests and calculations confirms it:
- At 50FPS, it takes 2906px raw movement to do a 360 turn at 1000Hz polling
rate
- At 100FPS, it takes 4129px raw movement to do a 360 turn at 1000Hz polling
rate
In both cases, logging out the PeekMessage values and running the algorithm
above on the logs gave me approx 2080px on-screen movement which the game
translated into a 360 turn.
Interestingly at low polling rates the pattern reverses: high FPS gives faster
movement speed than low FPS.
For the algorithm to work, there are some assumption made:
- every mouse motion must enter the message queue
- there cannot be a new motion between calling GetCursorPos and SetCursorPos,
and the next motion after SetCursorPos should be the center of the screen.
With wine, neither of the conditions stands:
- GetCursorPos by default gives back the position from the wine server, even
though the display driver may have unsent motion messages in the output buffer.
- SetCursorPos will tell X11DRV_MotionNotify to ignore all these unprocessed
motions using the "warp_serial" value. The ignored messages won't translate to
camera movements and will get lost.
I modified the code so only the raw inputs get processed, effectively ignoring
all X11DRV_MotionNotify events, and commenting out all code that attempts to
sync the graphics driver position. This does not cause problems in this case
because for every frame SetCursorPos sends the center of the screen both
directly to the message queue and the graphics driver. It solved the issue and
the mouse movements became very smooth and uniform however it is not a proper
solution.
I will attach logs of me doing a 360 turn on both 50FPS and 100FPS.
To sum the raw values I used this script:
```
cat messages.log | grep map_raw_event_coords | sed -E 's/.*input
(-?[[:digit:]]+).*/\1/' | awk '{ sum += $1}; END { print sum }'
```
To run the algorithm which I think the game is doing (sum the PeekMessage
deltas) to calculate the total motion I used this:
```
cat messages.log | awk 'BEGIN { last = 960; sum = 0 }; { if (match($0,
"peek_message WM_MOUSEMOVE: \\(([[:digit:]]+) ", m)) { sum += m[1] - last; last
= m[1] } else if (match($0, "X11DRV_SetCursorPos warped to ([[:digit:]]+)", m))
{ last = m[1] } }; END { print sum }'
```
I will also attach the stripped down version of the relay log of the game loop
and my attempt at patching wine 9.0 git 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=56826
Bug ID: 56826
Summary: Warcraft III Reign of Chaos 1.27 black screen
Product: Wine
Version: 9.10
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: msvcrt
Assignee: wine-bugs(a)winehq.org
Reporter: zsolt_vadasz(a)protonmail.com
Regression SHA1: 2fc773199080dedbe64a33ef66be02a4f44bcd08
Distribution: Other
Created attachment 76635
--> https://bugs.winehq.org/attachment.cgi?id=76635
+msvcrt bad commit
When launching the game, the screen is black. You also need to kill it with
`wineserver -k`, since the game detaches from the terminal.
I bisected the issue starting from wine-8.10, because it's the latest tested
version in the AppDB.
Tested with a vanilla prefix.
--
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=56740
Bug ID: 56740
Summary: AvizoToGo fails with "EnableNonClientDpiScaling()
failed for HWND 0x100ea (120) (Call not implemented.)"
Product: Wine
Version: 9.8
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: alois.schloegl(a)gmail.com
Distribution: ---
Created attachment 76520
--> https://bugs.winehq.org/attachment.cgi?id=76520
debug log when running AvizoToGo
Amira-Avizo 2023.2 contains a "gratis" viewer. When testing that version on
wine 9.9, it shows only the splash screen, and does not proceed. The wine debug
log is attached.
The crtical lines seem to be
0148:fixme:system:EnableNonClientDpiScaling (00000000000100EA): stub
EnableNonClientDpiScaling() failed for HWND 0x100ea (120) (Call not
implemented.)
In order to reproduce:
1) donwload the installer and run in wine
https://download.amira-avizo-software.com/private/MASTERS/AmiraAvizo3D/2023…
2) Then run the application:
wine $WINEPREFIX/drive_c/Program\ Files/Thermo\ Scientific\ Amira-Avizo3D\
2023.2/bin/arch-Win64VC16-Optimize/AvizoToGo.exe
Disclosure: Sveinar's nvidia-libs were installed in the WINEPREFIX, but I doubt
this makes a difference.
--
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=54630
Bug ID: 54630
Summary: Can't run installed VCarve Pro trial: Unhandled
exception: page fault on write access / invalid
program stack in 64-bit code
Product: Wine
Version: 8.3
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: defsnotaburner0(a)gmail.com
Distribution: ---
Created attachment 74152
--> https://bugs.winehq.org/attachment.cgi?id=74152
backtrace from crash
Steps to reproduce:
1. download VCarve Pro V11.5 from
https://www.vectric.com/support/makerspace-sign-up
2. `wine VCarveProTrialEditionV11_SetupENU.exe`
3. install default steps, then run program
4. expected: run, actual: 'serious problem' message
system: Ubuntu 22.04,
wine development installation
--
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.