December 2022 - Wine-Devel - list.winehq.org

Re: What does the "Override" button do in joy.cpl?

by Rémi Bernon

On 12/13/22 08:25, Alex Henrie wrote: > While looking at the new messages to translate for Wine 8.0, I noticed > several like this: > > "No user detected on slot #0, make sure your gamepad is plugged in, > and not overriden for DInput in the Joysticks tab." > > Leaving aside the misspelling of "overridden" in English, I want to > make sure that I translate this text intelligibly into Catalan. I > assume that the message is related to the "Override" button in > joy.cpl. What exactly does that button do? > > -Alex Hi Alex, The button "overrides" an XInput compatible device to make it DInput only. Normally XInput compatible gamepads are exposed to DInput through a compatibility interface, which has a specific behavior, like for instance with a combined trigger axis (LT / RT will control the same Z axis). This button allow a gamepad to be exposed directly to DInput instead, and bypass this compatibility interface. The gamepad will also not be available through the XInput interface anymore when it is overridden. Cheers, -- Rémi Bernon <rbernon(a)codeweavers.com>

Dec. 13, 2022

What does the "Override" button do in joy.cpl?

by Alex Henrie

While looking at the new messages to translate for Wine 8.0, I noticed several like this: "No user detected on slot #0, make sure your gamepad is plugged in, and not overriden for DInput in the Joysticks tab." Leaving aside the misspelling of "overridden" in English, I want to make sure that I translate this text intelligibly into Catalan. I assume that the message is related to the "Override" button in joy.cpl. What exactly does that button do? -Alex

Dec. 13, 2022

Re: Regarding Coverity

by Alex Henrie

On Mon, Dec 12, 2022 at 2:56 PM Fabian Maurer <dark.shadow4(a)web.de> wrote: > > I'm sometimes working through the issues Coverity scan reported, and I come across a lot of issues that I consider false positives. I however am not 100% comfortable marking them as such, just in case I am wrong... > > What's the policy on that? Are those getting reviewed by other devs? Should I just mark them as false positives if I think they are? In my opinion, if you are reasonably confident that a "defect" is a false positive then it is helpful to mark it as a false positive. Other developers can change it back if you make a mistake, and Coverity keeps a "triage history" of these changes so that it is clear if there has been a disagreement. While we're on the subject, it would be very helpful to split defects found in the "libs" directory into a separate Coverity component, similar to how we split the tests into a separate component. -Alex

Dec. 12, 2022

Regarding Coverity

by Fabian Maurer

Hello, I'm sometimes working through the issues Coverity scan reported, and I come across a lot of issues that I consider false positives. I however am not 100% comfortable marking them as such, just in case I am wrong... What's the policy on that? Are those getting reviewed by other devs? Should I just mark them as false positives if I think they are? Regards, Fabian Maurer

Dec. 12, 2022

Why is vkd3d an extra projekt?

by Fabian Maurer

Hello, For a while now I'm curious, so I have to ask: Why is vkd3d an extra project? Is that because it is reusable as standalone library? Just curious, because it's the only library in Wine that is a separate project. Wouldn't it have made sense to develop it as part of Wine to reuse the wine infrastructure and always have the most recent code for dx12/shaders? Regards, Fabian Maurer

Dec. 12, 2022

Wayland driver - December 2022 update

by Alexandros Frantzis

