https://bugs.winehq.org/show_bug.cgi?id=49980
Bug ID: 49980
Summary: Freeze at start when ran on X11 with
AllowNVIDIAGPUScreens
Product: Wine
Version: 5.19
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: luca.boccassi(a)gmail.com
Distribution: ---
Created attachment 68381
--> https://bugs.winehq.org/attachment.cgi?id=68381
winecfg log
When running wine on an optimus laptop set up to use prime - ie: X11 with
AllowNVIDIAGPUScreens enabled and the nvidia modules auto loaded - any
application ran with wine immediately freezes at startup, even winecfg.
You can't even interrupt with ctrl-c, until after half a minute or so when this
message is displayed:
0024:err:environ:run_wineboot boot event wait timed out
And then it's possible to interrupt.
This used to work until a couple of months back.
Last tested on Debian 10 Gnome, with wine-staging 5.19 from wine's repository,
kernel 5.6/5.7/5.8 from backports.
WINE_LOG_LEVEL=debug log attached.
Exact same setup, but running on Wayland without AllowNVIDIAGPUScreens, works
just fine. Even 3D applications via bumblebee work fine.
--
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=49942
Bug ID: 49942
Summary: Games on Battle.net refuse to launch using either
wine-5.18 or wine-staging-5.18
Product: Wine
Version: 5.18
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: nvaert1986(a)hotmail.com
Distribution: ---
After recently upgrading from wine-staging.5-0 to wine-staging-5.18 (tried
wine-5.18 too) all of my Battle.net games fail to launch. When pressing the
launch button, the games simply do nothing and sit there stating they're
running or state they're running for a few seconds and the message is gone.
I've tried running Warcraft 3: Reforged from the terminal and all I receive is
a failed to initialize ClientSdk.dll. Haven't tried this for other games.
I've tried a clean install but it gives the game result.
Whenever I revert back to wine-staging-5.0 the games start fine.
--
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=45124
Bug ID: 45124
Summary: Fortnite: crash when loading battle royal lobby
Product: Wine
Version: 3.7
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: ado92300(a)gmail.com
Distribution: ---
Created attachment 61306
--> https://bugs.winehq.org/attachment.cgi?id=61306
wine log of launching fortnite
As of Fortnite 4.0/for now, battle eye is not required to play fortnite and
when run through wine the launcher will set -nobe (no battleeye) and fortnite
launches with out this bug https://bugs.winehq.org/show_bug.cgi?id=41670. But
once you load the title screen and select battle royal it crashes without a
clear error (in wine output).
I included the log of wine64 (Wine 3.7 Staging) and the UE4 Log for fortnite
the only dll override set is shcore to disabled because the launcher wont load
with it
note: sometimes i can hear the battle royal intro video but never see 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.
http://bugs.winehq.org/show_bug.cgi?id=12443
Summary: Multi-monitor handling in ddraw/d3d
Product: Wine
Version: CVS/GIT
Platform: Other
OS/Version: other
Status: NEW
Severity: normal
Priority: P2
Component: directx-ddraw
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: thestig(a)google.com
In bug 1347, I write:
I'm guessing slideshows in Picasa with multi-monitors is affected by this as
well. When starting the slideshow, the entire screen gets blanked. After the
slideshow ends, the screen that showed the slideshow gets restored, but the
secondary screen remains blank until it gets drawn over.
Stefan replied:
This could as well be a bug with multi-monitor handling in ddraw, as ddraw is
pretty ignorant to that.
Yes, a bug on d3d multi-monitor handling is a good idea I think.
Thus this bug serves as a reminder to look at multi-monitor handling issues in
ddraw/d3d.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=7416
Marcin Zajaczkowski <mszpak(a)wp.pl> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mszpak(a)wp.pl
--
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=49973
Bug ID: 49973
Summary: 64-bit Cheat Engine does not properly handle 32-bit
processes
Product: Wine
Version: 5.4
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: subgraph93(a)gmail.com
Distribution: ---
Created attachment 68374
--> https://bugs.winehq.org/attachment.cgi?id=68374
cheatengine-x86_64.exe attaching to Tutorial-i386.exe
Distribution: Ubuntu 20.04
Program download: Cheat Engine 7.1, available from
https://cheatengine.org/downloads.php (the actual link appears to change on
every page refresh)
Program source code: available at https://github.com/cheat-engine/cheat-engine/
On Windows 7, 64-bit Cheat Engine (cheatengine-x86_64.exe) works fine for
32-bit processes as well as 64-bit processes. However, when using Wine, 64-bit
CE cannot properly attach to 32-bit processes. 32-bit CE works fine for 32-bit
processes. Explaining in some more detail below.
To attach CE to a program, start CE and the program (in any order), then when
CE opens, click the "Open process" icon (it looks like a desktop monitor with a
magnifying glass; it's below the "File" menu button) and select the target
process from the list. CE comes with its own tutorial programs (32-bit and
64-bit), so installing another, unrelated program shouldn't be needed for
testing.
A simple way to identify whether the issue exists is to add an address using
the executable name. To do this, click the "Add Address Manually" button in CE,
enter ["programname.exe"] (with the square brackets; e. g.
["Tutorial-i386.exe"]) in the "Address" box, then click OK. Note the new entry
in the address list below and check the value in the "Address" column for that
entry. When using 32-bit CE on a 32-bit program, the address column shows the
actual address (e. g. 00905A4D) and may show a value, but when using 64-bit CE
on a 32-bit program (something that works on Windows), the address column shows
the text with the program name – something like (["Tutorial-i386.exe"]), with
the parentheses, – and the value is just question marks.
The most obvious impact of the issue is that cheat tables and assembly scripts
cannot work unless the base address (is this the right term?) of the .exe is
hardcoded. Other problems with using 64-bit CE on 32-bit programs are that the
code finder does not work (so you can't complete Step 5 of the tutorial, which
requires you to overwrite an instruction that changes a value; you can't find
that instruction), and that pointer scans do not work. (I'll file other tickets
if these turn out to be their own issues; but both features work fine if 32-bit
CE is used on a 32-bit process.)
I set the version as 5.4 because it's the first version I noticed this issue
in. This issue was also present in every newer version up to 5.19 (both devel
and staging channels). I don't think it's a regression. I didn't use Cheat
Engine with Wine versions before 5.4.
Attached the terminal output for the 5.19-staging test with 64-bit CE and the
32-bit tutorial.
--
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=49971
Bug ID: 49971
Summary: LTC2983 demo software Version 1.7.9 adjusting window
size is very slow
Product: Wine
Version: 5.18
Hardware: x86-64
URL: https://www.analog.com/en/products/ltc2983.html#produc
t-requirement
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: cedric.dewijs(a)eclipso.eu
Distribution: ArchLinux
Created attachment 68371
--> https://bugs.winehq.org/attachment.cgi?id=68371
console messages
Summary
LTC2983 demo software Version 1.7.9 adjusting window size is very slow
Download location
https://www.analog.com/en/products/ltc2983.html#product-requirementhttp://swdownloads.analog.com/ltc2983/installltc2983.zip
$ sha256sum installltc2983.zip
b0b4b1ef8447adfdb4cb30dae8742d1ca5458e86bc17cf8e4dafa33978eecd67
installltc2983.zip
$ unzip installltc2983.zip
$ cd InstallLTC2983/
Steps to reproduce:
1) Install the program:
$ wine CDM20824_Setup.exe This does not seem to do anything
$ wine start ins2983.msi
and accept the defaults.
2) Start the program:
$ wine LTC2983.exe
3) Adjust the window size. Now the program redraws the elements on the screen.
This takes multiple seconds.
My versions
$ wine --version
wine-5.18 (Staging)
$ pacman -Q wine
wine-staging 5.18-1
uname -a
Linux cedric-p4 5.8.14-arch1-1 #1 SMP PREEMPT Wed, 07 Oct 2020 23:59:46 +0000
x86_64 GNU/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.
https://bugs.winehq.org/show_bug.cgi?id=8051
--- Comment #184 from Chebanenko Igor <chebanenkoigor93(a)gmail.com> ---
I found this:
https://www.braynzarsoft.net/viewtutorial/q16390-07-dx9-index-buffers
Quote:
Index Buffers are used to speed up or optimize your program. They are pretty
much the same thing as Vertex Buffers, but instead of storing vertices, it
stores indeces.
Is it possible to make logic similar with Index Buffers,but for Vertex Buffer
routines? Any ideas?
--
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=14398
Summary: X3 Reunion crash on opening comm menu
Product: Wine
Version: 1.1.0
Platform: PC
URL: http://www.egosoft.com/games/x3/info_en.php
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: pablo.bueti(a)gmail.com
Created an attachment (id=14712)
--> (http://bugs.winehq.org/attachment.cgi?id=14712)
The console outuput when game hangs
When selecting a ship and pressing C to open comms dialog the game hangs, there
are several fixme:amstream lines in console that don't stop showing while games
is hang. After pressing Ctrl-c in console I got the output to report the error
here (attached).
This was tested on openSuSe 10.3, kernel 2.6.22.18-0.2-default and Wine 1.1.0
without modifications.
Also videos and sounds aparently in mp3 format don't play. I found that I'm not
the only having this problem and seems to be related to amstream.dll. Also
tried using native dll but don't help (game crashes and return to console).
--
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.