Wayland talk at FOSDEM

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

Hi Philipp

Yes. There are some more or less banned things, but I would tend to
think that they are a minority in numbers. "Without user permission" is
the main problem for most of the popular features that are not yet
standardised - the features are good, necessary and supportable, but
the main issue is how to expose them without compromising security and
without annoying users or asking users questions they cannot reliably
answer.

I believe it is actually quite likely that the solution to the
authentication problem is mostly outside of the scope of Wayland
protocol, but we would still need a working example in some environment
to be able to comfortably promote "privileged interfaces".

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

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.

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.

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.

Technically the definition of an extension is "it is advertised through
wl_registry".

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

That could be a nice definition.

I suppose what's on the website is all what we officially have. The
meaning of the name depends quite much on the context it is used in.

I think that a big part of Wayland is the architecture: desktop
environment and domain specific display servers, and applications doing
the drawing themselves; libwayland being essentially just an IPC shim.
Moving window management and compositing into the display server.

For the Wayland architecture to work to begin with, there have been
huge amounts of prerequisite work, kernel drivers with standardized
UAPIs for a start: DRM, KMS, evdev; not forgetting EGL and Mesa and
libinput, and kernel features like dmabuf. It has been a long road away
from display server specific hardware drivers.

The thing almost everyone new to Wayland gets wrong is they think that
Wayland is a display server. This leads to strange questions like "how
do I run wayland?", "where does wayland save logs?", etc. and of course
blaming "wayland" for bugs or misfeatures that could actually be anywhere
except Wayland. (Protocol issues OTOH are Wayland issues.)

The idea of a separate display server in each DE project is still
fairly alien to the masses. Everyone has had just Xorg for so long they
don't even realize that it's not the only X11 server either.


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

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.

v5 is more problematic because of naming conflicts with the stable
version.

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

Yes, flushing should be part of the client main loop, it's even in the
prepare_read API doc. :-)

If someone is sprinkling flush calls in other places, it is highly
likely that they have something fundamentally broken. Maybe their
main / event loop is broken, or they are not returning to it as often
as they should. This applies to clients, but especially to servers, IMO.

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

That seems to be the most important. There are quite some details about
threading, but maybe they would be too much for the time you can have
for the presentation. :-)

Maybe also mention that libwayland-server is completely thread-unsafe,
contrary to libwayland-client which has some thread-safety support.

Well, everything that can be traced back to the same server wl_display
C struct/object must be processed/poked in the same thread. There is no
static data IIRC, but since the C objects heavily reference each other
and there is zero locking, it's pretty safe to just say it's
thread-unsafe.


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/20171208/7a5c87fe/attachment-0001.sig>