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

[Bug 52019] New: DigiCertUtil wrong size

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=52019 Bug ID: 52019 Summary: DigiCertUtil wrong size Product: Wine Version: 6.21 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: aros(a)gmx.com Distribution: --- Created attachment 71018 --> https://bugs.winehq.org/attachment.cgi?id=71018 DigiCertUtil sha256sum DigiCertUtil.exe 1f0b80db162ebdb0b1c84e57fca2396aaa5b477b62dee570ad69ef2321116fef DigiCertUtil.exe Check the attached screenshot. -- 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. 11, 2021

[Bug 51748] NIK Dfine2 crashes/hangs (worked before)

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=51748 --- Comment #8 from Pit <pit(a)astro.su.se> --- My excuses, I lost track of this due to local issues.... Did that hack make it into the main tree meanwhile? I just tried the latest distribution package (wine-6.19-1379.12.x86_64, openSUSE Tumbleweed), and it still crashes :( -- 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. 11, 2021

[Bug 51873] Joy.cpl crashes on the FFB tab when the FFB device is selected in the drop down list

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=51873 --- Comment #16 from Ivo Ivanov <logos128(a)gmail.com> --- Created attachment 71017 --> https://bugs.winehq.org/attachment.cgi?id=71017 dinput-additions-and-fixes.patch Rebased the patchset to the current master 97d6cfd7059fbe55fdd24a04e8d9133848328d4e Decided to save you some time, since there are a lot of merge conflicts with today's 'master' :) -- 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. 11, 2021

[Bug 48968] Cossacks 2 Battle for Europe broke bottom of screen when using ALT + TAB

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=48968 --- Comment #3 from Rafał Mikrut <mikrutrafal(a)protonmail.com> --- With wine-devel and wine-staging 6.21 after alt-tabing I don't see anymore GUI -- 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. 11, 2021

[Bug 48968] Cossacks 2 Battle for Europe broke bottom of screen when using ALT + TAB

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=48968 --- Comment #2 from Rafał Mikrut <mikrutrafal(a)protonmail.com> --- Created attachment 71016 --> https://bugs.winehq.org/attachment.cgi?id=71016 Screenshot of broken view -- 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. 11, 2021

[Bug 51873] Joy.cpl crashes on the FFB tab when the FFB device is selected in the drop down list

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=51873 --- Comment #15 from Ivo Ivanov <logos128(a)gmail.com> --- (In reply to Rémi Bernon from comment #13) > It could be possible to do it the same way as feature reports but the > problem I'm seeing there is that IOCTL_HID_GET_INPUT_REPORT needs to be > explicitly requested and I don't see how it would specify the event number > it's interested in. I didn't think about the effect id. Yeah, looks like the most logical way to implement this from manufacturer POV is to send periodical Input reports on the INTERRUPT IN channel, and seems this is what the specification suggests. Otherwise they would have written this explicitly. There is no logic for such report to be implemented on the control endpoint, without a way to specify the input parameters as effect id, etc. If the authors of the specification wanted such a thing, they would have implemented it with feature reports in the same manner as Create New Effect -> PID Block Load sequence. I've looked again the usb capture data from the WheelCheck application on Windows 10, and there is no trace of any Input report through the control endpoint or any Input report with id 2 (the PID State Report id in Simucube 2) in the INTERRUPT IN endpoint. So MS doesn't use the control endpoint as well. IMO this is probably either overlooked by the device manufacturer, or a bug in the firmware. I'm not on the latest firmware, though. There are few iterations from the last few months, that mostly add support for new revisions of the device. I'll install the latest firmware, and let you know for the results. I plan to contact the manufacturer for the issue with the report descriptor we talked about a few weeks ago, so I can tell them about this issue too. > Is HIDIOCGINPUT returning an error if there's no more input report for the > matching id, or is it blocking until there's one? > > If it's the case, we'll maybe have to implement IOCTL_HID_GET_INPUT_REPORT > in the same kind of way then, instead of succeeding every time and returning > the last report seen. This would need to be the case for all the backend > though, and maybe not completely straightforward. I have read again the MS documentation about the IOCTL_HID_GET_INPUT_REPORT / HidD_GetInputReport. They seem to suggest that IOCTL_HID_GET_* / HidD_Get* routines should be used non regularly only to get the current state of the device. Something that is always mentioned for the control endpoint in the USB HID specification. They also always couple the info for IOCTL_HID_GET_INPUT_REPORT with IOCTL_HID_GET_FEATURE. For continuously obtaining Input reports, they suggest IRP_MJ_READ / ReadFile. So I would assume that IRP_MJ_READ uses the highly responsive INTERRUPT IN endpoint, while IOCTL_HID_GET_* uses the control endpoint. So, IMO to be more consistent with MS' documentation, we should implement IOCTL_HID_GET_INPUT_REPORT (using HIDIOCGINPUT) in the same manner as IOCTL_HID_GET_FEATURE. This way it (HidD_GetInputReport) would do exactly what the applications expect from it. And some apps might use it just because it supposedly uses the control endpoint, and not the INTERRUPT IN. It would also help to better and more easily test this particular issue, of course. > The client (dinput) will also need to make a dedicated asynchronous ioctl to > read effect statuses, instead of reading them in the same way as the device > state reports. > > Another possible approach would be to do like the SDL backend, where we > would request HIDIOCGINPUT regularly and push the report in the same way as > device state reports. That may be simpler from the client perspective as we > wouldn't have to worry whether a device needs IOCTL_HID_GET_INPUT_REPORT > requests or just ReadFile calls. IMO, the proposed patchset is the right way to implement this feature. If the state of the effect is unknown by the time GetEffectStatus is called, then there should be an alternative way to calculate this on the dinput side. It would need the effect start time, loop count (or infinity), duration and startdelay (if supported) to calculate the current state of the effect, taking into account if the device is acquired and all the other factors, etc. On every successful Start it would set the start time, and on every Stop, Unload, Reset, etc. it would zero it. Every successful SetParameters would set the other time parameters. Then it's pretty easy to calculate if the effect is currently playing or not. -- 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. 11, 2021

