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 <la...@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.
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 ... #else 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: https://drewdevault.com/2018/07/29/Wayland-shells.html 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." and "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?