[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Wayland backend update

From: Ladislav Michl
Subject: Re: Wayland backend update
Date: Mon, 27 Jan 2020 22:49:43 +0100

On Sun, Jan 26, 2020 at 10:22:28PM +0000, Ivan Vučica wrote:
> On Sun, Jan 12, 2020 at 9:23 PM Ladislav Michl <address@hidden> 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.

Git itself (well, at low level) is just an object store, so "a valid
workflow" is whatever policy you mark as such :)

Anyway, I'm certainly not the one, who wants to decide how should
merge be done, especially when there is a lot to do before merge.

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

Fair enough, I'll learn to use github then.

> 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?

Eh, I've never seen any Wayland nor libs-back code before touching this,
so I'm certainly not qualified enough to anwer that question.

However, my messy work in progress contains something like this
#ifdef XDG_SHELL
static void
wl_shell_surface_on_ping(void *data, struct wl_shell_surface *shell_surface,
                         uint32_t serial)
but I've never tested #else branch and later found this blog entry:
with those notes interesting here:
"xdg-shell is currently the only shell whose protocol is considered stable,
and it is the shell which describes application windows."
"wl_shell, the now-deprecated original desktop shell of Wayland"

> 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 solved it similar way as above patch does. I'm using Debian unstable
running Gnome session and things just worked somehow here. But I was
unable to debug using xdg_popup windows for menus, etc. It always
crashed Gnome session. So I cross-compiled everything to embedded
targed and used Wayland-1.17.0 and Weston-7.0.0 and run into the
same issue as you.

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]