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=52185
Bug ID: 52185
Summary: IDA 7.6 irregular crashes when used in an IPC
namespace
Product: Wine
Version: 6.23
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: esteve.varela(a)gmail.com
Distribution: ---
When used within an environment that restricts the IPC Namespace, such as
within a Docker container or a Firejail environment, IDA crashes irregularly
when performing certain tasks. This can result in frustrating crashes and lost
work.
This is fairly simple to reproduce with just the help of the "unshare" utility:
1. Install IDA Free:
wget https://out7.hex-rays.com/files/idafree76_windows.exe
wine idafree76_windows.exe
# Follow the installation, install to default location
unshare -Ui wine 'C:\Program Files\IDA Freeware 7.6\ida64.exe'
2. Follow the prompts until you reach the main window which says "Drag a file
here to disassemble it"
3. Unmaximize the window if maximized, grab a corner and keep resizing the
window
4. Keep doing this for up to 10 seconds. The window will disappear and the
following will be shown on the terminal:
X Error of failed request: BadValue (integer parameter out of range for
operation)
Major opcode of failed request: 131 (MIT-SHM)
Minor opcode of failed request: 3 (X_ShmPutImage)
Value in failed request: 0x2e0
Serial number of failed request: 5854
Current serial number in output stream: 5858
This has been tested and verified on the following platforms:
- Gentoo (WINE 6.20, 6.22)
- Kubuntu 21.10 (WINE 6.0.2, 6.23)
- Kubuntu 20.04 (WINE 6.0.2, 6.23)
As well as the following desktop environments/window managers:
- KDE
- i3
Workarounds:
On docker, you can use the `docker run --ipc=host` command to disable the IPC
namespace.
On firejail, you can use the `ignore ipc-namespace` setting to disable the IPC
namespace.
--
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.