https://bugs.winehq.org/show_bug.cgi?id=51481
Bug ID: 51481
Summary: Why is the Epson printer printing blank pages?
Product: WineHQ.org
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: www-unknown
Assignee: wine-bugs(a)winehq.org
Reporter: baroncorrz(a)gmail.com
Distribution: ---
Epson printer printing blank pages because there must be some problem related
to the cartridge ink or the nozzle. The cartridge ink must have been depleted.
You need to check the level of ink by comparing the ink level with the marker
on the ink tank. If the ink level is low, then it means that you need to put in
a new cartridge. If you have an ink tank with a low ink level, then fill the
ink tank with the ink. The problem can also be due to the clogging of the
nozzle. You need to clean the nozzle if this happens. One of the best ways to
prevent this is by giving fewer jobs to the printer.
https://www.epsonprintersupportpro.us/blog/printer-printing-blank-pages/
--
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=21158
Summary: Hitman: Contracts ignores mouse press events
Product: Wine
Version: 1.1.35
Platform: x86
URL: http://www.gamershell.com/download_5663.shtml
OS/Version: Linux
Status: NEW
Keywords: download, regression
Severity: minor
Priority: P2
Component: directx-dinput
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: arethusa26(a)gmail.com
CC: vitaliy(a)kievinfo.com
With wine-1.1.35-180-g20a50f3, after launching Hitman: Contracts, mouse press
events at the main menu are ignored by the game. Since a user reported that the
game worked normally in wine-1.1.9, a regression test was performed, which
indicated:
3743a1a7ca170c765cd779c61b9e362c5b1c5203 is first bad commit
commit 3743a1a7ca170c765cd779c61b9e362c5b1c5203
Author: Vitaliy Margolen <wine-patches(a)kievinfo.com>
Date: Sun Feb 1 13:11:46 2009 -0700
dinput: Consume mouse & keyboard events in exclusive mode.
:040000 040000 6ae6b43b3c100af38ed4f27384470dc4d2595bc1
700b35b9bc8fd27239ee8faaed8ca1c10cfc31d4 M dlls
Wine built prior to the indicated commit allows mouse input to work normally.
Interestingly, doing graphical mode changes (via keyboard input) makes mouse
input work again. The AppDB also suggests adding the strings:
UseDirectInputMouse
UseDirectInputKeyboard
to the HitmanContracts.ini configuration file to have mouse input work. The
only visible output under wine-1.1.35-180-g20a50f3 is:
fixme:dinput:SysMouseAImpl_Acquire Clipping cursor to (0,0)-(1280,1024)
fixme:win:EnumDisplayDevicesW ((null),0,0x32eb58,0x00000000), stub!
fixme:dsalsa:IDsDriverBufferImpl_SetVolumePan (0x253b060,0x253afa8): stub
fixme:dsound:DllCanUnloadNow (void): stub
fixme:dsalsa:IDsDriverBufferImpl_SetVolumePan (0x253b060,0x253afa8): stub
(Z:\code\hitman2\gui\MainMenu.cpp:554)Hitman Contracts build 171 (Apr 26 2004
14:42:27)
fixme:dsound:DllCanUnloadNow (void): 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.
https://bugs.winehq.org/show_bug.cgi?id=50129
Bug ID: 50129
Summary: Calibre-portable error initializing the bypy frozen
importer
Product: Wine
Version: 5.0.3
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: bilbiliblus(a)gmail.com
Distribution: ---
When I try to run Calibre-portable.exe y have this message:
There was an error initializing the bypy frozen importer:
<class 'MemoryError'>:
Traceback (most recent call last):
File bypy-importer.py, line 250, in <module>
File bypy-importer.py, line 195, in __init__
It only happens since Calibre changed to version 5 and on.
This very morning I've tried with Calibre 5.3
Thank you
--
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=52461
Bug ID: 52461
Summary: The Legend of Heroes: Trails of Cold Steel III usually
hangs on exit
Product: Wine
Version: 7.0
Hardware: x86-64
OS: Linux
Status: NEW
Keywords: patch
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: z.figura12(a)gmail.com
Distribution: ---
Created attachment 71749
--> https://bugs.winehq.org/attachment.cgi?id=71749
patch mitigating the race
To reproduce it's sufficient to install the game from Steam, get into the main
menu, and select the "exit" option (page down with the S key then press Enter).
Closing the window also works. The hang doesn't happen every time but does
happen most times I tested.
This is an application bug. There are two threads—a main thread and a worker
thread. The main thread closes the handle to a mutex, goes off and does some
other things, and then tries to wait on the mutex handle again (with a timeout
of INFINITE). The worker thread basically does a timed wait, in a loop, on a
set of handles, except that instead of passing a timeout to
WaitForMultipleObjects(), it repeatedly creates a non-periodic auto-reset timer
object, sets it for 1 ms, and adds it to the wait array, and then closes the
handle.
Because of the way handles are allocated in Wine (i.e. "lowest slot first"),
and because of the specific pattern of handle usage of the program, what
usually happens is that when the mutex handle is closed, the value is reused
for a timer handle in the worker thread. While the worker thread is sleeping on
the timer, the main thread also waits on it, and when the timer fires, it only
wakes up the worker thread (which is almost always first in the queue). Closing
the handle of a waitable object in Windows doesn't interrupt other waits in
progress, and because the timer is non-periodic and auto-reset, the main thread
ends up waiting forever.
It turns out that Windows doesn't allocate handles like this. Rather, it seems
to use a free list, much like we use in other places in Wine: testing shows
that handles are always allocated in the reverse order that they are freed,
including across multiple threads, and regardless of how many handles were just
allocated.
Changing Wine to use a free list like this actually does mitigate the problem.
Because the worker thread closes its timer handle and then immediately creates
a new one, it will almost always get back the same handle value. The main
thread will most likely close its mutex handle while the worker thread is still
sleeping, with the effect that the mutex handle won't be reallocated and the
subsequent wait will return STATUS_INVALID_HANDLE.
In theory the potential for the race is still there, however; it's still
possible for the mutex handle to be closed after the timer handle is closed but
before a new timer is created, in which case the mutex handle value will be
reused for the timer value as it is currently. In practice I'm not sure if this
happens more than a negligible fraction of the time. I certainly couldn't
reproduce it after 6 or so tries, although that's not very many. Note that
there are also reports of it hanging on Windows [1]...
[1] https://steamcommunity.com/app/991270/discussions/0/2145343189632898904/
--
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=51313
Bug ID: 51313
Summary: gdi32:driver sometimes fails with a
STATUS_GRAPHICS_PRESENT_OCCLUDED error
Product: Wine
Version: 6.10
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: gdi32
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
gdi32:driver sometimes gets one or two failures like these:
https://test.winehq.org/data/patterns.html#gdi32:driver
driver.c:649: Test failed: Got unexpected return code 0xc01e0006.
driver.c:689: Test failed: Got unexpected return code 0xc01e0006.
0xc01e0006 is STATUS_GRAPHICS_PRESENT_OCCLUDED. This has happened before but
the reason for this error was not identified:
https://www.winehq.org/pipermail/wine-devel/2019-July/148494.html
I initially suspected a leftover window from a previous test, specifically an
Internet Explorer first-run dialog. However the screenshots in the TestBot jobs
show that this happens even when there is no such dialog (or at least the
dialog is gone by the time the tests complete).
The failures always happen on the same two lines despite the occlusion status
being checked in other places. Also both failures happen right after minimizing
the windows. So it seems likely there is a race condition, either in the test
or in the underlying API (if so it spans Windows 10 1607 to 2009).
--
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=51040
Bug ID: 51040
Summary: msi:package fails on Windows 10 if privileges not high
enough
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: msi
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
The following failures only happen if the test is run on a recent enough
Windows (i.e. Windows 10) in a user account with too few privileges.
package.c:5079: Test failed: Expected "keydata", got ""
package.c:5084: Test failed: Expected "field2", got ""
package.c:5089: Test failed: Expected "keydata,field2", got ""
package.c:5096: Test failed: Expected
"C:\Users\winetest\AppData\Local\Temp\FileName1", got ""
package.c:5107: Test failed: Expected "C:\Users\winetest\AppData\Local\Temp\",
got ""
package.c:5113: Test failed: Expected "C:\Users\winetest\AppData\Local\Temp\",
got ""
package.c:5123: Test failed: Expected "C:\Users\winetest\AppData\Local\", got
""
package.c:5136: Test failed: Expected
"C:\Users\winetest\AppData\Local\Temp\FileName2.dll", got ""
package.c:5147: Test failed: Expected
"C:\Users\winetest\AppData\Local\Temp\FileName4.dll", got ""
package.c:5651: Test failed: Expected , got winetest
In particular one can notice this bug on the TestBot's w1064_adm VM.
Note however that these tests seem to be run and succeed on wvistaadm and
w7u_adm.
See:
https://test.winehq.org/data/tests/msi:package.html
--
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=47508
Bug ID: 47508
Summary: FL Studio: Pressing backspace while editing the name
of something closes edit name window prematurely
Product: Wine
Version: 4.9
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: ajduck(a)outlook.com
Distribution: ---
Created attachment 64895
--> https://bugs.winehq.org/attachment.cgi?id=64895
A channel highlighted in the channel rack
Since Wine 4.9, pressing backspace to remove text while editing the name of
something closes the window and sets the name as whatever was in the box
usually with one character removed. Before 4.9 pressing backspace only removed
a character without closing the window which is correct behaviour.
Steps to reproduce:
1. Open FL Studio.
2. Press F6 to open the channel rack. If nothing appears or a window
disappeared, press F6 again.
3. There are probably already a few "channels" in the project file (possibly
the demo project opened up). See the image attached. You need to hold shift and
click on the highlighted bit, which is a channel. (Alternatively right click
and select "Rename, color and icon..."). You can pick any channel for this.
4. The edit name window will appear. Type anything, then press backspace to try
and remove a character.
What is expected:
It should remove a character without closing the window, as text editing
usually goes.
What actually happens:
It closes the edit name window.
Sometimes pressing backspace again after the edit name window has closed
(especially when doing this on the mixer) goes on to close the playlist (the
window with a big grid) which is not normal behaviour (doesn't happen before
4.9 either). Pressing backspace usually only changes the snap settings (the
little drop down menu at the top panel of the main FL Studio window which has a
magnet by 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.
https://bugs.winehq.org/show_bug.cgi?id=52354
Bug ID: 52354
Summary: winemac.drv not functional on non metal GPUs
Product: Wine
Version: 6.17
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: winemac.drv
Assignee: wine-bugs(a)winehq.org
Reporter: gcenx83(a)gmail.com
Distribution: ---
Since wine-6.17 winemac.drv no longer functions on non Metal GPUs this breaks
legacy versions of mac OS X below 10.11 and systems that contain GPUs that
don't support Metal.
--
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=51784
Bug ID: 51784
Summary: The dinput8:hid output is too big in Wine
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: directx-dinput
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
dinput8:hid outputs ~26kB of data. This is too much and contributes in pushing
the WineTest reports above the 1.5MB limit.
The traces break down as follows:
0kB failures
25kB todos
0kB traces
0kB test framework (summary lines, etc.)
Time to fix Wine to reduce the number of todos!
--
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=49443
Bug ID: 49443
Summary: Anno 1800: Super slow & bad performance
Product: Wine
Version: 5.11
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: holzminister(a)t-online.de
Distribution: ---
Created attachment 67544
--> https://bugs.winehq.org/attachment.cgi?id=67544
terminal out WineD3D
Hi,
I tried to run Anno 1800 but unfortunately it runs pretty terrible slow on my
end.
The game itself seems to work fine. But when loading into a game it takes me
about 30 minutes on my machine (The loading screen seems unresponsive for most
of the time, animation plays like once every 5 minutes or so). When loaded into
a game I get like <10 FPS (DXVK & WineD3D) and you can visible see the assets
and texures being loaded when scrolling through the map (DXVK, with WineD3D it
is the same, but there are a lot of graphical glitches in addition).
The terminal output attached is with WineD3D. If you require more information
please let me know and I will try to provide it.
my pc
Archlinux
Ryzen 2700x
32gb ram
AMD Vega 56 (Mesa 20.1.1)
game and os on ssd
Kind Regards.
--
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.