[RFC] Announcing Wayland driver development

[Zebediah Figura (she/her)]

On 12/16/20 2:44 AM, Julian Rüger wrote:
> Hi Alexandros,
> 
> first of all, congratulations and thanks for your work, this sounds very
> cool!
> 
> Disclaimer:
> 
> I'm little more than a curious observer of the larger developments in
> Wine, but I've been around for a while and have picked up a few things.
> Still, you should probably take anything someone who actually
> understands the code says over my ramblings ;)
> 
> 
>> My first question to the Wine community is how complete the driver
>> should be before being considered for inclusion. Is the current Wayland
>> driver state enough?
> 
> The most important and probably trickiest order of business is to
> convince Alexandre you're going the "Right Way" (tm), from an
> architectural standpoint.
> I can't really say if your current progress is enough to gauge that, but
> I think it is.
> 
>> If there is interest, I was hoping to get the
>> driver in earlier rather than later, in an experimental capacity, in
>> order to provide a single, official point of development for people
>> wanting to contribute.
> 
> You should talk to our tireless and competent staging developers,
> Zebediah Figura and Alistair Leslie-Hughes about that.

That's probably about right. I would like to be sure that a Wayland
driver will be accepted upstream in some form or another before we take
it—I don't want to maintain any patch set in wine-staging forever, but
an entire graphics driver least of all.

In particular I've seen a lot of concerns about the long list of things
Wayland can't support. Window positioning is one, but not the only by
far. See also [1] (not that I can personally verify the veracity of any
of these; I don't work with window managers).

[1] https://bugs.winehq.org/show_bug.cgi?id=42284#c17

> 
>> My second question is about the best way to move forward with
>> upstreaming. The code is currently split between just a few commits,
>> mostly as a result of the experimental nature of this effort, and also
>> because I used existing code from winex11 and wineandroid as my starting
>> point. I would like to split this into smaller commits to make it more
>> review-friendly for the mailing list. I was thinking of splitting by
>> user32 function (and internal dependencies), but since this is going to
>> be an artificial split, I am open to other ideas to make reviewers'
>> lives easier.
> 
> Again, I'm no expert, but from what I've seen, a good approach would be
> to start with a stubbed skeleton driver and build it up from that, piece
> by piece, in small logical steps.
> 
> The rules for commits are basically:
> * leave wine in a consistent and working state after every commit!
> * don't introduce dead code
> * have meaningful commit messages
> 
> (* normally tests are very important, though I'm not sure how much that
> applies in this case or how to go about failing tests under your driver)
> 
> Read the wiki for more info, notably
> https://wiki.winehq.org/Submitting_Patches
> and most of https://wiki.winehq.org/Wine_Developer%27s_Guide
> though some stuff may be out of date.
> 
> FWIW, I recommend looking at the commit history, how past big changes
> were introduced i.e. the Mac driver, maybe the DIB-Engine (although that
> was quite long ago and a lot has changed since)
> 
> Better wait for advice from actual developers here ;)

I think you've described our development guidelines pretty well ;-)

It's probably worth pointing out that "leave wine in a working state" is
a bit less important when it comes to things like introducing a new
driver, at least with respect to that driver itself. You definitely
shouldn't break anything when Wayland isn't used, and ideally something
working in Wayland from an earlier patch shouldn't be broken by a later
one (e.g. the style of development that produces lots of "fixup earlier
patch" patches is frowned upon), but of course it's expected that the
driver won't be working on Wayland in every patch.

> 
>> Looking forward to your feedback and questions!
> 
> I hope that helps a bit, and that when the experts ship in they don't
> have to repeat the basics.
> 
> This is about all I know, sorry I can't really be more specific. Please
> correct anything I got wrong!
> 
> 
> Best,
> Julian
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x0D9D358A07A17840.asc
Type: application/pgp-keys
Size: 1769 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20201216/a71a66c6/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20201216/a71a66c6/attachment-0001.sig>