https://bugs.winehq.org/show_bug.cgi?id=57900
Bug ID: 57900
Summary: ML Sound Labs Amped Flagship: Audio not working within
Amp simulator programs since the 10.0 update
Product: Wine
Version: 10.0
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: wjm146(a)gmail.com
Distribution: ---
Created attachment 78141
--> https://bugs.winehq.org/attachment.cgi?id=78141
settings menu for the applications detailing pulseaudio
I use WINE previously to use software guitar amps sims. Specifically Amped
plugins from ML Sound Lab worked the best in my environment. Ever since the
10.0 update I have had issues. All of the Apps seemingly work fine other than
it does not process audio using Pulseaudio. It recognizes my Focusrite
interfaces as both an input and output as seen here.
The only way that it outputs sound is the 'test' output button. Even before if
I was having with outputs It would at least give static, but my output is dead
silent. Out of curiosity I tried other guitar amp sim programs with similar
problems. I assumed it was a bug that would have been fixed in 10.0-1 and -2,
but the problem remains. This bug is present on multiple systems (arch and
opensuse). This is seemingly not exclusive to the amp sims made by ML Sound Lab
as I downloaded an unrelated amp sim to 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=57834
Bug ID: 57834
Summary: Regression: Cyberpunk 2077 doesn't load with
CyberEngine Tweaks
Product: Wine
Version: 10.1
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: shtetldik(a)gmail.com
Distribution: ---
Between Wine 10.0 and 10.1 some regression occurred that causes Cyberpunk 2077
with cyber engine tweaks plugin not to load (without CET it works fine in 10.1
too).
CET is loaded in general by overriding version.dll as native, builtin.
The only suspicious error in the log that I see is this:
0184:fixme:graphics:ShutdownBlockReasonCreate (0000000000030056,
L"Generating error report"): stub
I'm running the game with usual things like
* esync from staging
* dxvk / vkd3d-proton
--
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=40495
Bug ID: 40495
Summary: Impossible to function at 64 bit on FreeBSD
Product: Wine
Version: 1.7.46
Hardware: x86-64
OS: FreeBSD
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: alexandrosperdikomatis(a)gmail.com
Created attachment 54269
--> https://bugs.winehq.org/attachment.cgi?id=54269
the regular backtrace report
I've compiled wine64 several times in many ways at FreeBSD.
32 bit version always works fine.
This is the port emulators/wine-devel from RELEASE ports collection at FreeBSD
10.2
Application tried was Wow-64.exe
I am really disappointed with wine64 at FreeBSD. On Linux it flies.
--
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=57788
Bug ID: 57788
Summary: "You have been unsubscribed from the wine-bugs mailing
list"
Product: WineHQ Bugzilla
Version: 3.2.3
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: bugzilla-unknown
Assignee: wine-bugs(a)winehq.org
Reporter: austinenglish(a)gmail.com
CC: austinenglish(a)gmail.com, jnewman(a)codeweavers.com
Distribution: ---
Twice now, I've gotten an email that I've been unsubscribed from the wine-bugs
mailing list (I've been subscribed for years without issue).
The first time was January 22, and again just now.
@Newman, is this related to recent site upgrades?
--
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=57430
Bug ID: 57430
Summary: Guild Wars 2: erratic camera movements while holding
mouse buttons on Wine Wayland
Product: Wine
Version: 9.21
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: winewayland
Assignee: wine-bugs(a)winehq.org
Reporter: mweires(a)googlemail.com
Distribution: ---
using GNOME 47.1 (Wayland) and Wine 9.21 (Wine Wayland) the camera will do a
hefty jerk to the top anytime you hold the left or right mouse button and move
the mouse slightly. everything else seems to work as expected ingame.
tested on a clean wine prefix with only DISPLAY="" set + latest Guild Wars 2
(64-bit) client.
--
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=3930
--- Comment #88 from zebra2745(a)vibzi.net ---
> That doesn't work, because GetCurrentThread() only returns a pseudo handle,
> "a special constant that is interpreted as the current thread handle"
> (MSDN). I think we have to compare the globally unique thread IDs to be sure:
https://www.codeproject.com/Tips/5350589/The-Current-Thread-Handle says:
> What to do when you want to use the current thread handle
> This tip shows a side effect of GetCurrentThread and explains what to do when you need to avoid that.
> Introduction
> When you need to get a handle to the current thread, you can use
> GetCurrentThread which gives you a pseudo handle which you don't need to close
> because it is not a real reference counted handle. This is mentioned clearly in
> the documentation. However, I recently bumped my head against this. I wanted to
> share it so that others can avoid having to chase this down.
> My Headbump
> Consider the following example:
> ------------------------------ snip ------------------------------
DWORD worker(void* ctx)
{
std::cout << "Thread id: " << GetThreadId((HANDLE)ctx) << std::endl;
return 0;
}
int main()
{
HANDLE hMainThread = GetCurrentThread();
std::cout << "Thread id: " << GetThreadId(hMainThread) << std::endl;
HANDLE hThread = CreateThread(NULL, 0, worker, hMainThread, 0, NULL);
WaitForSingleObject(hThread, INFINITE);
}
> ------------------------------ snip ------------------------------
> This is what happens:
> Thread id: 44068
> Thread id: 36376
> Without thinking, I had assumed that the pseudo handle was just a weak copy of
> the actual handle (a non reference counted copy of the current handle), and I
> could reference it in a worker thread. Instead, it is a special constant that
> literally means 'when this handle value is supplied, use the current thread'.
> And if you pass that special value to another thread, then that value will
> translate to the thread handle of 'that' thread.
> If you read the documentation, then this is exactly what it says. Only I
> didn't stop to think about what that actually meant.
> Getting the Real Thread Handle
> If you want to get a real handle that you can pass to another thread, do this:
> ------------------------------ snip ------------------------------
HANDLE hMainThread = NULL;
if (!DuplicateHandle(
GetCurrentProcess(),
GetCurrentThread(),
GetCurrentProcess(),
&hMainThread,
0,
FALSE,
DUPLICATE_SAME_ACCESS)) {
cout << "Error " << GetLastError() << " cannot duplicate main handle." <<
endl;
return GetLastError();
}
> ------------------------------ snip ------------------------------
> Of course, when you do this, you get a HANDLE value that you do need to close
> when you no longer need 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=3930
--- Comment #87 from Damjan Jovanovic <damjan.jov(a)gmail.com> ---
(In reply to Dmitry Timoshkov from comment #86)
> Created attachment 78138 [details]
> patch
>
> Something like this may work.
That doesn't work, because GetCurrentThread() only returns a pseudo handle, "a
special constant that is interpreted as the current thread handle" (MSDN). I
think we have to compare the globally unique thread IDs to be sure:
---snip---
if (GetCurrentThreadId() == GetThreadId(thread) && (GetVersion() &
0x80000000))
return 0;
---snip---
That fixes all the tests, but doesn't fully fix the game: it no longer
deadlocks and even plays music (it was silently frozen before), but shows badly
corrupted video (bottom ~2/3 of the screen are black, and the top 1/3 has
randomly colored pixels), which makes it completely unplayable. Running it with
"wine HEROES.EXE /s0" (which disables all sound) gets the graphics fully
functional. This however, seems to be a separate issue, probably a regression
as this WINMM fix was enough in earlier Wine versions, but now isn't.
--
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=3930
--- Comment #86 from Dmitry Timoshkov <dmitry(a)baikal.ru> ---
Created attachment 78138
--> https://bugs.winehq.org/attachment.cgi?id=78138
patch
Something like this may work.
--
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=3930
--- Comment #85 from Dmitry Timoshkov <dmitry(a)baikal.ru> ---
(In reply to Damjan Jovanovic from comment #84)
> (In reply to Dmitry Timoshkov from comment #83)
> > Could SuspendThread() fail in win9x mode when called for the same thread?
>
> Yes, SuspendThread(GetCurrentThread()):
> - deadlocks on all Windows versions, even 95, when running as is.
> - returns 0 instead, when newer Windows versions emulate Windows 95 or 98/ME.
It would be helpful to know what last error is set to for the failing case.
> What should Wine do?
Add a check to SuspendThread() and fail in the win9x mode?
--
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=42308
Bug ID: 42308
Summary: LTspice XVII: some checkboxes not shown or being
overlapped by labels
Product: Wine
Version: 2.0
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: Rakusan2(a)gmail.com
Distribution: ---
Created attachment 57042
--> https://bugs.winehq.org/attachment.cgi?id=57042
Missing checkboxes and their labels bellow the textboxes
In LTspice XVII when opening "Edit Simulation cmd" the checkboxes and their
labels are not shown. After switching tabs the labels appear but some slightly
overlap their checkbox
This problem does not occur in native windows
--
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.