On Wed, 10 Jan 2018 14:41:46 +0100 Philipp Kerling <pkerl...@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 <pkerl...@casix.org> wrote: > > > > > Hi Pekka, > > > > > > 2017-12-07 (木) の 09:56 +0200 に Pekka Paalanen さんは書きました: > > > > On Tue, 05 Dec 2017 16:46:41 +0200 > > > > Philipp Kerling <pkerl...@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
pgpBkhSlXsTbL.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel