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

Re: How to delete a git branch that's not been merged?

by Hin-Tak Leung

You can just push empty to delete remote branch (note the nothing before ":"): git push origin :branch_name The normal push is equivalent to (your current HEAD is branched from remote "branch_name") git push origin HEAD:branch_name On Saturday, 17 December 2022 at 05:51:25 GMT+8, Gerald Pfeifer <gerald(a)pfeifer.com> wrote: On Tue, 13 Dec 2022, Gerald Pfeifer wrote: > https://wiki.winehq.org/Git_Wine_Tutorial#Deleting_branches has > > Deleting branches > > git branch -D new-branch > > Alas that does not work for me. > > % git branch -a > * master > remotes/origin/HEAD -> origin/master > remotes/origin/dll_soinit.c-stddef.h : > > % git branch -D dll_soinit.c-stddef.h > error: branch 'dll_soinit.c-stddef.h' not found. I believe I can now answer my own question, having dug into it a bit. The invocation above is for *local* branches, branches in the local checkout. To remove a *remote* branch, for example where a merge request was not accepted or was "bad" for some reason, we need to use `git push` instead of `git branch`: % git push origin --delete dll_soinit.c-stddef.h I plan on adding this to the Wiki in a few days. Any suggestions/concerns? Gerald

Dec. 17, 2022

Re: How to delete a git branch that's not been merged?

by Gerald Pfeifer

On Tue, 13 Dec 2022, Gerald Pfeifer wrote: > https://wiki.winehq.org/Git_Wine_Tutorial#Deleting_branches has > > Deleting branches > > git branch -D new-branch > > Alas that does not work for me. > > % git branch -a > * master > remotes/origin/HEAD -> origin/master > remotes/origin/dll_soinit.c-stddef.h : > > % git branch -D dll_soinit.c-stddef.h > error: branch 'dll_soinit.c-stddef.h' not found. I believe I can now answer my own question, having dug into it a bit. The invocation above is for *local* branches, branches in the local checkout. To remove a *remote* branch, for example where a merge request was not accepted or was "bad" for some reason, we need to use `git push` instead of `git branch`: % git push origin --delete dll_soinit.c-stddef.h I plan on adding this to the Wiki in a few days. Any suggestions/concerns? Gerald

Dec. 16, 2022

Re: git pull --rebase upstream ?

by Gerald Pfeifer

On Tue, 13 Dec 2022, Alex Henrie wrote: >> It appears the invocation should be shown as >> >> # git pull --rebase upstream master >> >> instead? > Yes, that looks like a mistake. : > We could certainly use more wiki editors. Last I checked, Rosanne was > the one to ask about account creation. Thank you, Alex! Rosanne got me set up, and I just clarified both instances of "git pull --rebase upstream" in the Wiki. Further changes to come as Git and me are working to become friends. :-) Gerald

Dec. 16, 2022

Re: Wayland driver - December 2022 update

by Alexandros Frantzis

On Fri, Dec 16, 2022 at 08:44:05AM +0100, Rémi Bernon wrote: > Hi Alexandros! Hi Rémi! <snip> > > 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? > > > > Probably not as large as this year's refactoring in any case. Ofc, any user > driver refactoring (and I can think already of a couple of things I'd like > to see) is hindered by additional driver implementations, but I think it > shouldn't be a blocker either. FWIW, I am happy to get involved whenever a core change requires non-trivial driver updates (see also my comment at the end about maintainership). > > 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? > > > > I'm only giving my opinion here, I'd suggest to try and see how it goes. > > Note that IMHO you'd probably be better with someone willing and dedicated > to reviewing the changes, rather than hope that review will happen by chance > or by the maintainer. I would certainly appreciate having a dedicated reviewer (or reviewers). I know that people's time is both limited and precious, so I would like to make the process as easy as possible for them. The driver commit structure, containing generally small and focused commits, was designed with this goal in mind. The trade-off is that the driver proposal has ended up with a lot of commits. The idea is to iteratively propose the first of the remaining commits from the driver that logically belong together, discuss/update/merge and continue like this with the next commits/MR, until the whole driver is upstream. I expect the process will take some time, that's why I would like to start early, but that's fine. The goal is to ensure that people are happy with and confident in what ends upstream, and I hope to learn more myself. Hopefully this process will allow people to become more familiar with Wayland, too. If anyone reading this is interested in reviewing when the time comes, please let me know :) > In the same way, it would also probably help if you are ready to assume > maintainership of the module from the beginning, or if someone (else than > the Wine maintainer) is. My intention is to keep on working on and maintaining the driver. In fact, I expect I won't be alone, as this year our "Wayland driver" team gained two more people, who will be able to help going forward, too. Thanks, Alexandros

Dec. 16, 2022

Re: Wayland driver - December 2022 update

by Rémi Bernon

Hi Alexandros! On 12/12/22 18:48, Alexandros Frantzis wrote: > 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? > Probably not as large as this year's refactoring in any case. Ofc, any user driver refactoring (and I can think already of a couple of things I'd like to see) is hindered by additional driver implementations, but I think it shouldn't be a blocker either. > 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? > I'm only giving my opinion here, I'd suggest to try and see how it goes. Note that IMHO you'd probably be better with someone willing and dedicated to reviewing the changes, rather than hope that review will happen by chance or by the maintainer. In the same way, it would also probably help if you are ready to assume maintainership of the module from the beginning, or if someone (else than the Wine maintainer) is. Cheers, -- Rémi Bernon <rbernon(a)codeweavers.com>

