http://bugs.winehq.org/show_bug.cgi?id=58951
Bug ID: 58951
Summary: Zbrush (2022.06) Pen tablet pressure drops out if the
tablet is used to open a system file menu prompt
(save, load, export, import, etc)
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)list.winehq.org
Reporter: brandon(a)garagebay9.com
Distribution: ---
Created attachment 79649
--> http://bugs.winehq.org/attachment.cgi?id=79649
Log showing pressure sensitivty drop in zbrush
Program: Zbrush 2022.06 (this is not the latest release, but it is the last
release with a permanent license version, so it is in heavy use)
Issue: even with properly configured and functioning pen tablet pressure
functionality, pressure sensitivity will be lost for the rest of the program
session if tablet input is used to invoke an action that opens a file menu
prompt, such as saving, loading, exporting, importing, etc. Using the mouse
does not cause this and is a workaround. Using the pen tablet to move the
cursor outside the Zbrush program window and interact with the rest of the
desktop environment does not appear to reliably trigger this.
This is separate from bug 58950 (pen tablet pressure functionality regression
in 10.x Staging). This issue has been present for several stable releases.
OS: Debian 13 / Trixie
Kernel: 6.16.3+deb13-amd64
Tablet: Bus 001 Device 007: ID 056a:00b5 Wacom Co., Ltd PTZ-631W [Intuos3
(6x11)]
(Note this issue is also seen on my Huion Kamvas 16 Pro 2.5k)
Wine version: Current Staging (10.18), current Stable (10), prior stable
releases back to at least Wine 7.
Test procedure for attached log:
WINDEBUG = +wintab,+heap,+err,+hid
1. Open Zbrush
2. Create test subtool (subdivided cube)
3. Sculpt with pen tablet, observe pressure input working (stroke size varies
with pressure)
4. Use mouse to open Save As dialogue, exit dialogue
5. Sculpt with pen tablet, observe pressure input *still* working (stroke size
varies with pressure)
6. Use pen tablet to open Save As dialogue, exit dialogue
7. Sculpt with pen tablet, observe pressure input lost (stroke size does not
vary with pressure input)
--
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=58950
Bug ID: 58950
Summary: Pen tablet pressure not working in Zbrush (2022.06)
Product: Wine
Version: 10.18
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)list.winehq.org
Reporter: brandon(a)garagebay9.com
Distribution: ---
Program: Zbrush 2022.06 (this is not the latest release, but it is the last
release with a permanent license version, so it is in heavy use)
Issue: Pressure input on a pen tablet (ie Wacom, Huion, XPpen, Monoprice, etc)
does not work at all, in any of the three API compatibility modes Zbrush offers
(Wintab, Stylus, WM_event).
*This is a regression from Wine 10 stable*, where pen tablet pressure works
correctly (with some setup and some caveats)
Worth noting: there are longstanding issues (back 5+ years) with even properly
configured pressure input dropping out when opening a system menu dialogue
(load / save window, export file prompt, etc). I am filing a separate bug on
that, but it may be entangled with this.
OS: Debian 13 / Trixie
Kernel: 6.16.3+deb13-amd64
Tablet: Bus 001 Device 007: ID 056a:00b5 Wacom Co., Ltd PTZ-631W [Intuos3
(6x11)]
(Note this issue is also seen on my Huion Kamvas 16 Pro 2.5k)
Wine version: 10.x Staging. NOTE: CORRECT PRESSURE INPUT BEHAVIOR IS PRESENT IN
WINE 10 STABLE
--
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=58957
Bug ID: 58957
Summary: KindleForPC-installer-2.8.70980.exe
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)list.winehq.org
Reporter: sb(a)dod.no
Distribution: ---
Created attachment 79654
--> http://bugs.winehq.org/attachment.cgi?id=79654
Program Error Details from kindle installer crash
Installation of KindleForPC 2.8.70980 failed with a crash
back trace 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=41930
Bug ID: 41930
Summary: Civilization III Complete shows black terrain (Wine
compiled with OSMesa support)
Product: Wine
Version: 1.7.38
Hardware: x86
OS: Linux
Status: NEW
Keywords: regression
Severity: normal
Priority: P2
Component: gdi32
Assignee: wine-bugs(a)winehq.org
Reporter: gyebro69(a)gmail.com
CC: michael(a)fds-team.de
Regression SHA1: e618ab65ed5b623785c58ea5ece6e39895d43063
Distribution: ---
Created attachment 56311
--> https://bugs.winehq.org/attachment.cgi?id=56311
screenshot
This is one of the few games that I know of which makes some use of OpenGl in
bitmaps. When Wine was compiled with OSMesa support, tiles containing terrain
turn black as soon as I launch a game.
Reproduced with Nvidia binary drivers 375.20 and nouveau/mesa.
I tried Civilization III Complete (both the Steam and the GOG.com versions have
this bug).
Terminal output:
fixme:x11drv:X11DRV_desktop_SetCurrentMode Cannot change screen BPP from 32 to
16
err:ole:CoGetClassObject class {5959df60-2911-11d1-b049-0020af30269a} not
registered
err:ole:CoGetClassObject no class object {5959df60-2911-11d1-b049-0020af30269a}
could be created for context 0x1
Reverting the following patch on top of git fixes the problem:
commit e618ab65ed5b623785c58ea5ece6e39895d43063
Author: Michael Müller <michael(a)fds-team.de>
Date: Tue Feb 3 11:07:38 2015 +0100
gdi32: Fix arguments for OSMesaMakeCurrent when using 16 bit formats.
Please let me know if you need debug logs.
wine-1.9.24-105-g1d3b944
Fedora 24 x86_64
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce GT 730/PCIe/SSE2
OpenGL core profile version string: 4.5.0 NVIDIA 375.20
Installed packages:
mesa-libOSMesa.i686 13.1.0-0.12.git95ddb37.fc24
mesa-libOSMesa.x86_64 13.1.0-0.12.git95ddb37.fc24
mesa-libOSMesa-devel.i686 13.1.0-0.12.git95ddb37.fc24
mesa-libOSMesa-devel.x86_64 13.1.0-0.12.git95ddb37.fc24
--
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=58956
Bug ID: 58956
Summary: Drop-down menu remains open when a dialog is moved
Product: Wine
Version: 10.0
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)list.winehq.org
Reporter: rikul(a)inbox.ru
Distribution: ---
******************
SUMMARY
******************
When the Open dialog is moved while a drop-down menu is open, the drop-down
menu is not closed and remains in place,
though it should be closed when the dialog is moved
******************
STEPS TO REPRODUCE
******************
1. Open Notepad.
2. Keep a drop-down menu open, such as in File → Open under the “File
name”/"Files of type"/"Encoding" list.
3. Move the dialog while the drop-down menu is open.
The menu still in its old location while the dialog is at a new location.
******************
ACTUAL RESULTS
******************
The menu still in its old location while the dialog is a new location.
******************
EXPECTED RESULTS
******************
The menu should be closed before the dialog moves.
--
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=58953
Bug ID: 58953
Summary: Wine 10 steals all mouse input when playing any game
Product: Wine
Version: 10.18
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: xinput
Assignee: wine-bugs(a)list.winehq.org
Reporter: shockwaves08(a)hotmail.com
Distribution: ArchLinux
Issue: When launching any game with Wine 10 selected, the game steals all mouse
cursor focus completely, and does not relinquish control if the user switches
to a background app (i.e. Google Chrome and/or Discord). Makes any sort of
multitasking in completely impossible until the game in question is closed.
In certain games, like Grand Theft Auto V Enhanced, the inverse is true; while
mouse can be used in external apps, doing so completely shuts down ALL in-game
input, whether by gamepad or mouse and keyboard, requiring a force-close and
restart to restore normal functionality.
Expected Behavior, circa Wine 9 and earlier: Game relinquishes mouse cursor
control when switching between currently-running apps, allowing for normal
mouse control.
I already reported this same bug on Valve's Proton GitHub, but I figured I'd
tackle this severe issue at the source too.
--
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=58847
Bug ID: 58847
Summary: Screen lock during DirectX application operation
Product: Wine
Version: 10.17
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: d3d
Assignee: wine-bugs(a)winehq.org
Reporter: axis6404(a)proton.me
Distribution: ---
On Windows, power-saving features like screen locking do not activate while
DirectX-based applications such as games are running. However, when playing
games using controllers (other than a mouse) via Wine, the screen turns off and
locks.
--
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=58012
Bug ID: 58012
Summary: DOOM + DOOM II: rsaenh regression
Product: Wine
Version: 10.3
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: rsaenh
Assignee: wine-bugs(a)winehq.org
Reporter: joelh(a)disroot.org
Distribution: ---
Created attachment 78271
--> https://bugs.winehq.org/attachment.cgi?id=78271
backtrace of doom_gog.exe
DOOM + DOOM II by Nightdive Studios released in 2024. I am using the GOG.com
version.
The game will get past the opening screens, then crash on the main menu. It
worked okay in Wine 10.2.
I have tracked down the problematic commit to:
fd539487b7860ff0a53474aa6fbcbe229f3f42c1 rsaenh: Use the bundled tomcrypt
to replace the local copy.
--
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=57960
Bug ID: 57960
Summary: ChessBase 18 hangs / stops accepting input a few
seconds after launch
Product: Wine
Version: 10.3
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: winehq(a)brobston.com
Regression SHA1: fd539487b7860ff0a53474aa6fbcbe229f3f42c1
Distribution: Ubuntu
Created attachment 78212
--> https://bugs.winehq.org/attachment.cgi?id=78212
Log from first bad commit with most warnings enabled
I'm running with "Emulate a virtual desktop" active. I can start ChessBase 18
from the command line with `WINEDEBUG="-warn+all,warn-dpa" wine start
"C:\\Program Files\\ChessBase\\CBase18\\CBase18.exe"` in a 64-bit prefix. The
application launches as usual, but after a few seconds, it stops responding to
the mouse altogether. The CBase18.exe process consumes around 200% CPU as
shown in `top` when this situation occurs. The log output does show new log
entries when I focus or unfocus the virtual-desktop window, but otherwise, it
does not typically appear to be logging anything. I then stop the process from
the command line with, for instance, `killall CBase18.exe`.
I will attach a log from the first bad commit and, shortly thereafter, the last
good commit.
--
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=54626
Bug ID: 54626
Summary: Saving files in Microsoft Word/Excel 2010 creates
useless shortcut files
Product: Wine
Version: 8.0
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: shell32
Assignee: wine-bugs(a)winehq.org
Reporter: kle(a)bluewin.ch
Distribution: ---
Here follows a new bug report regarding the problem observed in old bug report
15480.
It was told me that I should open a new bug report. ;-)
Okay, the issue regarding the creation of useless shortcut files is back in
Wine 8.0 (stable).
When I open a *.xlsx file at the desktop and save it (with the same name) to an
*.ods file then Excel 2010 will create two files. One is a *.lnk (which points
to the original xlsx) and the other is a shortcut regarding the ods file but
also with *.ods ending.
As mentioned, both of them are non-functional.
--
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.