June 2025 - Wine-Bugs - list.winehq.org

[Bug 58317] On one Fedora 42 machine after update it fails. Works on Fedora 41, and another Fedora 42 worked?

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=58317 --- Comment #2 from Michael Setzer II <mikes(a)kuentos.guam.net> --- Created attachment 78675 --> http://bugs.winehq.org/attachment.cgi?id=78675 log file of wine notepad with 10.9 on Fedora 42 One acer notebook fails with error, but oher Fedora 42 machines installed and worked without the error. -- 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.

June 3, 2025

[Bug 58317] On one Fedora 42 machine after update it fails. Works on Fedora 41, and another Fedora 42 worked?

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=58317 --- Comment #1 from Michael Setzer II <mikes(a)kuentos.guam.net> --- Update. Did update on Dell Machine 1st running Fedora 41, and it had no issue. Did Update on a Acer notebook, and it get the error with wine 10.9, but works fine if downgraded to 10.8? Saw something that mentioned error might be a memory issue. Ran memtest 7.20 and took over 20 minutes to run full cycle no errors. Did try update on 5 other Fedora 42 machines, and they had no problems. Note: no delay. enter wine notepad and errors come up immediately No delay. dnf downgrade winehq-devel goes back to 10.8, and everything works. Will add attachment logout.bz2 of wine notepad run. -- 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.

June 3, 2025

[Bug 56285] Scaling on screen is wrong with Wine Wayland driver while resolution detected is correct.

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=56285 --- Comment #5 from garrett m <garrettm4(a)protonmail.com> --- Thinking about this some more, maybe a new environment variable (WINE_PHYSICAL_PIXEL_SPACE=1) could avoid a lot of logic by ignoring the DE's display scale / Wine's DPI setting, but maybe keep the DPI setting for the cursor, and report physical pixels to the app instead of logical pixels. This would fix older, non-DPI aware games with native resolutions equal to the display resolution. For non-DPI aware games with native resolutions less than the display resolution, everything seems to already work, but it would be nice to have an environment variable to pillar-box fullscreen output and pick the filter for older games / apps. This could also be used for manual scaling of select non-fullscreen apps like old windowed games and XP era (or older) apps too (e.g., WinXP FreeCell). Say WINE_APP_WINDOW_UPSCALE=[<n>,<nearest|linear>] WINE_APP_FULLSCREEN_UPSCALE=[<none|fill|aspect|integer>,<nearest|linear>] where, MANUAL WINDOW SCALING n - manual scaling factor to apply to windowed app/game (integer value, but maybe fp for fraction scaling) AUTO FULLSCREEN SCALING BEHAVIOR none - do not scale fullscreen app, center output on screen fill - scale requested window size to fill screen, ignoring aspect ratio aspect - scale requested window size to fill screen, preserving aspect ratio integer - scale requested window size to fill screen using closest integer value SCALING FILTER nearest - nearest neighbor upscaling filter (useful for old XP/9x apps and games with integer scaling factor) linear - bilinear upscaling filter -- 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.

June 3, 2025

[Bug 56285] Scaling on screen is wrong with Wine Wayland driver while resolution detected is correct.

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=56285 garrett m <garrettm4(a)protonmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |garrettm4(a)protonmail.com --- Comment #4 from garrett m <garrettm4(a)protonmail.com> --- Changing the winecfg DPI to match the DE's display scale works for games with resolutions less than the native display resolution. For example, a 4k display with 200% scaling would use double 96dpi or 192dpi in winecfg. However, for games with native resolution equal to the display resolution, the game will select a lower resolution (1920x1080) and be upscaled by Wine to the native display resolution (3840x2160) which is not what we want. Ideally, the Wine Wayland driver needs to avoid scaling any fullscreen app that requests a window size equal to the display resolution. Currently, it will apply the DE's display scale when the fullscreen window size = display resolution and thus overflow the screen. E.g., 200% scaling in GNOME will scale a 4k game window twice as large... >From talking with the Niri DE developer, he said this is a client side viewport issue. When working with full screen apps/games only physical pixel space should be used. Logical pixel space is really only useful for decorated windowed apps with sizes much smaller than fullscreen. For fullscreen apps that have a resolution / window size equal to the display resolution, Wine's Wayland driver should not scale the app and report the display's physical pixel dimensions so the app can scale itself correctly. For a fullscreen app with a resolution / window size less than the display resolution, Wine should scale the app. However, it would be nice to have an environment variable to configure this behavior such as setting integer scaling and the scaling filter used (nearest or bilinear). -- 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.

June 3, 2025

[Bug 58304] Question on programs that use files with $ in file names?

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=58304 --- Comment #11 from Michael Setzer II <mikes(a)kuentos.guam.net> --- Ran it with +relay,+sed but it just sat there and created a 6G log file. Tried it with +relay only and did the same thing. Got to 4G before cancel. Then ran it with +sed Original logfile with 6M and with +sed is like 12M 242K Jun 3 10:51 logfile3.log.bz2 6.0M Jun 1 23:58 logfile.log 12M Jun 3 10:50 logfile3.log Don't know that $ is the issue might be something else. Saw no lines with error or critical in original log file. When thru original log file scanning for IERenderer and nothing stood out as an error. Lots of file nof found or no file messages. Also loooked at first one with winedb, but didn't see anything obvious before or write after that. -- 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.

