Re: Wayland backend update

[Ivan Vučica]

On Sun, Jan 12, 2020 at 9:23 PM Ladislav Michl <ladis@linux-mips.org> wrote:
>
> Keep in mind that it will break any git-bisect plumbing people might run
> on libs-back as you are intentionally creating point in history, where
> things even do not compile.

I haven't thought about it that way before. This is worth considering,
but I have not been strict about it in personal projects, and I'm not
sure people have been strict about it here.

I've treated it as follows: Git makes it a valid workflow to create
chains that are not actually continuously functional; semantics and
history may matter more.

> Unfortunately I had to create GitHub account, but I'm happier with mail
> and patches.

I do not have a good workflow for mail+patches; if I would switch to
mutt completely, it might be easier, but I don't use just mutt.

Viewing diffs completely locally is also painful. Inline reviews with
patches are much harder for me (as it becomes hard to view changes in
full context). Github and its near-clones are not ideal for code
review and collaboration, but for someone that hasn't dealt with mail
patches, switching to them would be hard.

However: I am still happy to accept them, I will just apply them to my
local tree + push them somewhere (e.g. Github) as a reviewable chain.

> Btw, in case you are not aware of https://wayland-book.com/ I recommend
> reading it. It is certainly worth $10, but you can read it for free if
> you are working on open-source project (condition met :)).

Thank you for the reference to the book. I was happy to buy this to
support Drew DeVault, despite this being for work on free software.

Thank you also for the updates: I certainly wouldn't have known where
to begin the API updates you've done in the fifth patch. It's good
that I have the updated environment set up now, so I will be able to
easily get back into debugging things.

Primarily to more easily review what changed, I've opted to create a
PR: https://github.com/gnustep/libs-back/pull/17


I've already hit what's likely a useful problem to spot: I'm getting
the error here in _initWaylandContext in WaylandServer.m:

    if (!wlconfig->compositor || !wlconfig->wm_base) {
        [NSException raise: NSWindowServerCommunicationException
                    format: @"Unable to get compositor"];

(In context: 
https://github.com/gnustep/libs-back/pull/17/commits/696ab6353488c203f4db68f1d62c9fd437bc0a6f#diff-659b64781af0473e6aa3f84a89e9ef8eR760
)

I understand that these are both supposed to be registered from the
registry in the callback 'handle_global' (which maybe we should rename
into 'registry_handle_global', as is in the book). I've modified this
into two checks, and what's failing is wm_base.

I've looked at SDL 2's source code and it looks like they support
multiple shells, xdg_wm_base being only one of them (they call it just
'xdg'):

  368     } else if (strcmp(interface, "xdg_wm_base") == 0) {
  369         d->shell.xdg = wl_registry_bind(d->registry, id,
&xdg_wm_base_interface, 1);
  370         xdg_wm_base_add_listener(d->shell.xdg, &shell_listener_xdg, NULL);
  371     } else if (strcmp(interface, "zxdg_shell_v6") == 0) {
  372         d->shell.zxdg = wl_registry_bind(d->registry, id,
&zxdg_shell_v6_interface, 1);
  373         zxdg_shell_v6_add_listener(d->shell.zxdg,
&shell_listener_zxdg, NULL);
  374     } else if (strcmp(interface, "wl_shell") == 0) {
  375         d->shell.wl = wl_registry_bind(d->registry, id,
&wl_shell_interface, 1);

I'm running Weston from Debian buster (current stable). It seems to be
Weston 5.0.0. And this Phoronix article:
https://www.phoronix.com/scan.php?page=news_item&px=Weston-6.0-XDG-Shell-Stable
says that only Weston 6.0 support 'xdg-shell stable'. I suspect this
is exactly what we need, as xdg_wm_base functions seem to be defined
in /usr/share/wayland-protocols/stable/xdg-shell/xdg-shell.xml on my
machine.

Ladislav, do you think it's worth supporting other shell APIs? Are you
interested in writing this?


However, that's not the only problem I've run into. The second one is
more worrying. Even after biting the bullet and installing Weston 6
from Debian testing, I'm getting 'xdg_surface@12: error 3: xdg_surface
has never been configured' from the client app (and from weston,
'[21:59:20.865] libwayland: error in client communication (pid
99330)'. Rebuilding the protocol source/headers doesn't help. I've
checked and made sure that all Wayland and Weston-related libraries
that I could find are up to date. Apps I tested are Calculator.app
from GUI examples and SystemPreferences.app.

This sounds like the surface has in general not been 'configured':
https://patches.videolan.org/patch/20875/

I'll stop looking at this for today, as it's gotten late. Do you have
any idea what might be going on?