Wayland driver development - December 2021 update and next steps

[Alexandros Frantzis]

On Tue, Dec 14, 2021 at 06:32:00PM +0100, Alexandre Julliard wrote:
> Alexandros Frantzis <alexandros.frantzis at collabora.com> writes:
> 
> > 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:
> >> > 
> >> > 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.
> 
> I expect we'd want to test the new interface against the X11 driver,
> which is a known quantity. Then once this works correctly and the
> interface has stabilized, we can introduce a new driver using that
> interface. It doesn't seem to make sense to upstream a new driver at the
> same time as the driver interface is changing.
> 
> I think what Jacek was suggesting is that you adapt your driver to the
> win32u interface and track the upcoming changes, so that once win32u is
> ready and stabilized your driver is already making use of it, and can be
> upstreamed at that point without needing further changes.

Hi Alexandre,

Thanks for the reply!

My thinking related to the win32u changes was that I would perform as
much of the transition as possible before upstreaming (my understanding
is that a chunk of the work can be done already), and then keep close
track of changes as things progress. I agree that's not the same as
testing an established driver, but perhaps it could provide some early
feeback.

It seems that the feeling is that this would in fact complicate the
whole effort, in which case I am happy to continue tracking externally,
providing any related feedback and waiting until stabilization to
upstream.

Excluding the currently ongoing driver transition, i.e., let's assume it
was finished and the Wayland driver was up-to-date for it, what are your
thoughts about the proposed upstreaming plan for the Wayland driver?
Would you be willing to accept the driver upstream (assuming good
quality code etc) according to that plan?

Thanks,
Alexandros