Wayland talk at FOSDEM

Thu Dec 7 21:56:49 UTC 2017

Hi Pekka,

2017-12-07 (木) の 09:56 +0200 に Pekka Paalanen さんは書きました:
> On Tue, 05 Dec 2017 16:46:41 +0200
> Philipp Kerling <pkerling at casix.org> wrote:
> 
> > Hey everyone,
> > 
> > I've been thinking about submitting a Wayland-themed talk to the
> > FOSDEM
> > graphics devroom [1] and wanted to check with the community if
> > anyone
> > else has considered this or another Wayland topic and whether you
> > think
> > it would be a good idea™.
> > 
> > What I would want to talk about is a beginner's introduction to
> > Wayland
> > from the client perspective. I think that resources on this (and on
> > Wayland in general to be honest) are quite scarce and that I could
> > pass
> > on some of the knowledge I have gained by implementing native
> > Wayland
> > support in Kodi this way.
> 
> Hi,
> 
> that sounds like a good idea.
Thanks!

> 
> > This would include stuff such as:
> >  * Wayland architecture
> >     * Comparison with X
> >     * Security architecture
> >     * Limitations: What is not possible with Wayland (currently)
> 
> Please underline that many things are wanted and the only reason they
> are not there yet is because they have not been worked on enough to
> produce a Waylandish solution and reach a concensus, not because they
> are somehow "banned". :-)
Good point since you hear from time to time that Wayland "forbids"
this-and-that and therefore is evil ... I'll definitely keep it in
mind. Even so, I guess it is a quite safe bet to e.g. say that
accessing the buffer contents of all other applications without any
user authentication will not be a feature of mainstream Wayland
compositors anytime soon.

> In some cases, the Waylandish solution to produce an end-user feature
> may be very different from what has traditionally been done. In some
> other cases, a solution might be better or already exist outside of
> Wayland.
Yes, the problem lies mostly in the expectation that things will work
just like they did with X.

> 
> >     * Difference between core and extension protocols
> 
> This is a bit hazy to me as well, depending on at what level you are
> looking to use Wayland. Only wl_display, wl_registry and wl_callback
> interfaces are not extensions, strictly speaking. What extensions are
> mandatory depends on the target environment. Technically, e.g.
> wl_compositor is an extension and not mandatory, but it's hard to
> find
> a use case without it.
I'd have argued that the wayland.xml shipped with wayland is the "core"
protocol and wayland-protocols + all other stuff are "extensions." Is
that a reasonable assumption or should I be more careful about the
wording here? In any case, I guess it makes sense to mention that
Wayland is not only built for traditional desktop environments, even if
that is what I'll be focusing on in the talk.

> So it kind of depends on your definition of "Wayland". Purely IPC? A
> graphical output protocol? A windowing protocol with input? A desktop
> window system protocol?
> 
> Maybe giving a definition for "Wayland" would be a good way to start?
Is there an officially accepted one? :-)
My personal stance would be: Windowing protocol definition + ecosystem
(C libraries, scanner, extension protocols that among other things
cover the traditional desktop use case)

> >     * Global registry
> >     * Relevant documentation and resources
> >  * Why you should not be writing a Wayland client yourself (aka use
> >    toolkits if possible)
> 
> +1
> 
> >  * Relevant compositors to test on and how to use nested mode
> >  * Basic client programming
> >     * Protocols needed to get a surface on screen (wl_compositor,
> >       wl_surface, wl_shm, wl_shm_pool, wl_shell, wl_shell_surface)
> 
> Mind that wl_shell is finally officially deprecated with the
> stabilization of xdg-shell.
I'm not sure how to handle that yet. Technically, it would make sense
to directly introduce xdg-shell and skip the wl_shell details. But
realistically speaking it will still take some time until there is
sufficient compositor support and you can get by with an application
that does not support anything but the xdg_wm_base global.
One alternative could be to introduce xdg-shell unstable v6 instead of
wl_shell and tell people to switch to xdg-shell stable at some point?
I'm not sure the latest KDE stable release supports xdg-shell unstable
v6 though. Last time I checked KDE only had v5 in stable.

> >     * Seats and input
> >        * Keyboard: wl_keyboard and libxkbcommon
> >        * Mouse: wl_pointer and libwayland-cursor for cursor
> > handling
> >     * xdg_wm_base
> >     * Window decorations
> >     * EGL
> > 
> > Possible extensions/replacement topics:
> >  * Bindings (just mention: C++, D, Java, Rust)
> >  * Vulkan (I think EGL is more relevant at the moment)
> >  * Some more extension protocols such as pointer-constraints and
> >    relative-pointer (relevant e.g. for games)
> >  * Subcompositing
> >  * ...
> > 
> > I would not include:
> >  * Details of libwayland API (e.g. proxy wrappers)
> 
> I suppose one detail might be worth mentioning: client projects are
> expected to run wayland-scanner (or equivalent) as part of their
> builds. The only exception are the interfaces in wayland.xml, but
> it may be a surprise to realize that wayland.xml is the exception,
> not
> the rule.
Thinking about it, there is probably more that should be mentioned,
like common pitfalls. From the back of my mind:
 * Don't forget to flush... (I learned this the hard way)
 * Don't create lots of objects that have no destructor request (like
   wl_registry)
 * Be careful with multithreading
 * Use the prepare_read API for poll/read
Anything else?

Best regards,
Philipp

> 
> >  * Every extension protocol or even core protocol object just for
> >    completeness
> >  * Historical baggage such as xdg_shell v5
> >  * EGL/Mesa internals
> > 
> > I'd love to hear any comments/suggestions you might have and
> > generally
> > what kind of topics people would be interested in.
> > 
> > [1] https://lists.freedesktop.org/archives/wayland-devel/2017-Novem
> > ber/035880.html
> 
> 
> Thanks,
> pq