[Bug 52008] Star Ocean The Last Hope International crashes on startup after Wine 6.17

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=52008 --- Comment #2 from Patrick Hibbs <hibbsncc1701(a)gmail.com> --- Created attachment 71015 --> https://bugs.winehq.org/attachment.cgi?id=71015 Shell32 trace on git master OK after debugging with WINEDEBUG="+shell", we find out that it crashed attempting to resolve the path to the My Documents directory. Looking at the prefix I found that the "My Documents" folder was a broken symlink. (Caused due to a user home directory migration.) Fixing the symlink allowed the game to run correctly, and even fixed the saving issue. (Which means the broken symlink was to blame here as well.) Is this the correct behavior? It would seem to me that the proper behavior would be to either: 1. Fail to resolve the broken symlink and return an error to the caller. 2. Delete the broken symlink, fall back to creating a folder within the prefix's user profile and using it instead. (Or maybe using the folder redirection support to do this so it's visible in winecfg.) In any case, wine previously allowed this. Even if it could not open the directory, the path would still be "resolved" as far as the caller is concerned. At the very least, a warning in the console would be a nice user friendly improvement here. So that wine doesn't get inundated with "I broke my prefix" bug reports. :P -- 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. 11, 2021

[Bug 50680] Detroit: Become Human crashes at launch with ntdll-NtAlertThreadByThreadId

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=50680 --- Comment #21 from Zebediah Figura <z.figura12(a)gmail.com> --- Created attachment 71014 --> https://bugs.winehq.org/attachment.cgi?id=71014 patch 0010 + increased futex hash list size So, after off-bug discussion and some manual testing on my end, I have a pretty good theory as to what's going on now. I'd like to ask for one more test, though. This test does a lot to confirm my theory on *my* machine, but I'd like to get a second opinion. Please try the attached patch, on top of upstream wine (current git). This is basically a rebased version of patch 0010 by itself, *but* it also increases the addr_wait hash list size. If my theory is right, this will fix the game consistently. It does for me in something like 10/10 runs. -- 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. 11, 2021

[Bug 51832] Fork: "The selection contains a non-folder object" when selecting a folder

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=51832 --- Comment #22 from Alexandr Oleynikov <sashok.olen(a)gmail.com> --- This patch will likely fix the issue: https://source.winehq.org/patches/data/219298 -- 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. 10, 2021

[Bug 45901] Avoid GPU synchronization due to GPU-CPU transfer (Overwatch)

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=45901 mirh <mirh(a)protonmail.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mirh(a)protonmail.ch --- Comment #14 from mirh <mirh(a)protonmail.ch> --- There has been an absolute buttload of work on this front (discussion is hot in these very days) https://gitlab.freedesktop.org/mesa/mesa/-/issues/1030 https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12096 https://gitlab.freedesktop.org/mesa/mesa/-/issues/4735 https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11984 Btw is this in any way related to bug 44315? -- 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. 10, 2021