Wayland driver development - December 2021 update and next steps

[Zebediah Figura]

On 12/12/21 19:13, Alexandros Frantzis wrote:
> On Fri, Dec 10, 2021 at 06:46:46PM -0600, Zebediah Figura wrote:
>> On 12/10/21 14:30, Paul Gofman wrote:
>>> On 12/10/21 23:05, Alexandros Frantzis wrote:
>>>> On Fri, Dec 10, 2021 at 09:44:23PM +0300, Paul Gofman wrote:
>>>>> Hi Alexandros,
>>>> Hi Paul,
>>>>
>>>> Thanks for the feedback!
>>>>
>>>>> On 12/10/21 20:56, Alexandros Frantzis wrote:
>>>>>> In the mailing list discussions earlier this year it was recommended
>>>>>> that we go through wine-staging as a stepping stone towards upstream.
>>>>> Do you recall which part of the prior discussion made such an
>>>>> impression?
>>>>> Staging used to be a testing ground for some patches, yes, but
>>>>> as far as I
>>>>> know no patchset was ever easier to get accepted upstream because of its
>>>>> presence in Staging. Nor that ever was a requirement for any
>>>>> patches to get
>>>>> upstream. So in this regard it would be probably more interesting to get
>>>>> some opinion if the direction the things are being implemented now is
>>>>> acceptable for upstream and Staging probably can't help with that.
>>>> My understanding was based on a discussion earlier the year, see for
>>>> example the thread at:
>>>>
>>>> https://www.winehq.org/pipermail/wine-devel/2021-February/181667.html
>>>>
>>>> Of course, the circumstances have changed since then, and it could be
>>>> the case that going through wine-staging is not the most productive way
>>>> forward anymore.
>>>
>>> Yeah, I see... I don't think anything changed. I think it would be best
>>> if Zebediah would comment directly but I suppose the meaning of her
>>> older comment is that she's not against seeing it in Staging if there is
>>> a clear understanding that something along the lines of present
>>> implementation can go upstream. Maybe it might be a good way for some
>>> riksy patches to get some prior testing before the patches get finalized
>>> and go upstream but (correct me please if I am wrong) I don't think
>>> upstream maintainers recommended patches to go to Staging first or
>>> otherwise indicated that it is a shorter or preferred way for patches to
>>> go upstream.
>>>
>>>
>>
>> I don't think I'd assert that patches, however large or small, *should* go
>> through wine-staging as a "stepping stone" to upstream. I wouldn't see
>> wine-staging as an end goal or even a necessary step. I'd rather look at it
>> as a tool; essentially a way of getting broad testing. In essence, the same
>> reason that staging branches exist in any project.
>>
>> Thus I'm not sure that the sheer existence of a patch has helped its
>> credibility upstream—it might have happened, but I haven't heard of it. On
>> the other hand, I can name several patches which have benefited greatly from
>> user testing while in wine-staging, such that a lot of bugs were flushed out
>> by that time. ntdll-Junction_Points, Rémi's raw input patches, Andrew's
>> winepulse timing rework, and my own server-default-integrity and
>> ntdll-NtAlertThreadByThreadId are several such cases.
>>
>> I can't speak for Alexandros, but if this is his goal in proposing the
>> driver for wine-staging, I don't have any objections, at least on those
>> grounds. And, frankly, when we're talking about an entire USER driver, I can
>> anticipate that the testing that wine-staging provides would be quite
>> useful.
>>
>> I do have some other thoughts, but I'll have to defer them for a separate
>> email.
> 
> Hi Zebediah (and Paul)!
> 
> The primary reason for proposing the driver to wine-staging is that I
> was under the impression (which seems to be mistaken), that there was a
> strong recommendation to do so for this particular patchset, before
> proposing to upstream.
> 
> As you mentioned, wine-staging could be a useful tool for broader user
> testing, which is indeed one of my goals. However, I think such testing
> could also be enabled by having the driver in upstream and allowing
> users to easily opt in at runtime (see my proposal below).
> 
> Of course, as Paul mentions, a prerequisite for upstreaming is that
> upstream has decided that the direction of the driver is acceptable.
> This has been been one of my primary goals during the whole development
> effort, by implementing a wide range of features, leading to a quite
> capable driver at this point (within noted Wayland constraints). A big
> part of the work since the last report also aims to facilitate such an
> assessment of direction, by splitting and structuring the commits to
> make them more easily digestible and reviewable.
> 
> Perhaps wine-staging could play a role in the assessment of direction,
> but, then again, the whole driver has been available and easily
> buildable from my repository from the start, for anyone to examine and
> try out.
> 
> Given the above, it seems to me that the benefits of wine-staging could
> be gained through a different path, and in combination with the concerns
> about the overall cost of maintaining such a big patchset in
> wine-staging, I am now leaning more towards a direct-to-upstream
> approach.
> 
> My proposal would be:
> 
> 1. Establish that the direction of the driver is acceptable for
>     upstream. Do people think we haven't reached that point yet (and,
>     if so, how can we get there)? Who could provide a final
>     acknowledgment?

Ultimately the decision is up to Alexandre. Based on his prior response 
it doesn't seem out of the question, but it also seems like it depends 
on whether the Wayland driver is better in any concrete sense than using 
the winex11 driver plus XWayland. E.g. does it provide access to 
features only available via Wayland? (Are there any? I vaguely remember 
that HDR is one, because apparently that one was too hard to retrofit 
into X11.) Or better rendering performance?

Not being excessively ugly is probably also a prerequisite. I haven't 
yet got a chance to review the code to make a guess of this (although 
I'm planning to), although personally I don't have a lot familiarity 
with USER drivers and I wouldn't trust my judgement anyway. Jacek or Huw 
might be able to give a better review in this respect.

> 
> 2. After the 7.0 freeze, start upstreaming the driver. As noted, I
>     structured the commits in the 'wayland' branch specifically for ease
>     of review and upstreaming, so the rough plan is that I will be
>     proposing chunks of commits from that branch (mostly in order) until
>     all of it is upstream.
> 
> 3. The Wayland driver will have a lower precedence than the X11 driver,
>     so X11/Xwayland will continue to be used by default when available.
>     This will make it easy for distributions to include the Wayland
>     driver in their normal package builds without compromising their
>     stable user experience, while still allowing all users to easily
>     try the Wayland driver (e.g., by unsetting DISPLAY). This would
>     allow for broader testing compared to wine-staging.
> 
> 4. Development continues, with the benefit of being in upstream, which
>     is more likely to attract additional contributions, compared to just
>     being a patchset in wine-staging.

Yes, this sounds quite reasonable to me ;-)

Although upstreaming it in the middle of the win32u work may be an 
interesting proposition.