Dec. 16, 2022

Re: Why is vkd3d an extra projekt?

by Zebediah Figura

On 12/12/22 15:42, Fabian Maurer wrote: > Is that because it is reusable as standalone library? Just curious, because > it's the only library in Wine that is a separate project. FWIW, this isn't really true either. There are several other libraries that expose an API near-identical to win32, but aren't part of wine itself. In particular FAudio, Samba's NetAPI, and (in a somewhat looser sense) Mono come to mind.

Dec. 13, 2022

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

by Alex Henrie

On Tue, Dec 13, 2022 at 2:40 AM Rémi Bernon <rbernon(a)codeweavers.com> wrote: > > 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? > > 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. Ah, so it puts the "direct" in "DirectInput" ;-) In all seriousness, that was a very helpful explanation. Thank you! -Alex

Dec. 13, 2022

Re: git pull --rebase upstream ?

by Alex Henrie

On Tue, Dec 13, 2022 at 3:07 AM Gerald Pfeifer <gerald(a)pfeifer.com> wrote: > > These days I find myself spending more time wrestling with Git/Gitlab than > it takes me to create and test a patch. > > So I am keenly interested to help improve > https://wiki.winehq.org/Git_Wine_Tutorial#Creating_a_fork_on_Gitlab :-) > > > Here is the first item: I ran > > # git clone git(a)gitlab.winehq.org:gerald/wine.git > # git remote add upstream https://gitlab.winehq.org/wine/wine.git > > followed by > > # git pull --rebase upstream > > following https://wiki.winehq.org/Git_Wine_Tutorial#Creating_a_fork_on_Gitlab > > And there is where the instructions fail as follows: > > # git pull --rebase upstream > From https://gitlab.winehq.org/wine/wine > * [new branch] master -> upstream/master > * [new branch] oldstable -> upstream/oldstable > * [new branch] stable -> upstream/stable > You asked to pull from the remote 'upstream', but did not specify > a branch. Because this is not the default configured remote > for your current branch, you must specify a branch on the command line. > > > It appears the invocation should be shown as > > # git pull --rebase upstream master > > instead? Yes, that looks like a mistake. > PS: I'd volunteer to update the Wiki accordingly if confirmed, alas my > wiki.winehq.org account (GeraldPfeifer) does not appear to exist any > longer? And creating a new one is not possible? We could certainly use more wiki editors. Last I checked, Rosanne was the one to ask about account creation. Rosanne, could you please create a wiki account for Gerald? -Alex

Dec. 13, 2022

Re: Why is vkd3d an extra projekt?

by Giovanni Mascellani

Hi, Il 12/12/22 22:42, Fabian Maurer ha scritto: > > 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. > Yeah, that's the main idea, as far as I know. Any Linux or macOS application that wishes to use D3D12 or any compiler in the vkd3d-shader library can do so without having to depend on the whole of Wine. > 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? > While Wine ships with a convenience copy of vkd3d that is regularly (though not at every commit) updated, you are not bound to use that one. You can either copy a more recent version of vkd3d in Wine just before building it, or building vkd3d independently as a PE module and then using it within Wine (that's not really trivial, but see docs at https://wiki.winehq.org/Building_a_MinGW_WoW64_Wine_with_a_custom_vkd3d_bui…) Also, many prominent downstreams of Wine, like Proton, automatically keep vkd3d more up-to-date, or even include patches that are not yet accepted in the official vkd3d repository. My personal point of view is that "regular" versions of Wine (i.e., those that are not x.0) are not necessarily meant for an end-user. They are rather development snapshots taken every two weeks of whatever happened to be in the Wine repository at that time. Stable yearly x.0 releases are better tested and regressions are fixed, so it's what end users should use. For that case, vkd3d is released just before the code freeze, so that it is as up-to-date as possible in the stable release. My two cents, Giovanni.

Dec. 13, 2022

git pull --rebase upstream ?

by Gerald Pfeifer

These days I find myself spending more time wrestling with Git/Gitlab than it takes me to create and test a patch. So I am keenly interested to help improve https://wiki.winehq.org/Git_Wine_Tutorial#Creating_a_fork_on_Gitlab :-) Here is the first item: I ran # git clone git(a)gitlab.winehq.org:gerald/wine.git # git remote add upstream https://gitlab.winehq.org/wine/wine.git followed by # git pull --rebase upstream following https://wiki.winehq.org/Git_Wine_Tutorial#Creating_a_fork_on_Gitlab And there is where the instructions fail as follows: # git pull --rebase upstream From https://gitlab.winehq.org/wine/wine * [new branch] master -> upstream/master * [new branch] oldstable -> upstream/oldstable * [new branch] stable -> upstream/stable You asked to pull from the remote 'upstream', but did not specify a branch. Because this is not the default configured remote for your current branch, you must specify a branch on the command line. It appears the invocation should be shown as # git pull --rebase upstream master instead? Gerald PS: I'd volunteer to update the Wiki accordingly if confirmed, alas my wiki.winehq.org account (GeraldPfeifer) does not appear to exist any longer? And creating a new one is not possible?

Dec. 13, 2022