Wayland driver development - December 2021 update and next steps

[Alexandros Frantzis]

On Mon, Dec 13, 2021 at 01:18:49PM -0600, Zebediah Figura wrote:

Hi Zebediah,

Also, hi Alexandre (CCed), what are you thoughts about starting the
upstreaming process for the Wayland driver as outlined in my previous
email?

> On 12/12/21 19:13, Alexandros Frantzis wrote:
> > 
> > 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?

Generally speaking, being much more likely to benefit from future
developments is one of the advantages of the Wayland backend compared to
using XWayland.

More concretely, HDR is indeed one of the features that is currently
being worked on in Wayland upstream and is unlikely to be available on
X11.

Another such development, which can have performance benefits, is
allowing the compositor to dynamically notify clients when a different
surface format/modifier would lead to more efficient presentation, e.g.,
a format/modifier pair suitable for direct scanout vs texturing of
surface contents. This feature landed very recently as an official
Wayland protocol extension (dmabuf-feedback).

Concerning current rendering performance, I can't really comment
concretely without performing more controlled and broad testing. There
is the potential for some improvement by virtue of removing a whole
layer from the stack, but I think that taking advantage of Wayland
specific features (e.g., the aforementioned dmabuf-feedback) is more
likely to have a notable effect. For what is worth, I haven't personally
seen any noteworthy differences, but testing and optimizing performance
hasn't been my focus so far.

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

Thanks, looking forward to any feedback!

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

This is indeed a complication, but as proposed by Jacek, the Wayland
driver can be on the front line of the transition, and perhaps this
could help exercise all the new infrastructure early with little risk to
the more stable drivers.

Thanks,
Alexandros