July 2024 - Wine-bugs - list.winehq.org

[Bug 55868] New: Horizontal tab character (ASCII 0x09) not rendered in text fields
by WineHQ Bugzilla 19 Jul '24

19 Jul '24

https://bugs.winehq.org/show_bug.cgi?id=55868 Bug ID: 55868 Summary: Horizontal tab character (ASCII 0x09) not rendered in text fields 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: vojtech.turek(a)hotmail.cz Distribution: --- Created attachment 75394 --> https://bugs.winehq.org/attachment.cgi?id=75394 Wine vs. Windows: the text field contains two horizontal tab characters, none of which are rendered by Wine If a text field contains horizontal tab (ASCII 0x09) characters, these are not rendered. See the attached screenshot from Wine 5.0.3 (left) and the same application running under Windows 10 x64 (right). The field value is "<HT>www.test.org<HT>x" ("<HT>" denotes a single horizontal tab character), yet Wine shows just "www.test.orgx" in the field. However, Wine clearly knows the horizontal tab characters are present, because it shows them in the text field tooltip stating (in English) "Website address<NEW LINE>[<TEXT FIELD VALUE>]". Installing corefonts via winetricks (as recommended in bug #45316) does not lead to any improvement. -- 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.

1 12

[Bug 56986] New: Cursor flickering in Infinity Engine games
by WineHQ Bugzilla 19 Jul '24

19 Jul '24

https://bugs.winehq.org/show_bug.cgi?id=56986 Bug ID: 56986 Summary: Cursor flickering in Infinity Engine games 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: accounts.winehq.org(a)vv221.fr Distribution: --- I get cursor flickering with some of the Infinity Engine games, maybe in all of them. csmt is disabled, to prevent performance problems. The games are run in a WINE virtual desktop. The flickering disappear if the games are run in windowed mode, it only happens when in full screen mode. I plan to run extra tests, first to ensure it actually affects all Infinity Engine games, then to check if the flicker still happens with the current development build of WINE, finally to find out when this problem was introduced. I am quite sure this is a regression, as I do not remember this flickering from the last time I played these games (that was probably prior to WINE 9.0). -- 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.

1 6

[Bug 56987] New: PiTool (pi_server.exe) can't detect Pimax HMD hid/usb devices
by WineHQ Bugzilla 18 Jul '24

18 Jul '24

https://bugs.winehq.org/show_bug.cgi?id=56987 Bug ID: 56987 Summary: PiTool (pi_server.exe) can't detect Pimax HMD hid/usb devices Product: Wine Version: 9.12 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: hid Assignee: wine-bugs(a)winehq.org Reporter: ivarbug(a)gmail.com Distribution: --- Created attachment 76817 --> https://bugs.winehq.org/attachment.cgi?id=76817 using app's hidapi.dll https://appdb.winehq.org/objectManager.php?sClass=application&iId=19830 The windows application is able to enumerate hid devices but doesn't identify or start talking to it's devices. The app comes with and uses a build of hidapi.dll (version <= 0.9.0 based on it's exports). I followed https://wiki.winehq.org/Winelib_User%27s_Guide#Building_Winelib_DLLs and tried building my own hidapi.dll that uses Linux native hidapi-hidraw. Using this the app does pick up the device, but crashes (probably unrelated to hid) after ~5s in an ungetc call. -- 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.

1 3

[Bug 31990] New: Add ability to upload extra files along with test ext
by wine-bugs＠winehq.org 18 Jul '24

18 Jul '24

http://bugs.winehq.org/show_bug.cgi?id=31990 Bug #: 31990 Summary: Add ability to upload extra files along with test ext Product: Wine-Testbot Version: unspecified Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: titan.costa(a)gmail.com Classification: Unclassified That would be good to have the ability to upload extra files (avi files, dlls, .drv, ...) to perform individual test (not part of the test suite). Otherwise it requires to embed the file or use a self extracting exe which are not very convenient. -- 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.