Hi everyone! It's been some time since our last Wayland driver update ([1]), and, with the year coming to an end, I wanted to share information about the progress we made this year and discuss future steps. The focus in 2022 was on maturing the Wayland driver and keeping up to date with the Wine upstream internal changes. This involved, among other things, splitting the driver into a PE and Unix part, updating it for the latest internal driver APIs, and making preparations to support WoW64 (we are not there yet, but we are close). A significant improvement compared to last year is support for cross-process rendering, which is required by Chromium/CEF applications. Last year the driver was able to run Chrome with the "--in-process" command-line option. This year Chrome is supported without any special flags, fully GPU accelerated on both OpenGL and Vulkan! This was achieved by implementing what is effectively an internal off-screen swapchain in the driver's OpenGL and Vulkan integration code, along with a mechanism to send buffers to other processes for presentation when needed. This update also brings enhanced support for the linux-dmabuf v4 Wayland protocol (aka dmabuf-feedback), which allows compositors to dynamically send information about optimal formats and modifiers, e.g., depending on the surface presentation mode (fullscreen vs windowed). Our new internal OpenGL swapchain can handle such feedback directly, while for Vulkan we rely on the Wayland WSI to provide this functionality. This year we also made a lot of smaller scale fixes and enhancements, that in aggregate have greatly improved driver stability. These were a result of both testing we performed ourselves, and also of reports from people trying out the Wayland driver, for which we are very grateful. All the features listed in our previous update (multi-monitor, display mode changes, copy-paste, keymaps, relative mouse etc) have been further refined. One issue for which we haven't yet found a reasonable solution, is how to properly position the context/right-click menu in the standalone systray. The Wayland driver uses the Wayland protocol in a manner that, although in spec, exercises less well-trodden paths in compositor code. Throughout the year we have come across a few issues with compositors, which we have been working with upstreams to address. One issue that people should be aware of, in particular, manifests as improper relative mouse motion in first-person 3D games when using the Wayland driver with some compositors (e.g., see [2]). TL;DR of how to use the development branch: $ git clone -b wayland https://gitlab.collabora.com/alf/wine/ $ cd wine $ ./configure --with-wayland [--with-vulkan] $ make [-jN] $ DISPLAY= WAYLAND_DISPLAY=wayland-0 ./wine ... Especially note the use of 'DISPLAY=', which we use to opt in to the Wayland driver by disabling the higher priority X11 driver. Here is a video showing the latest version of the Wayland driver in action (note that in this video I am using Mutter from git main that includes the fix for the relative motion issues mentioned above): https://www.youtube.com/watch?v=lZ-MK72Kyp8 --- Next steps: Last year, due to the extensive ongoing internal rework in Wine (e.g., win32u), the decision was made to postpone the upstreaming of the Wayland driver until some amount of internal stability had been reached. My impression is that things are a lot more stable now, from the drivers' point of view at least. Is there any upcoming work that people feel would be severely hindered by the upstreaming of the Wayland driver? Ideally, I would like to start the upstreaming effort (which I expect will take some time) at some point early next year, after the codebase has been unfrozen. Does this sound reasonable? Thanks, Alexandros [1] https://www.winehq.org/pipermail/wine-devel/2021-December/203035.html [2] https://gitlab.gnome.org/GNOME/mutter/-/issues/2223

Dec. 12, 2022

Code freeze plans

by Alexandre Julliard

