January 2024 - Wine-Devel - list.winehq.org

Re: 9.0 release notes, please review

by Francois Gouget

> - Smart cards are supported in the Winscard dll, using the Unix > PSCSlite library. It should probably be noted that this is not supported for 32-bit Windows applications despite Wine providing a 32-bit winscard.dll. See https://bugs.winehq.org/show_bug.cgi?id=54661 The situation would be a lot better if at least Wine did not provide a broken 32-bit dll. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Before you criticize someone, walk a mile in his shoes. That way, if he gets angry, he'll be a mile away - and barefoot.

Jan. 16, 2024

Re: 9.0 release notes, please review

by Hans Leidekker

On Tue, 2024-01-16 at 12:40 +0100, Alexandre Julliard wrote: > Cryptography and security > * Smart cards are supported in the Winscard dll, using the Unix PSCSlite > library. PCSClite

Jan. 16, 2024

9.0 release notes, please review

by Alexandre Julliard

Folks, We've once again made very good progress on the regressions during this code freeze period, thanks to everybody for your help! It's now time for the final release. I've attached the tentative release notes, written with help from Jacek, Rémi and Zeb, and for the first time in Markdown format <g>. Please review these and let me know if anything is wrong, missing, or unclear. -- Alexandre Julliard julliard(a)winehq.org

Jan. 16, 2024

Re: Force feedback auto center implementation?

by Tyson Whitehead

Put together an implementation. Works good on my hardware. Here were the required changes dinput - always DIERR_ACQUIRED if trying to set autocenter and acquired - send a stop to all effects on acquire if autocenter is off bus{sdl,udev} - enable autocenter on reset - disable autocenter on stop all effects https://gitlab.winehq.org/wine/wine/-/merge_requests/4830 The prior code didn't DIERR_ACQUIRED if it was in exclusive mode, but Windows does. This behaviour is what makes it easy to implement as it means you only have to deal with autocenter during an acquire where you can just do a stop all effects as only autocenter is running.

Jan. 13, 2024

Wine staging 9.0-rc5 release

by Alistair Leslie-Hughes

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 9.0-rc5 (500 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * None Added: * None Updated: * vkd3d-latest Where can you help * Run Steam/Battle.net/GOG/UPlay/Epic * Test your favorite game. * Test your favorite applications. * Improve staging patches and get them accepted upstream. * Suggest patches to be included in staging. As always, if you find a bug, please report it via https://bugs.winehq.org Best Regards Alistair.

Jan. 13, 2024

Re: vkd3d request

by Giovanni Mascellani

Hi, Il 08/01/24 20:44, Henri Verbeet ha scritto: > How would that work in concrete terms though? Is the idea here that > someone is volunteering to keep track of this and hand the maintainer a > list to include in the release notes? Or would we keep something along > the lines of a ChangeLog file that individual developers should update > in their MRs? Perhaps something else entirely? Thinking again, a more lightweight solution might be to introduce a tag that we can use in commit messages and can be easily grepped for when nearing the release. Something like: Impacted-Application: The Incredible Machine I'm using a generic word rather than "fixed" or "improved" because in general the impact might be negative, or the submitter might fear that. I gather that the request is about having a list of all the applications that vkd3d maintainers know or suspect it makes sense to test when nearing the release time, which is a broader concept that just applications that were fixed. How does that sound? Gio.

Jan. 9, 2024

Re: vkd3d request

by Alistair Leslie-Hughes

Hi Henri On 9/1/24 06:44, Henri Verbeet wrote: > On 18/12/2023 13.13, Giovanni Mascellani wrote: >> Il 07/12/23 21:13, Alistair Leslie-Hughes ha scritto: >>> Would it be possible to include a file of all games/applications that >>> have fixes when they are committed. It's too hard to track unless you >>> really doing serious work with it. >> >> It looks like a sensible request. I usually mention games which are >> fixed by a commit in the commit message, but it's true that having a >> list somewhere is easier than scanning all the commits in a new version. > > How would that work in concrete terms though? Is the idea here that > someone is volunteering to keep track of this and hand the maintainer a > list to include in the release notes? Or would we keep something along > the lines of a ChangeLog file that individual developers should update > in their MRs? Perhaps something else entirely? The Changelog idea was what I was thinking. The developer already knows what game/application they are fixing, so makes sense to be part of the MR. Pushing the burden on to the maintainer, feels like double handling of information which means it will get lost/forgotten. Regards Alistair

Jan. 8, 2024

Re: Force feedback auto center implementation?

by Tyson Whitehead

On Mon, Jan 8, 2024 at 2:58 AM Rémi Bernon <rbernon(a)codeweavers.com> wrote: > Interesting, thanks for that investigation. I think we can do the same > in dinput, and send DISFFC_STOPALL when auto-centering is off. > > Then, in winebus.sys, and depending on the backend -in evdev, but maybe > also SDL unless it has another better way for doing it- we could > implement PID_USAGE_DC_DEVICE_RESET in a way that it adds an implicit > spring effect when supported. In retrospect, it makes sense that the reset state has a spring effect playing. Without a default spring effect playing on startup/reset, it wouldn't be usable as a regular HID joystick on systems that don't have PID support. Are there actually devices that don't reset to a spring effect being played then?

Jan. 8, 2024

Re: vkd3d request

by Henri Verbeet

On 18/12/2023 13.13, Giovanni Mascellani wrote: > Il 07/12/23 21:13, Alistair Leslie-Hughes ha scritto: >> Would it be possible to include a file of all games/applications that >> have fixes when they are committed. It's too hard to track unless you >> really doing serious work with it. > > It looks like a sensible request. I usually mention games which are > fixed by a commit in the commit message, but it's true that having a > list somewhere is easier than scanning all the commits in a new version. How would that work in concrete terms though? Is the idea here that someone is volunteering to keep track of this and hand the maintainer a list to include in the release notes? Or would we keep something along the lines of a ChangeLog file that individual developers should update in their MRs? Perhaps something else entirely? Henri

Jan. 8, 2024

Re: [PATCH] po: Update Asturian translation

by Enol P.

Jan. 8, 2024