https://bugs.winehq.org/show_bug.cgi?id=51172
Bug ID: 51172
Summary: Blank screen with many games using wine-staging 6.9
and Arch (wine 6.9 works OK)
Product: Wine-staging
Version: 6.9
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: vulture6(a)mail.com
CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com
Distribution: ArchLinux
Most games now just give a blank screen when they are run with wine-staging 6.9
on my Arch distro. Can list some if necessary, but should be obvious. No clear
errors from debug log. Changing to standard wine 6.9 fixes problem.
System: Core i5 with Intel UHD 630.
--
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=51198
Bug ID: 51198
Summary: regression: black screen in main menu of warcraft 3
reforged with wine-staging-6.9
Product: Wine-staging
Version: 6.9
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: idarktemplar(a)mail.ru
CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com
Distribution: ---
Created attachment 70072
--> https://bugs.winehq.org/attachment.cgi?id=70072
wc3.log.bz2
When running Warcraft 3 Reforged in wine-staging 6.9, main menu is a completely
black screen, and instead of cursor there are some visual artefacts.
With wine-staging 6.8 it works acceptably: it's really slow, but at least
there's properly rendered main menu.
No DXVK is used.
OS: Gentoo Linux, kernel 5.10.27
Proprietary Nvidia driver 460.67:
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce GTX 750/PCIe/SSE2
OpenGL core profile version string: 4.6.0 NVIDIA 460.67
OpenGL core profile shading language version string: 4.60 NVIDIA
Wine output contains a lot of lines similar to:
03bc:err:d3d:state_undefined Undefined state UNKNOWN_STATE(0) (0).
Log 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=50520
Bug ID: 50520
Summary: Any Rust-Lang application: Cannot create an async tcp
connection
Product: Wine
Version: 5.0
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: major
Priority: P2
Component: winsock
Assignee: wine-bugs(a)winehq.org
Reporter: winehq(a)greaka.de
Distribution: ---
Created attachment 69183
--> https://bugs.winehq.org/attachment.cgi?id=69183
minimal example
Rust applications are not able to use async libraries in wine. TCP connections
send Syn, receive Syn/Ack, send Reset.
Test matrix:
- Wine versions 5.0, 5.8, 5.22, 6.0rc0 , 6.0rc6
- Ubuntu, Arch
- WSL, native on laptop
- Tokio, Smol, Async-Std (Smol and async-std use the same under the hood)
- Rust versions 1.48 stable, 1.49 stable, 1.50 beta
- Targets windows-gnu, windows-msvc
- Toolchains gnu, msvc
Every combination fails to connect.
Minimal example source code: https://pastebin.com/SZavTYD7
precompiled binary 1.50 beta/windows-msvc/msvc attached.
The example expects a listener on localhost:41206!
You can easily open one with ncat -l -k -p 41206
The error returned to rust:
[src\main.rs:10] TcpStream::connect(addr.as_slice()).await = Err(
Os {
code: 10045,
kind: Other,
message: "OS Error 10045 (FormatMessageW() returned error 317)",
},
)
Trace from wineserver:
Short version
https://cdn.discordapp.com/attachments/596410107726921728/79886280364864308…
Long version
https://cdn.discordapp.com/attachments/596410107726921728/79885875841138688…
--
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=48726
Bug ID: 48726
Summary: Final Fantasy XIV, freezes for several seconds when
the mouse is moved with ReShade / GShade installed.
Product: Wine-staging
Version: 5.0
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: HereInPlainSight+wine(a)gmail.com
CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com
Distribution: ---
First time submitting -- apologies if I'm missing anything obvious.
Firstly, the regression was tested using the git repos from wine's 'wine-5.0'
tag and wine-staging's 'v5.0' tag. The issue is still present even with the
wine 5.3 versions, but when I tried to follow the regression tests, I was
failing to compile. I might've screwed something up, I can try again if you
need me to, but I am a bit of a derp and I'm punching upward. The output I got
from the regression test (following instructions from
https://wiki.winehq.org/Wine-Staging#Reporting_and_debugging_bugs_against_S…
) was:
014cecf3f8e5eac5f8e23ef1aaf07f8e17169188 is the first bad commit
commit 014cecf3f8e5eac5f8e23ef1aaf07f8e17169188
Author: Rémi Bernon <rbernon(a)codeweavers.com>
Date: Mon Aug 26 14:08:20 2019 +0200
dinput8: Use raw input interface for dinput8 mouse device.
dlls/dinput/mouse.c | 117 +++++++++++++++++++++++++++++++++++++++++++-
dlls/dinput8/tests/device.c | 10 ++--
2 files changed, 119 insertions(+), 8 deletions(-)
Second, the game currently requires ntdll-Hide_Wine_Exports, and it works fine
with just that, and people can use an older version of Proton / Wine and that
works around the problem too.
Finally, the actual problem:
If ReShade (or GShade, a fork of ReShade) is installed with FFXIV, as soon as
you get into the game itself (not the launcher), the game works perfectly fine
unless you move the mouse. As soon as you move the mouse the game freezes from
around five to ten seconds every time you move the mouse, making it effectively
unplayable. This did not happen with Wine-Staging prior to 5.0.
Reproduction:
1) Download and install FFXIV (I realize Lutris is an extraneous program and I
can go through the details, but I'd just be repeating what the scripts at
https://lutris.net/games/final-fantasy-xiv-a-realm-reborn/ say to do / what's
required. I can add the info if it's preferable).
2) Download and install a shader program (I use GShade, so instructions are
based on that arbitrarily, but I confirmed the same issue with ReShade):
2a) Easiest installation is to download
https://github.com/Mortalitas/GShade-Shaders/releases/latest/download/GShad…
into the prefix/drive_c/Program Files (x86)/SquareEnix/FINAL FANTASY XIV - A
Realm Reborn/game/ directory and unzip it. Also download
https://lutris.net/files/tools/dll/d3dcompiler_47.dll to the same location.
2b) Add overrides for d3d11 (native,builtin) and d3dcompiler_47 (native) to the
prefix.
3) Run the game, sign in through the launcher.
4) When the game loads, move the mouse.
There's no output of the issue such that I can see by default in the console.
--
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=51725
Bug ID: 51725
Summary: 7-zip 19.0 (up to 21.03) crashes opening Z: or local
file system
Product: Wine-staging
Version: 6.16
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: major
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: noabody(a)yahoo.com
CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com
Distribution: ---
Created attachment 70609
--> https://bugs.winehq.org/attachment.cgi?id=70609
Log of both wine/staging 6.16
See attachment:
System: Manjaro 21.1.2 (Arch-like)
Summary: wine-6.16, 7-zip 19.00 through 21.03 can open "Z:" drive local
filesystem without issue.
wine-6.16 (Staging), 7-zip 19.00 through 21.03 cannot open "Z:" drive
local filesystem without immediate crash.
See 7zip.org to download and test.
--
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=48945
Bug ID: 48945
Summary: "Show Advanced Fields" link should be made more
visible and changed to a button
Product: WineHQ Bugzilla
Version: unspecified
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: bugzilla-unknown
Assignee: wine-bugs(a)winehq.org
Reporter: stefan.riesenberger(a)gmail.com
CC: austinenglish(a)gmail.com
Distribution: ---
Created attachment 66919
--> https://bugs.winehq.org/attachment.cgi?id=66919
Example modification of the "Show Advanced Fields" button
This is a enhancement bug about the bug report page itself.
The "Show Advanced Fields" link isn't really eye catching and blends in with
labels or links that will move you to other pages. I would suggest changing it
to a real button instead, which would make it's function more obvious.
The placement could also be improved, but that's not as important. Currently it
gets overshadowed by the components list, so you pretty much overlook it. I
would suggest moving it between the version and summary field.
I attached a screenshot on how I think it should look like, but as said above
the button position is probably more subjective.
I hope I explained everything in an understandable way.
Kind regards,
Riesi
--
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=36544
Bug ID: 36544
Summary: The Weather Channel Desktop App for Windows fails to
install
Product: Wine
Version: 1.6.2
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: alfredo.pacheco32(a)gmail.com
Created attachment 48639
--> http://bugs.winehq.org/attachment.cgi?id=48639
Backtrace text file
When attempting to open and install the app, an error occurs, stating missing
files.
http://www.weather.com/mobile/win7desktop/installer/twcsetup.exe
Lubuntu 14.04
GNOME v3.8.4
Kernel 3.13.0.-27-generic
--
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=32845
Bug #: 32845
Summary: Installing Cisco CSM 4.2 in Ubuntu x64 fails (32bit
works)
Product: Wine
Version: 1.4.1
Platform: x86-64
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: lordmael(a)gmail.com
Classification: Unclassified
Created attachment 43377
--> http://bugs.winehq.org/attachment.cgi?id=43377
Backtrace from the wine error log.
Installing Cisco Security Manager (CSM) 4.2 on ubuntu 64bit fails but when
installing it in 32bit ubuntu it installs and runs fine.
I followed the directions to install the replacement advpack.dll and update it
in the wine libraries as well as installing java in the wine environment prior
to installing CSM.
Running ubuntu 12.10 x64 with wine 1.4.1 (perhaps I need to update)
Willing to help out as much as needed :)
--
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=34648
Bug #: 34648
Summary: J2SE Runtime Environment 5.0 Update 10 installer
'patchjre' tool crashes due to unbuffered io on
redirected stdout pipe
Product: Wine
Version: 1.7.3
Platform: x86
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: msvcrt
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: focht(a)gmx.net
Classification: Unclassified
Hello folks,
as the summary says ...
The first thing to notice is the installer seeming to hang without showing GUI.
It actually tries to call home to 'jal.sun.com' which might take up to a minute
until it times out.
Not sure why they didn't remove the DNS entry if the host is
dead/filtered/blocked anyway.
--- snip ---
0009:trace:wininet:HTTP_HttpSendRequestW Request header -> L"HEAD
/webapps/installstat/CountryLookup HTTP/1.1\r\nHost:
jal.sun.com\r\nContent-Length: 0\r\nUser-Agent: jupdate\r\nCache-Control:
no-cache\r\nConnection: Keep-Alive\r\n\r\n"
0009:trace:wininet:GetAddress L"jal.sun.com"
0009:trace:wininet:HTTP_ResolveName resolved L"jal.sun.com" to 192.18.97.143
0009:trace:wininet:open_http_connection connecting to L"jal.sun.com", proxy
(null)
--- snip ---
(test with a browser)
The crash itself can be reproduced by running the following command after
failed install attempt:
--- snip ---
$ pwd
/home/focht/.wine/drive_c/Program Files/Common Files/Java/Update/Base
Images/jre1.5.0.b64/patch-jre1.5.0_10.b03
$ wine ./patchjre.exe -s "C:\\Program Files\\Java\\jre1.5.0_10"
--- snip ---
Backtrace:
--- snip ---
Unhandled exception: page fault on read access to 0x00000001 in 32-bit code
(0xf7527245).
Register dump:
CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
EIP:f7527245 ESP:0033c33c EBP:0033c398 EFLAGS:00010206( R- -- I - -P- )
EAX:00000001 EBX:f75a5000 ECX:00000022 EDX:00000000
ESI:7e5ea308 EDI:7b868ca6
Stack dump:
0x0033c33c: 00000001 00000000 00000004 0033c398
0x0033c34c: 00000000 00000000 0012fa10 00000000
0x0033c35c: 00000000 00000000 00000000 0033c340
0x0033c36c: 7e61e000 7e5ea308 7b868ca6 0033c398
0x0033c37c: 7e5ea32f 00000001 0040a32c 0033db40
0x0033c38c: 0040626c 00000000 00000000 0033db40
000c: sel=0067 base=00000000 limit=00000000 16-bit --x
Backtrace:
=>0 0xf7527245 __strstr_sse42+0x25() in libc.so.6 (0x0033c398)
1 0x7e5ea32f MSVCRT_strstr+0x26(haystack=*** invalid address 0x1 ***,
needle=""") [/home/focht/projects/wine/wine-git/dlls/msvcrt/string.c:1725] in
msvcrt (0x0033c398)
2 0x0040628f in patchjre (+0x628e) (0x0033db40)
3 0x00401155 in patchjre (+0x1154) (0x0033fd84)
4 0x00406daa in patchjre (+0x6da9) (0x0033fe20)
5 0x7b863cf0 call_process_entry+0xb() in kernel32 (0x0033fe38)
--- snip ---
The patcher creates pipes for child process stdio:
--- snip ---
0025:Call KERNEL32.CreatePipe(0033db30,0033db24,0033db18,00000400) ret=0040616e
0025:Ret KERNEL32.CreatePipe() retval=00000001 ret=0040616e
0025:Call KERNEL32.CreatePipe(0033db34,0033db28,0033db18,00000400) ret=0040618b
0025:Ret KERNEL32.CreatePipe() retval=00000001 ret=0040618b
0025:Call KERNEL32.CreatePipe(0033db38,0033db2c,0033db18,00000400) ret=004061a2
0025:Ret KERNEL32.CreatePipe() retval=00000001 ret=004061a2
...
0025:Call KERNEL32.SetHandleInformation(00000064,00000001,00000000)
ret=00406205
0025:Ret KERNEL32.SetHandleInformation() retval=00000001 ret=00406205
0025:Call KERNEL32.SetHandleInformation(00000068,00000001,00000000)
ret=0040620d
0025:Ret KERNEL32.SetHandleInformation() retval=00000001 ret=0040620d
0025:Call KERNEL32.SetHandleInformation(00000070,00000001,00000000)
ret=00406215
0025:Ret KERNEL32.SetHandleInformation() retval=00000001 ret=00406215
--- snip ---
The child process is started:
--- snip ---
...
0025:Call KERNEL32.CreateProcessA(00000000,0033cbbc "C:\\Program
Files\\Java\\jre1.5.0_10\\bin\\java.exe
-fullversion",00000000,00000000,00000001,08000008,00000000,00000000,0033dabc,0033db00)
ret=00406248
...
0027:Call KERNEL32.__wine_kernel_init() ret=7bc594f9
0025:Ret KERNEL32.CreateProcessA() retval=00000001 ret=00406248
...
--- snip ---
The parent (patcher) immediately issues a blocking read on child stdout pipe
without waiting for anything.
It blocks until the child writes something to other end of pipe:
--- snip ---
0025:Call KERNEL32.ReadFile(00000070,0033d3bc,00000100,0033db48,00000000)
ret=0040626c
--- snip ---
The child parses the command line and (f)prints out the version string to
"stdout" pipe.
I added more trace info to show 'MSVCRT_fwrite' and 'MSVCRT__write' calls +
args.
--- snip ---
0027:trace:msvcrt:MSVCRT__isatty :fd (2) handle (0x74)
0027:Call KERNEL32.GetFileType(00000074) ret=7ecacf3f
0027:Ret KERNEL32.GetFileType() retval=00000003 ret=7ecacf3f
0027:trace:msvcrt:pf_printf_a Format is: "%s full version \"%s\"\n"
0027:trace:msvcrt:_lock (30)
0027:trace:msvcrt:MSVCRT_fwrite :file (0x7ed22320) ptr (0x40809c) wrcnt (4)
file->_cnt=0
0027:trace:msvcrt:MSVCRT__isatty :fd (2) handle (0x74)
0027:Call KERNEL32.GetFileType(00000074) ret=7ecacf3f
0027:Ret KERNEL32.GetFileType() retval=00000003 ret=7ecacf3f
0027:Call ntdll.RtlAllocateHeap(00110000,00000008,00000200) ret=7ecb8877
0027:Ret ntdll.RtlAllocateHeap() retval=00134f48 ret=7ecb8877
0027:trace:msvcrt:MSVCRT__write :fd (2) handle (116) buf (0x40809c) len (4)
0027:Call KERNEL32.WriteFile(00000074,0040809c,00000004,0033f7a4,00000000)
ret=7ecb4157
0027:Ret KERNEL32.WriteFile() retval=00000001 ret=7ecb4157
0027:trace:msvcrt:_unlock (30)
0027:trace:msvcrt:_lock (30)
--- snip ---
Upon pipe write of client, the parent's blocking read returns and it starts
parsing the output:
--- snip ---
0025:Ret KERNEL32.ReadFile() retval=00000001 ret=0040626c
Regards
...
0025:Call msvcrt.strstr(0033d3bc "java",0040a32c "\"") ret=00406280
...
0025:Ret msvcrt.strstr() retval=00000000 ret=00406280
...
0025:Call msvcrt.strstr(00000001,0040a32c "\"") ret=0040628f
...
0025:trace:seh:raise_exception code=c0000005 flags=0 addr=0xf747d245
ip=f747d245 tid=0025
--- snip ---
Unfortunately the buffer of client fprintf() call was not written in one piece
(buffered io) causing the parent to read only a partial string.
Due to crappy coding it crashes (2x strstr for '"' won't work for partial
data).
As seen in trace the first 4 bytes were directly written to pipe without any
buffering.
The child process fprintf() call to stdout (pipe):
--- snip ---
...
0040111F mov dword ptr [40AEB8h], 40809Ch ; offset "java"
...
00402007 push 4085DCh ; offset to "1.5.0-b64"
0040200C push dword ptr [40AEB8h] ; -> "java"
00402012 add eax, 40h
00402015 push 4085E8h ; offset to "%s full version \"%s\"\n"
0040201A push eax ; FILE *
0040201B call fprintf
--- snip ---
The first call to WriteFile() is actually the result of outputting first string
argument after format string -> 40809Ch = "java" (len=4).
Each vfprintf() argument handler -> pf_output_xxx will immediately trigger an
unbuffered write to the pipe(s).
Example session with winedbg showing use of buffered stdio when started from
console (len = 0x1f):
--- snip ---
=>0 0x7b83db29 WriteFile(hFile=0x17, buffer=0x112110, bytesToWrite=0x1f,
bytesWritten=0x33f9bc, overlapped=(nil))
[/home/focht/projects/wine/wine-git/dlls/kernel32/file.c:529] in kernel32
(0x0033fa38)
1 0x7ecace65 msvcrt_flush_buffer+0x54(file=0x7ed22320)
[/home/focht/projects/wine/wine-git/dlls/msvcrt/file.c:565] in msvcrt
(0x0033fa78)
2 0x7ecad0b8 remove_std_buffer+0x10(file=0x7ed22320)
[/home/focht/projects/wine/wine-git/dlls/msvcrt/file.c:628] in msvcrt
(0x0033fa98)
3 0x7ecb7630 MSVCRT_vfprintf+0x91(file=0x7ed22320, format="%s full version
"%s"
", valist="") [/home/focht/projects/wine/wine-git/dlls/msvcrt/file.c:4491] in
msvcrt (0x0033fae8)
4 0x7ecb7aca MSVCRT_fprintf+0x35(file=0x7ed22320, format="%s full version
"%s"
") [/home/focht/projects/wine/wine-git/dlls/msvcrt/file.c:4612] in msvcrt
(0x0033fb1c)
5 0x00402021 in java (+0x2020) (0x00111ff3)
--- snip ---
It seems to me that buffered io should be still done even if stdout is
connected to a pipe.
Regards
--
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=48101
Bug ID: 48101
Summary: Metatester 5 exits silently
Product: Wine
Version: 4.19
Hardware: x86-64
URL: http://files.metaquotes.net/metaquotes.software.corp/m
t5/mt5tester.setup.exe
OS: Linux
Status: NEW
Keywords: download
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: imwellcushtymelike(a)gmail.com
Distribution: Ubuntu
Metatester 5 exits silently after an unknown period of time.
The agent starts a number of background services (that apparently install
correctly), but when it exits, Wine kills off the background services along
with everything else.
To workaround that specific problem:
1. wineserver -p
2. wineboot
3. Anything else.
(Bug 39030)
Nonetheless if you let the agent, or Wine itself, start up the services the
result is the same: the agent simply vanishes after an unknown amount of time.
Usually less than an hour. Under Windows 8.1 and 10 it runs indefinitely.
Entire log (wineserver and wineboot already run):
0190:fixme:heap:RtlSetHeapInformation 0x6a0000 0 0x22f3f0 4 stub
0190:fixme:font:get_outline_text_metrics failed to read full_nameW for font
L"Ani"!
0190:fixme:nls:GetThreadPreferredUILanguages 00000038, 0x2263e4, 0x226400
0x2263e0
0190:fixme:nls:get_dummy_preferred_ui_language (0x38 0x2263e4 0x226400
0x2263e0) returning a dummy value (current locale)
0196:fixme:kernelbase:AppPolicyGetThreadInitializationType FFFFFFFFFFFFFFFA,
0000000000C5FD80
0190:fixme:ntdll:server_ioctl_file Unsupported ioctl 9003c (device=9 access=0
func=f method=0)
0190:fixme:ntdll:NtQuerySystemInformationEx Relationship filtering not
implemented: 0x1
0190:fixme:ntdll:NtQuerySystemInformationEx Relationship filtering not
implemented: 0x1
0190:fixme:shell:InitNetworkAddressControl stub
0198:fixme:secur32:schan_QueryContextAttributesW Unhandled attribute 0x64
0197:fixme:secur32:schan_QueryContextAttributesW Unhandled attribute 0x64
0190:fixme:kernelbase:AppPolicyGetProcessTerminationMethod FFFFFFFFFFFFFFFA,
000000000022FCD0
No workarounds used.
The app can be started again without 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.
https://bugs.winehq.org/show_bug.cgi?id=51831
Bug ID: 51831
Summary: TrueDrive: On start shows an alert that the steering
wheel is turned around too close to the bump stops,
while the wheel is actually aligned on top center
Product: Wine
Version: 6.18
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: hid
Assignee: wine-bugs(a)winehq.org
Reporter: logos128(a)gmail.com
CC: rbernon(a)codeweavers.com
Regression SHA1: 8b434bdc7fe98e3bd97e180f31bc18d87161c05a
Distribution: ArchLinux
Created attachment 70718
--> https://bugs.winehq.org/attachment.cgi?id=70718
0001-winebus.sys-Fix-possible-memory-access-error-in-bus_.patch
In addition to the summary, the in app steering wheel animation is indeed
turned around usually on left, and the high torque mode of the Simucube 2 FFB
wheel is also being disabled, as the alert warns. After closing the alert, the
steering wheel animation resumes proper tracking of the real wheel.
After some regression testing found out that in bus_event_queue_pop()
(winebus.sys/unixlib.c) the size for the memcpy operation is calculated on base
of the event->input_report.length, and when the event operand is passed for
first time to this function, its input_report.length is uninitialized. The
bus_event structure is being allocated once per bus thread.
This could lead to either insufficient bytes being copied to the event struct,
or memory access error for an out of bounds copy operation of the tmp struct.
The consecutive calls of this function use the event->input_report.length
again, which in this case is just the length of the input buffer from the
previous operation.
If the device uses multiple input reports with different ReportIDs and
different lengths, this could lead to serious issues.
Attached a patch which fixes the issue (based on the current master)
--
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=51828
Bug ID: 51828
Summary: Simucube 2: All applications using raw HID access to
communicate with devices, stopped tracking steering
axis movement
Product: Wine
Version: 6.18
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: hid
Assignee: wine-bugs(a)winehq.org
Reporter: logos128(a)gmail.com
CC: rbernon(a)codeweavers.com
Regression SHA1: d40d8d968658dca4a75afc97f9e48acda0654b0f
Distribution: ArchLinux
Created attachment 70716
--> https://bugs.winehq.org/attachment.cgi?id=70716
0001-hidclass.sys-Fix-input-reports-with-ReportID-being-d.patch
Found out that the dropping of input packets with lengths different than
desc->InputLength, which was introduced with the regression commit is causing
this issue.
Since the Simucube 2 is a HID PID device, it uses multiple HID reports (with
defined ReportIDs), which are different lengths. For such devices
desc->InputLength specifies the biggest possible buffer length, that would fit
any of the input reports. If the most essential input report for tracking the
steering axis movements is smaller than desc->InputLength, it'll be dropped by
that check. Only the reports with the exact same size go through in non polled
mode.
In this case with Simucube 2 the biggest input report is of 61 bytes, and is
vendor defined. All the other input reports are smaller sizes, and will get
dropped.
Attached a patch which fixes the issue. It also fixes possible memory access
error with report->buffer while copying it to irp->AssociatedIrp.SystemBuffer,
due to the internal buffer for hid_report being just report->length which could
be less than or equal to desc->InputLength.
The patch is based to the current master
(aa629c4c7225166f4ee46476d98702df2e142711).
--
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=51824
Bug ID: 51824
Summary: TrueDrive, SimHub, Fanaleds,etc.: Non smooth movement
tracking with severe skipping/jumping of the steering
wheel/controller axis
Product: Wine
Version: 6.18
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: hid
Assignee: wine-bugs(a)winehq.org
Reporter: logos128(a)gmail.com
CC: rbernon(a)codeweavers.com
Regression SHA1: 325984ded50b354686e5a454aa5aca3aafa81432
Distribution: ArchLinux
Created attachment 70711
--> https://bugs.winehq.org/attachment.cgi?id=70711
0001-hidclass.sys-Fix-writing-all-new-reports-at-the-last.patch
All the mentioned applications use raw HID access (through HidD/HidP calls) to
the devices they controll, so the movement tracking problems appear only there.
DirectInput works well.
After further investigation, found that the simpler ring buffer
(hidclass.sys/device.c) introduced with the mentioned regression commit is
causing the issues. Appeared that all new reports are pushed at the last
available ring buffer slot, due to reaching the end of the buffer before the
reading has started. Usually such devices as joysticks, controllers, steering
wheels, etc., use constant stream of INPUT reports to report their axis
movement, so any report skipping or change of the sequence, while the
interested apps are reading, would lead to such issues.
Attached a patch which fixes the issue (based on the current master
aa629c4c7225166f4ee46476d98702df2e142711).
--
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=51822
Bug ID: 51822
Summary: Simucube 2 TrueDrive: Doesn't recognize the steering
wheel device
Product: Wine
Version: 6.12
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: hid
Assignee: wine-bugs(a)winehq.org
Reporter: logos128(a)gmail.com
CC: rbernon(a)codeweavers.com
Regression SHA1: 51560aabcb259cb89659d96654d8ad38edbb528d
Distribution: ArchLinux
Created attachment 70707
--> https://bugs.winehq.org/attachment.cgi?id=70707
0001-hidparse.sys-Preserve-the-original-state-items.repor.patch, wine_6.18.log,
SC2_descr.txt
Simucube 2 is FFB steering wheel device using the HID PID specification for
FFB. Thus the support for it is included in the Linux kernel as part of the HID
specification. It still needs some patching of the usbhid kernel module, but in
general is entirely functional in Wine, as long as "DisableInput" and "Enable
SDL" are disabled in the Wine registry, and for the HIDRAW device is granted rw
user access.
TrueDrive is an application for controlling and fine tuning various parameters
of the steering wheel (using HidD/HidP calls), which also includes real time
animation of the steering wheel movement, buttons pushed, etc. The application
is not used/needed during gameplay. The TrueDrive version used is 2020.10. The
application can be downloaded from the manufacturer site:
https://granitedevices.com/wiki/Simucube_2_True_Drive_releases
The mentioned regression commit is the earliest in which the problem occurs.
I've investigated further, and found that state->items.report_count in the
parse_new_value_caps() function (hidclass.sys/descriptor.c) is not preserved
properly. While being used for building the alternate value array it's set to
1, and since "Report Count" is a global item, reset_local_items() at the end of
the function preserves its state. Thus if there are subsequent main items
(Input, Output, etc.) with more than one usages, and with no "Report Count"
specified in between, the parser would calculate wrong bit sizes, report len,
etc.
The particular problem was at the end of the descriptor. Here is an excerpt:
/* Usage Page (FF00h), */
/* Usage (01h), */
/* Collection (Application), */
/* Usage (01h), */
/* Report ID (107), */
/* Report Size (8), */
/* Report Count (60), */
/* Logical Minimum (0), */
/* Logical Maximum (255), */
/* Output, */
/* Usage (01h), */
/* Report ID (108), */
/* Input, */
/* End Collection, */
The Input report 108 follows immediately the Output report 107, without Report
Count specified in between. In our case parse_new_value_caps() would set
erroneously Report Count to 1, after being called on the Output main item. Thus
the next Input report size would be calculated wrongly. This is a vendor
defined report, which they probably use in the process of recognizing the
device.
Since then the issue was mitigated a little bit with commit
7096c26a2e48089424fe90956c80c29617bce9f2, when button array value caps were
introduced, which stopped modifying state->items.report_count if the parsed
item is an array.
The issue is still present in the new hidparse.sys (main.c), where the parsing
code has been moved with commit a290c5bf7c9ddc92af56231693c6d8f00c3efd7b.
It is present in Output report 2. Here is an excerpt:
/* Usage (5Ah), */
/* Collection (Logical), */
/* Report ID (2), */
...
/* Report Count (2), */
/* Output (Variable), */
/* Usage (5Ch), */
/* Usage (5Eh), */
/* Unit (Seconds), */
/* Unit Exponent (-3), */
/* Logical Maximum (32767), */
/* Physical Maximum (32767), */
/* Report Size (16), */
/* Output (Variable), */
/* Physical Maximum (0), */
/* Unit, */
/* Unit Exponent (0), */
/* End Collection, */
Since the Output main items are variable, state->items.report_count is still
being modified to 1. So the second Output item ends up with two usages, one 16
bit report, and one 0 bit report. This can be seen in the attached log file
wine_6.18.log. For Output report 2, the RCnt for Usage 0x5E is 0.
The following debug options were used for the log:
WINEDEBUG=+timestamp,+pid,+hid,+hidp,+hid_report,+plugplay. The Wine build is
6.18-107-gbcdb28a563d.
I've attached the Simucube 2 device descriptor in SC2_Descr.txt. Hope it can
help as a real life example of a HID PID device with multiple ReportIDs.
Attached also a patch which is fixing the issue (based on the latest master
aa629c4c7225166f4ee46476d98702df2e142711).
--
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=51710
Bug ID: 51710
Summary: 3utools doesn't see iPad
Product: Wine
Version: 6.16
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: major
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: aykutboray(a)gmail.com
Distribution: ---
Created attachment 70586
--> https://bugs.winehq.org/attachment.cgi?id=70586
Bug moment
When I wanted to install new IPad OS software 3utools doesn't see my iPad it
was connected to pc.
--
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=51987
Bug ID: 51987
Summary: Multiple GUI elements are not rendered when using a
theme
Product: Wine
Version: 6.21
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: uxtheme
Assignee: wine-bugs(a)winehq.org
Reporter: aros(a)gmx.com
Distribution: ---
Created attachment 70975
--> https://bugs.winehq.org/attachment.cgi?id=70975
All broken
This is a follow up to bug 51986.
See the attached screenshot.
--
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=52028
Bug ID: 52028
Summary: Regression: Themed contents doesn't displays correctly
in some themes
Product: Wine
Version: 6.21
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: comctl32
Assignee: wine-bugs(a)winehq.org
Reporter: joseskvolpe(a)gmail.com
Distribution: ---
Created attachment 71028
--> https://bugs.winehq.org/attachment.cgi?id=71028
good vs bad
Regression test result:
7c9cacd47f969181624b2c5fafd7554188d7fa47 is the first bad commit
commit 7c9cacd47f969181624b2c5fafd7554188d7fa47
Author: Zhiyi Zhang <zzhang(a)codeweavers.com>
Date: Fri Nov 5 14:34:58 2021 +0800
comctl32/button: Correctly place parts for themed group boxes.
Signed-off-by: Zhiyi Zhang <zzhang(a)codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard(a)winehq.org>
dlls/comctl32/button.c | 49 +++++++++++++++++++++++++++----------------------
1 file changed, 27 insertions(+), 22 deletions(-)
Procedure:
1 - Open winecfg
2 -- Apply a theme that presents this issue
I've used a modified theme from VLT by evgkursai. Original msstyles file
presents this issue too. You can download it here:
https://www.deviantart.com/evgkursai/art/VLT-2-0-VS-36103075
--
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=52025
Bug ID: 52025
Summary: Custom color configuration is reseted if custom theme
is applied
Product: Wine
Version: 6.21
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: uxtheme
Assignee: wine-bugs(a)winehq.org
Reporter: joseskvolpe(a)gmail.com
Distribution: ---
Regression result:
3762a11c81455edee65881702c5c26ae5d3081b3 is the first bad commit
commit 3762a11c81455edee65881702c5c26ae5d3081b3
Author: Zhiyi Zhang <zzhang(a)codeweavers.com>
Date: Thu Nov 4 14:44:47 2021 +0800
uxtheme: Fix loading a different theme when theming is on.
When a theme is already active and a user tries to activate another theme,
the new theme configuration should be written to the registry so that it's
still in effect after a wine reboot.
Fix a regression introduced in d290362.
Signed-off-by: Zhiyi Zhang <zzhang(a)codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard(a)winehq.org>
dlls/uxtheme/system.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
Wine 6.20 -> 6.21
Procedure:
1 - Open winecfg
2 - Apply a custom theme, theme used on this test was VLT by evgkursai:
https://www.deviantart.com/evgkursai/art/VLT-2-0-VS-36103075
3 - Change any color and apply. On this test, i've changed "Selection
Background" ("Fundo da Seleção" in portuguese-brazilian) color
4 - Close winecfg
5 - Open winecfg again
--
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=51934
Bug ID: 51934
Summary: Battle.Net after login bug
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: ptg76(a)ukr.net
Distribution: ---
Created attachment 70899
--> https://bugs.winehq.org/attachment.cgi?id=70899
backtrace log
Hi, All!
After updates, I cannot log in to Battle.Net nor the Starcraft game directly.
After entering username and password it falls into repeating "crash"(?).
I've attached the backtrace log file.
Any ideas, workarounds, something?
Sincerely, Peter
--
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=32385
Bug #: 32385
Summary: MSTSC (Remote Desktop) drawing issues
Product: Wine
Version: 1.5.18
Platform: x86-64
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gdi32
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: kenjiru.ro(a)gmail.com
Classification: Unclassified
Created attachment 42734
--> http://bugs.winehq.org/attachment.cgi?id=42734
Drawing issues.
When it works, it has some drawing issues. Some windows are not drawn correctly
at all, the title bars of some windows are not drawn.
I see a lot of messages in the console, but I don't know which ones are to
blame.
I've attached the console output.
--
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=52113
Bug ID: 52113
Summary: Killing Floor 2 : Item Server not connectable
Product: Wine
Version: 6.21
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: major
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: maycne.sonahoz(a)posteo.net
Distribution: ---
Overview:
In Killing Floor 2, the Item Server cannot be reached. In consequence,
neither the Inventory nor the Store are available from within the game.
Steps to Reproduce:
1) Launch Killing Floor 2.
2) In the main menu, an icon should tell the connectivity with the Item
Server. That icon shows the server is unreachable.
3) Access the Inventory tab. It should be filled with your custom items,
but it always shows empty.
4) Access the Store tab. It should be filled with store offers, but it
always shows empty.
Build Date & Hardware:
Manjaro stable - Xfce - kernel 5.10.79-1 - 2021-11-16
The issue has been happening from a long time now. As for today's
reference:
- Failed to reach the steps to reproduce the issue with Development Wine:
- Development Wine built locally from source
- Steam (for Windows) installed through Wine
- Steam refuses to install Killing Floor 2 : "invalid platform"
- Issue reproduced with:
- Steam (for Linux) Beta
- Proton-6.21-GE-2 (based on Wine 6.21)
Additional Builds and Platforms:
Manjaro stable - Xfce - kernel 5.10.79-1 - 2021-11-16
The issue does not (yet) reproduce with:
- Steam (for Linux) Beta
- Proton 6.3-8 (based on Wine 6.3)
--
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=29503
Bug #: 29503
Summary: Stucuk's Setup System patcher often fails with 'Canvas
does not allow drawing' error message
Product: Wine
Version: 1.3.36
Platform: x86
URL: http://www.fileplanet.com/207230/200000/fileinfo/Dark-
Horizon-Patch-v1.0.6.1
OS/Version: Linux
Status: NEW
Keywords: download, Installer
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: gyebro69(a)gmail.com
Classification: Unclassified
Created attachment 38206
--> http://bugs.winehq.org/attachment.cgi?id=38206
screenshot (patcher running in virtual desktop)
The installer of the patch made for Dark Horizon uses a Stucuk's Setup System
according to the file properties. The installer of the community patch made for
Original War also uses this kind of patcher, sharing the same problem.
The patcher for Dark Horizon consists of nearly 3000 small files. The
installation process doesn't take long (15-20 seconds). At some point during
the install process, the patcher is interrupted with an error message:
'Setup Thread Error: Canvas does not allow drawing', and the installer quits
prematurely.
This happens fairly often (maybe 8 times out of 10 attempts), but sometimes the
patcher finishes the job without erroring out.
Before the error message pops up, text which normally appears inside the
installer window also printed and overwritten several hundreds of times in the
upper left corner of the screen (see attached screenshot). This happens both in
virtual desktop mode and in full-screen.
To reproduce the problem with the patcher made for Dark Horizon you don't have
to download the demo for the game; the patch can be installed alone in a
selected directory anywhere inside a wineprefix.
--
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=41615
Bug ID: 41615
Summary: Max Payne 1 and 2 crash using glsl=enabled
Product: Wine
Version: 1.9.21
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: mrdeathjr28(a)yahoo.es
Distribution: ---
Created attachment 55965
--> https://bugs.winehq.org/attachment.cgi?id=55965
backtrace-max-payne-1-glsl
Max Payne 1 and 2 crash using glsl=enabled during 1st chapter
Both crash during 1st chapter however if use glsl=disabled in wine register
works stable both games pass 1st chapter with crashes
System Specs Using in Tests
Nvidia Drivers 375.10 (run package from nvidia drivers homepage)
Xubuntu 16.04 64Bit - Kernel 4.4.0-44 generic (ubuntu mainline) - CPUFreq:
Performance
CPU: INTEL Pentium G3258 (Haswell 22nm) 4.1Ghz + Artic Cooling Alpine 11 Plus
MEMORY: 8GB DDR3 1333 (2x4) Patriot value (dual channel: 21.3 gb/s)
GPU: Zotac Nvidia Geforce GT630 (GK208 28nm: 384 Shaders / 8 ROPS) Zone Edition
Passive Cooling 2GB DDR3 1800Mhz 64Bit (14.4Gb/s)
MAINBOARD: MSI H81M E33
--
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.