Folks, As you know, we are now in code freeze towards 8.0. This means that only reasonably small, targeted bug fixes can be accepted. As far as possible, please mention the bug number that the fix is for. We currently have 242 open regressions (cf. https://source.winehq.org/regressions) I'm hoping that we can release 8.0 with fewer open regressions than 7.0, which means we have to bring that number down to 150. All help is welcome! Fixes to the tests can always be accepted since they can't break apps, so this is also a good opportunity to fix some long-standing failures. The rc releases will be a bit more spread out than usual, because I'll be out during the Christmas break. My plan is to have rc2 on December 21, rc3 on January 6, and then resume weekly rc releases, with a final 8.0 towards the end of January. -- Alexandre Julliard julliard(a)winehq.org

Dec. 12, 2022

Re: Wine staging 8.0-rc1 release

by Rémi Bernon

On 12/12/22 10:30, Alistair Leslie-Hughes wrote: > Hi Alois, > > On 11/12/22 22:23, Alois Schlögl wrote: >> >> Dear Alistair, >> >> >> thanks for the information. I see that the nvcuda patches are still >> disabled, that means cuda applications (e.g. cuda-z, and warpem) do >> not run anymore on wine-staging. >> In the announcement for wine-staging 7 22 you wrote: >> >>> The number is quiet lower compared to the previous version due to the >>> disabling of the >>> nvidia dll patchesets. >> >> which broke the cuda support in wine-staging. I'm wondering what the >> reason for disabling these patches is? Is it to much work to maintain, >> and rebase these? Or is there a technical reason ? >> Most importantly, can we expect to have cuda supported again anytime >> soon ? >> > > The basic, is that the nvcuda and the other nv dll's need to be > converted to the unix function call syntax. > Considering, the first patch that implement the nvcuda has around 245 > functions, that is a huge amount of effort (Time) to change over. > > We are still trying to workout, if we will convert it over. This dll > and the other nv* at present, are never going to be upstreamed (at this > stage). > > There has been some talk that these nv*/amd_ags* dlls should be external > project(s) and be maintained there. These are vendor specific DLL's > after all, so windows doesn't have them by default. So technically wine > shouldn't either. There is already a project for nvapi but that wont > help in this case. > > On the other side of things, some games and applications expect them to > be there in certain scenarios. There is a balance that need to be > found, which is the hard part. > FWIW games usually try to load them based on GPU vendor ID, maybe upstream Wine should hide it and use a Wine-specific ID to solve that. -- Rémi Bernon <rbernon(a)codeweavers.com>

Dec. 12, 2022

Re: Wine staging 8.0-rc1 release

by Alistair Leslie-Hughes

Hi Alois, On 11/12/22 22:23, Alois Schlögl wrote: > > Dear Alistair, > > > thanks for the information. I see that the nvcuda patches are still > disabled, that means cuda applications (e.g. cuda-z, and warpem) do not > run anymore on wine-staging. > In the announcement for wine-staging 7 22 you wrote: > >> The number is quiet lower compared to the previous version due to the >> disabling of the >> nvidia dll patchesets. > > which broke the cuda support in wine-staging. I'm wondering what the > reason for disabling these patches is? Is it to much work to maintain, > and rebase these? Or is there a technical reason ? > Most importantly, can we expect to have cuda supported again anytime soon ? > The basic, is that the nvcuda and the other nv dll's need to be converted to the unix function call syntax. Considering, the first patch that implement the nvcuda has around 245 functions, that is a huge amount of effort (Time) to change over. We are still trying to workout, if we will convert it over. This dll and the other nv* at present, are never going to be upstreamed (at this stage). There has been some talk that these nv*/amd_ags* dlls should be external project(s) and be maintained there. These are vendor specific DLL's after all, so windows doesn't have them by default. So technically wine shouldn't either. There is already a project for nvapi but that wont help in this case. On the other side of things, some games and applications expect them to be there in certain scenarios. There is a balance that need to be found, which is the hard part. Regards Alistair

Dec. 12, 2022

Re: Wine staging 8.0-rc1 release

by Alois Schlögl

Dear Alistair, thanks for the information. I see that the nvcuda patches are still disabled, that means cuda applications (e.g. cuda-z, and warpem) do not run anymore on wine-staging. In the announcement for wine-staging 7 22 you wrote: > The number is quiet lower compared to the previous version due to the > disabling of the > nvidia dll patchesets. which broke the cuda support in wine-staging. I'm wondering what the reason for disabling these patches is? Is it to much work to maintain, and rebase these? Or is there a technical reason ? Most importantly, can we expect to have cuda supported again anytime soon ? Best regards, Alois Am 12/11/22 um 07:23 schrieb 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 8.0-rc1 (473 patches are applied to wine > vanilla) > > Upstreamed (Either directly from staging or fixed with a similar patch). > * winegstreamer: Implement MF_SD_LANGUAGE. > > Added: > * None > > Updated: > * none > > 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. > >

Dec. 11, 2022