Wayland talk at FOSDEM

Thu Jan 11 15:02:57 UTC 2018

On Wed, 10 Jan 2018 14:41:46 +0100
Philipp Kerling <pkerling at casix.org> wrote:

> Hey Pekka,
> 
> thanks for your input - further comments below. The talk has been
> accepted, but shortened to 25 min due to the amount of talks that had
> been submitted overall. This means that I will have significantly less
> time than I thought and most of the advanced stuff will have to go I'm
> afraid, but I'll still try to give a comprehensive overview within the
> timeframe I'm given.
> 
> 2017-12-08 (金) の 10:39 +0200 に Pekka Paalanen さんは書きました:
> > On Thu, 07 Dec 2017 23:56:49 +0200
> > Philipp Kerling <pkerling at casix.org> wrote:
> >   
> > > 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.    

> > > > >     * Difference between core and extension protocols    

Maybe there is actually not so much a difference to emphasize but more
of what programs tend to require.

> > > > 
> > > > 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.  
> > 
> > The split is not so clear. The most obvious example of the contrary
> > is
> > wl_shell extension which is in wayland.xml, but is not considered
> > "core". E.g. IVI environment using Wayland does not use it.  
> I think I've raised this point in #wayland before, but part of the
> problem seems to be that wayland.xml does not explicitly spell out (in
> most cases) what is considered "core" at the moment and what not. You
> can sort of infer it from the description, but it's not very clear imo.
> As you said though, protocols depend heavily on the environment Wayland
> is used in. What do you in general think about making a recommendation
> such as "All compositors MUST implement wl_compositor, wl_shm, etc.
> Desktop compositors SHOULD additionally implement this and that."? That
> would at least give client apps some information on what they can
> expect to be there.

Rather than giving "must" and "should" lists, maybe it'd be better to
list what most common toolkits expect: what do you need to get a GTK+3
app up, for example.

> > wl_shell is a "shell extension", which is a category of Wayland
> > extensions. With Wayland core protocol and wl_compositor, you cannot
> > actually show a window. A shell extension is necessary to tell the
> > compositor what it should do with a wl_surface, i.e. assign the
> > wl_surface a role. Wayland.xml does have some interfaces which can be
> > considered core and assign surface roles, but they are not enough to
> > have a working application. An example of such role is the pointer
> > cursor.
> > 
> > The other global interfaces (advertised through wl_registry) in
> > wayland.xml are quite "core" I think, but it's not unthinkable to
> > imagine to replace them in the future, should the need arise.
> > 
> > That is actually a design feature of Wayland: (almost) everything is
> > an
> > extension. As a corollary, everything can be deprecated and replaced
> > with something else if really necessary, forming a new "core". The
> > old
> > stuff can eventually be dropped completely, except for the interfaces
> > that exist without having to find them in wl_registry.
> > 
> > For instance, wl_output could be replaced with something better, but
> > the replacement would be a hard one because wl_surface references
> > wl_output and practically everything references wl_surface. It would
> > not be easy to drop wl_output. So I guess that could be one
> > definition
> > of "core", what you could replace without essentially throwing out
> > everything we have.  
> Yeah, that could be a working definition. With that notion of "core"
> protocols, what would your wording be for the distinction between
> wayland.xml as shipped with wayland vs. stuff in wayland-protocols/all
> external protocols not part of wayland.xml?

That's a tough question. With the above definition for "core", the core
set can change: new extensions may become de facto required. Everything
is an extension, nothing else comes to mind on that level.

> > However, for your presentation, I imagine you would like to settle
> > for a
> > simplification. Too many details will cloud the message. So it would
> > be
> > fine to say that core is wayland.xml without wl_shell, for instance.
> > Maybe also add that not all of core is mandatory for all environments
> > either.  
> Sounds OK. It should be fine if I get the message across that it is
> really environment-dependent and desktop WM usage is just one of the
> possible environments (the one I'll talk about though). That makes it
> clear that the scope of Wayland is broader and might explain some of
> the peculiarities of the protocol.

Right. Aside from desktop, there are non-desktop use cases that still
use a traditional display server concept, but then there are even
application-internal uses for Wayland. For instance, a web browser
while being a single application can internally be split into several
processes that use Wayland to talk to each other. A benefit of using
Wayland is that you can easily leverage EGL without needing a
connection to a "real" display server, and the graphics driver
stack takes care of the details of buffer sharing between processes.

> > > > 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.  
> > 
> > Yeah, the timing is perfectly awkward here. ;-)
> > 
> > If you want to give hands-on examples of how to write the code, then
> > I'd recommend xdg-shell unstable v6. The migration to the stable
> > version is almost a sed job, I believe.  
> Yup, recently done it for Kodi. Real C code would be too bulky to show
> during the talk, but maybe I'll show protocol interactions. I'll do
> that with unstable v6 then and briefly mention that one can switch to
> the stable version easily once it's out there in the compositors.

The stable version is out with wayland-protocols 1.12! \o/

Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20180111/5fc7611e/attachment-0001.sig>