2 3

[Bug 33126] New: divided SysEx and coalesced midiOutLongMsg
by wine-bugs＠winehq.org 18 Jul '24

18 Jul '24

http://bugs.winehq.org/show_bug.cgi?id=33126 Bug #: 33126 Summary: divided SysEx and coalesced midiOutLongMsg Product: Wine Version: 1.5.25 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: winealsa.drv AssignedTo: wine-bugs(a)winehq.org ReportedBy: hoehle(a)users.sourceforge.net Classification: Unclassified Johannes Kroll reported in wine-patches that the KORG Kontrol Editor software hung after sending an ill-formed SysEx via winealsa's midiOutLongMsg. http://www.winehq.org/pipermail/wine-patches/2013-January/121335.html The MIDIHDR data is F0 ... F7 00 00 00 (125 bytes). http://www.winehq.org/pipermail/wine-devel/2013-February/098852.html He observed that no hang occurs when skipping the trailing 3 zero bytes. F7 is the "End Of SysEx" (EOX) marker. It is still unclear what happens. MIDI HW is expected to skip over bogus bytes, thus the zero bytes should cause no harm. OTOH, ALSA might be getting into trouble processing ill-formed messages, and we don't know if or how many bytes ALSA actually sent out through the serial port. In any case, midiOutLongMsg handling in Wine needs fixes. - winealsa should extract the F0...F7 part and send that as a SysEx. - More generally, midiOutLong is known to accept not only SysEx packets, but also coalesced status messages. Some MIDI authors prefer to send e.g. chords via one LongMsg rather than successive calls to midiOutShortMsg, arguing that it's faster. Hence all Wine MIDI drivers need to decompose midiOutLongMsg into packets consisting of status message, regular SysEx ... and possibly junk. - All APIs (MS, ALSA, OSS, CA) acknowledge the existence of divided SysEx. As a result, framing SysEx with F0 ... F7 is entirely under application control. The current winealsa framing code is simply wrong. - winecoreaudio always declared 3 bytes for short messages, even program change. I have written a sequence of patches to fix all of this. The only thing that is unclear is how to encapsulate garbage data like the above 3 zero bytes or real time messages with ALSA. What ALSA API function and what ALSA message type to use? Heck, I'm not even sure winealsa.drv/midi.c:modData is ok to send a 2-byte MTC quarter frame via snd_seq_ev_set_sysex instead of using a primitive that sets the type SND_SEQ_EVENT_CLOCK/TICK. -- 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.

2 3

[Bug 56962] New: Moto Racer 4 intro movie has broken aspect
by WineHQ Bugzilla 17 Jul '24

17 Jul '24

https://bugs.winehq.org/show_bug.cgi?id=56962 Bug ID: 56962 Summary: Moto Racer 4 intro movie has broken aspect Product: Wine Version: 8.6 Hardware: x86-64 OS: Linux Status: NEW Keywords: regression Severity: normal Priority: P2 Component: winegstreamer Assignee: wine-bugs(a)winehq.org Reporter: andrey.goosev(a)gmail.com CC: z.figura12(a)gmail.com Regression SHA1: ef354da59097b206122ec9101ee1f44201cca466 Distribution: --- Created attachment 76780 --> https://bugs.winehq.org/attachment.cgi?id=76780 comparison Good and bad versions. -- 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.

1 1

[Bug 56981] New: Mouse movement causes huge CPU spikes when using WINEESYNC.
by WineHQ Bugzilla 17 Jul '24

17 Jul '24

