discuss-gnustep
[Top][All Lists]
Advanced

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

Re: Wayland backend update


From: Ivan Vučica
Subject: Re: Wayland backend update
Date: Sat, 25 Apr 2020 19:33:59 +0100

Some updates, especially. for those who didn't follow
https://github.com/gnustep/libs-back/pull/17.

Fred and I have chosen to merge sooner rather than later. Despite the
rendering being ultra buggy (screenshots posted on the pull request
above -- floating wayland surfaces seem to be created even for backing
NSView surfaces, and are drawn on the screen), we'll likely merge the
backend in the current state so it can be iterated upon in the main
branch.

Besides the obvious, immediately visible bugs, there are a lot of
little things that we can and should change in the implementation. For
one, I think C structs might be overused, and I'd like to hand off
event handling to ObjC objects earlier even if the handlers have to be
a C class.

But, looking at the x11 subclass of GSDisplayServer, things are pretty
messy there, too, so I don't feel that bad about merging messy code --
I feel bad only about those bugs that I didn't get around to looking
at.

I am somewhat torn on whether this should be a separate displayserver
backend, however; in the typical GNUstep approach, it should, but with
GTK the actual "GDK" backend gets autodetected based on presence of a
Wayland environment, and can be overridden with an environment
variable. Should we perhaps build both X11 and Wayland displayserver
into the same lib, and switch between them at runtime, to match the
behavior of other toolkit libs?

On Mon, Jan 27, 2020 at 9:49 PM Ladislav Michl <ladis@linux-mips.org> wrote:
>
> > 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"


I've opted not to deal with this in the beginning, and simply require
the stable XDG Shell protocol.

I expect this is not going to be a problem for a new implementation
that we're launching in 2020.

>
> > 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've worked around this. Some details in the PR.

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


It sounds like things have at some point worked fine for you.

But everything is ultra messy for me ever since I got the
implementation not to crash. If you have a clear idea about what my
changes did to break the implementation, i.e. why there are floating
cairo surfaces all over the place, let me know. I have my suspicions
(WaylandCairoSurface likely shouldn't instantiate a wayland surface
for every cairo surface, but only do so on demand?) but I didn't get
to dig into this.



reply via email to

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