Wayland talk at FOSDEM
ppaalanen at gmail.com
Thu Dec 7 07:56:22 UTC 2017
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  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.
that sounds like a good idea.
> 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". :-)
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
> * 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.
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?
> * Global registry
> * Relevant documentation and resources
> * Why you should not be writing a Wayland client yourself (aka use
> toolkits if possible)
> * 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.
> * 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
> * Every extension protocol or even core protocol object just for
> * 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.
>  https://lists.freedesktop.org/archives/wayland-devel/2017-November/035880.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the wayland-devel