https://bugs.winehq.org/show_bug.cgi?id=56981 Bug ID: 56981 Summary: Mouse movement causes huge CPU spikes when using WINEESYNC. Product: Wine-staging Version: 9.13 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: logos128(a)gmail.com CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Regression SHA1: e479cad86f1f7de5d2a0a0d1398e7733c0aaef3e Distribution: ArchLinux The problem occurs every time when Wine is launched with WINEESYNC=1 - doesn't matter the application or the type of desktop used (virtual/non-virtual). It also happens when wine apps are in background, i.e. the topmost window is from a Linux app, etc. (As a side note Proton's fsync patchset is also affected.) The process with highest CPU usage is c:\windows\system32\explorer.exe (~70%) followed by /usr/bin/wineserver (~40%) - on a 6 core Intel CPU (12 virtual cores). Normally these processes have very low CPU usage (<1%) on mouse movement. I did manual bisect on the wine-development tree and found that commit 90dcd2eaa6b6a2afaf298f1e457938350b0becfc "win32u: Use the thread message queue shared memory in peek_message." was causing the problem with the eventfd_synchronization patchset. After reverting this commit + the other two related win32u commits, CPU usage is back to normal when using esync. Steps to reproduce: 1. Launch any Wine app - for example "winecfg". 2. Move the mouse pointer intensively. 3. See the CPU usage. -- 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.

1 5

[Bug 46392] New: Commandos: Behind Enemy Walls is freezing while using native quartz.dll
by wine-bugs＠winehq.org 17 Jul '24

17 Jul '24

https://bugs.winehq.org/show_bug.cgi?id=46392 Bug ID: 46392 Summary: Commandos: Behind Enemy Walls is freezing while using native quartz.dll Product: Wine Version: 4.0-rc4 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winegstreamer Assignee: wine-bugs(a)winehq.org Reporter: gang65(a)poczta.onet.pl Distribution: --- Created attachment 63153 --> https://bugs.winehq.org/attachment.cgi?id=63153 Terminal logs with WINEDEBUG=+quartz+gstreamer+amstream Commandos: Behind Enemy Walls is freezing while using native quartz.dll. This is caused lack of support for 8 bit colour mode (it is using in Cinepak codec): https://multimedia.cx/mirror/cinepak.txt It is also visible in the logs with fixme warning: 003c:trace:gstreamer:accept_caps_sink 0x7add5558 0x7be6aac8 003c:fixme:gstreamer:amt_from_gst_caps_video Unknown bpp 8 The cinepak gstreamer codec is already installed with command (Ubuntu 18.04): sudo apt install gstreamer1.0-libav:i386 -- 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.

2 24

[Bug 56901] New: Error Starting Counter Strike 2 from Steam
by WineHQ Bugzilla 17 Jul '24

17 Jul '24

https://bugs.winehq.org/show_bug.cgi?id=56901 Bug ID: 56901 Summary: Error Starting Counter Strike 2 from Steam Product: Wine Version: 8.7 Hardware: x86-64 OS: FreeBSD Status: UNCONFIRMED Severity: normal Priority: P2 Component: gameux Assignee: wine-bugs(a)winehq.org Reporter: raviraj_basis(a)hotmail.com Created attachment 76723 --> https://bugs.winehq.org/attachment.cgi?id=76723 Attachment 1 Hi Visual C++ Runtime Error pops-up when i try to run Counter Strike2(see Screen shot below): Attachment 1. Thanks rraj -- 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.

1 7

[Bug 56979] New: the default font should use utf-8 full font in freebsd because none english country file name didn't show char.
by WineHQ Bugzilla 16 Jul '24

16 Jul '24

https://bugs.winehq.org/show_bug.cgi?id=56979 Bug ID: 56979 Summary: the default font should use utf-8 full font in freebsd because none english country file name didn't show char. Product: Wine Version: 9.10 Hardware: x86-64 OS: FreeBSD Status: UNCONFIRMED Severity: normal Priority: P2 Component: fonts Assignee: wine-bugs(a)winehq.org Reporter: iwlb(a)outlook.com Created attachment 76804 --> https://bugs.winehq.org/attachment.cgi?id=76804 it didn't show chinese char. the default font should use utf-8 full char font in freebsd because none english country file name didn't show char. -- 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.

1 0