November 2021 - Wine-Bugs - list.winehq.org

[Bug 52113] New: Killing Floor 2 : Item Server not connectable

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=52113 Bug ID: 52113 Summary: Killing Floor 2 : Item Server not connectable Product: Wine Version: 6.21 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: maycne.sonahoz(a)posteo.net Distribution: --- Overview: In Killing Floor 2, the Item Server cannot be reached. In consequence, neither the Inventory nor the Store are available from within the game. Steps to Reproduce: 1) Launch Killing Floor 2. 2) In the main menu, an icon should tell the connectivity with the Item Server. That icon shows the server is unreachable. 3) Access the Inventory tab. It should be filled with your custom items, but it always shows empty. 4) Access the Store tab. It should be filled with store offers, but it always shows empty. Build Date & Hardware: Manjaro stable - Xfce - kernel 5.10.79-1 - 2021-11-16 The issue has been happening from a long time now. As for today's reference: - Failed to reach the steps to reproduce the issue with Development Wine: - Development Wine built locally from source - Steam (for Windows) installed through Wine - Steam refuses to install Killing Floor 2 : "invalid platform" - Issue reproduced with: - Steam (for Linux) Beta - Proton-6.21-GE-2 (based on Wine 6.21) Additional Builds and Platforms: Manjaro stable - Xfce - kernel 5.10.79-1 - 2021-11-16 The issue does not (yet) reproduce with: - Steam (for Linux) Beta - Proton 6.3-8 (based on Wine 6.3) -- 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.

Nov. 26, 2021

[Bug 52020] Multiple games crash after intros (Borderlands GOTY Enhanced, Dark Souls: Remastered)

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=52020 Andrey Gusev <andrey.goosev(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Borderlands GOTY Enhanced |Multiple games crash after |crashes after intros |intros (Borderlands GOTY | |Enhanced, Dark Souls: | |Remastered) -- 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.

Nov. 26, 2021

[Bug 51564] Can't run 16bit programs when built without mingw

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=51564 --- Comment #38 from O. Nykyforchyn <oleh.nyk(a)gmail.com> --- (In reply to Mike Purtell from comment #37) > This bug is marked as "Status: CLOSED FIXED". > Can we continue to pursue a solution here or do I need to submit a new bug? I'd rather file a new one, because the original bug report states that ANY 16 bit program cannot be run at all. Now cardfile.exe starts, but there are troubles with background and/or with usability. -- 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.

Nov. 26, 2021

[Bug 51564] Can't run 16bit programs when built without mingw

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=51564 --- Comment #37 from Mike Purtell <mmikeinsantarosa(a)gmail.com> --- This bug is marked as "Status: CLOSED FIXED". Can we continue to pursue a solution here or do I need to submit a new bug? -- 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.

Nov. 26, 2021

[Bug 52089] d2d1:d2d1 fails in test_draw_geometry() on Wine

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=52089 Stefan Dösinger <stefan(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |stefan(a)codeweavers.com --- Comment #1 from Stefan Dösinger <stefan(a)codeweavers.com> --- I can't reproduce this or 52090 on my Nvidia card here. I have an old geforce 460 something hanging around, I'll try on that one. Otherwise I'll have to remote debug. -- 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.

Nov. 26, 2021

[Bug 52106] dxva2:dxva2 fails in test_progressive_device() on cw-rx460 (AMD)

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=52106 --- Comment #1 from Nikolay Sivov <bunglehead(a)gmail.com> --- Created attachment 71140 --> https://bugs.winehq.org/attachment.cgi?id=71140 patch Does this help? I would have tried myself, but I don't see these boxes on testbot. -- 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.

Nov. 26, 2021

[Bug 51899] 16-bit Collins Dictionary has black background.

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=51899 --- Comment #27 from O. Nykyforchyn <oleh.nyk(a)gmail.com> --- Resent patch that corrects (at least part of) failures in 16 bit <-> 32 bit handles conversion: https://source.winehq.org/patches/data/220679 Tested with wine-6.22 -- 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.

Nov. 26, 2021

[Bug 52101] The winebus.sys process crashes in lnxev mode when a keyboard key is pressed.

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=52101 --- Comment #3 from Ivo Ivanov <logos128(a)gmail.com> --- (In reply to Rémi Bernon from comment #2) > Interesting, although I don't think we're supposed to support keyboard or > mouse devices this way, at least not for now, as winebus.sys is really only > written for joysticks and gamepad devices. I agree. Especially mouse devices push a lot of staged Input reports from the lnxev side, which go in the UDEV bus thread together with the reports from hidraw devices. And if there is a hidraw device like mine, which pushes around 1000 input reports per second, all those additional unused reports from mouse devices, etc. only could hinder the performance of the sole thread. IMO, would be good if keyboards and mouse devices are excluded from the enumeration of the UDEV lnxev bus. > I think the problem is either, that we send a report before the device has > been started, or that the device doesn't have any report, or that it's not > been started at all maybe because the hidclass.sys driver didn't match it > somehow. > > I guess the first case may also happen with any device if anything is > pressed after the device has been created and before it has received the > IRP_MN_START_DEVICE request (or after IRP_MN_REMOVE_DEVICE if it's being > forcefully removed from the Win32 side). >From the log I could see two instances of the keyboard - /dev/input/event3 -> "SIGMACHIP USB Keyboard" and /dev/input/event5 -> "SIGMACHIP USB Keyboard Consumer Control". After that in the log there are a lot of descriptors with report_len 0, which have collections without usages. They probably cause the issue. >From the code is visible that only buttons from BTN_MISC to KEY_MAX are being enumerated. There is even a comment in build_report_descriptor() about ignoring regular keys and adding only buttons (this is the UDEV lnxev bus with staged HID reports). This IMO produces the empty reports, as probably some of these keyboard devices expose only regular "keys". -- 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.

Nov. 26, 2021

[Bug 39244] scrrun:filesystem BOM tests fail in the Korean and Chinese locales

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=39244 --- Comment #3 from Robert Wilhelm <sloper42(a)yahoo.com> --- This is also reproducible on Linux, same results as Windows VM. Therefore I think tests need to be fixed. $ cd dlls/scrrun/tests $ export LANG=zh_CN $ make test tools/runtest -q -P wine -T . -M scrrun.dll -p dlls/scrrun/tests/scrrun_test.exe filesystem && touch dlls/scrrun/tests/filesystem.ok 00f8:fixme:scrrun:textstream_get_AtEndOfLine (0049ED88)->(0031FDC8): stub 00f8:fixme:scrrun:textstream_get_AtEndOfLine (0049ED88)->(0031FDC8): stub filesystem.c:1529: Test failed: got L"\f8f5", expected L"\f8f5?" filesystem.c:1658: Test failed: got L"\f8f5\fa0f", 93 filesystem.c:1802: Test failed: got L"\f8f5\fa0f", expected L"\f8f5?" -- 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.

Nov. 26, 2021

[Bug 39244] scrrun:filesystem BOM tests fail in the Korean and Chinese locales

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=39244 Robert Wilhelm <sloper42(a)yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sloper42(a)yahoo.com --- Comment #2 from Robert Wilhelm <sloper42(a)yahoo.com> --- In dlls/scrrun/filesystem.c append_read_data() we check if last char in buf is IsDBCSLeadByte and move it to next read. But if last char in textstream is LeadByte, it will be ignored. Tests behave different, we do not check for leadbyte here. This leads to test failure because second bom byte (0xFE) is Leadbyte in e.g. CN locale. -- 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.

Nov. 26, 2021