[RFC] Wayland driver development update

[Alexandros Frantzis]

On Fri, Feb 19, 2021 at 10:55:20AM -0600, Zebediah Figura (she/her) wrote:
> Hello Alexandros,

Hello Zebediah,

Thank you very much for your response!

> On 2/19/21 9:16 AM, Alexandros Frantzis wrote:
> > In previous discussions there were some concerns about accepting the
> > Wayland driver into staging, unless there was more confidence that it
> > would eventually be accepted upstream. What's the best way to get an
> > answer to this question of (eventual) upstream acceptance? Even in this
> > somewhat experimental state the driver is viable for many use cases.
> > What would be required to drive this effort forward on the path to
> > staging and, later, upstream inclusion?
> 
> Having a positive answer from Alexandre (viz. that a Wayland driver is 
> desirable) is one thing, and would be necessary for me to agree to 
> maintain the driver, but I'd also like to see the following before 
> accepting anything into wine-staging:

Alexandre (Cc-ed and hi!), it would be great if we could get some input
about your views on the upstream inclusion of a Wayland driver.

> * The driver should be at least as feature-complete as the X11 driver. 
> Ideally, it should be *more* feature-complete. That includes not just 
> support at the protocol level, but actual implemented support across all 
> major window managers. There's no point accepting the driver into 
> wine-staging if it's not enabled by default, and I want to deal with as 
> few bug reports as I possibly can. This also helps prove that the driver 
> is not a bad idea.
>
> * A promise from the developers to respond promptly to all bug reports 
> concerning window management (provided, I guess, that the same bug 
> reports don't occur with the X11 driver).

The Wayland driver is not, in my view, a competitor to the X11 driver,
but an independent entity, targeting an entirely different platform with
its own capabilities and constraints. The existence of XWayland muddies
the waters a bit, and one can certainly consider the Wayland driver as a
competitor to the X11 -> XWayland path. This is a path which, as noted
previously [1], provides fewer features than direct X11.

Perhaps it would make sense to use X11 running with XWayland as the
bar to compare against in this case?

> * A promise from the developers to deal with any difficult rebase work. 
> Rebasing is normally our responsibility as wine-staging maintainers, but 
> for large and difficult patch sets we do request that the author be on 
> hand to maintain their own work.
> 
> * A promise from the developers to try to upstream the driver after it 
> is introduced into wine-staging. I will *not* be upstreaming the driver 
> myself, and I do *not* intend to maintain it forever. Please do not 
> treat wine-staging as an end goal in itself—it is a testing ground and 
> nothing more.

I fully agree with the above.

> Even with all that, I'm not thrilled about the driver. I recognize I may 
> not have a choice in the matter, and I recognize I'm not an X11 
> developer and thus lack significant context, but I don't like the way a 
> feature-incomplete protocol has been forcibly pushed on applications 
> with the apparent intent of quickly replacing and removing its predecessor.

This is certainly a big discussion with reasonable arguments from both
sides, depending on the goals and trade-offs that one considers
important. Regardless of where one stands, though, the fact is that
Wayland adoption has been growing significantly, with some major
distributions already using it as their default display architecture,
and others planning to do so soon. 

This growth in adoption of Wayland as the default choice, coupled with
the significant reduction of development activity and thus the lack of
new features on X11/XWayland (e.g. HDR), means that a lot of people are
going to use Wine on Wayland-based desktops. I believe it would be in
the best interest of both Wine and Wayland to work on providing the best
experience possible by using a direct driver, instead of forcing users
to go through the impedance-mismatch layer of XWayland.

Thanks,
Alexandros

[1] https://www.winehq.org/pipermail/wine-devel/2020-December/178633.html