https://bugs.winehq.org/show_bug.cgi?id=56315
Bug ID: 56315
Summary: Package wine-mono for Debian
Product: Packaging
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: wine-packages
Assignee: wine-bugs(a)winehq.org
Reporter: shtetldik(a)gmail.com
CC: dimesio(a)earthlink.net
Distribution: ---
It would be nice to have Wine-mono packaged for Debian and be available in Wine
repos in order to avoid manually installing it in /opt/... every time there is
a version bump that Wine expects.
Those who don't want to use the packaged version for whatever reason (i.e.
preferring per prefix installation for example) could simply not install the
package. But everyone else could benefit from more automation.
--
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=56314
Bug ID: 56314
Summary: MPEG-1 video playback does not properly resize screen
Product: Wine
Version: 9.1
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: cthielen(a)gmail.com
Distribution: ---
Created attachment 76042
--> https://bugs.winehq.org/attachment.cgi?id=76042
Screenshot showing the video in the corner. It should be fullscreen.
Ultima IX has MPEG-1 based video playback that is now working thanks to
https://bugs.winehq.org/show_bug.cgi?id=9127 being fixed. Thanks for everyone
who helped out there!
However, now the video playback only appears in the upper-left corner of the
screen. It isn't clipped, but it looks like the system is failing to change
screen resolution. These videos playback fullscreen on Windows. See attached
for a visual.
--
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=56210
Bug ID: 56210
Summary: Very slow event processing (seconds)
Product: Wine
Version: 9.0
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: nagle(a)animats.com
Distribution: ---
The Windows event queue, as emulated under Wine, appears to work differently
than the real one under Windows 10.
If you build my Rust test program, ui-mock, arc branch:
[code]
git clone https://github.com/John-Nagle/ui-mock.git
cd ui-mock
git checkout arc
cargo build --release --target x86_64-pc-windows-gnu --examples
cd target/x86_64-pc-windows-gnu/release/examples
wine ui-mock.exe
[/code]
it will run fine under real Windows 10. But, built on Ubuntu 22.04 LTS with
current Rust, it behaves strangely.
Click on one of the big bars that says "placeholder", and you get get a login
popup. It doesn't do anything; this is just a GUI dummy.
Type something into the user name box.
On real Windows, characters are echoed at full speed.
[b]Under Wine 8 or 9, character echo is delayed about 3-4 seconds.[/b]
What seems to be happening is that the endless refreshing of the screen (this
is a game-type program) is starving out event processing.
This uses the Rust crates Rend3, Winit, egui, and wgpu, all of which work
cross-platform.
A newer version of Rend3 (see the Cargo.toml file for the rev number) has a
different approach to the event loop. There are two callback functions -
"event", and "redraw" in Rend3's framework. The framework itself does a
request-redraw at the end of each redraw. This seems to starve out non-redraw
event processing.
An earlier version of Rend3 did not have this problem. That older version can
be built as above, by removing the line
git checkout arc
This uses a different version of the Rend3 framework, one which only redraws
when the event queue is empty.
"winit", a standard Rust crate, claims in its documentation that non-redraw
events are always processed before redraws. But "winit", which has
platform-dependent code for Windows, seems to assume, in the Windows platform
code, that the underlying platform event queue does that. For real Windows, it
does seem to do that. But Wine's event queue does not seem to work that way.
If someone reports this problem in a commercial game, it's probably going to be
reported as "keys are sluggish". Here, you have sources for everything and can
reproduce the problem.
--
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=56313
Bug ID: 56313
Summary: InstallShield is crashed when complete the setup
Product: Wine-staging
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: matnazarovsobirjon123(a)gmail.com
CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com
Distribution: ---
Created attachment 76041
--> https://bugs.winehq.org/attachment.cgi?id=76041
Wine dialog ask me to save this logs
Hello Wine Team!
I received an exception from Wine when I installed the NetSupport Manager
program, its installer is InstallShield as I understand 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=56312
Bug ID: 56312
Summary: Vulkan is broken for me after certain commits
Product: Wine
Version: 9.1
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: major
Priority: P2
Component: winevulkan
Assignee: wine-bugs(a)winehq.org
Reporter: airidaslideikis(a)gmail.com
Distribution: ---
Created attachment 76035
--> https://bugs.winehq.org/attachment.cgi?id=76035
Contains Vulkan assert error.
So after February 6 commits, I can't get Vulkan to work anymore. I'm suspecting
it has to do with Vulkan headers update, because right before Vulkan headers
were updated - Vulkan was working fine.
My system - Samsung Galaxy S23U with Snapdragon 8 Gen 2, Termux-glibc prefix,
latest dev build of box64, Mesa 24.1.0 latest dev build, latest dev build of
Wine 9.1. Right before it got updated to Wine 9.2.
Same error occurs when using DXVK. I enabled Vulkan renderer on WineD3D just to
make a problem more in line with Wine and exclude any external factors.
Funnily enough, if I switch WineD3D to use OpenGL, it works fine. Utilizes zink
without an issue.
Oh and by the way, same exact issue happens on vanilla and with staging
patches. This means staging patches aren't at fault here. Couldn't bother
reinstalling vanilla Wine for the same exact issue.
Added a log which confirms Vulkan failure.
I'll try reverting vulkan header update, because this is pretty much the only
suspicious thing that's keeping Vulkan from working to my eyes.
Or, it could also be Mesa bug. I'm completely lost here.
--
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=56311
Bug ID: 56311
Summary: HwINFO does not display temperatures
Product: Wine
Version: 9.0
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: celestial.ameba(a)gmail.com
Distribution: ---
I would expect to see 2-4 temperature sensors listed for the CPU and
Motherboard listed in the Sensor Status window. Instead there are no entries at
all. The exact names of the sensor will vary based on the computer's specific
hardware.
It can be accessed by clicking the following buttons:
Start>Sensors>CPU[#0][CPU NAME]
The values I am expecting can be found using `lm-sesnors` and `watch sensor`
The values are also available via `cat /sys/class/thermal/thermal_zone*/temp`
FYI: As of Wine 9.0 you need to downgrade from windows 10 to windows 7 in
winecfg in order to get past the landing window.
`
--
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=14010
Summary: RivaTuner 2.09 not work ,no overclocking or sensor
ability
Product: Wine
Version: 1.0.0
Platform: All
OS/Version: Linux
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: dj--alex(a)ya.ru
RivaTuner 2.09 not work ,no overclocking or sensor ability
My videocard is very loud without this program!!
I and not only i, want to overclocking without BIOS VRAM rewrite.
Program can be downloaded free from
http://www.radeon.ru/
(Main menu left - newest version)
--
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=56259
Bug ID: 56259
Summary: Microsoft Webview 2 installer hangs forever
Product: Wine
Version: 9.1
Hardware: x86-64
URL: https://developer.microsoft.com/en-us/microsoft-edge/w
ebview2/?form=MA13LH
OS: Linux
Status: NEW
Keywords: download
Severity: normal
Priority: P2
Component: ntdll
Assignee: wine-bugs(a)winehq.org
Reporter: xerox.xerox2000x(a)gmail.com
Distribution: Debian
Created attachment 75970
--> https://bugs.winehq.org/attachment.cgi?id=75970
stub that lets installer finish
A user reported troubles with this at the forum. Apparently (didn't verify
this) the installer works in win 7 because it downloads an older version of
webview2. When version is set to win10 another version seems to be downloaded.
See https://forum.winehq.org/viewtopic.php?t=38443
A +relay showed following trace, the kernelbase.SleepConditionVariableCS
sequence keeps going on and on forever.
Adding a stub for the function that the program tries to find
(RtlGetDeviceFamilyInfoEnum) just before the "loop" of
SleepConditionVariableCS, makes the installer succeed for me (it exits without
a success message, but the files seem to be installed).
I'll try to add a test and submit the patch later
+relay log:
0204:Call KERNEL32.GetProcAddress(6fffffc50000,14038602f
"RtlGetDeviceFamilyInfoEnum") ret=1401736ba
0204:Ret KERNEL32.GetProcAddress() retval=00000000 ret=1401736ba
0204:Call kernelbase.SleepConditionVariableCS(1403deb48,1403deb58,00000064)
ret=14020442a
0204:Call ntdll.RtlSleepConditionVariableCS(1403deb48,1403deb58,7ffffe1ff2f8)
ret=6fffff4cbd7d
0204:Ret ntdll.RtlSleepConditionVariableCS() retval=00000102 ret=6fffff4cbd7d
0204:Call ntdll.RtlNtStatusToDosError(00000102) ret=6fffff4cbd98
0204:Ret ntdll.RtlNtStatusToDosError() retval=000005b4 ret=6fffff4cbd98
0204:Ret kernelbase.SleepConditionVariableCS() retval=00000000 ret=14020442a
0204:Call kernelbase.SleepConditionVariableCS(1403deb48,1403deb58,00000064)
ret=14020442a
0204:Call ntdll.RtlSleepConditionVariableCS(1403deb48,1403deb58,7ffffe1ff2f8)
ret=6fffff4cbd7d
0204:Ret ntdll.RtlSleepConditionVariableCS() retval=00000102 ret=6fffff4cbd7d
--
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=56250
Bug ID: 56250
Summary: Elite Dangerous client gets stuck on black screen
after launch
Product: Wine
Version: 9.0
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: d3d
Assignee: wine-bugs(a)winehq.org
Reporter: brendan(a)redmandi.com
Distribution: ---
When using WINE_D3D_CONFIG='renderer=vulkan' to launch Elite, the game will
launch but then get stuck on a black screen.
The problem appears to be related to the following entry in the log:
fixme:d3d11:d3d11_device_CheckFeatureSupport Unhandled feature 0xe.
--
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=51360
Bug ID: 51360
Summary: vkGetDeviceProcAddr invalid behavior for functions
from extensions unsupported by host Vulkan instance
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: winevulkan
Assignee: wine-bugs(a)winehq.org
Reporter: loothelion(a)nvidia.com
Distribution: ---
I believe the below may also be true for vkGetInstanceProcAddr, but I haven't
confirmed this locally.
The Vulkan 1.2.182 specification states the following about the behavior of
vkGetDeviceProcAddr:
> The table below defines the various use cases for vkGetDeviceProcAddr and
> expected return value for each case.
>
> The returned function pointer is of type PFN_vkVoidFunction, and must be cast to
> the type of the command being queried before use. The function pointer must only
> be called with a dispatchable object (the first parameter) that is device or a
> child of device.
>
> Table 2. vkGetDeviceProcAddr behavior
>
> device | pName | return value
> ---------------------------------------------------------------------------------------
> NULL | *[1] | undefined
> ---------------------------------------------------------------------------------------
> invalid device | *[1] | undefined
> ---------------------------------------------------------------------------------------
> device | NULL | undefined
> ---------------------------------------------------------------------------------------
> device | core device-level Vulkan command [2] | fp[3]
> ---------------------------------------------------------------------------------------
> device | enabled extension device-level commands [2] | fp[3]
> ---------------------------------------------------------------------------------------
> any other case, not covered above | NULL
>
> [1] - "*" means any representable value for the parameter (including valid
> values, invalid values, and NULL).
>
> [2] - In this function, device-level excludes all physical-device-level
> commands.
>
> [3] - The returned function pointer must only be called with a dispatchable
> object (the first parameter) that is device or a child of device e.g.
> VkDevice, VkQueue, or VkCommandBuffer.
Winevulkan's behavior differs from this slightly. Note the fifth row of the
table uses the language "enabled extension device-level commands", this means
that if a command is queried via vkGetDeviceProcAddr and isn't part of core,
the extension which introduces it must be enabled for the given VkDevice object
in order for vkGetDeviceProcAddr to return a valid function pointer, and
otherwise it should return NULL.
In order to properly conform to the Vulkan specification Winevulkan should only
expose device-level commands whose extensions have been enabled.
Note that applications should not be querying for Vulkan commands via
vkGetDeviceProcAddr if they know the extension is not supported by the
underlying implementation. However in the case of an application which does
rely on this bad behavior, Winevulkan will return a function pointer to one of
its thunks and then proceed to deference a null function pointer when it tries
to call into the underlying host Vulkan implementation.
--
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.