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