https://bugs.winehq.org/show_bug.cgi?id=47397
Bug ID: 47397
Summary: Altium Designer 13.3.4 cannot render DirectX 3D on
second monitor in Wine 4.10
Product: Wine
Version: 4.8
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: brian.mccarter.ctr(a)navy.mil
Distribution: ---
I have been running Altium Designer 13 on Wine successfully for some time,
using these packages installed with winetricks: gdiplus, corefonts, riched20,
mdac28, msxml16. That list was compiled from suggestions on the AppDB and may
include unnecessary packages, but it's been working fine for me through Wine
4.7. The wineprefix is otherwise unmodified, and contains only the Altium
installation. I use PlayOnLinux to manage the wineprefix and launch the
application. The WINEARCH is win32.
I recently upgraded to Wine 4.10 (vanilla, not staging), and found that Altium
is no longer able to render DirectX 3D on my second monitor. Rendering on my
primary monitor still works fine, and Wine does not crash or otherwise throw an
error when I move the Altium window to my second monitor. The only error is
reported by Altium, and reads: "Graphics adapter for this display does not meet
DirectX requirements (DirectX 9.0c, Shader Model 3.0). Unable to switch to 3D."
Doing some digging, I found that the last version of Wine that renders
correctly on the second monitor is Wine 4.7. Versions 4.8, 4.9, and 4.10 all
cause Altium to display the error.
My system uses an NVIDIA Quadro M4000 and the proprietary driver, version
430.14. The OS is Gentoo Linux, kernel 5.1.5, mesa 18.3.6. I have also tried
a recent Radeon card with mesa drivers and found the same problem, though I
haven't tested that configuration as extensively.
Nothing notable appears the debugger window when I launch the application
through PlayOnLinux.
I have tried to install several other programs with simple 3D displays in an
attempt to duplicate the error with other software, but I haven't been
successful.
Please let me know how I can help resolve this issue.
--
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=36734
Bug ID: 36734
Summary: TrackMouseEvent TME_LEAVE should not be influenced by
dwHoverTime
Product: Wine
Version: 1.4.1
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: user32
Assignee: wine-bugs(a)winehq.org
Reporter: n296869(a)rtrtr.com
When specifying both TME_LEAVE and TME_HOVER in a TRACKMOUSEEVENT, the provided
"dwHoverTime" timeout should only be applied to TME_HOVER, i.e. the hover event
should be emitted after "dwHoverTime" milliseconds. However, the WM_MOUSELEAVE
generated for TME_LEAVE should be sent instantly as soon as the mouse leaves
the window. As far as I can see, Wine delays the WM_MOUSELEAVE event by the
specified amount of milliseconds, although it shouldn't do that.
--
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=50050
Bug ID: 50050
Summary: Wine 5.20 build fails on Ubuntu 16.04
Product: Wine
Version: 5.20
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: windowscodecs
Assignee: wine-bugs(a)winehq.org
Reporter: dimesio(a)earthlink.net
Distribution: ---
Created attachment 68503
--> https://bugs.winehq.org/attachment.cgi?id=68503
Failed build log
Newer distros had no problem, but the build failed on Ubuntu 16.04. Build log
from the x86_64 build on the OBS attached; the i586 build failed in the same
way.
--
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=46373
Bug ID: 46373
Summary: i dont know about this
Product: Wine
Version: unspecified
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: documentation
Assignee: wine-bugs(a)winehq.org
Reporter: gowthamraghunathan(a)gmail.com
Distribution: ---
Created attachment 63115
--> https://bugs.winehq.org/attachment.cgi?id=63115
What to do?
I want to play windows games in ubuntu
--
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=25834
Summary: Adobe Reader X cannot open in Protected Mode
Product: Wine
Version: 1.3.11
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: winehq.crackjack(a)spamgourmet.com
Adobe Reader Protected Mode does not function, this error appears when starting
AcroRd32.exe
It's a minor issue as you can continue without it.
the log file is very short, so I'm not attaching it:
fixme:process:SetProcessDEPPolicy (1): stub
fixme:heap:HeapSetInformation (nil) 1 (nil) 0
fixme:advapi:CreateRestrictedToken (0x90, 0x2, 3, 0xb08238, 19, 0xb08408, 3,
0xb07fc8, 0x32f04c): stub
--
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=22797
Summary: BoxedApp sample apps fail on Wine
Product: Wine
Version: 1.1.44
Platform: x86
URL: http://www.boxedapp.com/boxedappsdk/download.html
OS/Version: Linux
Status: NEW
Keywords: download
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: dank(a)kegel.com
BoxedApp is an SDK used by some debugging tools (dxprof in particular)
to hook function calls and emulate filesystem operations.
(It's a bit like Thinstall, which does work with Wine, thanks to Ge's efforts.)
I tried their four sample apps.
Sample1_DLLEmbeddsamples crashing.exe crashes after you click the 'call
function' button;
evidently the LoadLibrary hooking didn't work.
Samples 2 and 3 crash faster. Sample 4 seems to run (but might not do exactly
what it should).
I'll attach a +relay,+seh log of sample 1 running.
It seems to use mpr.dll as part of its magic.
--
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=49298
Bug ID: 49298
Summary: Path of Exile crashes when switching to Vulkan
Renderer on RADV. Switching works in proton.
Product: Wine
Version: 5.9
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: winevulkan
Assignee: wine-bugs(a)winehq.org
Reporter: GloriousEggroll(a)gmail.com
Distribution: ---
Path of Exile introduced a new Vulkan renderer in the game.
When switching to Vulkan in-game, the game pauses for a few seconds then
crashes.
If I switch to proton/steam play, the switch to the vulkan renderer in-game, it
works fine and switches as expected.
This leads me to believe this is either a winevulkan or winex11.drv problem,
since those are the two main graphical differences between Standard wine and
Proton. The fact that it runs on proton with RADV also shows that RADV is
likely not the issue.
Current system is Fedora 32 with KDE, mesa-git as of 5/29/20, Vega VII, Ryzen
3950x
--
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=33072
Bug #: 33072
Summary: dxdiag: can't retrieve network info
Product: Wine
Version: 1.5.24
Platform: x86
OS/Version: Linux
Status: NEW
Keywords: download
Severity: minor
Priority: P2
Component: directx-dplay
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: austinenglish(a)gmail.com
Classification: Unclassified
$ rm -rf ~/.wine
$ winetricks -q dxdiag
$ wine dxdiag /t foo.txt
Error: Problem getting network info, result code = 0x80040154 (Class not
registered)
(split off from bug 32846)
--
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=50039
Bug ID: 50039
Summary: Wine 5.18+ fails build on Ubuntu 18.04 with libwine.so
Makefile symbolic link
Product: Wine
Version: 5.18
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: build-env
Assignee: wine-bugs(a)winehq.org
Reporter: simonnatella(a)gmail.com
Distribution: ---
I make community bi-arch wine builds for the Star Citizen community (used by
others too due to high compatibility) on Ubuntu 18.04LTS using containers for
each arch, and I've noticed that since Wine 5.18 builds fail on 64bit due to
the following:
...
gcc -m64 -c -o dlls/msvcrtd/onexit.o /build/wine-git/dlls/msvcrt/onexit.c
-Idlls/msvcrtd -I/build/wine-git/dlls/msvcrtd \
-I/build/wine-git/dlls/msvcrt -Iinclude -I/build/wine-git/include
-I/build/wine-git/include/msvcrt \
-D__WINESRC__ -D_MT -D_MSVCR_VER=0 -D_REENTRANT -fPIC
-fasynchronous-unwind-tables -fno-builtin \
-fshort-wchar -mabi=ms -Wall -pipe -fno-stack-protector -fno-strict-aliasing
\
-Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers
-Wshift-overflow=2 \
-Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wvla
-Wwrite-strings -Wpointer-arith \
-Wlogical-op -gdwarf-2 -gstrict-dwarf -g -O2 -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=0
rm -f /build/data64/build/lib64/libwine.so && ln -s libwine.so.1
/build/data64/build/lib64/libwine.so
LC_ALL=C sed -e 's,@bindir\@,/build/data64/build/bin,g' -e
's,@dlldir\@,/build/data64/build/lib64/wine,g' -e 's,@PACKAGE_STRING\@,Wine
5.19,g' -e 's,@PACKAGE_VERSION\@,5.19,g' /build/wine-git/tools/widl/widl.man.in
>tools/widl/widl.man || (rm -f tools/widl/widl.man && false)
LC_ALL=C sed -e 's,@bindir\@,/build/data64/build/bin,g' -e
's,@dlldir\@,/build/data64/build/lib64/wine,g' -e 's,@PACKAGE_STRING\@,Wine
5.19,g' -e 's,@PACKAGE_VERSION\@,5.19,g'
/build/wine-git/tools/winebuild/winebuild.man.in >tools/winebuild/winebuild.man
|| (rm -f tools/winebuild/winebuild.man && false)
ln: failed to create symbolic link '/build/data64/build/lib64/libwine.so': No
such file or directory
Makefile:221721: recipe for target 'libs/wine/install-dev' failed
make: *** [libs/wine/install-dev] Error 1
make: *** Waiting for unfinished jobs....
Switching to 19.10 fixes the issue, except that 19.10 is of course no longer
updated and 20.04 would break the compatibility I'm aiming for.
I'm presuming it's some sort of autotools error, but I don't understand
autotools much myself, nor how fixable this is.
--
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=49813
Bug ID: 49813
Summary: Implement debugging feedback extensions
(VK_EXT_debug_utils/VK_EXT_debug_report) to forward
data to Linux impl
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: winevulkan
Assignee: wine-bugs(a)winehq.org
Reporter: loothelion(a)nvidia.com
Distribution: ---
Was discussing the following earlier with Georg Lehmann and Hans-Kristian
Arntzen:
Looking for a way to forward application Vulkan API debugging info (tagged
objects / perfmarkers / queue-labels) such that the host loader will receive
these calls from the windows application.
I believe that VK_EXT_debug_marker should pass-through fine with ToT
winevulkan, but that should be confirmed.
A few thoughts on test cases to verify this missing functionality / verify an
implementation:
- Sascha Willems' debugmarker example -
https://github.com/SaschaWillems/Vulkan/tree/master/examples/debugmarker (uses
VK_EXT_debug_marker)
- Quake 2 RTX - https://github.com/NVIDIA/Q2RTX (uses
VK_EXT_debug_utils/VK_EXT_debug_report)
- Should add to dlls/vulkan-1/tests for a simple usage of tagging an object
(similar to the private data test). Maybe a small companion layer that just
plainly prints out debug information would also be of use.
Connecting to these applications via a graphics debugging tool should yield
Vulkan debug information from the application.
Some potential challenges that may be hit:
- Implementation of debug utils messenger callback in concern with
calling-convention and alignment
- make_vulkan currently notes interaction issues with VK_EXT_debug_marker and
VK_EXT_debug_utils and implementations within LunarG's vulkan-1.dll, we may
wish to conditionally expose this functionality either via a regkey, or if we
detect WINE's vulkan-1.dll implementation is in use.
Helpful links:
-
https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_EX…
-
https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_EX…
-
https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_EX…
--
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.