[RFC] Wayland driver development update

[Zebediah Figura (she/her)]

On 2/23/21 10:16 AM, Alexandros Frantzis wrote:
> 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.
> 

I fail to understand this statement. Wayland is a competitor, or at 
least a replacement, of X. It is used in the same ways, on the same 
distributions, and it was explicitly designed as such. That may not 
matter to Wine as an isolated project, but in my view we are not—we are 
part of an open source ecosystem, and should care about what happens to 
the libraries and protocols that we depend on.

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

In terms of avoiding bug reports, perhaps. In terms of proving that 
Wayland is not as bad as an idea as I fear, we really should compare it 
to native X11. Wine has to support a lot of things; if Wayland can't 
support them (or can't support them except with a hacky and WM-dependent 
interface) it's not a sufficient window protocol.

(Frankly, it's even possible that a user will upgrade from one Ubuntu 
LTS to the next and find that suddenly wine isn't working as well as it 
was before, because they've been quietly switched from X11 to Wayland. 
At that point it wouldn't matter that XWayland provides no better of an 
experience.)

> 
>> * 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.

Yes, and if Wayland didn't have such glaring problems I'd fully agree. 
But at this point it's not clear to me that Wayland can (ever!) provide 
"the best experience possible" for those distributions already using it, 
or that it's worth what will probably be a lot of ugly code on our part.

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