[RFC] Wayland driver development update

[Zebediah Figura (she/her)]

On 3/1/21 7:49 AM, Gabriel Ivăncescu wrote:
> On 28/02/2021 01:51, Zebediah Figura (she/her) wrote:
>> On 2/26/21 11:23 AM, Giovanni Mascellani wrote:
>>> Hi,
>>>
>>> Il 24/02/21 09:34, Alexandre Julliard ha scritto:
>>>> I'm not opposed in principle to having a Wayland driver upstream. In
>>>> fact I started writing one myself many years ago... It got stalled when
>>>> I realized there was essentially no way to do decent window management,
>>>> and that the best we could do would be the equivalent of X11 desktop
>>>> mode, where we manage the windows ourselves. I don't have the
>>>> impression
>>>> that the situation has improved in the meantime, or that there is any
>>>> interest in improving it.
>>>
>>> I have very little knowledge of how Wayland compares with X11 from the
>>> protocol point of view. Could you please elaborate a little bit on what
>>> is missing in Wayland? The only thing I've heard about so far is
>>> changing a window's absolute position. Can be annoying, but it's not a
>>> terrible issue...
>>>
>>> My understanding is that X11 is basically in maintenance mode ad
>>> libitum, so as time passes it will lack new features that will get added
>>> only to Wayland. Eventually people might find that using
>>> Wine-with-Wayland, while having problems because Wayland is not perfect,
>>> is still better than Wine-with-Xorg or Wine-with-XWayland, because the
>>> latter do not support the features they like. So I think that having a
>>> Wayland driver would be a good service to at least some users.
>>>
>>> On the other hand I don't think, as Zeb was suggesting, that if there is
>>> a Wayland driver, then it should have higher priority than X11. It's
>>> totally sensible to ship it, but require the user to set it as preferred
>>> in winecfg or some other way if they want to use it. Users who believe
>>> that direct Wayland's advantages outweigh its disadvantages will use it,
>>> and the others will not.
>>
>> As a general rule putting patch sets in wine-staging that aren't
>> enabled by default is pointless, inasmuch as wine-staging is only a
>> testing ground. If we're going to root out all the bugs, I'd like the
>> patch set to be enabled by default for all users, not just the ones
>> that know about it and want to use it.
>>
>> That doesn't necessarily mean that the driver should be the default in
>> upstream wine, though.
>>
>>>
>>> My 2 cents, Giovanni.
>>>
>>>
>>
> 
> Doesn't wine-staging have a specific tab in winecfg for experimental
> options that aren't on by default? CSMT used to be one of those way back.

Yes. However, this is a decision that the current wine-staging
maintainers made, and some patches are effectively grandfathered in
because we don't have the time to change them.

(There's also the GTK theming patch, which makes more sense to be
optional since it's a matter of user preference. Really that should be
the only thing on that tab...)

-------------- 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/20210301/b5a9f07d/attachment.sig>