June 3, 2025

[Bug 58304] Question on programs that use files with $ in file names?

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=58304 --- Comment #10 from Michael Setzer II <mikes(a)kuentos.guam.net> --- Created attachment 78674 --> http://bugs.winehq.org/attachment.cgi?id=78674 logfile created with bz2 using +sed since +relay got 6G file before killing Created file, but with the +relay option it created file to 6G and was just going. With +sed it runs in same amount of time and has same crash. -- 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.

June 3, 2025

[Bug 58317] New: On one Fedora 42 machine after update it fails. Works on Fedora 41, and another Fedora 42 worked?

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=58317 Bug ID: 58317 Summary: On one Fedora 42 machine after update it fails. Works on Fedora 41, and another Fedora 42 worked? Product: Wine Version: 10.9 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: blocker Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: mikes(a)kuentos.guam.net Distribution: --- wine notepad 002c:err:seh:NtRaiseException Unhandled exception code c0000005 flags 0 addr 0x6fffffc4c133 0034:err:seh:NtRaiseException Unhandled exception code c0000005 flags 0 addr 0x6fffffc4c133 003c:err:seh:NtRaiseException Unhandled exception code c0000005 flags 0 addr 0x6fffffc4c133 Error after update to 10.9, downgrade to 10.8 and it works fine. Worked fine on Fedora 41 machine, and on anoher Fedora 42 machine. Not sure what that error might mean? -- 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.

June 3, 2025

[Bug 58316] New: Wine Wayland window only opens on "monitor 1" and cannot be moved

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=58316 Bug ID: 58316 Summary: Wine Wayland window only opens on "monitor 1" and cannot be moved Product: Wine Version: 10.4 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winewayland Assignee: wine-bugs(a)winehq.org Reporter: dakky198(a)gmail.com Distribution: --- I've tested this both on Mutter and KWin. When launching a fullscreen game using Wine's Wayland drivers (by utilizing `env -u DISPLAY game.exe` the game launches on my secondary monitor no matter what you try doing. I've determined this is because my graphics drivers have that monitor set as "monitor 1". If I try to move the window to my other monitor, the window snaps back immediately to it's original position. Windowed applications also spawn only on "monitor 1" but allow themselves to be moved to another monitor. However, they retain the resolution/scaling/etc from their original position and do not update to match the new monitor. In my case, they spawn on a 1080p monitor and when moving them to 1440p the window scales to be quite small. -- 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.

June 2, 2025

[Bug 58315] New: Clip Studio Paint 4 menus turn black when clicked

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=58315 Bug ID: 58315 Summary: Clip Studio Paint 4 menus turn black when clicked Product: Wine Version: 10.9 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: michelpereira4410(a)gmail.com Distribution: --- Created attachment 78673 --> http://bugs.winehq.org/attachment.cgi?id=78673 Wine debug d3d + normal log Clip Studio Paint on Wine (version X.Y) exhibits a rendering issue where certain UI components — specifically the Settings window and the Login window — appear completely black when opened. Despite the lack of visible content, the menus remain clickable and functional if the user knows where to click. This behavior makes it extremely difficult to use those parts of the application effectively. -- 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.

June 2, 2025

[Bug 58314] New: GetGlyphOutlineW returns a negative number sometimes

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=58314 Bug ID: 58314 Summary: GetGlyphOutlineW returns a negative number sometimes Product: Wine Version: 10.8 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: gdi32 Assignee: wine-bugs(a)winehq.org Reporter: skyfloogle(a)protonmail.com Distribution: --- Created attachment 78672 --> http://bugs.winehq.org/attachment.cgi?id=78672 Source code for a repro, an exe build, Windows and Wine sample logs, and the necessary font. In an application I'm developing, I've found that GetGlyphOutlineW returns a negative number under specific circumstances in Wine. According to the documentation, it should return a positive number, with the exception of GDI_ERROR (-1). My program therefore treats the return value as unsigned (as specified in the documentation) and checks against -1, which doesn't work when it returns -32 instead. It's not clear to me why this value is being returned, but I've only seen it reproduce with a specific character (¯) in a specific font. I've put together a minimal reproducing sample. The issue reproduces on both 32 and 64 bit, and does not reproduce on Windows. Source code and a copy of the necessary font (https://ggbot.itch.io/raster-forge-font) are attached, as are expected and actual logs. In this sample, -8 is returned instead of -32, but I suspect the root cause is similar - it shouldn't be returning anything lower than -1 in either case. For what it's worth, I'm running on EndeavourOS, which hasn't received 10.9 yet at the time of writing, but I've checked the commit logs for gdi32 and haven't seen anything that looks relevant. -- 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.

June 2, 2025